В наше непростое время за серверами нужно следить по ряду причин... В первых, как правило, многие сервера установлены на *nix платформах (Linux, *BSD, SunOS, etc). Винду не беру во внимание из-за ее, ИМХО, невозможности стать сервером (плохое удаленное администрирование, склонность к зависанию и т.д.) - админам NT прошу строго не судить - такое уж мое мнение 😉
Так вот, с увеличением числа серверов (не даром же вводят ipv6) повышается конкуренция и случаи взлома серверов (в частных случаях эти 2 сочетания сходны между собой). Представим картину: хороший web-дизайнер, но неопытный администратор содержит какой либо проект. Все идет хорошо, но внезапно его сервер взламывают, и... хорошо если будут бэкапы 🙂
Данная статья дает некоторые начинающим админам, чтобы приблизить к минимуму взлом его сервера.
Сервисы и доступ к ним
Несомненно твой сервер содержит сервисы (www,
ssh, ftp, pop3)... В наше время нужно устанавливать лишь самые последние релизы этих сервисов, так как не исключено, что устаревшие версии подвержены взлому. Поэтому необходимо отслеживать выходы новых версий и делать апдейт.
Что касается доступа, то файрволл бы не помешал. Все равно доступ, например к ssh, осуществляется с определенных хостов (почему бы их не разрешить, а на все остальные сделать запрет на порт). Пример с ipchains для ssh (допустим, что 195.1.1.1 - разрешенный ip-адрес):
[root@www /]# ipchains -A input -s ! 195.1.1.1 -d 0.0.0.0 22 -p 6 -j REJECT
Не забудь добавить строку файрволла в автозапуск.
Рекомендуется также, сделать фильтрацию на все авторизированные сервисы (если это возможно).
Логи
Логи - вот прелесть *nix серверов. Как правило, логи находятся в папке /var/log (или /var/adm в Solaris). Про них забывать не стоит. Но, если логов много, то они могут ввести в заблуждение и привести к тому, что админ их даже не будет смотреть. В FreeBSD каждый день отправляется отчет на root-ящик (неудачные коннекты, список пользователей, суидные бинарники и так далее. В Linux ты можешь сам организовать такое применив смекалку, написав парсер логов например на Perl (написание парсера логов - тема уже совсем другой статьи :)).
Желательно установить атрибут +a на логи (append only). К атрибутам я вернусь чуть позже. Теперь скажу кратко, какой logfile за что отвечает:
messages - сообщения от сервисов (sshd,pop3,всякая локальная авторизация и так далее...)
secure - успешная или неудачная авторизация на сервисах.
maillog - лог smptd
cron - лог выполнения crontab
boot.log - логфайл пишется при каждой перезагрузке сервера.
wtmp - бинарный файл - информация о пользователях, заходивших на сервер (команда last работает напрямую с этим файлом).
Это основные логи. Особого внимания и изучения требуют messages и secure.
Мэйл рута на сервере лучше всего оформлять как редирект на другом ящике (пример записи в /etc/aliases: root: admin@another.server.com), так как, если будет производится взлом - почта будет уходить руту без проблем ее нейтрализации.
Бэкапы
Делать бэкапы следует в обязательном порядке, особенно, если на сервере есть важные сайты.
Самый простой вариант создать /var/backups и скидывать туда бинарники, важные файлы и так далее... Но не исключено, что, при взломе их также могут удалить (изменить). Поэтому, безопаснее писать бэкапы на отдельный винт (который должен либо быть размонтирован, либо вообще впоследствии отключен от сервера), либо на rw-матрицу (идеальный вариант). Бэкапить лучше раз в неделю (и следить за контрольной суммой рабочих бинарных файлов - для этого есть свой софт). Разумеется, для удобства забэкапенные бинарники и www-ресурсы лучше сжимать архиватором (например: tar zcf
/var/backups/bin.tar.gz /bin /usr/bin /usr/local/bin).
Локальная безопасность и атрибуты
Что касается локальной безопасности, то тут есть о чем поговорить. Во первых, не давай shell-доступ тому, кому он не нужен (допустим пользователю, который снимает только почту). В качестве shell установи /bin/nologin если таковой имеется (либо какой-нибудь другой
fake-shell). Следи за тем, чтобы у пользователей были сложные пароли - либо напоминай им сам об этом, либо проверяй пароли на сложность самостоятельно.
На бинарные файлы обязательно установи атрибут +i (chattr +i /bin /usr/bin /usr/local/bin), чтобы в случае массового удаления либо замещения система не дала этого сделать.
Не свети свою историю команд. Уведи ее командой: ls -sf /dev/null /root/.bash_history - так как, взломщик через нее может многое узнать о системе.
Слово о снифферах
Я обещал вернуться к выбору сервисов. Дело в том, что пароли передающиеся в plain-text могут быть перехвачены снифферами (даже не на твоем сервере, а в подсети например). Поэтому лучше использовать криптованную передачу, даже через ftp и pop3 (благо такой софт существует). В этом случае, шанс утечки пароля сведется к 0.
Вот такие советы я тебе дал. При выполнении хотя бы половину этих советов, твой сервер будет в относительной безопасности, и даже в случае взлома, можно быстро проконтролировать ситуацию.
