Общий обзор наиболее часто применяемых техник компьютерных атак и защиты от них

АЛЕКСАНДР ПОТЁМКИН

Общий обзор наиболее часто применяемых техник компьютерных атак и защиты от них

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

Доступ/результат	D.o.S.	Root
Local	IV (относительно низкая)	III
Remote	II	I (высочайшая)

Относительность здесь вполне объяснима – ведь результат же всё равно будет налицо – машина выйдет из строя или будет не в состоянии обслуживать пользователей какое-то время. Однако перейдём к конкретике.

Local D.o.S. attack

D.o.S.-атаки (Denial of Access – отказ в доступе) могут быть популярны, потому что особых навыков не требуют. Здесь используется грубая сила, да и только. Из локальных методов здесь можно выделить исчерпание ресурсов памяти и процессора и/или места на диске.

Первый метод реализации D.o.S.-атаки (исчерпывание ресурсов памяти) может выглядеть так (примеры приведены для *nix-систем):

Листинг программы LocalDoS.c:

#include

main ()

{

while(1) /*Бесконечный цикл*/

{

malloc(10000);

/*Из помощи man: calloc, malloc, free, realloc – Allocate and free dinamic memory – занимаем определённый объём памяти*/

fork();

/*Оттуда же: fork – create a child process – и создаём много дочерних процессов (порождёных процессом-родителем)*/

}

}

В данном случае надо отдавать себе отчёт, что машина перестанет подавать какие-либо признаки жизни очень быстро, и единственным методом вывести её из забытия будет даже не волшебная комбинация из трёх пальцев (Ctrl+Alt+Del), а только маленький «апдейт» к ней – Reset, со всеми вытекающими последствиями.

Второй метод – это забивание дискового пространства. Результатом может быть невозможность нормального функционирования системы и, что наиболее интересно в этой ситуации – все попытки syslogd (или её аналога в Windows NT-based) записать лог будут неудачными… Из локальных реализаций такого метода самым простым (по необходимым навыкам программирования) будет сочетание языков Си и shell:

Листинг программы Echo.c : 

#include

void main()

{

while (1)

printf («X»); /*Печатаем символ “X”*/

}

Листинг disk_DoS.sh :

#!/bin/sh

./echo > /tmp/.

Здесь есть маленькая хитрость – стандартный вывод пойдёт в файл с именем «. » (то есть «точка пробел»), а потому в листинге, получаемом командой «ls» будет не очень заметен (даже при добавлении опции « -a»).

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

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

Защищая всю систему как работоспособный организм от последствий заполнения диска, необходимо было ещё на уровне инсталляции системы некоторые каталоги поместить в отдельные разделы (первыми претендентами туда идут /tmp, /var, /home), таким образом можно и работоспособность системы сохранить при заполнении этих разделов, и поставить разные полезные опции команде mount, например, запретить siud-ные программы… Откуда им взяться у простых пользователей или во временном каталоге…? Однако таким образом система не застрахована от невозможности вести лог. Здесь может помочь только ежечасное cron-задание в виде, скажем, shell-скрипта, который будет искать файлы определённого размера в наших отдельных разделах, и в случае нахождения их архивировать и помещать в каталог /root. Здесь стоит позаботиться о том, чтобы это задание (равно как и все другие – хуже от этого не будет) не было читаемо для всех, иначе можно обойти нашу политику разбиения на разделы. Это может быть реализовано с помощью утилит «find», «xargs» и «gzip».

Remote D.o.S. attack

С локальными D.o.S.-атаками разобрались. Теперь перейдём к атакам удалённым, основная задача всё та же – вывести машину из строя на какой-то период времени, когда доступ к машине есть только удалённый. Воздействовать остаётся только на те демоны/сервисы, которые «вывешены» для доступа. Такого вида атаки можно условно разделить на два типа – атака посредством большого количества запросов и атака, реализующая дыру в программном обеспечении.

Для реализации первой атаки не требуется практически никаких особенных знаний, только большая пропускная способность линии, по которой происходит доступ к данной сети. Суть наиболее распространённой в этом виде атак заключается в применении принципов реализации TCP/IP-протокола. Здесь для реализации атаки интересна начальная стадия установки соединения между двумя машинами.

