Мы начинали книгу с рассмотрения того, как взламываются компьютеры, а напоследок поговорим про общие принципы безопасности. Некоторые аспекты, которые мы будем рассматривать, затронут только ОС Linux, а кое-какие советы можно применять к любой операционной системе и компьютеру (серверу) в целом.

В этой главе я развею некоторые мифы о безопасности и покажу множество примеров из собственного опыта.

Почему необходимо уметь строить оборонительные рубежи? Неужели ОС или серверные программы не могут быть изначально защищенными? Вы сами должны помнить об этом постоянно и именно потому, что ОС и программы всегда уязвимы, т.е. имеют погрешности, позволяющие хакеру получить доступ к файлам или возможностям, которых у него быть не должно.

Лазейки есть всегда, потому что программы пишут люди, а им свойственно ошибаться. Получается, что даже в самой защищенной программе есть дыра, просто ее, наверное, еще не нашли. Спросите любого хакера про самое защищенное ядро Linux, и он вам скажет, что последняя версия отличная и не содержит багов. Повторите вопрос через месяц, но на этот раз тоже ядро окажется дырявым и без заплаток, и с ним работать не рекомендуется.

При появлении каждой новой версии ОС мы слышим, как она надежна и безопасна, но через короткое время появляются обновления. Избежать ошибок невозможно, и с этим надо смириться и регулярно устанавливать исправления.

В большинстве случаев я бы не назвал уязвимости ошибками, потому что программы работают верно, просто хакер использует их особым образом и выводит из строя систему. Такие ситуации предусмотреть очень сложно, и задача разработчика максимально их сократить.

Итак, рассмотрим основные принципы безопасности, которые могут понадобиться в нашей повседневной жизни.

 

14.1.1. Ответственность

Первое, с чем необходимо разобраться, — кто должен отвечать за безопасность системы. В большинстве организаций этим занимаются администраторы, и это первая ошибка. Человек, который настраивает систему, может не иметь исчерпывающей информации по безопасности и просто не будет видеть своих ошибок.

В администрировании очень часто возникают классические ошибки обмана зрения. Я написал достаточно много работ и постоянно сталкиваюсь с такой проблемой. Когда вы читаете свой текст, то видите его таким, какой он должен быть, а не то, что есть на самом деле. Например, вы можете написать слово "горад", а читать его как "город" только потому, что так было задумано.

Ошибка в одной букве конфигурационного файла может привести к плачевным последствиям, и администратор ее может не увидеть, потому что воспринимает параметр таким, как надо. Зато любой взгляд со стороны без проблем зацепится за ошибку. Лучше всего, если таким наблюдателем будет специалист.

Администратор должен настраивать и обслуживать систему, а специалист по безопасности обязан проверять настройки и тестировать систему на уязвимости. Конечно же, оба человека должны помогать друг другу и могут быть взаимозаменяемы, но не стоит их объединять в одном лице, особенно в крупных компаниях.

Оплата высококвалифицированных специалистов должна быть достойная, и здесь не стоит экономить, потому что человеческий фактор — самая большая дыра в безопасности.

 

14.1.2. Защищайте только то, что нужно

Многие специалисты по безопасности рекомендуют защищать только то, что нужно. Действительно, зачем охранять мусорную корзину, когда в ней находятся одни только отходы, которые никому не нужны. Тут же вспоминается знаменитый фильм "Хакеры", в котором главные герои залезали в мусорный бак. Что они там искали? Различные документы или бумажки. Нередко пользователи записывают пароль на листочках, или им раздают параметры доступа в виде распечаток, именно это искали хакеры.

То же самое и с файловой системой. Некоторые безобидные папки могут оказаться хорошим материалом для хакера. Однажды я тестировал на безопасность систему, в которой была открыта только одна директория с файлами, содержащими тексты песен группы "Dune". Вроде бы невинная вещь, и что можно сделать через текстовые файлы?

Я запустил подбор пароля для пользователя root и в качестве словаря указал эти файлы, Каково же было мое удивление, когда я увидел, что установленный пароль root — название группы "Dune". Взлом занял всего несколько секунд!!!

Очень часто в открытые папки администраторы выкладывают информацию, связанную с их интересами, и если параметры доступа тоже заданы исходя из этих пристрастий, то и на подбор пароля потребуется не более 5 минут.

С другой стороны, получив хоть какой-то доступ к системе (особенно на запись данных), у хакера появляется возможность повысить свои привилегии аж до администратора. В Интернете все чаще появляются сплоиты, которые позволяют это сделать. Если злоумышленник вообще не имеет доступа к системе, то и взломать ее сложнее.

На данный момент известно не так уж много способов для удаленного взлома, зато, имея локальный доступ к системе, вероятность повысить свои права увеличивается в несколько раз. Защищать компьютер от проникновения по сети проще, и основным способом в этом случае является использование сетевого экрана. Если хакеру все же удалось пробраться, то тут уже все зависит от правильной политики регламентации доступа. Если хоть где-то есть ошибка, то хакер сможет получить права администратора.

Когда злоумышленник пытается удаленно пробиться в систему, защищенную сетевым экраном, то его возможности сильно ограничены еще из-за того, что он слишком мало знает об атакуемой системе. Проникнув внутрь, объем информации сразу увеличивается в несколько раз.

Основными целями, которые подвергаются атакам хакеров, являются:

□ уязвимые программы ОС. Если посмотреть отчеты по безопасности, то вы увидите, что дыры в различных утилитах появляются почти каждую неделю, и программисты с администраторами только и успевают их затыкать;

□ программы сторонних разработчиков. Все программное обеспечение, которое включается в дистрибутив производителем, тщательно тестируется. Сторонние же разработчики осуществляют проверку только на своем дистрибутиве, и нет гарантии, что программа будет также безопасно и стабильно работать со всеми вариантами ОС Linux. К тому же профессионализм некоторых "чужих" разработок оставляет желать лучшего, и мы об этом уже говорили, когда рассматривали безопасность открытого программного обеспечения (см. разд. 1.3);

□ сценарии и программы, написанные администратором системы или программистами вашей организации. Очень часто для расширения возможностей ОС пишутся собственные сценарии (чаще всего используется интерпретатор Perl), и нередко именно они становятся причиной взлома. Только профессионал, хорошо знакомый с принципами безопасности и правилами создания кода, сможет создать защищенный сценарий или программу. Любители и простые администраторы слишком мало внимания уделяют различным проверкам параметров, чем незамедлительно воспользуется хакер.

Итак, разделение на "важно" и "неважно" должно быть. Значимые данные должны защищаться лучше, их надо шифровать и устанавливать за ними более тщательное наблюдение. Но при этом необходимо думать о системе в целом.

Были случаи, когда администраторы один сервер с закрытой информацией защищали и любили, а другой — открывали для всеобщего обозрения и использования. Это правильное решение, но между этими серверами не должно быть доверительных отношений, и имена пользователей и пароли следует делать разными. Но т.к. мы ленивые, то пароль root для всех серверов, чаще всего, один и тот же или отличается незначительно, чтобы легко было запомнить. Если не совершать этой ошибки, то решение с физически разделенными для разных задач серверами является верным решением.

 

14.1.3. Нет поблажек

Допустим, что вы администрируете сервер на крупном предприятии с большим количеством офисов. Это самое сложное с психологической точки зрения. Почему? Сейчас увидите.

Большинство администраторов защищают сеть от внешнего вмешательства. Но по статистике большинство взломов, причем самых жестоких, происходят внутри системы (работниками фирмы, друзьями и т.д.), потому что администраторы не выдерживают натиска друзей и коллег, требующих дать пароль или доступ к определенному ресурсу. Вы не должны поддаваться на такие уговоры. Если предоставить большие привилегии другу, он может наказать вас взломом. Пусть он будет и случайным или просто шалостью, но ликвидация последствий может оказаться достаточно проблематичной.

Безопасность — это не только надежная защита системы от взлома, но и устойчивость к неправильным действиям пользователя. Хотите пример? Их у меня много, но простейший и чаще всего встречающийся — это эффект начальника. Многие администраторы считают, что руководитель или директор фирмы должен иметь все права, чтобы иметь возможность просмотреть любую информацию. Идея хорошая, но реализуется достаточно сложно, потому что начальники, получив доступ на чтение, начинают просить право на запись, чтобы можно было что-то изменить. А это уже намного страшнее, особенно, если шеф не IBM-совместимый и плохо знает компьютер. Именно такие просят максимальные права, и неумелые/случайные действия могут уничтожить все данные. Виноватым сделают вас.

Еще один недостаток повышенных прав для друзей и начальства — невозможность защитить их пароли. Когда только один пользователь (root) имеет максимальные права в системе, то его пароль защитить достаточно просто. Но если таких 10 человек, то за их паролями уследить сложнее. Любой из этих пользователей может выбрать себе слабый по стойкости пароль или просто записать его на бумаге. Благодаря этому хакер может получить привилегированный доступ к системе и натворить бед.

 

14.1.4. Защита рабочего места

Охрана рабочего места является не менее важной, чем защита ОС и ее сервисов. Когда мне пришлось работать программистом в большой компании, в мои обязанности входили: разработка модулей сбора информации с производственного оборудования, настройка и установка сервера с программой в цех и сопровождение ПО. Для каждого компьютера я выбрал разные пароли, которые были сложными для запоминания.

Я хорошо позаботился о безопасности, но через некоторое время, когда пришел снимать копию базы данных на случай краха системы, увидел на мониторе написанный маркером пароль. Возникает вопрос — зачем я мучился и придумывал хитрую комбинацию, когда любой проходящий мимо работник фирмы или даже посторонний мог ее увидеть?

Начинающие пользователи не любят запоминать сложных вещей, поэтому рисуют пароли на мониторе, клавиатуре или на листиках, которые лежат прямо на столе, тогда все попытки обезопасить систему бессмысленны.

Защищать рабочее место нужно так же, как и доступ по сети. Из моей практики могу сказать, что большинство взломов происходят именно из-за безответственного отношения самих пользователей.

Для предохранения рабочего места следуйте следующим рекомендациям:

1. Никогда не записывайте пароли на листиках и других заметных и легко доступных местах. Потратьте немного времени, чтобы запомнить основные кодовые комбинации.

2. Отходя от компьютера, блокируйте клавиатуру утилитами vlock или xlock, или выходите из системы, чтобы в ваше отсутствие никто и ничего не мог делать.

3. Если хакер получил доступ к клавиатуре работающего компьютера, поменяйте пароль текущего пользователя — это дело пяти секунд. Никогда не надейтесь на хранитель экрана, потому что пока он включится, вы потеряете контроль над своей учетной записью. Я отключаю хранитель экрана, чтобы его наличие не смущало меня, а вместо этого выработал привычку всегда блокировать работу компьютера.

4. Если вы используете графический режим, то никогда не держите ярлыки на рабочем столе. На экране могут быть видны только значки по умолчанию, а если поместить туда ссылку на чужой компьютер, с которым вы работаете, то хакер увидит это. Такая информация может сильно развязать руки злоумышленнику.

5. Необходимо разрешать вход в BIOS (Basic Input Output System, базовая система ввода вывода) только с помощью пароля. Если хакер получил физический доступ к компьютеру, то он сможет его перезагрузить в однопользовательском режиме и далее взломать пароль root.

6. Защищайте паролем загрузку ОС в конфигурационном файле LILO. Проблемы загрузчика мы рассматривали в разд. 3.2.

7. Перезагрузка компьютера не должна быть случайной или незапланированной. Отключите в файле /etc/inittab строку, отвечающую за сочетание клавиш ++.

 

14.1.5. Документация по безопасности

Многие считают документацию уделом бюрократов и категорически не пишут никаких инструкций или других руководств. Я сам до поры до времени был таким и предпочитал следить за системой самостоятельно, пока она не стала слишком сложной, что не охватить одному, и не произошел взлом.

Мы рассмотрим много рекомендаций по обеспечению безопасности, и впоследствии многие правила станут для вас родными, — вы будете знать, как действовать во время и после взлома. Но пользователи останутся в неведении.

Рассмотрим простейший пример. Хакер проник в систему и получил исключительные права root. Вы закрываете уязвимость и меняете пароль администратора, но хакер возвращается в систему. Почему? Во время взлома хакер мог украсть файлы /etc/passwd и /etc/shadow и расшифровать пароль (подобрать с помощью специализированных утилит для хранящихся в файле зашифрованных его версий). После взлома все пользователи должны поменять свои пароли. Для решения этого вопроса есть два способа:

1. Самостоятельно сгенерировать пароли и раздать пользователям. В большой организации это удобно, потому что можно быть уверенным, что все пароли изменены, но с передачей могут быть проблемы.

