Сетевая безопасность. Часть 1 - Ubuntu Server.

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

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

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

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

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

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

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

С чего начинается безопасность?

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

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

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

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

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

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

Устройства локальной сети должны иметь доступ только к тем службам в DMZ, которые им необходимы, например SMTP, POP3, HTTP, остальные соединения должны блокироваться. Это позволит надежно изолировать злоумышленника или вредоносное ПО, воспользовавшихся уязвимостью в отдельном сервисе, демилитаризованной зоной, закрыв им доступ к основной сети.

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

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

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

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

Неплохо завести практику менять пароли раз в 30-40 дней. Понятно, что подобная политика способна вызвать неприятие со стороны пользователей, но вы должны всегда помнить, что пароли типа 123 или qwerty равносильны ключу оставленному под ковриком.

Безопасность сервера - ничего лишнего.

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

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

Сконфигурируйте службы, обслуживающие локальную сеть (например squid), таким образом, чтобы они принимали запросы исключительно с локального интерфейса. Чем меньше служб доступно извне, тем лучше.

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

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

Сканер показывает открытые порты, пытается определить тип работающей службы и, если это удалось, уязвимости для нее. Как видим - правильно сконфигурированная система вполне безопасна, однако не стоит оставлять ключ под ковриком, наличие на роутере открытых портов 1723 (VPN) и 3389 (RDP, проброшен на терминальный сервер) хороший повод подумать о политике паролей.

Отдельно стоит поговорить о безопасности SSH, данная служба обычно используется администраторами для удаленного управления сервером и представляет повышенный интерес для злоумышленников. Настройки SSH хранятся в файле /etc/ssh/sshd_config, все описываемые ниже изменения вносятся в него. В первую очередь следует запретить авторизацию под пользователем root, для этого добавьте опцию:

PermitRootLogin no

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

Стоит явно указать список разрешенных пользователей, при этом можно использовать записи типа user@host, которая разрешает указанному пользователю подключаться только с указанного хоста. Например чтобы разрешить пользователю ivanov подключаться из дома (IP 1.2.3.4) следует добавить следующую запись:

AllowUser ivanov@1.2.3.4

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

Protocol 2

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

sudo apt-get install fail2ban

Данная утилита готова к работе сразу после установки, однако мы бы советовали сразу изменить некоторые параметры, для этого внесите изменения в файл /etc/fail2ban/jail.conf. По умолчанию контролируется только доступ к SSH и время бана составляет 10 минут (600 секунд), на наш взгляд стоит его увеличить, изменив следующую опцию:

bantime = 6000

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

[proftpd]
enabled = true

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

sudo /etc/init.d/fail2ban restart

Лог работы утилиты вы можете посмотреть в /var/log/fail2ban.log.

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

Записки IT специалиста