Для лучшего понимания рассмотрим всё это на конкретном примере – обращение к почтовому сервису клиента (client) на сервер (victim). Естественно, что, для того чтобы можно было воспользоваться услугами какого-либо сервиса/демона, необходимо, чтобы была готовность обслуживать – то есть необходимо, чтобы программа прослушивала какой-либо порт на наличие «желающих подключиться». Когда таковые находятся, происходит следующее:

Клиент создаёт определённые TCP-пакеты, из которых заголовок первого всегда должен быть с установленным битом SYN и без бита ACK. В последующих пакетах всё ровно наоборот. Итак, далее сервер отвечает (если отвечает) на первый пакет клиента пакетом с установленным битом ACK – ответом на получение пакета и своим SYN-запросом синхронизации. При получении этого пакета от сервера, содержащего подтверждение и запрос, клиент передает собственное подтверждающее сообщение. Только теперь соединение считается открытым; до последнего момента это было полуоткрытое соединение.

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

Наибольшей «популярностью» пользуются программы, которые сами генерируют адреса «подставных» машин и посылают запросы как бы от них. Результат – выведение атакуемой машины на более длительный промежуток времени. В это время с victim возможны два варианта: в том случае если администратор поставил ограничения на количество возможных запусков программы, то ничего смертельного для системы не случится, случится только то, что так называемые законные пользователи не смогут воспользоваться услугами почтового сервера (вплоть до того момента, пока не будут обработаны все запросы, посылаемые с client на victim). В том случае если администратор по доброте душевной или по каким другим причинам такого ограничения не поставил, то всё будет прозаичнее – так как ресурсы машины какое-то время останутся «захваченными», то сводного места для действий у системы будет оставаться всё меньше. В конечном итоге может произойти полное исчерпание ресурсов системы, которое приведёт к тому, что запросы будут обрабатываться всё медленнее и медленнее. Все операции могут быть приостановлены, пока не будут обработаны все поступившие запросы. Такая ситуация, кстати, не будет вечной. В конечном итоге машина может уже игнорировать поступающие TCP-пакеты. Одним из неплохих методов отслеживания состояния системы может служить её пингование. Только для получения относительно точного результата необходимо производить это либо с другой машины, чтобы загруженность канала машины атакующего не сказывалась на результате, либо следить за тем, чтобы загруженность канала не сильно влияла на время получения ответа от системы. Далее может существовать два пути – либо надеемся на создание непредусмотренной ситуации и, соответственно, на крах системы, либо ждём пока система обработает всё, что ей выдали.

Второй тип удалённых D.o.S.-атак реализуется благодаря ошибкам в программном обеспечении. Уровень реализации можно поделить на два: уровень конкретной программы и уровень операционной системы.

На уровне конкретной программы обычно эксплуатируются ошибки при программировании. Наиболее популярными из них на данный момент являются ошибки переполнения буфера (buffer overflow). Механизм действия достаточно прост, для большей наглядности рассмотрим его на конкретном примере. Пусть существует некоторая программа, которая прослушивает, скажем, порт 2101, и в задачи которой входит ожидание какой-то строки, которая при получении отсылается, скажем, на root@localhost (суперпользователю на локальной машине). Программа вроде полезная, но проблема у ней следующая: под буфер, в который помещается получаемая строка, отведено всего 32 768 бит. Скажем, какой-то программист, просматривая эту программу, обнаружил эту ошибку. Дальнейшая логика действий проста – ей посылается 32 768 плюс ещё сколько-то бит. В программе такой поворот событий не предусмотрен, а потому она аварийно завершается. При этом происходит то самое переполнение буфера, и появляется возможность немного поиграться с машиной, на которой запущена эта «дырявая» программа. Обычно желаемым действием является вызов командного интерпретатора. Привилегии, с которыми этот интерпретатор будет запущен, напрямую зависят от того, с какими привилегиями «бегала» наша испытуемая. Вот, собственно, и вся история. Впрочем, это всё так легко только на словах, так как зачастую необходимо возиться с регистрами процессора. Так как сейчас мы рассматриваем только удалённую атаку на отказ в обслуживании, то достаточно будет сказать, что, для того чтобы просто «свалить» программу, достаточно ей просто послать, скажем, 32 770 бит. А вот это уже можно сделать, не особо копаясь в процессоре, немножко модифицировав программку char_echo, и связав её с «nc» (net cat):

Листинг программы Char_echo.II.c :

 #include