2. Написать инструкцию по безопасности, которая обяжет всех пользователей по первому сигналу администратора сменить свои пароли. Этот документ должен быть прочитан всеми сотрудниками.

Из своей практики могу посоветовать использовать комбинацию этих двух методов: пользователи сами должны сменить пароли, но если этого не произошло в течение 3 часов после сигнала, то пароль меняется автоматически. В этом случае уже пользователи будут бегать к вам, чтобы узнать, как войти в систему.

Помимо этого, в инструкции по безопасности должны быть рекомендации по составлению сложного и длинного пароля, а вы просто контролируйте выполнение.

Через документацию вы можете заставить работников различных служб помогать вам в обеспечении безопасности. Например, администраторы серверов не могут отследить, когда увольняется кто-то из сотрудников. А ведь после ухода уже бывший служащий может отдать свои параметры доступа другому человеку, и он проникнет в систему.

Случаи со взломами, совершенные бывшими сотрудниками, случаются достаточно часто. Я сам неоднократно столкнулся с этим, когда администратор был уволен, но никто не изменил пароли. Через пару дней все файлы на сервере были уничтожены. Я в это время работал программистом в той фирме, и все сотрудники отдела ИТ в срочном порядке восстанавливали данные.

 

14.1.6. Пароли

Не буду повторяться, что пароли должны быть сложными, а поговорим немного о другом.

Все пароли необходимо менять через определенные периоды времени. На своем сайте (а к нему имеют доступ достаточно много человек) я это делаю каждый месяц, потому что в Интернете слишком много хакеров, которые только и ищут легкую добычу.

На серверы я также меняю пароли каждый месяц, а на особо важные — даже каждую неделю. Это сложно, потому что нужно постоянно запоминать новые комбинации, зато более безопасно.

Единственное, что не меняется, — это пароль на вход в Windows на моем ноутбуке. Со своим компьютером я работаю один и никого не подпускаю. Не потому, что боюсь обнародовать что-то важное, а больше опасаюсь случайной потери данных.

Многие хакеры, получая доступ к системе, некоторое время не проявляют никакой активности. Они осматриваются, знакомятся с принципами работы системы и определяются, как сделать, чтобы их не вычислили. Быстрые действия можно ожидать только от того, кто проникает в систему ради уничтожения всех данных, и кому нет смысла уничтожать следы своего пребывания. Слава богу, что таких взломов не так уж и много.

Итак, проникнув в систему, хакер будет незаметно сидеть в ней, и вы можете ничего не заподозрить. Но если каждый месяц меняется пароль, то после очередной смены злоумышленник теряет свои права, и требуется повторный взлом для выявления нового пароля.

Регулярное обновление паролей усложняет подбор. Как это происходит. Многие автоматизированные системы выявления атак могут без проблем определить, когда на отдельную учетную запись авторизуются несколько раз подряд. Чтобы обойти такие системы, хакеры проверяют пароли с определенной задержкой. Это делает взлом дольше, но, в конце концов, даст результат, если пароль несложный и постоянный. Если пароль изменчив, то вероятность успеть его подобрать до очередной смены становится очень низкой.

Чтобы увидеть это на примере, представим, что пароль может содержать только числа. Допустим, что на первоначальном этапе он был равен 7 000 000. Хакер тупым перебором прошел от 0 до 6 000 000, и в этот момент пароль меняется на 5 000 000. Дальнейшее сканирование хоть до миллиарда не даст результата, потому что диапазон, в котором находится новый пароль, уже пропущен.

Второе преимущество от регулярной смены пароля заключается в том, что пока хакер будет подбирать действительно сложный пароль, он уже устареет, и воспользоваться им не удастся.

Как заставить пользователя менять пароли через определенные промежутки времени? Для этого есть утилита chage, которая имеет следующий вид:

chage параметры пользователь

В качестве параметра можно указывать следующие ключи:

□ -m N — минимальное число дней (N) до смены пароля. Указав это значение чуть меньше, чем максимальный период (см. следующий параметр), вы защитите систему от нежелательной смены паролей. Это значит, что если хакер захватит учетную запись, он не сможет изменить пароль. Конечно же, злоумышленник тоже может выполнить команду chage, но только если у него есть права администратора. Три-четыре дня разницы между минимальным и максимальным значением необходимы для того, чтобы пользователь смог сменить пароль, пока он не устарел. Меньше 3 дней нежелательно, потому что существуют выходные, и если срок действия попадет на воскресенье, пользователь не успеет сменить пароль. По умолчанию стоит значение -1, что соответствует отсутствию проверки;

□ -M N — максимальный диапазон в днях (N), в течение которого действует пароль. После этого параметры авторизации считаются недействительными, и пользователь не сможет войти в систему. По умолчанию установлено 99999, что соответствует бесконечности, а значит, пароль никогда не устареет;

□ -d N — дата последнего изменения пароля. Параметр N указывает количество дней, начиная с 1 января 1970 года. Если установить 1000, то получится 27 сентября 1972 года. Чтобы не высчитывать дату в днях, можно указать ее явным образом в формате ГГГГ-ММ-ДД;

□ -Е дата — дата окончания действия пароля;

□ -I N — период в днях, после которого неиспользуемая учетная запись блокируется. Рекомендую указать не менее 3 дней и не более 4 дней, чтобы приостановить действие записи на время отпуска или болезни работника;

□ -W N — количество дней до окончания срока действия пароля, когда пользователю будет выводиться предупредительное сообщение. Нежелательно указывать менее 3 дней, чтобы не попасть на выходные;

□ -l пользователь — информация о времени жизни их пароля. С этим параметром команда может вызываться любыми пользователями. Чтобы получить сведения о пароле root, выполните директиву chage -l root.

Результат выполнения команды имеет следующий вид:

Minimum: -1

Maximum: 99999

Warning: -1

Inactive: -1

Last Change: Feb 04, 2004

Password Expires: Never

Password Inactive: Never

Account Expires: Never

Здесь отображаются следующие значения:

• Minimum — минимальный срок действия пароля;

• Maximum — максимальный период для пользования паролем;

• Warning — количество дней, за которые будет выдаваться предупреждение о завершении срока действия пароля;

• Inactive — максимальное количество дней, в течение которых учетная запись может не активироваться;

• Last Change — последняя дата изменения;

• Password Expires — дата окончания действия пароля;

• Password inactive — дата, когда пароль стал неактивным;

• Account Expires — дата окончания действия учетной записи.

Чтобы задать максимальное количество дней жизни пароля в 60 дней, выполните команду:

chage -М 60 robert

Слишком частая смена паролей приводит к тому, что пользователи просто не успевают запомнить их. Из-за этого сложные комбинации начинают писать на бумаге, чтобы случайно не забыть, или просто меняют пароль на старый. Ваша задача — контролировать замену, и в то же время не стоит заставлять пользователя делать это слишком часто. Период в 2–3 месяца (или 60–90 дней) считается вполне приемлемым.

А какие гарантии, что пароль выбран сложный или пользователь снова не указал старый шифр? В этом нам поможет PAM-модуль pam_cracklib.so, который выполняет основные проверки. Например, нельзя будет установить старый пароль или воспользоваться большей его частью.

Чтобы включить модуль pam_cracklib.so, необходимо добавить в файл /etc/pam.d/passwd следующую строку:

password required pam_cracklib.so retry=5 minlength=8

В этой команде мы заставляем систему использовать библиотеку pam_cracklib.so. Параметр retry задает 5 попыток для ввода нового пароля, а они понадобятся, если пользователь попытается задать слишком простую комбинацию. Параметр minlength задает минимальную длину пароля.

 

14.1.7. BugTraq

Честно сказать, настоящих хакеров в мире не так уж и много. Большинство взломов совершается подростками, которым нечего делать и хочется где-то применить свои силы. Знаний у них не бог весть сколько, поэтому в основном используются уже готовые решения, найденные настоящими хакерами. Это значит, что вы должны следить за новыми методами взлома и всеми появляющимися уязвимостями. Я для этого использую сайт www.securityfocus.com. Здесь регулярно обновляется информация по этим вопросам и предлагаются способы защиты.

Уже давно ходят споры о том, нужны ли сайты наподобие www.securityfocus.com. С одной стороны, они позволяют администраторам получать сведения об уязвимостях, а с другой — хакеры узнают, как можно взломать систему. Я считаю, что такие сайты должны существовать, проблема тут не в этом. Просто большинство администраторов никогда сюда не заходят, а узнают о наличии "тонких мест" в программном обеспечении только тогда, когда их сеть/сайт/сервер взломаны. Даже если вспомнить какую-либо брешь девяностых годов, можно найти в Интернете компьютер или сервер, который содержит эту уязвимость. Я бы таких администраторов увольнял без разговора.

Если вы думаете, что ежедневные проверки обновлений смогут спасти систему, то сильно ошибаетесь. После того, как найдена уязвимость, и до момента выхода обновления проходит некоторое время, и в этот период опасность проникновения на компьютер максимальная. Любой хакер, узнавший метод взлома, может начать штурм, и обязательно добьется успеха. Вы должны раньше него узнать об уязвимости и принять меры по предотвращению вторжения, пока не появится обновление.

Уязвимыми оказываются как сервисы, так и ядро ОС. Если погрешность найдена в программе, то ее нужно обновить, скачав более новую версию с сайта производителя. С ошибками в ОС дело обстоит сложнее. Тут необходимо обновление ядра, что не так уж и просто, если производить операцию из исходных кодов. Но можно облегчить себе задачу, если использовать RPM-пакет, тогда установка будет не намного сложнее, чем любой другой программы.

 

14.1.8. Патчинг ядра

Помимо официальных обновлений ядра существует множество заплаток, написанных сторонними разработчиками (SELinux, lcap, LIDS и т.д.). Все они предназначены для защиты системы на уровне ядра ОС. Например, можно запретить выполнение кода из стека, что сделает невозможным многие атаки, использующие его переполнение. Некоторые заплатки запрещают просмотр каталога /proc, следят за процессами в системе, защищают от сканирования портов и многое другое.

Почему я не рассматривал примеры сторонних патчей ядра более подробно раньше? Большинство из них требуют перекомпиляции ядра и работают не со всеми версиями/ядрами ОС Linux, а также требуют немалых усилий при установке. Безопасность повышается, и это факт, но стабильность может пошатнуться, потому что эти заплатки делаются сторонними разработчиками, а Red Hat просто может их не учесть.

Именно поэтому я не включал обзор этой тему в данную книгу. Но вы должны знать о существовании таких патчей, и может быть возможности какой-то заплатки вам покажутся удобными и помогут в обеспечении безопасности системы. Но любая их установка будет происходить на ваш страх и риск. Вы также должны учитывать, что обновление ядра может вызвать проблемы. К тому же, каждое новое устанавливаемое вами ядро тоже нужно будет патчить.

 

14.1.9. Развитие

Одна из важнейших составляющих эффективного управления — образование. В России проблема повышения квалификации стоит особо остро. Сколько администраторов самоучек? Очень много!!! Да и обучение (особенно в регионах) оставляет желать лучшего.

Многие специалисты в сфере безопасности не имеют специального образования. Я достаточно часто общаюсь с администраторами, и, глядя на компьютер, могу сказать, хороший он или нет. Если на компьютере стоят игры, то на 90% такой администратор свободное время тратит на разборки с монстрами. Если игрушек нет, и софт связан только с профессиональной деятельностью, то такой администратор хороший или может стать таким.

Компьютерные технологии стремительно развиваются, и если свободное время на работе тратить на бег с пистолетом по темным коридорам, то не сегодня, так завтра знания устареют. Нужно постоянно повышать свою квалификацию и осваивать что-то новое.

Специальное образование — это хорошо, но оно дает только базовые знания, которые можно получить из литературы в течение месяца. Более конкретные сведения устаревают еще до того момента, как вы закончите высшее учебное заведение, и без подпитки свежими данными можно превратиться в простого продвинутого пользователя.

Кто хорошо работает, тот должен обязательно отдыхать. Но только надо помнить, что деятельность специалиста по безопасности заключается не только в решении текущих задач, но и в повышении квалификации.

 

Мы уже говорили в разд. 1.4.4 о том, что в локальных сетях очень популярным методом взлома являются программы снифферы, т.е. подслушивание трафика. В Интернете такие программы тоже можно использовать, но здесь задача усложняется, хотя и осуществима. В данном разделе мы рассмотрим теорию реализации атаки с использованием сниффера и поговорим о том, как можно определить его наличие в сети.

Как мы уже знаем, снифферы перехватывают пакеты, которые адресуются другим компьютерам. Так как большинство протоколов создавались на заре становления Интернета и не используют шифрования, то в проходящих пакетах можно увидеть в открытом виде пароли доступа, номера кредитных карт и другую приватную информацию.

