Предисловие…
Приветствую Вас, друзья! Эта статья представляет собой очередной флешбэк из админского прошлого. буквально сегодня мне написал хороший товарищ, программист, с вопросом — как ему лучше для своего «домашнего» проекта настроить сервер. Цитата дословно (без ссылки на автора просто):
Нужен совет. Есть VDS, торчит в интернете(сайте). Какие вещи я должен на нем сконфигурировать с точки зрения секьюрности? Кроме того чтобы настроить ssh на нестандартном порту с аутентификацией по ключу и запретить ssh для рута? Может надо как-то правильно расставить права на папки, может включить какие-то дополнительные механизмы, что-то в этом духе? А может и не надо больше ничего. Мне не надо упарываться по самые бубенцы, просто хочу немного обезопасить себя.
Вопрос как оказалось очень даже актуальный. Да, если вы регулярно администрирует Linux и веб сервера, казалось бы, «что тут сложного» и «как это программист не знает». А вот очень просто. Ну не работает человек с этим постоянно. Имеет право не знать. Поэтому сегодня мы поговорим с Вами о настройке Linux сервера под сайт или любое другое веб приложение, в случаях когда этот самый сервер должен быть доступен из публичной сети интернет. Погнали!
Первое, о чем мы с Вами условимся — это не будет стандартный шаблонный How-to гайд с тонной команд без комментариев, мол вот это и это сделай и будет тебе счастье. Таким, простите за мой французский, низкопробным шлаком, Интернет переполнен. Я буду говорить о том что нужно сделать, как и почему, давая ссылки на документацию или авторитетные источники и уже в последнюю очередь — может буду приводить команды.
Второе о чем мы с Вами условимся — если будут примеры, они будут привязаны к Ubuntu как к ОС Вашего сервера. Сейчас любой Облачный провайдер или хостинговая компания позволяет Вам развернуть свой виртуальный сервер на базе этого Linux дистрибутива. Она ( Ubuntu) дружественна к пользователям, есть поддержка всего программного обеспечения какое только существует под Linux и т.д. Опять же, никто не мешает Вам применять эти рекомендации для любого другого дистрибутива, например Centos, просто используя другой набор команд. Например для установки ПО.
Третье и самое главное — это НЕ исчерпывающее руководство. Это просто список тех МИНИМАЛЬНЫХ мер «гигиены» которые Вы должны предпринять или убедиться что они предприняты по умолчанию, чтобы Ваш сервер хорошо себя чувствовал и радовал Вас стабильным аптаймом
Поехали!
Настройки ОС
Нус, с чего нам стоить начать?
Пункт первый — ставьте обновления! Черт возьми- первым делом после установки сервера — ставьте обновления! И в дальнейшем старайтесь про ни не забывать. Обновления в первую очередь закрывают баги и дыры в безопасности.
Шаг Второй — заведи учетную запись отличную от root. В 99% случаев аренды vps/vds Вам отдают виртуальную машину с единственной учетной записью — root. Это нормально. не нормально — оставлять ее просто так. Заведите отдельную учетку, с правами на sudo или без — уже Вам решать. Но сделайте это. А так же смените root пароль, чтобы не оставлять тот, который Вам изначально сгенерировал хостер. Мало ли что.
Кстати «о птичках» — если работать на сервере Вы будете не один, используя sudoers файлы, можно отлично «нарезать» привелегированный доступ другим сотрудникам, не выдавая им при этом возможность завладеть root привелегиями. Вот пример часто используемого мною файла sudoers, чтобы предоставить например веб-разработчикам на «продакшен» сервере довольно широкие права для исследования проблемы, но при этом без полного доступа к системе:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 |
# Alias for viewers utilites Cmnd_Alias VIEW = /bin/cat, \ /usr/bin/tac, \ /bin/zcat, \ /bin/grep, \ /usr/bin/zgrep, \ /bin/more, \ /usr/bin/head, \ /usr/bin/tail, \ /usr/bin/less, \ /usr/bin/zless, \ /usr/bin/diff # Alias for utilities for manipulating system services Cmnd_Alias SERVICE = /sbin/service, \ /etc/init.d/*, \ /sbin/initctl, \ /usr/bin/systemctl # Docker commands Cmnd_Alias DOCKER = /usr/bin/docker, /usr/bin/cgget # Alias for utilities to kill processes Cmnd_Alias KILL = /bin/kill, \ /usr/bin/killall, \ /usr/bin/pkill, \ /usr/bin/skill # Alias for statistics/monitoring tools Cmnd_Alias STATISTICS = /usr/bin/du, \ /bin/netstat, \ /usr/sbin/ss, \ /usr/bin/sar # Alias for file listing, read files attributes Cmnd_Alias FILES_LIST = /bin/ls, \ /usr/bin/lsattr, \ /usr/bin/file Cmnd_Alias REMOVE_COMMANDS = /bin/rm, \ /usr/bin/rm, \ /bin/rmdir, \ /usr/bin/rmdir # Alias for utilites for manipulating with network Cmnd_Alias NETWORK = /usr/sbin/tcpdump, \ /usr/sbin/ngrep, \ /bin/traceroute, \ /usr/sbin/lnstat # Reboot utilites Cmnd_Alias REBOOT = /usr/sbin/reboot *, /sbin/shutdown * # Alias for trouble shooting utilites Cmnd_Alias TSHOOT = /usr/sbin/lsof, \ /usr/bin/lsof, \ /usr/bin/abrt-cli, \ /sbin/service * status, \ /etc/init.d/* * status, \ /usr/sbin/lvs, \ /sbin/lvs # Alias for remote copy commands Cmnd_Alias REMOTE_COPY = /usr/bin/scp, \ /usr/bin/sftp, \ /usr/bin/rsync # Alias for file archivers Cmnd_Alias ARCHIVERS = /bin/gzip, \ /bin/gunzip, \ /bin/tar, \ /usr/bin/zip, \ /usr/bin/unzip, \ /bin/bzip2, \ /bin/bunzip2, \ /usr/bin/xz, \ /usr/bin/unxz # Alias for remove logs. Cmnd_Alias REMOVE_LOGS = /bin/rm /var/log/*, \ /bin/rm /var/log/*/*, \ /bin/rm /var/log/*/*/*, \ !/bin/rm /var/log/*\ *, \ !/bin/rm /var/log/*..*, \ !/bin/rm /var/log/secure*, \ !/bin/rm /var/log/wtmp*, \ !/bin/rm /var/log/btmp*, \ !/bin/rm /var/log/lastlog*, \ !/bin/rm /var/log/audit/* %linux_admins ALL=(ALL) ALL %linux_users ALL = NOPASSWD: NOEXEC: FILES_LIST, VIEW %linux_users ALL = NOPASSWD: SERVICE, \ STATISTICS, \ NETWORK, \ TSHOOT, \ ARCHIVERS, \ REMOTE_COPY |
Если не очень понятно что это и зачем — милости просим читать про sudo утилиту и sudoers файлы
Шаг четвертый — настройте правильно SSH. Тут существует 3 простые и максимально действенные настройки:
- Отключите вход по учетной записью root (саму запись можно не выключать, просто в настройках sshd скажите «PermitRootLogin no» )
- Сгенерируйте для себя ssh ключ, установите его на сервер под Вашей учетной записью, проверьте доступ по ключу и наконец отключите вход по паролю («PasswordAuthentication no»)
- «Скройте» стандартный ssh порт от всего Интернет. Самый простой способ для этого — переключите ssh на не стандартный порт ( т.е отличный от 22). Зачем это нужно — в сети огромное число ботов и авто сканирующих программ, которые просто рыщут по доступным ip адресам и найдя открытый 22 ssh порт, начинаю его брутфорсить. Посмотрите записи вашего лога аутентификаци и в реальном времени — «tail -f /var/log/auth.log», спустя час после запуска вашего сервера, а потом повторите эту процедуру после смены порта и перезапуска ssh — сразу поймете о чем я)
- Другие способы — это спрятать ssh за vpn, разрешить подключение к ssh только с определенных ip адресов с помощью firewall (например с вашего домашнего/рабочего адреса, если у Вас там статический IP)
Шаг пятый — раз уж мы заговорили про SSH, стоит вспомнить про тот факт, что не только Вы используете ключи при работе с сервером, но и он при работе с Вами. При установке OpenSSH сервера, происходит автоматическая генерация ключей для него, тем самым гарантируется их уникальность ( а значит и безопасность) для каждой новой инсталляции. Однако, нередко хостеры грешат тем, что при заказе Вами у них виртуалки, они не устанавливают ее «с нуля» а просто клонируют ее Вам из шаблона, сохраняя всю «начинку» ( и сгенерированные 1 раз ключи, и устаревшие пакеты без обновлений). Я уже писал про один такой хостинг. Как резюме — да, это плохо, да, про это надо помнить. Что в такой ситуации делать? Просто взять и перегенерировать эти ключи вручную с последующим перезапуском сервера. Вот пример из моего Ansible Playbook для настройки нового сервера, где я безапелляционно делаю:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
- name: SWE | Delete default ssh keys file: path: "{{ item }}" state: absent with_items: - /etc/ssh/ssh_host_dsa_key - /etc/ssh/ssh_host_dsa_key.pub - /etc/ssh/ssh_host_ecdsa_key - /etc/ssh/ssh_host_ecdsa_key.pub - /etc/ssh/ssh_host_ed25519_key - /etc/ssh/ssh_host_ed25519_key.pub - /etc/ssh/ssh_host_rsa_key - /etc/ssh/ssh_host_rsa_key.pub when: ssh_keys_flag.stat.exists == False - name: SWE | Create flag that default ssh keys were deleted file: path: /root/default_ssh_keys_removed_flag state: touch when: ssh_keys_flag.stat.exists == False - name: SWE | Generate /etc/ssh/ RSA host key command : ssh-keygen -q -t rsa -f /etc/ssh/ssh_host_rsa_key -C "" -N "" args: creates: /etc/ssh/ssh_host_rsa_key - name: SWE | Generate /etc/ssh/ DSA host key command : ssh-keygen -q -t dsa -f /etc/ssh/ssh_host_dsa_key -C "" -N "" args: creates: /etc/ssh/ssh_host_dsa_key - name: SWE | Generate /etc/ssh/ ECDSA host key command : ssh-keygen -q -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key -C "" -N "" args: creates: /etc/ssh/ssh_host_ecdsa_key - name: SWE | Generate /etc/ssh/ ED25519 host key command : ssh-keygen -q -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -C "" -N "" args: creates: /etc/ssh/ssh_host_ed25519_key |
Шаг шестой — настройка firewall. Да, да, да.. Если у Вас простой и не притязательный веб сервер, наружу у вас должны быть открыты 3 порта — два для web трафика (80 — http, 443 — https) и порт для ssh ( о том какой и как — говорили выше). Все! Все прочее должно быть закрыто наглухо. Ваш Firewall должен исповедовать политику «все что не разрешено явно, должно быть запрещено» — то есть для входящего трафика мы пишем 3 разрешающих правила, и выставляем политику по умолчанию в запрещающем режиме. Правда не стоит забывать, что так же нам нужно разрешить трафик, который возвращается на наш сервер в ответ на наши запросы с него. Т.е. трафик инициированный нами. Это так называемые «Established and Related Incoming Connections» — благо Linux-овый firewall «Netfilter» ( да именно он является фаерволом а не iptables, как многие пишут. iptables лишь утилита управления!) является statefull firewall — то есть он умеет в определение соединений и их состояний. Тут я могу посоветовать три модели поведения:
- Если Вам не очень хочется разбираться в тонкостях настройки, воспользуйтесь утилитой UFW, которая предоставляет более простой ( но и менее гибкий) чем iptables интерфейс. Вот отличная статья в wiki компании DigitalOcean на эту тему.
- Если вам все таки хочется быть настоящим админом — вот Вам wiki учебник по iptables и дерзайте. Это только первый шаг. Мастер класс ждет Вам вот в этой книжке от O’Raily
- Для тех кто хочет что-то среднее между 1 и 2, есть вот такой пошаговый гайд по правилам от компании Redhat.
Собственно выбор за Вами! И еще нюанс — настоятельно рекомендую, так же подумать над ограничительными правилами для исходящего трафика! Порой бывает полезно!
Веб сервер
Так как статья нацелена именно на вопросы security а не на вопросы просто настройки веб сервера, я буду краток. на Вашем сервере с вероятностью 99% будет либо nginx, либо apache. При условии что оба они обновлены (стоят последние пакеты со всеми патчами), сами по себе они безопасны. Вопрос сводится только к настройкам:
Веб сервер должен быть запущен от имени отдельного пользователя! Не root, не ваша учетка! Отдельный юзер, в настройках которого, в качестве командной оболочки стоит nologin. То есть, если веб сервер будет взломан и через него зальют некий shell скрипт, злоумышенник не сможет его запустить на Вашей машинке и не получит доступа к управлению:
Как видно на скриншоте, рабочий процесс Nginx работает из под пользователя www-data, для которого оболочкой стоит nologin.
Каталог, в котором лежат файлы Вашего сайта, должен принадлежать пользователю Вашего веб сервера и быть ограниченным в правах для других пользователей. Больше ни на какие каталоги в вашей системе пользователь веб сервера прав иметь не должен. Вот пример:
Конфигурация веб сервера для Вашего сайта должна содержать инструкцию, которая разрешает обращение к «админке» только с определенных адресов. Вот пример для nginx:
И наконец последний из моих советов (но не из всех действий которые Вы можете сделать) — это обязательно настройте httpS! Вот прям щас! Ранее я уже писал про Let’s Encrypt и применение certbot. С этими ребятами получить и установить себе SSL сертификат — да как два пальца…
Ну что, думали это всем? А вот нет уж… Это Минимальные действия которые Вы ДОЛЖНЫ предпринять.
Вот только офф гайды что еще можно сделать:
И Блогерские рекомендации по харденингу:
База данных
Тут все довольно просто. Скорее всего Вы используете MySQL или ее вариации (MariaDB или Percona Server).
Первым делом убедитесь, что Ваш движок СУБД не открыт всему миру, а слушает только локальный порт:
Далее — ваш сайт должен иметь отдельную базу, и отдельного пользователя внутри СУБД, которому разрешено пользоваться только этой базой и более ничем:
Ну и в конце — есть такой замечательный скрипт от самих разработчиков MySQL, как mysql_secure_installation, который позволит Вам быстро и просто подкрутить настройки безопасности СУБД, без страха сломать Вашу базу.
Дополнительные меры
Fail2ban
Одной из дополнительных мер защиты, которую я настоятельно рекомендую применять в любом случае, является установка и настройка службы fail2ban. Это очень хороший инструмент борьбы с различными брутфорсерами и сканировщиками в автоматическом режиме без вашего участия. Инструмент парсит логи различных служб ( поддерживется очень большое число популярных — начиная от ssh и заканчивая различными ftp сервисами) на предмет нездоровой активности, вычисляет источник и банит его по ip адресу, добавляя в специально созданное правило firewall. Для общего развития советую так же ознакомиться вот с такой статьей на хабре.
По умолчанию, fail2ban готов защищать ваш ssh сервер ( только в нашем случае нужно будет в настройках сменить порт с стандартного под псевдонимом ssh на тот который Вы указали в настройках sshd)
Как быть, если он забанил легитимного пользователя/адрес (например коллегу), а времени ждать пока произойдет анбан нет (срочная работа или Вы таймер бана поставили на неделю). Очень просто — находим что в цепочке ssh есть забаненый
|
1 2 3 4 |
root@server:~# fail2ban-client status Status |- Number of jail: 1 `- Jail list: sshd |
смотрим кто это
|
1 2 3 4 5 6 7 8 9 10 |
root@server:~# fail2ban-client status sshd Status for the jail: sshd |- Filter | |- Currently failed: 0 | |- Total failed: 23 | `- File list: /var/log/auth.log `- Actions |- Currently banned: 1 |- Total banned: 3 `- Banned IP list: 178.162.X.X |
если адрес совпал с тем кого надо разбанить — даем команду на анбан
|
1 2 3 |
root@server:~# fail2ban-client set sshd unbanip 178.162.X.X 178.162.107.191 root@server:~# |
Мониторинг
Все же, за сервером лучше присматривать. Мало ли- его там dos-ят, или таки взломали, а может кончается место на диске и вот вот «ляжет» база данных. Ситуаций есть много! Что я могу тут порекомендовать — установите систему мониторинга. Лучше отдельно ( да, это потребует отдельный, пусть и небольшой сервер, но мы же считаем что Ваш сайт для вас важен). Сейчас есть много систем мониторинга — по соотношению простота/возможности из коробки/удобство использования/объем информации в сети, на первом месте для меня Zabbix. В случае сложных и серьезных проектов его первенство спорно — возможно лучше взять Prometheus или TICK/TIG стэк. Но тут он подойдет как нельзя кстати.
Поэтому ставим, используя русскоязычную (полную и актуальную) документацию, «из коробки» получаем необходимым минимум и если не хватает уведомлений на почту — настраиваем хоть в Telegram, хоть в Slack.
Уведомления
Возможно Вам захочется получать каждое утро сводку новостей от сервера- что случилось, что изменилось и тд. Когда у вас таких серверов десятки это конечно перебор, но когда он один любимый, почему бы нет. В этом Вам поможет LogWatch — утилита парсит логи сервисов, за которыми вы ей приказали следить, и шлет вам на почту отчет регулярно в указанное время в виде симпатичного простого отчета:
Хотя по большому счету конечно хранение и анализ логов лучше доверить чему-то по серьезней, типа rsyslog +LogAnalyzer или ELK.
Но мы помним что вопрос идет про 1 сервер!
Сканирование
Время от времени не плохо было бы проверить Ваш сервер — а не забыли ли Вы чего, а не поселилось ли там что? Для этого нам помогут различные сканеры:
- Сканеры руткитов — помогут проверить, не завелась ли на сервере подозрительная бяка
- Онлайн сканеры сайта — проверят нет ли на страницах вашего сайта подозрительных вставок, скриптов и тп. Таковых в сети много — начиная от известного VirusTotal и различных антивирусных компаний и заканчивая просто отдельными сайтами.
- Сканеры уязвимостей — ну тутв помощь идут классический nmap (хотя он не совсем сканер уязвимостей но тоже в это может), или мощнейший Nessus. Только учтите что такое сканирование может сайт и «приложить»
Заключение
На этом все. Друзья — спешу повторить, что эта статья НЕ является исчерпывающим руководством. Это БАЗА, которую нужно знать и применять. Существует огромное множество руководств по настройкам и харденингу, как более подробных, так и узкоспециализированных, затрагивающих вопросы, которых мы в рамках данной статьи не касались — например тюнинг ядра Linux для повышения сетевой безопасности. Но эти меры уже нельзя назвать общими и применимыми в 99% случаев. Скорее наоборот — Вы четко должны понимать зачем вы это делаете, а главное ЧТО вы собираетесь делать и какие последствия это действие может за собой повлечь.
Всем спасибо, до новых встреч! Всем высокого аптайма!
П.С. Подписывайтесь на мой Telegram канал