Vera_Petrov
New member
Помню вечер, когда я случайно наткнулся на свой же тестовый сервер, который спокойно жил в интернете уже полгода. Пароль от рута был из разряда «придумал на бегу», SSH висел на 22 порту, а база данных смотрела наружу так же уверенно, как я смотрел на неё с ужасом. Именно тогда я понял простую вещь: безопасность — это не про сложные слова и не про корпоративный бюджет, а про десяток скучных настроек, которые занимают полчаса и снимают девяносто процентов головной боли. Ниже — те восемь пунктов, которые я теперь прогоняю на каждом новом сервере и в каждом новом репозитории, и делаю это раньше, чем устанавливаю первый пакет.
Начинаю всегда с SSH, потому что это входная дверь, и именно по ней ломятся боты круглосуточно. Отключаю вход root напрямую, оставляю аутентификацию только по ключу и запрещаю вход по паролю целиком. Порой меняю дефолтный порт — не как серьёзную защиту, а как способ убрать из логов девяносто процентов мусора и сразу видеть настоящие попытки взлома. Плюс ограничиваю список пользователей, которым вход вообще разрешён, и ставлю таймаут неактивной сессии. Пятнадцать минут работы, а спать становится заметно спокойнее.
Второй пункт — фаервол по принципу «запрещено всё, что не разрешено явно». Открытыми оставляю только те порты, которые реально нужны наружу, а базу данных, кэш и панели администратора прячу на localhost или закрываю доступом через туннель. Третьим пунктом идёт fail2ban: он банит адреса после нескольких неудачных попыток входа и честно срезает фоновый шум. Эти две настройки вместе дают тот эффект, когда сервер перестаёт быть заметен для автоматических сканеров — не потому что стал неуязвим, а потому что перестал быть лёгкой добычей.
Четвёртая настройка самая ленивая и самая важная: автоматические обновления безопасности. Я больше не жду «выходных, чтобы обновить всё руками», потому что откладывать патчи — это и есть главный источник уязвимостей в реальных проектах. Раз в неделю отдельно проверяю, что требует перезагрузки, и планирую её заранее, а не в момент внезапного падения. Пятый пункт — гигиена пользователей: никакой работы под root, у каждого человека свой аккаунт с sudo, доступы выдаются по необходимости и отзываются, когда человек уходит. И отдельно про Docker: сокет контейнеров — это фактически root, поэтому к нему не должно быть доступа у всех подряд.
Дальше перехожу к репозиторию, и тут моя главная боль — секреты. Шестой пункт: ни одного токена, пароля или ключа в коде и в истории коммитов. Всё живёт в переменных окружения и в защищённых настройках CI, файл с локальными значениями добавлен в игнор-лист с первого коммита, а не после инцидента. Если секрет всё-таки утёк, я не надеюсь на удаление коммита, а просто меняю сам ключ — это быстрее и надёжнее. Седьмой пункт — защита самой ветки: обязательная проверка перед слиянием, запрет принудительной отправки, запрет прямых коммитов в главную ветку и двухфакторная аутентификация для всех, у кого есть право писать в проект. Это дёшево, а ломает большинство сценариев «случайно сломал прод» и «залил утёкший ключ».
Восьмой пункт я долго считал необязательным, а зря: бэкапы и наблюдаемость. Резервные копии, которые ни разу не проверяли на восстановление, — это не бэкапы, а надежда. Я раз в месяц разворачиваю копию в отдельном месте и убеждаюсь, что данные живые, а доступ к самой копии закрыт отдельными ключами. Рядом — простые алерты на подозрительные вещи: всплеск неудачных входов, новый слушающий порт, вход в аккаунт из незнакомой страны, резкий рост трафика. Часто одна такая мелочь рассказывает о проблеме раньше, чем о ней сообщат пользователи.
Весь этот список я укладываю в один вечер и честно скажу: он не делает проект неуязвимым, но убирает целый класс скучных, обидных и абсолютно предсказуемых аварий. Самое ценное тут не технологии, а привычка делать это сразу, на пустом сервере и в пустом репозитории, когда настроить десять минут, а не разгребать последствия неделю. Заодно такой чек-лист отлично экономит нервы в команде: когда правила заданы заранее, спорить о них почти не приходится.
А теперь вопрос к вам, коллеги: какая настройка из вашего личного чек-листа однажды спасла вас от реальной проблемы — и что вы добавляете в него, когда времени всего полчаса? Делитесь историями, у вас наверняка есть пара приёмов, до которых я пока не дошёл.
Начинаю всегда с SSH, потому что это входная дверь, и именно по ней ломятся боты круглосуточно. Отключаю вход root напрямую, оставляю аутентификацию только по ключу и запрещаю вход по паролю целиком. Порой меняю дефолтный порт — не как серьёзную защиту, а как способ убрать из логов девяносто процентов мусора и сразу видеть настоящие попытки взлома. Плюс ограничиваю список пользователей, которым вход вообще разрешён, и ставлю таймаут неактивной сессии. Пятнадцать минут работы, а спать становится заметно спокойнее.
Второй пункт — фаервол по принципу «запрещено всё, что не разрешено явно». Открытыми оставляю только те порты, которые реально нужны наружу, а базу данных, кэш и панели администратора прячу на localhost или закрываю доступом через туннель. Третьим пунктом идёт fail2ban: он банит адреса после нескольких неудачных попыток входа и честно срезает фоновый шум. Эти две настройки вместе дают тот эффект, когда сервер перестаёт быть заметен для автоматических сканеров — не потому что стал неуязвим, а потому что перестал быть лёгкой добычей.
Четвёртая настройка самая ленивая и самая важная: автоматические обновления безопасности. Я больше не жду «выходных, чтобы обновить всё руками», потому что откладывать патчи — это и есть главный источник уязвимостей в реальных проектах. Раз в неделю отдельно проверяю, что требует перезагрузки, и планирую её заранее, а не в момент внезапного падения. Пятый пункт — гигиена пользователей: никакой работы под root, у каждого человека свой аккаунт с sudo, доступы выдаются по необходимости и отзываются, когда человек уходит. И отдельно про Docker: сокет контейнеров — это фактически root, поэтому к нему не должно быть доступа у всех подряд.
Дальше перехожу к репозиторию, и тут моя главная боль — секреты. Шестой пункт: ни одного токена, пароля или ключа в коде и в истории коммитов. Всё живёт в переменных окружения и в защищённых настройках CI, файл с локальными значениями добавлен в игнор-лист с первого коммита, а не после инцидента. Если секрет всё-таки утёк, я не надеюсь на удаление коммита, а просто меняю сам ключ — это быстрее и надёжнее. Седьмой пункт — защита самой ветки: обязательная проверка перед слиянием, запрет принудительной отправки, запрет прямых коммитов в главную ветку и двухфакторная аутентификация для всех, у кого есть право писать в проект. Это дёшево, а ломает большинство сценариев «случайно сломал прод» и «залил утёкший ключ».
Восьмой пункт я долго считал необязательным, а зря: бэкапы и наблюдаемость. Резервные копии, которые ни разу не проверяли на восстановление, — это не бэкапы, а надежда. Я раз в месяц разворачиваю копию в отдельном месте и убеждаюсь, что данные живые, а доступ к самой копии закрыт отдельными ключами. Рядом — простые алерты на подозрительные вещи: всплеск неудачных входов, новый слушающий порт, вход в аккаунт из незнакомой страны, резкий рост трафика. Часто одна такая мелочь рассказывает о проблеме раньше, чем о ней сообщат пользователи.
Весь этот список я укладываю в один вечер и честно скажу: он не делает проект неуязвимым, но убирает целый класс скучных, обидных и абсолютно предсказуемых аварий. Самое ценное тут не технологии, а привычка делать это сразу, на пустом сервере и в пустом репозитории, когда настроить десять минут, а не разгребать последствия неделю. Заодно такой чек-лист отлично экономит нервы в команде: когда правила заданы заранее, спорить о них почти не приходится.
А теперь вопрос к вам, коллеги: какая настройка из вашего личного чек-листа однажды спасла вас от реальной проблемы — и что вы добавляете в него, когда времени всего полчаса? Делитесь историями, у вас наверняка есть пара приёмов, до которых я пока не дошёл.