Изначально программа сниффер создавалась как помощник в работе администраторов. Но хакеры нашли ей другое применение, и простой анализатор работы сети превратился в мощное оружие взломщика.

Снифферы могут работать в активном или пассивном режиме. В разд. 14.5.2 и 14.5.3 нам предстоит познакомиться с обоими типами, но чтобы наш разговор был более понятным, вам необходимо знать, что такое модель OSI (Open Systems Interconnection, взаимодействие открытых систем).

 

14.5.1. Open Systems Interconnection

Каждый раз, когда вы передаете данные по сети, они как-то перетекают от вашего компьютера к серверу или другому компьютеру. Как это происходит? Вы, наверное, скажете, что по специальному сетевому протоколу, и будете правы. Но существует множество их разновидностей. Какой и когда используется? Зачем они нужны? Как они работают? Вот на эти вопросы я и постараюсь ответить в этом разделе.

Прежде чем разбираться с протоколами, нам необходимо узнать, что такое модель взаимодействия открытых систем, которая была разработана Международной Организацией по Стандартам (ISO, International Organization for Standardization). В соответствии с этой моделью сетевое взаимодействие делится на семь уровней.

1. Физический уровень — передача битов по физическим каналам (витая пара, коаксиальный или оптоволоконный кабель). Здесь определяются характеристики физических сред и параметры электрических сигналов.

2. Канальный уровень — передача кадра данных между любыми узлами в сетях типовой архитектуры или соседними узлами произвольной топологии. В качестве адресов на канальном уровне используются MAC-адреса.

3. Сетевой уровень — доставка (без каких-либо гарантий) пакета любому узлу в сетях произвольной топологии.

4. Транспортный уровень — доставка пакета любому узлу с произвольной архитектурой сети и заданной степенью надежности доставки. На этом уровне имеются средства для установления соединения, буферизации, нумерации и упорядочивания пакетов.

5. Сеансовый уровень— управление диалогом между узлами. Обеспечена возможность фиксации активной на данный момент стороны.

6. Уровень представления — здесь возможно преобразование данных (цифрация, компрессия).

7. Прикладной уровень — набор сетевых сервисов (FTP, E-mail и др.) для пользователя и приложения.

На рис. 14.1 вы можете увидеть, как должна выглядеть классическая сетевая модель.

Рис. 14.1. Сетевая модель OSI

Если вы внимательно прочитали предложенный список, то наверно заметили, что первые три уровня обеспечиваются оборудованием, таким как сетевые карты, маршрутизаторы, концентраторы, мосты и др. Последние три реализуются на уровне операционной системы или приложения. Четвертый уровень является промежуточным.

Как работает протокол по этой модели? Пакет попадает на прикладной уровень, и к нему добавляется заголовок. Затем пакет отправляется на уровень представления. Здесь ему также добавляется свой собственный заголовок, и пакет пересылается дальше. Так до физического уровня, который занимается непосредственно передачей данных.

Другая машина, получив пакет, начинает обратный отсчет. Пакет с физического уровня попадает на канальный, где убирается соответствующий заголовок, затем пакет поднимает выше. Уровень сети отсекает свой заголовок и передает пакет выше, и так до уровня приложения, где остается чистый пакет без служебной информации, которая была прикреплена на исходной машине перед отправкой.

Передача данных не обязательно должна начинаться с седьмого уровня. Если используемый протокол работает на 4 уровне, то процесс трансляции начнется с него, и пакет будет подниматься вверх до физического уровня для отправки. Количество уровней в протоколе определяет его потребности и возможности при передаче данных.

Чем ниже расположен протокол (ближе к прикладному уровню), тем шире его возможности и, соответственно, выше накладные расходы при передаче данных (больше и сложнее заголовок). Рассматриваемые сегодня протоколы будут находиться на разных уровнях, поэтому будут иметь разные возможности.

 

14.5.2. Пассивное подслушивание

Пассивный сниффинг — прослушивание пакетов, которые проходят непосредственно через вашу сетевую карту. Такой метод удобен только при соединении компьютеров через общую шину и в сетях с топологией "Звезда", где центром выступает хаб (см. разд. 5.2).

Использование пассивного сниффинга — самое простое занятие. Все пакеты, которые проходят мимо вашей сетевой карты, проверяются на принадлежность узлу. Сетевая карта сверяет адрес получателя в заголовке пакета со своим MAC-адресом, и если они совпадают, то пакет передается операционной системе для анализа. ОС читает из заголовка порт, на который направлен пакет, и далее определяет программу, открывшую порт для приема информации.

Обработка пакетов идет на уровне сетевой карты. Но эта карта может быть переведена в специальный режим, при котором все пакеты передаются операционной системе, и вы можете их увидеть с помощью специализированных программ. Необходимо заметить, что не все сетевые карты переводятся в этот режим, но, по крайней мере, современные поддерживают такую возможность.

В Интернете и в сетях, где используется Switch, такой трюк не проходит. Сетевая карта видит только свой трафик, т.к. чужие пакеты исключаются на коммутаторах или маршрутизаторах, которые установлены у провайдера. В этом случае на помощь приходит активный сниффинг.

На первый взгляд, прослушивание трафика абсолютно безопасно для хакера, и некоторые начинающие запускают программы сниффинга и сидят с ними целый день в ожидании заветных паролей. Но администратор может и должен определить наличие в сети прослушивания, даже пассивного, и наказать любознательного умельца, пока он не натворил бед.

Начнем с поиска пассивного сниффера. Для его обнаружения необходимо разослать всем компьютерам эхо-запросы (пакеты ping), в которых будет указан правильный IP-адрес, но неверный MAC-адрес. В нормальном режиме сетевая карта проверяет физический адрес, поэтому, увидев неправильное значение, пакет будет отброшен. Если на компьютере сетевая карта переведена в режим просмотра всего трафика, то пакет передается ОС, где сравнивается уже IP-адрес. Так как адрес верный, ОС откликнется. Если эхо-ответ получен, то это явно говорит о том, что на компьютере сетевая карта находится в подозрительном режиме.

Но хакеры не так уж глупы и защищаются сетевыми экранами. Достаточно запретить исходящий ICMP-трафик, и компьютер злоумышленника уже не ответит на ваши запросы, а значит, ничего определить нельзя.

Если на вашем сервере резко повысилась средняя загрузка процессора, то причиной может быть подброшенный сниффер, т.к. в этом случае сетевая карта начинает отдавать операционной системе весь проходящий трафик.

Чтобы узнать, в каком режиме работает ваш сетевой интерфейс, необходимо выполнить команду:

ifconfig -a

Если установлен параметр PROMISC, то сетевая карта работает в "неразборчивом" режиме и может прослушивать трафик.

 

14.5.3. Активное подслушивание

Активные снифферы делают все возможное, чтобы перенаправить чужой трафик на себя. Это достигается с помощью модификации таблиц маршрутизации и обмана сетевого оборудования.

С точки зрения реализации активный сниффер сложнее. Чтобы понять, как он работает, необходимо разобраться, как проходят пакеты на самых низших уровнях. Для передачи пакета в Интернете сетевые устройства оперируют IP- адресами. Когда вы обращаетесь по IP-адресу к какому-либо компьютеру в рамках одного и того же сегмента, используется MAC-адрес, а если адресат находится в другой сети, то пакет направляется на шлюз по умолчанию, который является маршрутизатором или компьютером, перенаправляющим пакеты на другой маршрутизатор, и он уже по IP-адресу найдет нужную сеть. Когда сеть обнаружена, внутри нее пакет следует до получателя по MAC-адресу.

Обман MAC-адреса

Как видите, внутри сети пакеты передаются только по MAC-адресу. Вот тут нам для понимания пригодится модель OSI, которую мы рассматривали в разд. 4.5.1. Сетевая карта, хаб и большинство коммутаторов работают на канальном уровне и оперируют только MAC-адресами. Заголовки других уровней недоступны и непонятны этим устройствам. Маршрутизаторы и коммутаторы разбирают пакет до уровня сети, где есть IP-адрес, т.е. внутри сети без этих устройств пакеты могут передаваться только по MAC-адресу.

Что же получается? В локальной сети, даже если вы отправляете данные на IP-адрес, используется физический адрес компьютера. При работе через Интернет всегда используется IP-адресация. Но просто направить в сеть пакет с IP-адресом нельзя, ведь сетевые карты не работают с IP, а пользователи никогда не указывают MAC.

Как же тогда узнать MAC-адрес получателя? Сначала отправитель пытается выяснить, у какого компьютера установлен IP-адрес в виде XXX.XXX.XXX.XXX. Для этого используется протокол ARP (Address Resolution Protocol, протокол разрешения адресов), который рассылает широковещательный запрос всем компьютерам сети и выясняет, где находится экземпляр с указанным IP-адресом. В этом пакете заполнен только IP-адрес, а вместо искомого MAC-адреса указано значение FFFFFFFFFFFFh, которое сетевая карта должна обработать и обязательно отдать на разборку операционной системе. Вот тут ОС рассматривает пакет на третьем уровне, где работает ARP-протокол, и если в сети есть компьютер с запрошенным IP, то в ответном пакете будет указан его MAC-адрес. Вот теперь мы получили искомый адрес.

А кто мешает нашему компьютеру отвечать на чужие ARP-запросы и представляться участникам сети от чужого лица? Вот и я говорю, что никто. У протокола ARP нет никакой авторизации и проверки достоверности ответа. Значит пакет получит тот компьютер, который откликнется, вне зависимости от его IP.

Но неприятности еще впереди. Получив ответ на ARP-запрос, ОС кэширует результат и при последующих обращениях к IP-адресу не отправляет широковещательный запрос, а использует информацию из ARP-кэша. И вот теперь о самом страшном. Некоторые ОС (не будем указывать пальцем) кэшируют ARP-ответы не только на свои, но и на чужие запросы. Таким образом, злоумышленник может разослать информацию (ARP-ответы) со своим MAC-адресом, но чужими IP, всем компьютерам, и они добавят в кэш неверные записи.

Для просмотра текущего кэша вашей ARP-таблицы можно выполнить команду arp. На экране вы увидите примерно следующий результат:

Address HWtype HWaddress Flags Mask Iface

192.168.77.10 ether 00:03:0D:06:A4:6C C eth0

Наиболее интересными колонками здесь являются:

□ Address — IP-адрес компьютера;

□ HWtype — тип удаленного устройства;

□ HWaddress — MAC-адрес удаленного устройства;

□ Iface — сетевой интерфейс.

Если вам необходимо обратиться к компьютеру с IP-адресом 192.168.77.10, то по этой таблице ОС определяет, что он находится на сетевом интерфейсе eth0, и его аппаратный адрес равен 00:03:0D:06:A4:6C.

Если вы явно видите, что адрес поддельный, то следует избавиться от неверных записей. После этого по MAC-адресу можно найти компьютер злоумышленника.

Для удаления записи необходимо использовать команду arp с ключом -d и IP-адресом. Например, для уничтожения ARP-записи, которая показана выше, необходимо выполнить следующую команду

arp -d 192.168.77.10

Если теперь просмотреть кэш ARP-таблицы, то в результате вы увидите вместо MAC-адреса запись (incomplete):

Address HWtype HWaddress Flags Mask Iface

192.168.77.10 (incomplete) eth0

При работе с кэшем ARP вы должны знать, что записи в нем не вечны. Все, что добавляется в кэш через ARP-протокол, а не вручную, имеет статус Dynamic (динамический). Такие записи через определенное время удаляются. Хакеры знают это, поэтому могут рассылать ARP-ответы с фальшивым MAC-адресом через определенные промежутки времени. Если вы будете просто удалять каждый раз неверные записи из кэша, то эффекта это не даст. Необходимо искать злоумышленника.

Чтобы вам проще было определить поддельные записи, можно использовать протокол RARP (Reverse ARP, обратный ARP), который по известному MAC-адресу запрашивает IP-адрес. В результате вам должны вернуться ответы со всех компьютеров, IP-адреса которых находятся в вашем кэше. Помните, что записей может быть несколько. Например, в моем компьютере на сетевой карте установлено сразу два адреса для одновременной работы в двух логических сетях. Это нормальная ситуация. А вот если ответ от какого-либо IP не получен, то такую запись следует удалить.

Для управления ARP-таблицами в Windows я рекомендую использовать утилиту CyD NET Utils (www.cydsoft.com).

В ОС Windows проводить атаку по подделке MAC-адреса очень сложно. Если вы разошлете ложные ARP-ответы для IP-адреса 192.168.77.10, указав собственный MAC-адрес, то этот компьютер выдаст ошибку с сообщением, что адрес уже используется другим сетевым устройством, и выйдет из сети. Чтобы этого не произошло, не рассылайте широковещательные ARP-пакеты с поддельным адресом. Необходимо целенаправленно обманывать только определенную машину.