main ()

{

int i; /*Объявляем переменную…*/

for (i=0; i<=33000; i++) /*Запускаем цикл на 33000 "заходов"*/

printf ("X"); /*И печатаем символ "X"*/

}

Листинг go.sh :

#!/bin/sh

./echo_char | nc victim 2101

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

Это что касаемо атак на уровне программ; на уровне операционной системы всё немножко интереснее. Задача заключается в том, чтобы либо ядро, либо какой-нибудь серьёзный модуль ядра не смог обработать ситуацию и привёл либо к «kernel panic» (панике ядра – *nix-системы), либо к «The blue screen of death» (синему экрану смерти – соответственно Windows-системы). Итог – автоматическая перезагрузка, полное зависание системы, приостановка работы, недоступность сети – что называется, на выбор. В общем и целом опять-таки законные пользователи не могут воспользоваться услугами сервера какое-то время. Зачастую такие атаки реализуются на ошибке в обработке протокола в общем и пакетов в частности. Самый банальный и немало известный пример – это здравствующая и поныне программа WinNuke. Программ, подобных этой, немало, да и существуют они не только для излюбленной народом ОС Windows. В список уязвимых попадают и такие операционные системы как Linux и OpenBSD.

Итак, относительно вывода системы из строя удалённо – всё. Теперь стоит рассказать ещё немного про приём, который может оказаться полезным в сочетании с чем-нибудь другим. Речь идёт об описанной ранее процедуре засорения дискового пространства системы. Конечной целью может являться невозможность системы протоколировать действия, которые с ней производятся. Можно также ориентироваться не на систему, а на человека – посылая большое количество фальшивых запросов, получим долгую обработку или даже игнорирование происходящих событий, имеющих малое отношение к действительности. Оба варианта требуют большой пропускной способности канала атакующего. Путей для реализации «плана максимум» относительно немало: любой сервис, к которому можно получить доступ, является потенциальной мишенью. Например, это может быть достаточно широко распространённый на многих машинах веб-сервер, ведь каждое обращение протоколируется, и потому можно, например, через анонимный прокси-сервер посылать уйму запросов. Лучше всего это делать через разные прокси-серверы, для того чтобы было сложнее вычислить. В том случае если приблизительно известно дисковое пространство, отведённое под систему (например, при наличии локального доступа свободное пространство узнаётся очень легко), то узнаётся, какой веб-сервер работает на атакуемой системе, приблизительно высчитывается пространство, которое тратится после каждой записи, и вперёд… Также можно использовать любые средства протоколирования (например, такие вещи как tcpspy, icmplog,…). Однако же, для этого необходим мощный канал связи.

Теперь: как с этим бороться. Относительно первой описанной атаки, SYN flood, однозначных методов борьбы нет, особенно если «подставляется» не одна машина, а целая серия. Полное закрытие доступа может отрезать законных пользователей от машины (иногда, кстати, может преследоваться именно эта цель, ведь каждый потенциальный покупатель, который не смог обратиться в нужное время к интернет-магазину может уйти к конкуренту, и тем самым атакуемый магазин будет терять прибыль), но и смотреть, как некто пытается вывести машину из строя, – не самое лучшее занятие. В общем, это каждый должен решать для себя. Единственное, что можно сказать точно, так это то, что лучше ограничивать программы в ресурсах, пусть и очень большой цифрой, но всё же ограничивать. Выяснение IP-адреса в большинстве случаев будет невозможно, и достать злоумышленника будет очень сложно. Разработки в защите от подобного рода атак ведутся, но распространения практически не имеют.

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

И относительно последнего трюка – здесь совет всё тот же, что и в защите от локальных D.o.S.-атак, и небольшое «сетевое» дополнение – не надо вешать на свою машину слишком много следящих средств, и неплохо бы позаботиться о том, чтобы их журналы располагались в независимых от системы местах.

Итак, с атаками на отказ в обслуживании в общем и целом разобрались, теперь разберёмся с атаками на получение прав суперпользователя на атакуемой машине.

Local root attack

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

