Ответьте параноику.
Итак, что было сделано:
сервер:
- запретил вход из под рута по SSH
- поменял порт SSH
- повесил fail2ban на mysqld, ssh с количеством попыток 3
- для каждого сайта создал своего пользователя mysql
- запретил заходить выше /var/www по SSH, без sudo su
сайты:
- так как использую Yii2, все данные из базы берутся с помощью PDO/AR, с биндингами
- запретил выполнение скриптов в папках, куда загружаются файлы
- включил csrf
- включил https
- шифрую данные клиентов, такие как email и пароль. Пароли не храню вообще, храню хеши. MD5 + соль надежно ли?
- бекапы еженедельно.
Можно ли теперь спать спокойно или что-то я упустил? Как вы защищаете сервера от доступа извне?
oni__ino: Хм, а что тут обновлять? Сейчас держу PHP 7.0, буду делать откат до PHP 5.6, так как по последнему ченжлогу, 7.0 решето. Также стоит MySQL 5.6, Nginx 1.10 (вот его да - надо обновлять). Ubuntu 16.04 еще сырая жуть, как минимум год сидеть буду на 14.04
Используйте контенеры. Создавайте отдельный контейнер со всем софтом для каждого сайта отдельно. В корневой системе оставьте только базовый софт и фаервол. Прокиньте внутрь только 80/443 порты. Ну и ссх по ключу в корневой. Даже если вам таки взломают один из сайтов - проникнуть в соседний контейнер будет проблематично. Что бы не настраивать каждый контейнер ручками - используйте chef/ansible или что угодно на ваш вкус. И каждый новый сайт - новый контейнер со своими mysqld/php/nginx и всем остальным. Даже если случайно установите что-то не защищенное из софта - получить к нему доступ их вне проблематично.
Создайте отдельный контейнер с nginx на который фаервол перенаправит 80/443 порты. А он уже проксирует запросы в нужные контейнеры. В нем же храните и SSL сертификаты и ключи. Что б их не угнали при взломе.
И конечно ossec или аналоги + оповещения от него. Расскажут вам о вторжении в тужу минуту. Ставить в каждый контейнер.
сервер:
- запретил вход из под рута по SSH
ни разу на тысячах серверов у меня не сломали рута за 10 лет
- поменял порт SSH
просто засканить можно ваш новый порт, тоже смысла нет
- повесил fail2ban на mysqld, ssh с количеством попыток 3
ни разу у меня не подобрали пароль на мускул или ссх на тысячах серверов за 10 лет , используйте длинные генеренные пароли и спите спокойно, от реальной угрозы если вы профукали пароль это не спасет
- для каждого сайта создал своего пользователя mysql
о боже , а что как то по другому бывает? даже говнопанели создают так
- запретил заходить выше /var/www по SSH, без sudo su
вообще зачем кому то разрешать туда заходить
используйте авторизацию по ключам а не по паролям для ссх
fman2: То, что вам не сломали SSH -- не означает, что его никому не сломали. Ну и в любом случае, перевешивание SSH на нестандартный порт в десятки разы снижает количество попыток подбора пароля со стороны ботов и скрипт-киддис. Да и логи замусориваются существенно меньше.
athacker: пфффффффф ага логи это секьюрная проблема. Если вы используете легкие пароли перемешивание на другой порт вас не спасет, если вы используете правильные пароли то и на стандартном порту их никогда не подберут, в общем это больше из разряда удобства что лог стал меньше а не про безопасность
Пума Тайланд: переполненные логи трудно читать, а следовательно, затрудняется расследование инцидентов. Так что да, куча левой информации в логах (которой легко избежать) -- это в том числе и секурная проблема.
athacker: о у ну вы прямо нашли проблему, а что если вас будут долбить на нестандартный порт и тоже будут переполненные логи, что теперь не делать расследований, ну есть греп есть другие штуки , ну не надо смешить тапочки что большой лог это все конец.
Пума Тайланд: как я уже сказал выше, перевешивание SSH на нестандартный порт делает количество попыток подбора пароля статистически незначимым. В то время как на стандартном количество таких попыток исчисляются минимум сотнями в день.
athacker: то есть вы реально считаете что перенос порта уменьшит вероятность подбора 20 символьного генеренного пароля?
И вы реально считаете что если вас взломали , маленький лог это какое то преимущество?
Еще раз скажу что перенос порта это мелкое удобство не имеющее отношения к безопасности.
Вот к примеру использование ключей вместо пароля и правильное их хранение это про безопасность,а перенос портов это просто баловство.
Пума Тайланд: я реально считаю, что безопасность -- это комплекс мероприятий. В который входят как генерация ключей на вход и сложные пароли, так и перенос портов. Не очень понимаю, почему у вас в голове это стало взаимоисключающими параметрами.
Karmashkin: То, что они трутся -- это не проблема, если у вас настроено централизованное логирование на отдельный syslog-сервер :-) А то, что их можно анализировать... Если злодей уже получил доступ к серверу -- что ему с тех логов?
Karmashkin: история команд -- это комплекс шагов, которые привели сервер к его текущему состоянию. Т.е. тому, к которому злоумышленник уже получил доступ. Зачем ему история? Знаете какие-либо реальные сценарии, когда история команд помогла с развитием взлома? К тому же, чтобы полную историю команд вести -- это надо специфично настраивать сервак, а просто включенный аудит показывает только исполняемые файлы.
un1t подскажете команду, которой можно запретить? Вроде бы порты не открываются, пока нет приложений, которые их слушают или не так? FTP я вообще не использую.
- еженедельный бекап - ИМХО слишком редко, хотя бы ежедневный
- после обновлений не забывать перезапустить сервисы, которым нужно подхватить новые либы. Можно посмотреть, что требует перезапуска, с помощью needrestart -r l
- веб-приложения можно закрыть WAF. Есть modsecurity, есть naxsi(только для nginx). Но это требует значительного времени на настройку и поддержку
- можно поставить HIDS, например ossec. После грамотной настройки ловит подозрительную активность, надо не забывать регулярно просматривать отчёты
- можно поставить NIDS: snort, suricata
- можно почитать PCI DSS и реализовать понравившиеся моменты
Павел, спасибо за ответ!
На счет бекапов - база ежедневно, сайты еженедельно. Дело в том, что на одном сайте у меня практически ничего не меняется в плане кода, файлов, а второй сайт занимает больше одного терабайта и его бекаплю я частям, просто физически каждый день бекапить невозможно:)
fman2: Есть смысл бэкапить сервер, а не только сайты и базу.
Положим раз в неделю full и каждый день инкрементом или дифференциалом (тут по вкусу в зависимости от задач)
fman2: а что непонятного? У вас один зараженный сайт не сможет заразить бд другого. А чаще заражение происходит через файлы. Альтернативы PMA есть - Adminer, phpminiadmin. Но PMA - лучший.
fman2: пользователь системы от имени которого запускается mysql, этот пользователь должен иметь права на запись только в свой каталог, где лежит его БД.
пользователь mysql - это пользователь от имени которого подключаются в mysql для получения данных.
Вход по SSH только по ключу. Не по паролю.
Изоляция приложений в отдельных контейнерах. Всех приложений. Как правило 1 приложение 1 контейнер. Ну в крайнем случае - chroot на каждый сайт.
Открыть на файрволе только необходимые порты (как правило 22, 80, 443 и все).
но если у вас текучий движок сайта - то все плохо.
обновлять регулярно.
продумать еще раз как выставить права на каталоги.
Соберем все в кучу:
1.ssh - запрет рута, вход по ключу.
2.фаервол - запретить все, кроме нужного.
3.контейнеры для каждого приложения.
4.запретить mysql смотреть на ружу.
5.сменить хэш md5 на более современный алгоритм.
Посмотрел я этот пост и вспомнил, как перед нг настроивал своего монстра. Перечитал много ненужной информации на тему безопасности. Чего только не советую делать и не делать.
В итоге плюнул: длинный пароль на
SSH + fail2ban
Виртуализация на XEN, под каждый сервис своя виртуалка. 2 виртуалки с http/mysql. Между двумя mysql репликация.
Бэкапятся ежедневно все виртуалки
Ну и так как я далек от сисадминства и ленивый шопипец:
При заходе по ssh из вне >> sms на телефон
И пару скриптов с говорящими названиями и запускаемые через бота telegram:
Сосискасарделька - поменять местами http виртуалки
mayday - завершение виртуалок, бэк-ап, перекинуть на диск и зашифровать случайным ключем диск целиком. У меня на тесте это делается за 15 секунд.
Жопа - закрыть все порты.
PS: Mysql смотрит наружу, это нужно. Пароли везде длинные. Но сам пользуюсь phpmyadmin, который весит на домене прописанном в hosts на своей машине. Нет домена - нет доступа. Очень удобно.
Еще изменил настройки fail2ban. Чтоб бан был не 15 минут, а сразу сутки. По SSH мало кто ломает, 2-3 бана в день. А вот на SIP порты список бана в день переваливает за 300 правил.
Алексей Ярков: sms.ru + google в помощь на тему, как вписать скрипт обработчик при выполнении успешного входа SSH. 5 сообщений на сервере бесплатно на свой телефон. Скрипт прописал на запуск прямо из примеров работы API PHP, изменив текст
Алексей Ярков: На самом деле, я не знаю что у вас за данные. У меня на железе данные, которые по стоимости превышают его стоимость раз в 100. И я такой херней не страдаю как вы. При этом уверяю вас, сервер личный и трафик на него идет знатный. Просто я избрал безопасность несколько иного формата, поговорив с людьми которые сидят на всяких CDN и крупных точках обмена трафика. Переводя смысл их слов в человекопонятный язык: Либо ты закрываешь все возможные дырки в безопасности - что априори невозможно, либо ты делаешь взлом бессмысленным подразумевая - хорошая система безопасности не так, которую сложно сломать. А та, которая не дает после взлома доступ к данным внутри и восстановление работы идет одной-двумя командами
Алексей Ярков: это намек на то, что вы параноик, в менее деликатной форме. Не более. Призыв к действию, а точнее бездействию и успокоению. Как вам легче, так и воспринимайте
Простой
Сложный