Рассылка ARP-пакетов — непростое занятие. Намного легче изменить аппаратный адрес, если это поддерживается вашей сетевой картой. Для этого используется уже знакомая нам утилита ifconfig с ключом hw, после чего нужно указать тип адреса и его новое значение.

С помощью подделки ARP-таблиц легко провести коммутаторы, но не маршрутизаторы, которые работают на 3 уровне, т.е. на уровне IP-адресов. Тут уже нужна фальсификация не аппаратных адресов, а IP-маршрутов. Чтобы сделать это, хакеры взламывают маршрутизаторы и перепрограммируют их на свой лад.

Противостоять подмене ARP-таблиц можно, только если вы используете для организации сети управляемые коммутаторы. В них есть возможность закрепить за каждым портом определенный MAC-адрес компьютера. Это усложнит задачу, но не разрешит ее полностью.

Полное решение проблемы кроется в использовании статичных ARP-записей, которые вы должны вручную прописать на каждом клиентском компьютере. Но в этом варианте кроется неудобство, потому что придется редактировать эти записи после каждого изменения сетевого оборудования на любом из компьютеров. Если где-то поменялась сетевая карта, то и ее MAC-адрес тоже изменится. Для облегчения этой процедуры можно создать сценарий на сервере, который будет заполнять ARP-таблицу нужными значениями. Клиенты должны при старте системы запускать этот сценарий.

Вывод из строя коммутаторов

Как мы уже говорили в разд. 5.2, концентраторы (Hub) — это устройства, которые все пришедшие с одного компьютера пакеты тиражируют на все порты, подключенные к этому хабу. Коммутаторы — интеллектуальные устройства, которые по MAC-адресу маршрутизируют трафик, проходящий через порты. Это значит, что пакеты будет видеть только получатель.

Если ваша сеть построена на основе коммутаторов, то прослушивание трафика становится невозможным. Но у Switch есть одна интересная особенность. Если он не справляется с анализом пакетов, то переключается в режим работы простого концентратора, когда входящие пакеты просто копируются всем подключенным компьютерам.

Задача хакера — загрузить коммутатор так, чтобы тот не успевал справляться с трафиком. Лучше всего это сделать, если засыпать коммутатор пакетами с неверными MAC-адресами. На анализ таких пакетов уходит слишком много ресурсов, и Switch перестает справляться с нагрузкой.

Проблема решается только установкой более мощного оборудования. В настоящее время коммутаторы таких производителей, как 3Com и Cisco, обладают достаточно мощными вычислительными ресурсами и способны преодолеть даже пиковую нагрузку ложных пакетов. Оборудование других производителей мне тестировать не приходилось.

Обман маршрутизатора

Маршрутизаторы тоже можно обманывать, точнее сказать, можно провести компьютер. Допустим, что ваша сеть разбита на несколько подсетей и использует несколько маршрутизаторов. На рис. 14.2 показан пример такой сети.

Рис. 14.2. Сеть с двумя маршрутизаторами

Если компьютер из сети 1 отправляет пакет другому компьютеру своей сети, то, как мы знаем, посылка осуществляется по MAC-адресу, и маршрутизатор не используется. Если пакет предназначен другой сети, то он направляется на шлюз по умолчанию. Допустим, что в качестве шлюза выступает сетевой экран. В этом случае, если компьютер 1 адресует пакет в Интернет, то Firewall просто перенаправляет его в сеть. А что если получателем пакета выступает компьютер из сети 2? Будет ли сетевой экран пересылать его маршрутизатору? Не обязательно. Сетевой экран в таком случае может вернуть ICMP-сообщение с предложением компьютеру самостоятельно работать с маршрутизатором, соединяющим сети 1 и 2.

Так как ICMP-протокол не использует авторизацию и шифрование, злоумышленник самостоятельно может направить такой пакет любому клиенту и попросить его работать не с маршрутизатором, а с его компьютером. В результате пакеты пойдут через компьютер хакера, и он сможет их просмотреть.

Я рекомендую отключить перенаправление маршрутизации. Для этого установите 1 в файле /proc/sys/net/ipv4/conf/all/accept_redirects, выполнив команду:

echo 1 > /proc/sys/net/ipv4/conf/all/accept_redirects

Можно изменить этот параметр и через файл /etc/sysctrl.conf, добавив в нем строку:

nt.ipv4.conf.all.accept_redirection=0

Если в вашей сети только один маршрутизатор, то ничего кроме повышения безопасности не произойдет. Даже если у вас два или более таких устройств, на работе сети это сильно не скажется. Разве что трафик будет идти через два маршрутизатора, а не напрямую.

Так как для проведения атаки необходим ICMP-протокол, то его можно запретить с помощью сетевого экрана, и хакер не сможет направить вам сообщение о перенаправлении маршрутизатора.

 

14.5.4. Перехват соединения

Атака на компьютеры с помощью перехвата соединения была первый раз применена еще несколько десятков лет назад, и до сих пор единственным эффективным методом борьбы с ней является использование шифрования пакетов.

Когда компьютеры по протоколу TCP устанавливают связь друг с другом, на начальном этапе вводятся два счетчика, увеличивающихся с каждым отправленным пакетом. Это позволяет проверять целостность соединения. С помощью сниффера этот счетчик может быть подслушан, что в определенный момент позволит хакеру перехватить соединение и стать его владельцем, общаясь с сервером вместо клиента. Компьютер, который устанавливал соединение, в этот момент теряет связь с сервером.

Опасность атаки заключается в том, что хакер таким образом обходит все механизмы аутентификации. Легальный клиент авторизуется на сервере, а хакер после этого перехватывает соединение на себя и использует его в своих целях.

Проблема незащищенности соединения кроется в устарелости протокола TCP/IP. Его создатели не ожидали, что сеть будут прослушивать, и злоумышленники смогут обойти простую защиту соединений, встроенную в протокол. Вопрос решится с переходом на протокол IPv6.

 

14.5.5. Защита от прослушивания

Несмотря на то, что можно определить, что вас прослушивают, иногда это может оказаться слишком поздно. Пока вы ищете хакера, он может успеть поймать пакет с паролями и взломать систему. Если прослушиванием занимается программа, которая установлена на взломанный компьютер, то можно вычислить только этот компьютер и его владельца, но не факт, что вы найдете самого хакера.

Получается, что бороться с прослушиванием такими методами нельзя. Необходимо сделать так, чтобы этот способ не дал результатов, и хакер перестал даже думать об этом. Полноценное решение проблемы таится в шифровании любого трафика.

Доверяться сети и передавать открытые данные уже нельзя. Прошли те времена, когда сети были только для профессионалов, использующих их исключительно по назначению. В наше время в Интернете можно встретить кого угодно, от ребенка до пенсионера, от школьника до ученого. В сети сейчас работают не только добропорядочные граждане, но и молодые любопытные ребята, и даже преступники.

В разд. 5.2 мы рассмотрели, как можно шифровать трафик любого сервиса. Вы можете закодировать любые соединения и должны это делать, если передается секретная информация.

Но прежде, чем организовывать зашифрованные каналы, необходимо убедиться, что этого не сделали до вас. Нет, я не говорю, что кто-то зашифровал ваш трафик по FTP-протоколу, я имею в виду готовые технологии. Так, для протокола HTTP уже давно существует реализация с поддержкой шифрования — HTTPS. Вы можете использовать протокол HTTP для передачи открытых данных, которые итак доступны для всеобщего просмотра (публичные Web-страницы), а секретную информацию (номера кредитных карт) можно передавать через HTTPS.

Если хакер перехватит зашифрованный пакет, то не сможет его расшифровать без закрытых ключей, которые получить практически невозможно. Единственный способ раскрыть данные — подбор пароля, но это отнимет слишком много времени, и не факт, что перехваченный пакет содержит необходимую злоумышленнику информацию.

 

14.5.6. Практика прослушивания

Прочитав этот раздел, складывается впечатление, что прослушивание сети приносит только беды и является оружием хакеров. Может даже показаться, что производители оборудования должны сделать аппаратную защиту от прослушивания.

Это не совсем так. Программы снифферы разрабатывались для программистов и администраторов и являются очень удобным средством для отладки работы различных протоколов.

Я не буду рассматривать все известные мне программы прослушивания трафика, потому что их много, и каждая из них обладает своими особенностями. Но хочу обратить ваше внимание на мою любимую (и одну из самых мощных) — hunt. С ее помощью можно подслушивать трафик, подменять ARP-записи и даже перехватывать соединения.

Очень популярным, а в некоторых случаях и более удобным, является пакет dsniff. Он включает свыше десяти утилит и может использоваться для решения любых, как администраторских, так и хакерских задач. Подробней о составе этого пакета можно узнать из приложения 2.

 

Одной из самых страшных является DoS-атака. На мой взгляд, это самое глупое, что могли придумать хакеры. Когда не получается взломать сервер, его делают недоступным различными методами, вплоть до бессмысленного замусоривания канала связи. В этом разделе мы и рассмотрим основные из этих способов.

Существует разновидность DoS-атаки — DDoS (Distributed DoS, распределенная DoS), отличается она тем, что штурм производят сразу множество компьютеров.

Самое страшное заключается в том, что от данного типа атаки иногда невозможно защититься, особенно от DDoS. Если на сервер поступает слишком много запросов, то он не успевает их обрабатывать, и не все смогут получить доступ к серверу. Представьте себе, если бы все компьютеры планеты одновременно попытались обратиться даже к самому могучему серверу (кластеру из серверов). Ни один канал связи не сможет пропустить такого количества соединений, даже у таких мощных серверов, как yahoo.com, googIe.com, не хватит мощностей. Таким образом, далеко не все пользователи смогут работать с сайтами.

Давайте разберем основные атаки DoS и DDoS и посмотрим, с какими можно бороться, а с какими — бесполезно. К тому же, нас будут интересовать методы противостояния этим атакам.

 

14.6.1. Ping of Dead

Мы уже знаем, что с помощью утилиты ping можно проверить соединение с удаленной системой (см. разд. 5.1). Для этого используется ICMP-протокол. Когда сервер получает ICMP-сообщение с кодом Echo Request, то он должен ответить таким же сообщением, с тем же количеством данных.

В некоторых ОС обнаружились ошибки обработки ping-пакетов. Просто программисты, которые реализовывали ICMP-протокол, подразумевали, что пользователи будут применять его правильно и не станут посылать слишком большие пакеты. Надежда на добросовестность пользователей обернулась появлением атаки Ping of Dead (Ping смерти). Хакеры формировали такие пакеты, которые сервер обрабатывал неверно и зависал. Наиболее нашумевшая атака вылилась в посылку пакетов размером более 64 Кбайт. Программисты зарезервировали под принимаемые данные только 64 Кбайта, и этого не хватило для приема пакетов. На сервере это может выглядеть как переполнение буфера.

Борьба с такими атаками может быть реализована только средствами сетевого экрана. Можно запретить получение ICMP-пакетов с кодом Echo Request и атака Ping of Dead на вашу систему не принесет результата. А затем обновите ОС.

 

14.6.2. ICMP flood

Когда не получается уничтожить сервер интеллектуальными способами, взломщики начинают использовать flood — засыпание сервера ICMP-пакетами. Вот это самый идиотский вид атаки, но легко загружает канал связи. Для его реализации достаточно половины канала штурмуемой системы.

Допустим, что у сервера есть канал связи с пропускной способностью 64 Кбит/с. Вам достаточно половины, чтобы полностью его загрузить. Для этого непрерывно посылаем на сервер ping-запросы с большим размером пакета. Желательно, чтобы в качестве отправителя стоял не ваш адрес, а любой другой. Если вы своими ping-пакетами создадите нагрузку на канал сервера в 32 Кбита/с, то вторая его половина будет занята ответами на несуществующий или чужой адрес.

Защита от этой атаки такая же, как и от Ping of Dead, а именно запрет ICMP-трафика. Благо этот протокол не очень нужен, особенно входящий из Интернета ICMP-трафик.

 

14.6.3. TCP SYN

У большинства серверов есть ограничение на количество подключений. В некоторых случаях это связано с используемой технологией, но может быть и лимит, определенный в настройках конкретного сервера.

Из названия атаки можно догадаться, что задача хакера — направить на сервер большое количество TCP-пакетов с установленным флагом SYN. Эти пакеты используются для установки подключения к серверу. Таким образом, достигнув ограничения, сервер больше не будет принимать новые подключения со стороны клиентов.

Спрятаться от подобной атаки собственными силами практически невозможно. Вам остается только с помощью сетевого экрана ограничить SYN-пакеты, но от этого защита не станет лучше.