Начнём, пожалуй, с локального варианта, так как зачастую он наиболее легко реализуем. Связанно это с тем, что при локальном доступе у пользователя гораздо больше возможностей найти «дырявую» программу. А далее – всё то же самое, что и описывалось ранее для удалённых атак на отказ в обслуживании – наиболее любимым способом заставлять программу делать не то, что ей «положено», является выход за пределы отведенного буфера. В том случае если программа имеет так называемый SIUD-бит, и если пользователь вообще имеет право на запуск этой программы, то её запуск произойдет от лица суперпользователя. Эти программы являются наиболее «лакомым» кусочком для поиска дырок. Существует же, однако, и другой род программ, дающих права суперпользователя – те, которые уже работают при запуске системы, и которым «по работе» необходим доступ к любому месту операционной системы. Например, это может быть почтовый демон. И алгоритм работы здесь точно такой же – переполнение буфера.

Впрочем, в работе локально добавляются ещё и другие прелести жизни – эта атака использует небезопасное создание временных файлов. Для лучшего понимания опять-таки рассмотрим пример: пусть существует база данных, которая во время запуска создаёт временный файл /tmp/NameOfFile.some_addition. Зачастую все, что находится до точки – не изменяется от запуска к запуску, а вот то, что после точки – должно быть всё время и, что немаловажно, уникальным. Наша программа будет иметь SUID-бит и создавать временный файл по следующей схеме – /tmp/NameOfFile.PID, где PID – это, соответственно, номер процесса. Вполне возможно, что такой файл будет уникальным, однако его имя будет предсказуемо, и в этом заключается главная ошибка. Директория /tmp обычно разрешает запись в неё любых файлов, любого пользователя, и потому можно создать символическую ссылку на файл, который нужно переписать, но который имеет «недостижимые» для нас права доступа. Кроме того, пусть наша база данных записывает в файл аргументы, с которыми она была вызвана. Тогда делаем просто – создаём ссылку, скажем, с /etc/passwd на /tmp/NameOfFile.Guesed_PID. Далее вызываем нашу базу данных с параметрами root::0:0:root:/root:/bin/sh. Допустим, по причине неправильных аргументов программа завершается, но что оказывается в файле /etc/passwd? Правильно – наша запись, которая позволяет заходить любому пользователю в качестве суперпользователя без пароля. Кстати, неплохо было бы сделать копию переписываемого файла, чтобы не было сильно заметно, что что-то произошло (благо /etc/passwd читаем любым пользователем). Вот и все.

Remote root attack

После краткого экскурса по локальному получению прав суперпользователя перейдём к гораздо более опасным атакам – получение root удалённо. Алгоритм здесь похож (и, можно сказать, является доведённым до ума) на алгоритм D.o.S.-атак, только с той разницей, что теперь необходимо не просто выбить программу, а заставить её выполнить необходимый код. Естественно, желательно, чтобы эта программа работала от имени суперпользователя. В таком случае, при применении эксплоита, человек получает полноценный шелл (shell), что называется, не выходя из дома.

Здесь нет особых премудростей (в использовании «дырок» по готовому шаблону), необходимо «просто» найти машину с уязвимой программой. Для этого даже существуют специальные сканеры. Алгоритм их работы прост – либо генерируется случайный IP-адрес, либо его задаёт пользователь. Далее этот адрес пингуется; в том случае если машина отвечает, происходит подключение к определённому порту. Если все эти шаги проходят удачно, то в зависимости от искомого сервиса либо посылается какая-нибудь строка, либо нет. В любом случае «грабится» (grab – захватывать) так называемый банер (то, что выдаёт программа подключившемуся клиенту) и анализируется версия программного обеспечения (которая обычно выводится в банере). Если она удовлетворяет необходимым условиям – то всё хорошо, адрес машины заносится в лог-файл (log file), и сканер переходит к следующему адресу. В том случае если происходит провал хотя бы на одной стадии, то адрес отвергается и берётся следующий. Существует ряд людей, которые либо предоставляют подобные сканеры через веб-доступ (то есть для этого совершенно не нужно что-либо знать и иметь специального образования), нередко ещё рядом можно найти инструкцию «по применению» и всё необходимое программное обеспечение. Другие люди занимаются подобным сканированием со своих собственных машин и в большинстве случаев далеко не для того, чтобы получив root shell, сразу же послать письмо администратору с тем, что его машина уязвима, а с несколько другими целями. Если оставить споры о том, как можно называть таких людей, то можно сказать, что это своего рода санитары леса.

Безопасность серверов организации (реализация требований безопасности на примере ОС Linux)

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

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

Ядро системы