Как временное решение, можно увеличить лимит подключений со стороны клиентов. Нагрузка на сервер от этого не возрастет, ведь хакер только инициализирует свои соединения, но не посылает какие-либо пакеты. Но ограничение в конфигурационном файле существует не всегда. Это может быть следствием используемой программой технологии.

Следующий способ защиты заключается в уменьшении времени действия неактивного соединения. В некоторых программах есть возможность в конфигурационных файлах установить длительность неактивного соединения. Убавив это значение до 10 секунд, сервер не получится загрузить SYN-пакетами. Пока образуется очередь подключений, первые соединения уже будут разрываться. Конечно же, могут возникнуть проблемы и неудобства у добропорядочных пользователей, которым, возможно, придется лишний раз устанавливать соединение с сервером, но, по крайней мере, работа не остановится.

Самая лучшая защита должна быть выполнена программистом. Как минимум, он должен реализовывать в своих программах две возможности: настройку ограничения на количество подключений и разрыв неактивных соединений через указанное в конфигурации время. Необходим запрет на установку нескольких подключений с одного и того же IP-адреса.

 

14.6.4. TCP flood

Эта атака аналогична ICMP flood. Если не помогает смекалка, и хакер не может найти уязвимого места, то начинается засыпание сервера бессмысленными TCP-пакетами. Их эффективность иногда даже ниже ICMP-пакетов. Если в случае использования ping-запросов сервер обязан вернуть пакет с такими же данными, то в TCP-протоколе это не обязательно. Таким образом, канал связи у хакера должен быть идентичным, а то и больше, чем у атакуемой системы.

В случае использования HTTP-протокола можно загрузить сервер даже с маленького канала. Необходимо посылать такие запросы, которые требуют на сервере большой нагрузки. Например, если необходимо вывести из строя поисковую систему, можно направить на сервер множество запросов на поиск особо популярных слов. Если серверные сценарии реализованы неэффективно, то обработка такого задания может занять слишком много времени.

Можно использовать скачивание большого файла по протоколу HTTP. Множество таких запросов при плохой организации кэширования на сервере также могут привести к зависанию.

Но у TCP-протокола есть преимущество. В большинстве сетей внешний ICMP-трафик нейтрализуется сетевыми экранами, а вот TCP-пакеты обязательно остаются открытыми для общедоступных ресурсов, и их блокировать невозможно.

Конечно же, организовать успешную атаку на мощный сервер в одиночку нереально, а вот большим количеством компьютеров можно добиться серьезных результатов.

 

14.6.5. UDP

Ошибки в программах, ориентированных на UDP, наиболее опасны, потому что этот протокол не использует виртуального соединения. По нему пакеты просто отправляются по сети, и нет никаких механизмов проверки достоверности указанных данных. Если при использовании TCP подделать IP-адрес достаточно сложно, то с помощью UDP-протокола это реализуется элементарно.

Благо UDP-протокол на публичных серверах используется редко, есть возможность его запретить с помощью сетевого экрана. Если протокол необходим, то защиту может построить только программист, создав на основе UDP хотя бы какую-то проверку подлинности получаемых пакетов.

 

14.6.6. DDoS

На данный момент можно сказать, что именно за DDoS будущее. Ошибки в программах, которые позволят несколькими пакетами убить сервер, с каждым днем уменьшаются и появляются все реже, потому что программисты теперь больше внимания уделяют безопасности при написании сетевых программ. А вот от DDoS никуда не денешься, и от этой атаки реальной, универсальной и эффективной защиты нет и сложно себе представить.

С другой стороны, реализовать действительно массовую атаку DDoS очень сложно, и крупные компании были даже уверены, что это практически невозможно. Даже очень большая группа хакеров на самых быстрых каналах не сможет получить в свое распоряжение такие вычислительные ресурсы, как у серверов yahoo.com, googIe.com или microsoft.com. Но хакеры находят новые способы. Мало кто из пользователей добровольно отдаст мощность своего компьютера для проведения распределенной атаки на крупные серверы. Чтобы решить эту проблему, хакеры пишут вирусы, которые без разрешения занимаются захватом.

Ярким примером удачной распределенной атаки является червь MyDoom. Этот червь, начиная с 22 августа 2003 года, в течение трех дней атаковал сайт компании SCO со всех зараженных в Интернете компьютеров. Через некоторое время подобную атаку пытались реализовать через вирус MyDoom В, но на серверы компании Microsoft. Вторая атака оказалась менее эффективной, но я это связываю с тем, что меньшее количество компьютеров в Интернете было заражено этим вирусом, поэтому мощности не хватило для проведения полноценного налета, да и код червя был далек от идеала.

Нередко для реализации DDoS хакеры используют захваченные мощные серверы на высокоскоростных каналах связи. Это позволяет злоумышленнику получить необходимые ресурсы для удачной распределенной атаки.

В будущем можно ожидать новые атаки DDoS, которые окажутся более эффективными и оригинальными. Здесь уже администратор будет бессилен, и в данном случае на помощь должны приходить правоохранительные органы.

 

14.6.7. DoS

Если вы уже посещаете бюллетени BugTraq, то должны заметить, что уязвимости, дающие повод для проведения атаки DoS, регулярно появляются в различных сетевых программах. К этой категории очень часто относят любые ошибки переполнения буфера, с помощью которых можно сделать сервер недоступным.

О переполнении буфера мы уже говорили в разд. 14.2 и знаем, что с этими ошибками можно бороться, даже не дожидаясь исправлений программистами. Достаточно только поставить патч на ядро ОС, при котором запрещено выполнять код из стека.

Самое странное, что количество ошибок не уменьшается, они идентичные во многих программах, а иногда совершаются одними и теми же людьми. В настоящее время существует множество книг и документов, в которых описаны все проблемы, связанные с переполнением буфера. И несмотря на это программисты продолжают совершать ошибки. Это говорит только о низком качестве образования.

Мне кажется, что качество программ падает из-за широкого распространения офшорного программирования, особенно если используются специалисты из малоразвитых стран, где и уровень подготовки низкий, и работники готовы получать мизерную зарплату, и, как следствие этого, — невозможность создать действительно качественный код. Из-за этого администраторам приходится сталкиваться с одними и теми же задачами.

Проблема может решиться, когда разработчики программного обеспечения начнут использовать более квалифицированные людские ресурсы.

ОС Linux поставляется в исходных кодах, и абсолютно любой доморощенный программист может вносить изменения. Когда она создавалась множеством энтузиастов, то ошибок было очень много, потому что отсутствовал четкий контроль.

В настоящее время уже мало дистрибутивов, выпускающихся стихийными группами программистов. Все, кто захотели делать качественные продукты, организовали фирмы. Теперь уже изменения, внесенные программистом- одиночкой, попадут в дистрибутив, только если его разработчик решит, что код безопасен и полезен для пользователей. Благодаря этому надежность Linux повышается, чего нельзя сказать об отдельных ее компонентах.

 

14.6.8. Защита от DoS/DDoS

Самая эффективная защита от атак DoS, проводимых через ошибки в программах, — это своевременное обновление этих программ. А вот если хакер направил свои усилия на полное поглощение ресурсов сервера, то в данном случае защититься сложно, но необходимо сделать все возможное, чтобы усложнить задачу злоумышленнику.

Сначала необходимо определить самое слабое место сервера. Для этого можно искусственно заставить его работать на максимальной нагрузке. Это можно сделать с помощью большого количества пользователей, которые будут обращаться к серверу, или написать специализированную программу, эмулирующую эту ситуацию.

Во время пиковой нагрузки необходимо проследить, каких ресурсов не хватает компьютеру. Обратите внимание на следующие компоненты:

□ пропускную способность сети;

□ пропускную способность сетевого оборудования;

□ загрузку процессора;

□ нагрузку на жесткий диск;

□ загрузку оперативной памяти.

Определите самые узкие места вашей системы, чтобы увеличить производительность. Нет смысла наращивать внешние каналы связи до 100 Мбит/с, если ваша внутренняя сеть работает только на скорости 10 Мбит/с. Это излишняя трата денег, а проблема останется. Хакеру достаточно будет направить на сервер любой трафик, чтобы забить 10 Мбитный канал мусором, и ресурсов вашей внутренней сети не хватит для обработки такого объема данных. Именно поэтому очень важно правильно определить слабое звено в вашей системе.

Настройте сетевые интерфейсы и параметры ОС на максимальную производительность (см. разд 14.11). Это значит, что не должно быть лишних затрат, особенно сетевых. Понизить расходы на обработку сетевых пакетов можно с помощью полного запрета ICMP-трафика.

 

Для эффективной защиты сервера очень важно вовремя определить, что сервер был взломан. Чем раньше вы узнаете о проникновении в систему хакера, тем скорее сможете отреагировать и предотвратить печальные последствия. Помните, взломы бывают всегда и с любой системой, но вы должны уметь их раскрывать.

Как можно выявить хакера? Существует очень много методов, и сейчас мы рассмотрим наиболее интересные и эффективные.

 

14.9.1. Осведомлен, значит защищен

Очень часто я использую чрезвычайно эффективный, но сложный в реализации метод — информирование при запуске потенциально опасных программ. Сложность заключается в том, что надо уметь программировать под Linux хотя бы на каком-нибудь языке. Лучше, если это будет С, но можно и Perl. В крайнем случае, подойдет умение писать сценарии (командные файлы).

Итак, в чем заключается мой метод? Войдя в систему, хакер всегда оглядывается и старается найти способ укрепиться в системе, чтобы оставаться долгое время незаметным для администратора. Для этого взломщик чаще всего выполняет команды who, su, cat и др. Ваша задача установить на них ловушки. Например, можно изменить код программы su так, чтобы сразу после ее выполнения администратору направлялось письмо.

Получив сообщение о том, что была выполнена опасная команда, и она запускалась не администратором, есть повод проверить систему на наличие в ней постороннего.

Если вы не умеете программировать, можно обойтись и средствами самой ОС. Допустим, что вы хотите получать сообщения каждый раз, когда выполняется команда who. Взломщик часто выполняет такую директиву, когда входит в систему, чтобы узнать, есть ли там администратор. Определить место расположения программы можно командой:

which who

В результате вы должны увидеть путь типа /usr/bin/who.

Для начала запоминаем права на файл, выполнив команду:

ls -al /usr/bin/who

Для данной программы должны быть права -rwxr-xr-x, что соответствует числу 755.

Теперь необходимо переименовать файл /usr/bin/who в /usr/bin/system_who. Это можно сделать следующей командой:

mv /usr/bin/who /usr/bin/system_who

Меняем права доступа:

chmod 755 /usr/bin/system who

Теперь, чтобы выполнить команду who, нужно использовать имя system_who. Но скопированный файл может стать неисполняемым, поэтому второй командой мы восстанавливаем права.

Затем создаем заглушку для программы who. Это будет файл с именем who, в директории /usr/bin. Когда хакер будет выполнять команду who, то будет запускаться наш файл. Для этого выполним команду:

cat /usr/bin/who

Теперь все команды, вводимые с консоли, будут записываться в файл /usr/bin/who. Наберите две строки:

/usr/bin/system_who

id | mail -n -s attack root@FlenovM

После этого нажмите сочетание клавиш + и измените права на созданный нами файл /usr/bin/who, установив значение 755.

Выполните команду who. Все вроде нормально, но если проверить почту, то в вашем ящике будет лежать новое письмо с заголовком "attack" (рис. 14.3), и в нем будут находиться параметры (все, что вернет команда id) пользователя, выполнившего команду. Это из-за того, что запустилась не системная команда, а наш файл, который содержит две строки:

□ /usr/bin/system_who — сначала запускаем системный файл who, который мы переименовали, чтобы взломщик ничего не заподозрил;

□ id | mail -n -s attack root@FlenovM — выполняется команда id, а результат направляется с помощью почтовой программы mail в почтовый ящик root@FlenovM. Ключ -s задает заголовок письма. Ключ -n предотвращает чтение файла /etc/mail.rc. Я рекомендую указывать только эти атрибуты, чтобы на экране не появлялось лишней информации, и взломщик ничего не заподозрил. Хакер не должен знать, что программа отправила администратору какое-нибудь сообщение.

Рис. 14.3. Пример сообщения об атаке

Таким образом, можно подменить все опасные программы, которые должны быть недоступны простым пользователям.

Хакеры чаще всего не проверяют утилиты, которые запускают, а ведь угрозу можно увидеть, если выполнить команду:

cat /usr/bin/who

Вот тут и проявляется недостаток использования сценариев — их можно просмотреть. Программы, написанные на языке С и откомпилированные в исполняемый файл, при просмотре обнаруживают абсолютно ни о чем не говорящий мусор.

 

14.9.2. Ловля на живца

В разд. 4.11 мы затронем тему построения сети, где публичные ресурсы вынесены на самостоятельные серверы и защищаются отдельно от основной сети. Мы уже коснулись вопроса создания серверов-приманок, и сейчас настало время поговорить об этом более подробно.

Администраторы очень любят оставлять приманки для хакеров, потому что они позволяют идентифицировать злоумышленника на начальном этапе. Эта технология даже получила название honeypot (горшок меда). Как это работает? В сети устанавливается один или несколько компьютеров, в которых изначально заложены ошибки конфигурирования или легкие для подбора пароли. Основная задача этого комплекса — отслеживание обращений извне и регистрация любых взломов.

На рис. 14.4 приведена схема классической honeypot-сети. От Интернета ее отделяет сетевой экран, за которым находится публичная сеть (общедоступные ресурсы и подставные серверы/компьютеры). Далее идет второй сетевой экран, который защищает и скрывает приватную сеть.

Рис. 14.4. Построение honeypot-сети

Как только хакер попадает в капкан, администраторы начинают идентификацию и его поиск. Пока злоумышленник пытается проникнуть далее в хорошо защищенную сеть, специалисты по безопасности уже успевают прийти к нему домой и физически остановить нездоровое любопытство.

Чтобы ваш капкан не ловил всех подряд и не давал сложных срабатываний, его защита должна быть достаточной, дабы сервер нельзя было сломать программами, автоматизирующими поиск уязвимостей. Иначе число ежедневно пойманных в ловушку хакеров будет исчисляться сотнями, а то и более, ведь количество сканирований популярного ресурса велико.

Я настраиваю свои honeypot-серверы на максимальную безопасность, просто сетевой экран, который их защищает (на рис. 14.3 это Firewall 1), пропускает практически любой трафик.

Это позволяет решить сразу несколько потенциальных проблем:

□ не вызывает подозрений у хакера. Слишком открытые серверы с дырявыми сервисами насторожат профессионала, и он не будет трогать такие компьютеры;

□ уменьшается количество срабатываний системы на каждого начинающего хакера, который случайно нашел программу для взлома;

□ позволяет выявлять атаки, которые еще неизвестны специалистам по безопасности, и защищаться даже от них. Если сервер с правильными настройками взломан, значит, компьютеры за пределами второго сетевого экрана тоже уязвимы, но вы еще не знаете об этой лазейке или могли совершить ошибку в конфигурировании.

Как только вы заметили взлом поддельного сервера, выполняются следующие шаги:

□ анализируется уязвимость, через которую проник хакер. Найдя ошибку в конфигурировании или дырявый сервис, необходимо отыскать заплатку и установить ее на компьютеры защищенной сети, чтобы хакер после взлома второго сетевого экрана не смог воспользоваться этой уязвимостью;

□ выясняется источник угрозы, IP-адрес хакера, и вся найденная информация сообщается в правоохранительные органы.

Так как на honeypot-компьютерах сервисы не обрабатывают, а только эмулируют реальные подключения пользователей, то для таких серверов нет необходимости устанавливать мощное оборудование. Достаточно устаревшего железа, которое вы уже давно не используете. В любой организации кабинет администратора завален старыми системными блоками, которые лежат только как запасные части.

Если у вас нет старых компьютеров, то в honeypot можно превратить и серверы, которые используются в качестве публичных. В принципе, каждый публичный сервер итак должен содержать мощные системы журналирования и мониторинга, и от honeypot их должно отличать отсутствие заведомо открытых уязвимостей и легких паролей.

Чтобы хакер ничего не заподозрил и обратил внимание на подставные компьютеры, одной защиты мало. Необходимо, чтобы honeypot создавали видимость действия и обрабатывали какой-либо трафик. Для этого могут быть написаны специальные утилиты, которые с определенным интервалом производят соединения между подставными компьютерами, имитируя работу пользователей. Компьютер, который находится в сети и ничего не делает, вызовет подозрение, и его будет ломать только "чайник".

 

Очередной идиотизм, который могли придумать хакеры, — это подбор паролей. Когда взломщик не может изобрести ничего оригинального, он запускает подбор паролей. Об этом мы уже говорили в разд. 1.1.7, но тогда мы затронули эту тему только вскользь, а сейчас поговорим более подробно. Нам предстоит свести всю отрывочную информацию, которую мы получали в предыдущих главах, в одно целое и узнать еще много нового по этому вопросу.

 

14.10.1. По словарю или все подряд

Существует два метода подбора паролей: по словарю и полный перебор всех возможных вариантов. Рассмотрим каждый из них.

Подбор по словарю. В этом случае хакер сначала готовит файл с наиболее часто используемыми для паролей словами. Затем запускается программа подбора паролей, которая последовательно проверяет все термины из указанного словаря.

Преимущество этого метода состоит в том, что пароль может быть найден достаточно быстро, если он простой и есть в словаре. Взломщик для подбора может использовать, например, словарь английского языка, и количество возможных вариантов не превысит 20 000 слов (я имею в виду наиболее часто используемые).

Задача хакера — составить как можно более эффективный словарь, который при этом может быть и незначительного размера. Для этого сначала собирается вся возможная информация об администраторе: имя и фамилия его и родственников, день рождения, клички домашних животных, интересы, любимые фильмы, музыка и т.д. Полученные данные добавляются в начало словаря. Все исследовательские конторы пришли к одному и тому же выводу, что большинство людей выбирают в качестве пароля имена своих любимых собачек, кошечек, знаменательные даты, номера телефонов, а чаще всего что- то связанное с хобби. Хорошо подобранный словарь может сломать практически любую систему, т.к. всегда найдутся неопытные пользователи с такими паролями.

С другой стороны, если использованы все рекомендации по подбору пароля (длинный и сложный, состоящий из букв и символов, да еще с использованием разного регистра), то вероятность того, что такая комбинация окажется в словаре хакера, стремится к нулю. И поэтому время, затраченное злоумышленником, окажется зря потерянным.

Полный перебор. В этом случае программа последовательно перебирает все возможные комбинации букв, цифр и символов в различных регистрах.

Количество вариантов при таком алгоритме исчисляется миллиардами и прямо пропорционально зависит от длины пароля.

Метод дает 100% гарантию удачного подбора, но реализация может отнять недели или даже месяцы. Если администратор системы ежемесячно меняет пароли, то пока хакер занимается подбором, результат уже устаревает.

 

14.10.2. Удаленно или локально

Подбор паролей разделяют на удаленный и локальный. В первом случае хакер пытается подключиться к компьютеру по сети с разными паролями. Это наиболее опасный для него метод, потому что каждая неверная попытка регистрации записывается в журнал безопасности. Если вы хотя бы иногда заглядываете туда, то уже на раннем этапе сможете найти злоумышленника и предотвратить подбор с помощью запрета подключения с IP-адреса хакера. Есть еще одна проблема — подбор осуществляется к определенному сервису, но нет гарантии, что другая программа тоже будет использовать этот пароль. Кроме того, большинство сервисов имеют настройки, лимитирующие попытки входа. И если хакер не уложится в это ограничение, то соединение разрывается, и его приходится восстанавливать. Каждое подключение — это лишние затраты времени, которые увеличивают время подбора даже по словарю.

Для того чтобы подбор оказался долгим занятием, в некоторых сервисах есть возможность при неправильном указании параметров доступа искусственно делать задержку между попытками ввода. Ярким примером является сама ОС. Попробуйте при регистрации в Linux указать неверный пароль или имя пользователя. ОС будет производить проверку намного дольше, чем при указании правильных параметров. Чем больше задержка, тем больше времени необходимо хакеру для подбора пароля.

Но это препятствие довольно просто обойти. Достаточно запустить несколько потоков подбора, которые будут параллельно подключаться к серверу.

Наиболее эффективный метод защиты в этом случае — запрет подключения с IP-адреса к серверу с помощью сетевого экрана. Если вы заметили, что кто-то пытается подобрать пароль, немедленно определите IP-адрес злоумышленника и добавьте запрещающий фильтр в сетевой экран.

Из-за сложности подбора пароля хакеры стремятся получить доступ к файлу /etc/shadow и скачать его на свой компьютер, чтобы работать с ним локально. В этом случае операция происходит намного быстрее по следующим причинам:

□ хакеру становятся известны реальные имена пользователей, которые зарегистрированы на сервере;

□ защита сервера уже не может ничем помочь, потому что вы потеряли контроль над паролями;

□ т.к. пароли хранятся в файле в зашифрованном виде, достаточно один раз зашифровать его и сравнить со всеми кэш-суммами. Чем больше в файле записей, тем больше вероятность, что хотя бы один пароль подойдет;

□ в больших файлах паролей существует вероятность, что хотя бы один пользователь задал в качестве пароля регистрационное имя.

Локальный взлом намного быстрее и безопаснее, единственная проблема заключается в том, как получить файл /etc/shadow. Этот файл доступен для чтения и записи только администратору root, а все остальные пользователи не могут его увидеть.

 

14.10.3. Защита

Защиты от подбора пароля в принципе нет и не может быть. Если хакер получит доступ к файлу /etc/shadow, то можно считать, что пароль у него в руках. Но если следовать следующим правилам, то можно избежать взлома:

□ меняйте пароли каждый месяц. Если хакер взламывает систему удаленно, то это может сделать подбор невыполнимым. Если взлом происходит локально, то пока хакер подберет пароль, он уже изменится;

□ проверяйте свои пароли на стойкость от подбора по словарю. Если найдено несоответствие критерию, заставьте пользователя сменить пароль;

□ устанавливайте сложные и длинные пароли, чтобы подбор по словарю стал невозможным;

□ защищайте файл /etc/shadow. Если файл /etc/passwd нужен для чтения всем пользователям для нормальной работы множества утилит, то /etc/shadow необходимо охранять всеми возможными средствами;

□ следите за журналом безопасности на предмет появления большого количества записей о неверном входе в систему.

Соблюдая эти правила, вы понизите вероятность взлома вашей системы методом перебора паролей.

В разд. 2.6 мы говорили о необходимости создания сложных паролей и рассмотрели некоторые рекомендации по этому вопросу. А сейчас я хочу предложить вам для этого еще один интересный метод:

□ создайте файл pass.txt с текстом, который нужно использовать в качестве пароля, например: echo "password" >> pass.txt;

□ шифруем файл с помощью OpenSSL. Для этого выполняем команду: openssl des -in pass.txt -out pass.txt.s. Ключ, который запросит программа для шифрования, не имеет значения, можно даже использовать слово password;

□ просмотрите содержимое файла pass.txt.s. В нем будет зашифрованный текст, который вы записали в файл pass.txt. Выберите читаемые символы и используйте их в качестве пароля. Такое нарочно не придумаешь, поэтому программы подбора по словарю будут бессильны, останется только полный перебор.

Отличным методом защиты от удаленного подбора может быть модульная аутентификация, которую мы рассматривали в разд. 3.3. Среди РАМ есть очень удобный в защитных целях модуль /lib/security/pam_tally.so. Он позволяет блокировать доступ после определенного количества попыток входа в систему. Рассмотрим использование модуля на примере авторизации в Linux, настройки которой находятся в файле /etc/pam.d/login. Для ограничения попыток ввода паролей добавим в этот файл следующую строку:

account required /lib/security/pam_tally.so deny=5 no_magic_root

В качестве аргумента модулю передается параметр deny, который равен 5. Это значит, что после этого количества попыток учетная запись блокируется. Число 5 является наиболее оптимальным. Меньшие значения приведут к проблемам, когда пользователи по несколько раз ошибаются при вводе своего пароля. Ну а если пяти попыток не хватило исправиться или вспомнить пароль, то далее идет уже подбор случайным образом, что надо запретить.

 

14.10.4. John the Ripper

Теперь рассмотрим на практике, как происходит подбор паролей. Это необходимо, чтобы понять технологию и уметь использовать ее самостоятельно для тестирования стойкости паролей ваших пользователей.

John the Ripper — самая популярная программа для взлома паролей, которая завоевала сердца большинства хакеров и администраторов. Она поддерживает основные алгоритмы шифрования MD5, DES и Blowfish.

Чтобы подобрать пароли, для начала необходимо выполнить следующие команды:

unshadow /etc/passwd /etc/shadow > pass.txt

jhon -incremental pass.txt

С помощью первой директивы мы получаем файл pass.txt, в котором находятся соответствия имен пользователей и паролей. Этот файл можно создать и вручную, перенеся пароли из файла /etc/shadow в файл /etc/passwd, но это занятие не для слабонервных, поэтому лучше довериться программе.

Вторая команда запускает полный перебор паролей. Если у вас есть файл со словарем, то для его использования выполните следующую команду:

jhon -wordfile:filename pass.txt

В данном случае filename — это имя файла словаря.

В ОС Linux уже есть словарь, который находится в файле /usr/share/dict/words. На заре становления Интернета самый знаменитый вирус Морриса, благодаря подбору паролей по словарю, встроенному в ОС Unix (в те времена Linux еще не было), смог взломать множество систем и заразить самое большое число компьютеров для своего времени. Для того чтобы использовать встроенный словарь, выполните команду:

jhon -wordfile: /usr/share/dict/words pass.txt

На сайте http://packetstorm.sequrity.com есть большая коллекция словарей, которую можно использовать для тестирования своей системы на сложность паролей. Если с помощью такого лексикона вы подберете пароль для одной из своих учетных записей, то поверьте мне, то же самое сделает и хакер.

Если нажать любую клавишу, то на экране будет отображена информация о ходе подбора. Для прерывания программы необходимо нажать сочетание клавиш +. Для продолжения процесса подбора можно выполнить команду:

jhon -restore

Чтобы просмотреть пароли, которые подобрала программа, необходимо выполнить следующую директиву:

jhon -show pass.txt

 

В течение всей книги мы говорили о безопасной и эффективной настройке ОС Linux и ее сервисов. В данном разделе подведем итог всему сказанному ранее и рассмотрим несколько новых параметров, которые могут сделать систему еще быстрее и надежнее. Эти установки уже относятся к более тонким, поэтому я оставил их напоследок.

Мы уже говорили о том, что лучшим средством повысить безопасность и производительность является загрузка только самого необходимого. От этого напрямую зависит использование памяти и нагрузка на процессор.

После того как вы определились со списком загружаемых сервисов и сократили их до минимума, необходимо позаботиться о настройке каждого из них с учетом целесообразности использования. Здесь опять вступает в дело минимизация возможностей. Например, сервис Apache загружает множество различных модулей, абсолютно ненужных для большинства сайтов.

Каждый лишний модуль — это очередной удар по производительности и безопасности. Закончив с этим, переходим к более тонким настройкам.

 

14.11.1. Параметры ядра

Для начала откроем конфигурационный файл /etc/sysctl.conf. В нем находятся параметры ядра. Пример файла можно увидеть в листинге 14.1.

Листинг 14.1. Конфигурационный файл /etc/sysctl.conf

# Kernel sysctl configuration file for Red Hat Linux

# Конфигурационный файл ядра для Red Hat Linux

# For binary values, 0 is disabled, 1 is enabled.

# See sysctl(8) for more details.

# Для бинарных значений, 0 - это отключен, а 1 - включен.

# Смотрите man sysctl для получения дополнительной информации

# Controls IP packet forwarding

# Контролирует переадресацию IP-пакетов

net.ipv4.ip_forward = 0

# Controls source route verification

# Контроль проверки маршрутизации от источника

net.ipv4.conf.default.rp_filter = 1

kernel.sysrq = 1

kernel.core_uses_pid = 1

#net.ipv4.tcp_ecn = 0

kernel.grsecurity.fifo_restrictions = 1

kernel.grsecurity.linking_restrictions = 1

# audit some operations

# аудит некоторых операций

kernel.grsecurity.audit_mount = 1

kernel.grsecurity.signal_logging = 1

#kernel.grsecurity.suid_logging = 1

kernel.grsecurity.timechange_logging = 1

kernel.grsecurity.forkfail_logging = 1

kernel.grsecurity.coredump = 1

# lock all security options

# блокировка всех опций безопасности

#kernel.grsecurity.grsec_lock = 1

Что представляют собой параметры, которые вы можете видеть в файле? Попробуем разобраться на примере net.ipv4.tcp_ecn. На самом деле это путь к файлу относительно каталога /proc/sys, в данном случае это файл /proc/sys/net/ipv4/tcp_ecn. Как видите, я просто заменил в параметре все точки на символ слэш и прибавил результат к подкаталогу /proc/sys. Выполните следующую команду, чтобы просмотреть содержимое файла:

cat /proc/sys/net/ipv4/tcp_ecn

В результате на экране вы должны увидеть 0 или 1. Это и есть значение параметра.

Но корректировать файл вручную нет смысла. Для изменения лучше использовать команду:

sysctl -w имя_параметра = значение

С помощью этой же команды можно просматривать значение параметров ядра:

sysctl имя_параметра

Например, следующая директива отобразит значение параметра

net.ipv4.tcp_ecn:

sysctl net.ipv4.tcp_ecn

В результате вы увидите то же значение, что и при просмотре файла /proc/sys/net/ipv4/tcp_ecn напрямую. Большинство параметров имеют логический тип, т.е. могут быть равны 0 (отключено) или 1 (включено).

Рассмотрим параметры, которые нужно изменить, а если их нет в файле, то добавить:

□ net.ipv4.icmp_echo_ignore_broadcasts — игнорировать широковещательные эхо-ICMP-пакеты (параметр включен);

□ net.ipv4.icmp_echo_ignore_all — запретить эхо-ICMP-пакеты (значение 1). Используйте этот параметр, если не хотите связываться с сетевым экраном. Запрет эхо-пакетов уменьшит трафик, хотя и незначительно, и при этом делает неэффективными любые атаки с помощью ping;

□ net.ipv4.conf.*.accept_redirects — разрешить принимать перенаправления маршрутизатора. В разд. 4.5.3 мы говорили о том. что это небезопасно и может позволить хакеру обмануть маршрутизатор и прослушать трафик атакуемой машины;

Вместо символа звездочка может быть любое имя директории. Дело в том, что в каталоге net.ipv4.conf находится несколько подкаталогов — по одному для каждого сетевого интерфейса. В вашей системе должно быть как минимум 4 директории со следующим распределением содержащейся в них информации:

 • all — конфигурационные файлы, которые влияют на все интерфейсы;

 • default — значения по умолчанию;

 • eth0 — конфигурационные файлы первой сетевой карты;

 • lo — конфигурационные файлы петлевого интерфейса loopback.

Звездочка указывает на то, что параметр должен быть назначен всем интерфейсам. В большинстве случаев достаточно заменить "*" на имя директории all, но иногда приходится подставлять все существующие директории;

□ net.ipv4.conf.*.secure_redirects — позволить принимать сообщения от шлюза по умолчанию о перенаправлении маршрутизатора. Параметр может быть включен, только если в вашей сети действительно более одного маршрутизатора, иначе лучше запретить;

□ net.ipv4.conf.*.send_redirects — разрешить компьютеру, если он является маршрутизатором, отправлять сообщения о перенаправлении пакетов. Если в сети несколько маршрутизаторов, то параметр можно включить, чтобы распределить нагрузку между ними и не пытаться пропускать весь трафик через основной шлюз;

□ net.ipv4.conf.*.accept_source_route — позволить принимать пакеты с маршрутизацией от источника. В разд. 14.12.2 мы поговорим об этом, а сейчас необходимо знать, что такие пакеты могут стать причиной обхода вашего сетевого экрана. Запретите этот параметр;

□ net.ip_always_defrag — дефрагментировать все приходящие пакеты. Так уж повелось, что сетевой экран проверяет только первый пакет, а все остальные считает разрешенными. Хакер может обойти сетевой экран, прибегая к разбивке посылки на части (см. разд. 4.13). Если установить этот параметр, то все входящие пакеты будут дефрагментированы, и обход сетевого экрана этим методом станет невозможным;

□ net.ipv4.ipfrag_low_thresh — определяет минимальный объем памяти, который выделяет ОС для сборки фрагментированных пакетов. Чем больше это значение, тем меньше будет манипуляций по выделению памяти. По умолчанию используется число 196608. Слишком большое значение отнимет лишнюю память и может привести к эффекту, при котором для обработки данных не хватит ресурсов сервера. Я бы оставил это значение по умолчанию;

□ net.ipv4.ipfrag_high_thresh — определяет максимальное количество памяти (по умолчанию 262144), выделяемое для сборки фрагментированных пакетов. Если значение превышено, то ОС начинает отбрасывать пакеты. Таким образом, хакер может закидать сервер большим количеством мусорных сообщений, и тот больше не будет выполнять дефрагментацию;

□ net.ipv4.ipfrag_time — определяет время хранения фрагментированных пакетов в кэше. По умолчанию используется значение 30 секунд. Это очень много, за это время хакер сможет забросать весь кэш. В случае атаки на систему следует понизить это значение до 20, а то и до 10 секунд;

□ net.ipv4.tcp_syncookies — продолжая тему DoS, я рекомендую включить этот параметр, чтобы защититься от атаки SYN flood, при которой на сервер направляется большое количество пакетов с запросом на соединение. Хакер устанавливает в пакетах ложный обратный адрес, и сервер ожидает соединения от несуществующих или ничего не подозревающих компьютеров. Таким образом, легко превышается максимально допустимое количество подключений.

Параметров ядра очень много, и рассматривать все мы не будем. Советую обратиться к документации.

 

14.11.2. Тюнинг HDD

Долгое время в ОС Linux для доступа к жесткому диску была отключена даже поддержка DMA (Direct Memory Access, прямой доступ к памяти), хотя эта возможность существует почти во всех материнских платах еще со времен первых компьютеров с процессором Pentium. ОС не использовала DMA в целях совместимости с более старыми компьютерами, поэтому функцию приходилось включать самостоятельно.

В современных дистрибутивах поддержка DMA уже включена, но работу винчестера можно еще оптимизировать. Для тестирования и настройки жесткого диска используется утилита hdparm. Для определения скорости работы диска выполните команду с ключом -t:

hdparm -t /dev/hda

В ответ вы получите сообщение типа:

Timing buffered disk reads: 64 MB in 3.02 seconds = 21.19MB/sec

Попробуйте в качестве параметра указать раздел:

hdparm /dev/hda2

В результате будут выведены параметры жесткого диска:

/dev/hda2:

multcount    = 128 (on)

IO_support   = 0 (default 16-bit)

unmaskirq    = 0 (off)

using_dma    = 1 (on)

keepsettings = 0 (off)

readonly     = 0 (off)

readahead    = 8 (on)

geometry     = 2088/255/63, sectors = 32515560, start = 1028160

В этой информации есть много интересного:

□ multcount — количество слов, читаемых за один такт. Эта опция должна быть включена, и желательно установить значение 128. Это может повысить производительность на 30–50%. Для изменения значения используется ключ mX, где X — это устанавливаемое значение;

□ using_dma — режим DMA. Для включения используется ключ d1;

□ IO_support — режим доступа к диску. По умолчанию стоит 16-битный, но сейчас уже можно использовать 32-битный режим. Для включения используется ключ c3.

Это основные три параметра, которые могут реально повысить производительность. Итак, давайте установим значения в соответствии с указанными выше рекомендациями. Для этого выполните команду:

hdparm -m128d1c3/dev/hda

Как видите, мы просто перечислили все ключи и указали диск /dev/hda. Обратите внимание, что при определении устройства не стоит никаких цифр, которые указывали бы на раздел, т.к. доступ можно изменить только жесткому диску в целом.

После изменения параметров их необходимо сохранить с помощью команды:

hdparm -k1 /dev/hda

После этого снова выполните команду тестирования скорости работы диска hdparm -t /dev/hda.

Помимо того, что вы увидели с помощью команды hdparm /dev/hda2, появился еще один параметр — режим доступа. В настоящее время поддерживается три режима ATA 33/66/100. Сверьтесь с документацией на жесткий диск, чтобы узнать, что он поддерживает.

Для смены режима используется ключ X:

□ X34 — ATA33;

□ X68 — ATA66;

□ X69 — ATA100.

Для установки ATA66 выполните команду:

hdparm -Х68/dev/hda

Самое странное, что установленные вами параметры не сохраняются после перезагрузки системы, поэтому желательно прописать эти команды в файл /etc/rc.d/rc.local. Для этого в самый конец файла добавляем три строки:

hdparm -m128d1c3/dev/hda

hdparm -Х68/dev/hda

hdparm -k1 /dev/hda

 

14.11.3. Автомонтирование

Если вы начали знакомство с компьютером под ОС Windows, то для вас может оказаться дикостью процесс ручного монтирования файловых систем и особенно CD-ROM-дисков. Действительно, для сервера это еще приемлемо, потому что там диски используются редко, а вот на рабочей станции внешние носители применяются регулярно. Мне иногда приходится вставлять по 20 разных дисков в день, и каждый раз монтировать/демонтировать их очень неудобно.

Так как ОС Linux все больше поворачивается в сторону домашних пользователей, в последних дистрибутивах производителями по умолчанию включена возможность автоматического монтирования. Для этого используется служба autofs. Убедитесь, что она запускается у вас, и можно приступать к настройке.