Операционная система Linux является плодом труда людей, а им, как известно, свойственно ошибаться, даже в коде ядра. Отсюда первая угроза безопасности – ошибки в ядре системы. Подобные ошибки обнаруживаются не столь часто, сколь ошибки во всём остальном программном обеспечении, однако же такое бывает. Защита здесь одна (одинаковая для всех подобных проблем) – постоянное отслеживание информации безопасности (например, неплохим источником информации, помимо списка рассылки от производителя дистрибутива, является сайт www.securityfocus.com и его списки рассылки) и показания сервера.

Впрочем, существуют патчи на ядро, которые позволяют повысить защищённость системы в целом и ядра в частности. Основное внимание в таких патчах (в том числе кумулятивных) уделяется возможности противостоять системе от общих атак на программы с ошибкой на переполнение буфера, от атак на программы с некорректным созданием временных файлов и также на возможность уменьшить количество информации, которую может получить атакующий о системе (http://www.openwall.com).

Также существуют патчи, специализирующиеся на сетевом аспекте работы ядра ОС. В их задачи входит встраивание функции защиты от сканирования в ядро системы (http://www.lids.org), а также функции затруднения определения версии ОС

средствами таких сетевых сканеров, как nmap.

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

Сетевые сервисы

В большинстве случаев, по непонятным для автора причинам, на «свежеустановленном» сервере по умолчанию запущены практически все возможные сервисы (например, совершенно не нужный на сегодняшний день 7-ой порт, сервис echo).

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

Защититься от таких проблем можно: во-первых, регулярно отслеживая события безопасности (и опять же www.securityfocus.com будет, пожалуй, самым авторитетным и полным источником информации); во-вторых, немного «подковав» ядро системы (различными патчами безопасности, как описано выше); и в-третьих, просто используя серверы, которые пишутся с большой осторожностью и с учётом требований безопасности, ну и конечно же, не используя ненужные сервисы.

Начнём, пожалуй, с ненужных сервисов. Задачи, конечно, у каждого сервера могут быть специфичными, но всё же можно сказать, что в большинстве случаев ненужными и в чём-то просто опасными являются порты (с соответствующими сервисами) с первого по девятнадцатый включительно. Какие-то из них могут быть полезными, но большинство из них сейчас не используется. Не стоит открывать без особых причин и такие порты как 37 (time), 69 (tftp), 79 (finger), 111 (sunrpc), 512 (TCP – exec; UDP – biff), 513 (TCP – login; UDP – who), 514 (TCP – cmd; UDP – syslog), 517 (talk), 525 (timeserver).

Теперь что касается наиболее часто используемых сервисов, а именно: HTTP/HTTPS, FTP, Telnet/SSH, SMTP, POP3/IMAP и прокси-сервисы. Рассмотрим каждый сервис подробно.

HTTP/HTTPS

Здесь особые вариации отсутствуют: на *nix-платформах безгранично властвует Web-server Apache. Сервер этот в особых проблемах с безопасностью замечен не был, за исключением, может быть, настройки по умолчанию (в каковой присутствуют два не очень приятных для администратора скрипта). Да и работает этот сервер обычно от пользователя с минимальными правами в системе (идеальный вариант – вообще для каждого сервера/демона и для Apache в том числе – выделить своего отдельного пользователя с непересекающимися группами других сервисов и пользователей).

FTP

Здесь ситуация уже не так однозначна: не столь редко, сколько хотелось бы можно встретить на дистрибутиве по умолчанию демон WU-FTP, который всем вроде неплох, но вот по количеству «дырок» среди себе подобных, он, пожалуй, безусловный лидер. В качестве альтернатив, написанных с учётом требований безопасности, можно предложить ProFTP, BSD FTPD. Стоит заметить, что сам по себе FTP-протокол небезопасен, о чём подробнее можно прочитать здесь http://www.security.nnov.ru/articles/sacerdote.asp.

Telnet/SSH

Оба вышеобозначенные протокола используются для удалённого доступа к машине. Относительно безопасности: в реализациях обоих протоколов были серьезные проблемы (например, remote root access через львиную долю реализаций протокола telnet), однако частота появлений таких дырок достаточно низка.

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

SSH изначально проектировался как замена telnet, а потому учитывает все его недостатки и, кроме того, добавляет большое количество полезных возможностей, а именно: полное шифрование сеанса, сжатие информации (вещь весьма полезная для доступа к серверу с dial-up соединений), а также возможность выступать посредником сетевого уровня между приложениями.

SMTP

С самим по себе протоколом проблем особенных нет (тем более что существует и его реализация с шифрованием информации), единственная проблема, обычно связанная с функцией отправки почты сервера – это сам демон – в большинстве случаев это сервер sendmail. В прошлом этот сервер имел, пожалуй, самую богатую родословную по количеству ошибок. Сейчас все (или большинство) эти проблемы похоже что устранены, но для использования на сервере всё же можно посоветовать почтовый клиент qmail (http://cr.yp.to), неплохо справляющийся со своими функциями и не имеющий (на данный момент) проблем с безопасностью.

POP3/IMAP

Здесь практически всё так же, как и с SMTP-протоколом, и в качестве сервера и здесь можно посоветовать всё тот же пакет qmail, куда входит и клиент для POP3.

Proxy-сервисы

Здесь выбор, по большому счёту, невелик, и его приходится делать между Squid, Oops и модулем для сервера Apache. Если всё же останавливаться на специализированных для выполнения функций прокси-сервера программах, то остаётся выбирать между Squid и Oops.

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

Безопасность на сетевом уровне

Кроме того что на сервере установлено специальным образом «пропатченное» ядро, безопасные сетевые сервисы, не помешает ещё озаботиться и безопасностью на уровне самого протокола TCP/IP, для чего обратимся к файрволу, стандартно идущему с системой (ниже будут даны правила ipchains, для ветки ядер 2.2.x).

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

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

ipchains -P input DENY

ipchains -O output REJECT

ipchains -P forward REJECT

Далее даётся разрешение на свободный трафик по «кольцевому» интерфейсу lo0 и идёт серия запрещающих (точнее фильтрующих) правил для внутренней сети – запрет явно фальсифицированных пакетов (например, пакеты, пришедшие с внешнего интерфейса, но имеющие в качестве исходного адреса внутренний), и серия для протокола ICMP. По большому счёту, все пакеты этого протокола можно запретить, но при грамотной фильтрации можно оставить пакеты третьего, четвёртого, восьмого, одиннадцатого и двенадцатого типов, которые будут полезны для диагностирования ошибок.

Дальше идёт последовательное расписывание правил для каждого сервиса, что в общем случае будет выглядеть так (дан вариант для HTTP-сервиса, другие сервисы, например DNS, могут иметь более сложную структуру):

#client

ipchains -A output -i $EXTERNAL_INTERFACE -p tcp -s $IPADDR $UNPRIVPORTS -d $ANYWHERE 80 -j ACCEPT

ipchains -A input -i $EXTERNAL_INTERFACE -p tcp ! -y -s $ANYWHERE 80 -d $IPADDR $UNPRIVPORTS -j ACCEPT

#server

ipchains -A input -i $EXTERNAL_INTERFACE -p tcp -s $ANYWHERE $UNPRIVPORTS -d $IPADDR 80 -j ACCEPT

ipchains -A output -i $EXTERNAL_INTERFACE -p tcp ! -y -s $IPADDR 80 -d $ANYWHERE $UNPRIVPORTS -j ACCEPT

где:

• $EXTERNAL_INTERFACE – название интерфейса, обращённого к внешней сети,
• $IPADDR – адрес сервера,
• $ANYWHERE – любой возможный адрес сети,
• $UNPRIVPORTS – номера непривилегированных портов (с 1024 по 65535).

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

Итого

С помощью всех вышеописанных шагов сетевая часть сервера была сделана более безопасной, однако же остаётся ещё много проблем: во-первых, постоянное отслеживание событий безопасности; а во-вторых, локальная безопасность, ведь у пользователя, имеющего регистрацию в системе, есть под рукой гораздо большее количество программ, чем только те, что были оставлены администратором для сетевого пользования, а потому и больше шансов на компрометацию системы. Часть проблем локального характера снимается вышеуказанными патчами на ядро, ещё часть проблем можно снять, удалив всё ненужное с сервера (например, первыми кандидатами можно назвать всевозможные игры). Всё остальное нужно только регулярно отслеживать, проверяя журналы регистрации (модифицированное таким образом ядро и грамотно настроенные программы будут оставлять много интересных записей в журналах).