Основной конфигурационный файл сервиса autofs /etc/auto.master. Просмотрите его содержимое в листинге 14.2.

Листинг 14.2. Конфигурационный файл /etc/auto.master

# $Id: auto.master,v 1.2 1997/10/06 21:52:03 hpa Exp $

# Sample auto.master file

# пример файла auto.master

# Format of this file:

# формат этого файла:

# mountpoint map options

# точка_монтирования карта настройки

# For details of the format look at autofs(8).

# для дополнительной информации выполните

# команду man autofs

/misc /etc/auto.misc --timeout=60

Если не считать комментариев, в этом файле только одна строка, которая может быть полезной — последняя. В вашей системе она может быть закомментирована, но для использования автоматического монтирования необходимо убрать знак "#".

У конфигурационной строки следующий формат:

точка_монтирования карта настройки

В данном случае точкой монтирования выступает директория /misc. Это немного затрудняет работу, потому что при ручном подключении используется директория /mnt. Второй параметр определяет карту монтирования. В данном случае это файл /etc/auto.misc. Формат и назначение файла чем-то похожи на файл /etc/fstab, который используется для команды mount. Содержимое файла /etc/auto.misc можно увидеть в листинге 14.3.

Последний параметр --timeout=60, это время простоя. Если в течение этого периода в директории, использованной под подключение, не будет активности, то устройство будет размонтировано. По умолчанию установлено 60 секунд. В большинстве случаев это вполне приемлемое значение.

Листинг 14.3. Содержимое файла /etc/auto.misc

# $Id: auto.misc,v 1.2 1997/10/06 21:52:04 hpa Exp $

# This is an automounter map and it has the following format

# Это карта автомонтирования, которая имеет следующий формат:

# key [ -mount-options-separated-by-comma ] location

# Details may be found in the autofs(5) manpage

# Дополнительную информацию можно получить в man autofs

cd -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom

# the following entries are samples to pique your imagination

# следующие записи являются примерами для

# пробуждения воображения

#linux -ro,soft,intr ftp.example.org:/pub/linux

#boot -fstype=ext2 :/dev/hda1

#floppy -fstype=auto :/dev/fd0

#floppy -fstype=ext2 :/dev/fd0

#e2floppy -fstype=ext2 :/dev/fd0

#jaz -fstype=ext2 :/dev/sdc1

#removable -fstype=ext2 :/dev/hdd

Теперь рассмотрим содержимое файла /etc/auto.misc. Здесь только одна строка без комментария, которая описывает команды подключения CD-ROM диска:

cd -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom

Первый параметр определяет директорию внутри /misc, куда будет монтировано устройство. Второй атрибут — параметры файловой системы и ключи, которые будут использоваться для подключения. В случае с CD-ROM указана файловая система iso9660, разрешено только чтение и запрещены SUID- и DEV-программы. Последний параметр определяет устройство, которое должно монтироваться.

Как видите, все очень даже просто. Если попытаться обратиться к директории /misc/cd, и в приводе CD-ROM в этот момент будет находиться диск, то он будет автоматически смонтирован. Только есть одно замечание, адресоваться лучше командами Linux (например, выполнить команду ls /misc/cd), а не с помощью программ. Если просмотреть директорию /misc/cd с помощью Midnight Commander, то диск не будет смонтирован.

 

Мы проанализировали достаточно много аспектов создания безопасной системы, но есть некоторые общие рекомендации, которые подытоживают рассмотренный в этой книге материал. Поэтому напоследок я собрал короткие советы, которые пригодятся вам в построении безопасного сервера или сети.

 

14.12.1. Дефрагментация пакетов

С помощью фрагментированных пакетов хакеры производят очень много атак на серверы. В Linux можно сделать так, чтобы ОС объединяла приходящие пакеты. Если у вас монолитное ядро (без поддержки модулей), то необходимо прописать 1 в файл /proc/sys/net/ipv4/ip_always_defrag. Это легко сделать с помощью команды:

echo 1 > /proc/sys/net/ipv4/ip_always_defrag

В последних ядрах, которые используют RPM-модули, необходимо подгрузить модуль ip_conntrack:

modprobe ip_conntrack

 

14.12.2. Маршрутизация от источника

Мы уже не раз говорили о том, как пакеты проходят по сети, и достаточно подробно затронули эту тему в разд. 4.5.1. Напоминаю, что внутри сети пакеты передаются по MAC-адресу, а для обмена между сетями необходимо маршрутизирующее устройство, которое умеет работать с IP-адресами и направлять пакеты по нужному пути, который они сами определяют. Но эти устройства управляемы, и существует несколько методов заставить их устремить пакеты в нужное русло. Один из этих методов — маршрутизация от источника (source routing).

С помощью маршрутизации от источника можно установить путь прохождения пакета по сети. Иногда это действительно удобно, но мы же знаем, что это "палка о двух концах", и вполне логичным было бы source routing запретить, а лучше вообще никогда не придумывать.

Как маршрутизация от источника влияет на безопасность? Допустим, что ваш сетевой экран запрещает подключения с адреса 192.168.1.1, потому что через этот IP к вам пытался проникнуть хакер. Так как все пакеты злоумышленника маршрутизаторы направляют именно через этот адрес, то подключение становится невозможным. Но благодаря source routing злоумышленник может сам указать путь, по которому должен следовать пакет, и провести его в обход маршрутизатора или сервера с запрещенным адресом.

Жаль, что мы не можем запретить маршрутизацию от источника на компьютере хакера, но мы не должны принимать такие пакеты на своей стороне и тем более на компьютере, который выполняет роль шлюза в Интернет (прокси-сервер или сетевой экран). Для этого необходимо установить 1 в файле /proc/sys/net/ipv4/conf/all/accept_source_route или выполнить команду:

echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

 

14.12.3. SNMP

Протокол SNMP (Simple Network Management Protocol, простой протокол сетевого управления) применяется для управления сетевыми устройствами, такими как маршрутизаторы, управляемые коммутаторы и даже бытовыми устройствами, подключенными к сети.

Существует три версии этого протокола. Первая версия была разработана очень давно и, конечно же, осуществляла открытый обмен паролями и данными. Шифрование было добавлено в SNMP, начиная со второй версии. Именно поэтому первую версию не рекомендуется использовать, а лучше даже запретить.

У SNMP есть еще один недостаток — протокол использует в качестве транспорта UDP-протокол, который не поддерживает виртуальное соединение, и передача осуществляется простой отправкой пакетов в сеть без подтверждения доставки и без каких-либо авторизаций, т.е. злоумышленник легко может подделать любые поля пакета.

Я не рекомендую использовать SNMP вообще, потому что для большинства задач можно обойтись без него. Конечно же, шифрование, добавленное во второй версии, значительно повысило безопасность, и его можно стало применять даже в особо важных случаях. Но необходимо сначала убедиться, что вы работаете именно со второй или более старшей версией и шифрование используется.

 

14.12.4. Полный путь

Когда вы запускаете какие-либо команды или программы, то необходимо указывать полный путь к ним. Большинство пользователей и администраторов просто указывают имя запускаемого объекта, что может стать причиной взлома. Да что там говорить, я сам грешу вводом коротких команд

Рассмотрим пример того, как злоумышленник может использовать короткие имена в своих целях на примере команды ls:

□ хакер создает в каком-либо каталоге (например, в общедоступном /tmp) файл с таким же именем, как и у атакуемой программы;

□ в этот файл может быть записан сценарий, который выполняет необходимые хакеру действия.

Например, следующий код может быть записан в такой файл:

#!/bin/sh

# Изменяем права доступа к файлам /etc/passwd и /etc/shadow

chmod 777 /etc/passwd > /dev/null

chmod 777 /etc/shadow > /dev/null

# Выполняем программу

ls exec /bin/ls "$@"

В данном примере выполняется всего три команды. Первые две изменяют права доступа к файлам /etc/passwd и /etc/shadow так, чтобы любой пользователь смог их прочитать. При этом все сообщения, которые могут возникнуть во время выполнения команд, направляются на нулевое устройство /dev/null, чтобы они не отображались на экране. После этого выполняется системная команда ls из каталога bin.

Теперь устанавливаем программе ls права, которые позволят выполнять ее любому пользователю:

chmod 777 /tmp/ls

Ложный файл готов. Теперь необходимо сделать так, чтобы он выполнялся вместо системной команды ls. Для этого достаточно добавить в системную переменную окружения PATH в самое начало каталог /tmp. Если теперь кто-либо запустит команду ls без указания полного пути, то выполнится наш сценарий, который попытается изменить права доступа на файлы паролей. Если у пользователя, запустившего команду, хватит полномочий для изменения прав, то можно считать, что система взломана.

Следите за содержимым системной переменной окружения PATH, чтобы ее никто не изменил.

 

14.12.5. Доверительные хосты

В файле .rhosts можно прописать адреса хостов, которым вы доверяете. Пользователи этих компьютеров смогут подключаться к серверу без аутентификации с помощью таких программ, как Telnet или FTP.

Мы уже столько раз говорили о безопасности, что нетрудно догадаться, что хакер может подделать адрес отправителя. Если ему удастся это сделать, то ваш сервер превращается в проходной двор.

 

14.12.6 Защита паролей

Для защиты паролей Linux достаточно только охранять файл /etc/shadow. Помимо этого вы должны контролировать сложность паролей, регулярно пытаясь подобрать пароль по популярным словарям, которые легко найти в Интернете (именно их используют хакеры). Если пароли сложные, то даже при получении файла взломщику понадобится слишком много времени, и скорей всего ничего не удастся.

Но не все так просто. Если пароли для доступа к системе защищаются самой ОС и обязательно шифруются, то остальные программы могут не иметь такой возможности. Например, в пользовательских программах для доступа к определенным сервисам, в частности FTP или POP3, может не использоваться шифрование, и в этом случае пароли могут находиться в конфигурационном файле в открытом виде.

Прежде чем устанавливать какую-либо программу, узнайте, где она хранит пароли и как они защищены (используется шифрование или нет). Устанавливайте такие права на файлы, чтобы доступ к ним мог получить только конкретный пользователь и администратор. Желательно, чтобы для группы стояли нулевые права, особенно если в ней может быть несколько пользователей.

Если отдельная группа создается для каждого пользователя, то группе можно выделить некоторые права. И все же, я бы не советовал этого делать, потому что неизвестно, что будет в будущем. Хакер может добавить себя в определенную группу, или вы сами можете случайно или намеренно объединить пользователей.

Всем своим пользователям я рекомендую не сохранять в программах паролей. Это значит, что при проверке почты надо каждый раз указывать свой пароль. Но это очень неудобно, особенно когда у пользователя более трех почтовых ящиков, а это в наше время является нормой. Да и при наличии одного очень трудно заставить пользователя помнить все пароли и не сохранять их в системе.

Но вводить пароль надо непосредственно в программе, и лучше всего, если он не будет отображаться на экране. Это значит, что надо стараться не указывать пароли в командной строке, которая не может использовать невидимые символы.

Существует множество методов, с помощью которых можно увидеть набираемый пароль, например, команда ps. Пример правильного получения пароля — утилита login, которая не отображает на экране вводимые данные.

В открытом виде пароли могут храниться и в базах данных, именно там содержится наиболее важная информация для любой организации. Базы данных требуют отдельного разговора, и в данной книге мы эту тему не затрагиваем, но забывать о ней нельзя.

 

14.12.7. Перенаправление сервисов

Если существуют какие-либо ресурсы, к которым обращается ограниченный круг людей, то необходимо заставлять сервисы работать на нестандартных портах. Это позволит защитить систему от излишних посягательств.

Одной из распространенных проблем использования стандартных портов является возможность их сканирования. Например, хакер узнает об уязвимости БД определенного разработчика. Допустим, что эта база использует порт 1457. Злоумышленнику достаточно только запустить сканирование сети в поисках компьютера с открытым портом 1457. Как только машина найдена, она попадает в "черный" список, и хакер может запустить программу, которая автоматически захватит все компьютеры из списка.

Проблема легко решается переконфигурированием сервиса для работы на другом порту, и при этом необходимо убрать любые баннеры, которые появляются при подключении на этот канал. В этом случае хакер не сможет узнать, что работает на порту и как взаимодействовать с удаленной программой.

Если с сервисами сервера работает небольшое количество людей, то можно поменять местами особо уязвимые (те программы, которые предоставляют пользователям возможность записи или выполнения команд в системе), например FTP (заставить работать на 80 порту) и HTTP (настроить на 21 порт). Жаль, что это нельзя сделать с общедоступными сервисами, а если и можно, то бесполезно. Например, если заставить работать Web-сервер на 81 порту вместо 80, то любой пользователь Интернета должен иметь возможность узнать об этом. А тогда и хакер будет в курсе.