Как у меня Debian 8 на сервере сломался
Решил запилить в личный блог сказ о том, как у меня впервые за 7 лет сервер с Debian дал сбой. Не знаю, связан ли как-то этот случай с новостью "Разработку Debian Linux возглавил араб из-под Парижа".
Итак, проверял недавно состояние web-серверов с сайтами клиентов и обнаружил на одном сервере упавший файервол. Да-да, правила iptables не только были обнулены, но и заботливо собранные адреса в /etc/iptables/rules.v* были затерты (бэкап был, но всё же...). Компьютер светил всеми открытыми портами в сеть. Что такое?
Оказалось, что установить причину не так-то просто. Спасибо systemd с его журналами и своеобразно раскиданными скриптами, модулями и логами. И спасибо разработчикам Debian, которые взялись за усложнение устройства дистрибутива сверх меры. Я о том, что в Debian 7 был прекрасный пакет iptables-persistent, позволявший на автомате сохранять введенные вручную правила для iptables, что позволяло им переживать перезагрузку. В Debian 8 iptables-persistent выкинули и запилили netfilter-persistent, который делает то же самое, но является надстройкой еще более высокого уровня. Оценили, да? iptables-persistent — это надстройка над iptables-save, а iptables-save — надстройка над iptables. Надстройка над надстройкой. И разработчикам Debian показалось этого мало. А еще systemd в Debian 8 в каком-то странном промежуточном состоянии и часть скриптов опирается на прежнюю систему инициализации. Таков Debian сегодня.
Результат: если раньше на локализацию подобной простой проблемы уходило минут 5, то теперь потребовалось 3 часа. Для тех, кому интересно расскажу в чем было дело. Одно из обновлений почему-то потянуло модуль ядра fuse, который на web-сервере не очень-то и нужен. Следующее обновление заменило этот модуль на криво собранный, который отказывался загружаться, но никаких уведомлений не выводилось. А systemd почему-то посчитал загрузку fuse зависимостью к netfilter-persistent, хотя это не так. И тоже промолчал. Таким образом, netfilter-persistent save затер конфиг пустым набором правил, а после перезагрузки восстановил этот пустой набор. Как догадаться, что одна из ключевых систем безопасности уничтожена? А никак. Это можно узнать только в том случае, если вы регулярно сканируете открытые вовне порты. Ну, либо после того, как сервер поимеют.
Я уже писал, что из-за проблем заменил Debian на Ubuntu на десктопе и остался доволен. Думаю, если ничего не изменится, то в ближайшие 2 года мы заметим спад интереса к Debian и на серверах. Куда-то не туда повел дистрибутив араб из-под Парижа.
Комментарии
Чингачгук
7 мая, 2016 - 00:24
Много лет обслуживаю разные сервера с линуксами и другими *nix'ами, и всегда стараюсь избегать использование решений вроде netfilter-persistent. Судя по этой записи — не зря. Сохранять РУЧНЫЕ настройки файрвола при перезагрузке на боевом сервере — это очень плохая идея. Мало-ли какой руткит или прочее говно можно подцепить за 7 лет эксплуатации, так оно ещё и после перезагрузки все нужные ему порты любезно откроет из прошлой сессии.
Не буду учить автора как нужно админить сервера, но, я считаю, что нужно стремиться к ситуации, когда в системе ничего не будет сохранятся персистентно, кроме непосредственно данных самого сервиса (сайта, или базы данных). То есть — вся система и её конфигурация кроме данных серверного приложения должна быть только на чтение. При перезагрузке системы — всё кроме конфигурации и данных приложения должно очищаться. В принципе, конфигурацию на некий "базовый образ" можно накатывать непосредственно перед стартом, скажем через оверлейную ФС. и держать снимки конфигурации, в какой-нибудь VCS типа гита.
Всё это конечно, сложно, и на 100% практически не реализуемо, но моё ИМХО — к этому надо стремиться. А то искать и чистить потом сервак от всякой дряни как-то тоже не комильфо. Да и вообще — такой подход, он как TDD в программировании — даёт некую уверенность, что сейчас ваш деплой работает, и будет работать так-же и завтра и на новом сервере.
pomodor
7 мая, 2016 - 01:38
Так список блокируемых узлов и политика фильтрации — это и есть, в некотором смысле, конфигурация. Только она создается динамически. Ведь нет никакого смысла обнулять блокировку тех хостов, которые постоянно пытаются рассылать спам и создают паразитный трафик.
Но за совет спасибо. Наверное, стоит подумать об этом. Просто я даже не догадывался, что netfilter-persistent и служба обновлений настроены на такое опасное поведение. Конфиг можно действительно не хранить, а создавать на лету на время аптайма. Тем более, что это месяцы, а иногда и годы. В принципе, тот же fail2ban создает отдельные цепочки для iptables на основе логов. Если что похерится, то новые правила будут воссозданы сами по мере роста журналов.
Чингачгук
7 мая, 2016 - 13:12
К сожалению, по закону подлости, оно всегда так — подобные критичные для безопасности штуки вылезают в самых казалось-бы привычных и проверенных местах. Взять тот-же bash shellshock или exec через dns. Бороться с этим можно при помощи изоляции системы от сервисов: контейнеры и виртуальные машины, описанное выше разделение системы на read-only и read-write части. Применение всяких систем ограничения доступа типа apparmor'а или selinux. А ещё можно проводить аудит безопасности и автоматизированные secuirity-check'и со внешней машины.
Чингачгук
7 мая, 2016 - 14:17
В дополнение к моему предыдущему комменту по поводу того что п**дец подкрадывается незаметно: на днях заметил что повреждается файловая система ext4 на одном серваке. Повреждаются данные некоторых файлов при записи, при определённом характере нагрузки на сервер. Сам сервер офисная файлопомойка с самбой, NFS, webdav и прочим. Почти 2 дня потратил чтобы стабильно воспроизвести глюк. А когда получилось, уже даже и не знал в какое спортлото об этом писать.
Сейчас вот залез на kernel.org, а там новые версии ядер (в частности 4.4.9) — смотрю, а там как раз в ченджлоге дофига багов для ext4 поправлено. Собрал новое ведро, обновился — данные повреждаться перестали. Вот тебе и глюк в испытанной системе. Так что бдительность терять нельзя... Эх. теперь вот осталось понять, сколько ещё данных могло повредиться до того как я это заметил и как долго они портились.
Чингачгук
4 октября, 2016 - 00:48
Я тоже предпочитал использовать возможности ifupdown, запуская правила для интерфейса только при поднятии интерфейса, но не соглашусь с такой критикой. Насколько я понял, -persistent сохраняет настройки только если его об этом попросить командой save. Ну или если вписать её в какой-нибудь скрипт завершения работы.
Чингачгук
7 мая, 2016 - 06:54
Давно заметил, как только куда то протягивают свои шаловливые ручки всякие арабоиндусы, все сразу же летит в тартарары..
Чингачгук
7 мая, 2016 - 12:05
Протяните свои.
Чингачгук
8 мая, 2016 - 05:58
Там, куда я протягиваю свои, всё работает годами без сбоев
Чингачгук
8 мая, 2016 - 16:47
Ну, дык тогда вперёд — OSS сообществу вас не хватает! Идите, в начальники всея дебиана, может, глядишь, и толк выйдет, и мы получим наконец дистрибутив мечты.
Чингачгук
7 мая, 2016 - 12:11
Ох уж эти разработчики. В серверах не разбираются. Совсем ничего не понимают.
Чингачгук
7 мая, 2016 - 12:13
Билла Гейтса на них не хватает.
Чингачгук
7 мая, 2016 - 12:22
Часто пишут, что что Debian может работать годами стабильно и без перезагрузок.
Но один, лично со мной незнакомый человек, все же взял, да и перезагрузил.. И что-то пошло не так..
Чингачгук
8 мая, 2016 - 11:22
Примерно так же матерился пару недель назад, когда они при апдейте самбы отменили "security = share" и ничего об этом не сказали.
Чингачгук
10 мая, 2016 - 05:25
Я вообще то новичёк в линуксе, потому себе поставил линукс минт и для игр 10ку. 4 дня назад при загрузке 10ки я видел только чёрный экран. Ни sfc /scannow ни чего другог не помогло. Как ни странно backup images все исчезли. Но самое странное окозалось то, что и линукс завис на чёрном экране а через несколько рестартов на своём logo. Пришлось всё сносить и ставить 7рку .
Что это может быть?
Чингачгук
10 мая, 2016 - 22:42
Храните на другом разделе или внешнем носителе.
Чингачгук
3 июня, 2016 - 22:35
Это пипец, товарищи!
Чингачгук
4 октября, 2016 - 00:52
Я думаю проблема не в арабе, а в systemd. Debian сдался ему раньше, чем вышла 8-я версия. Т. е. автор имхо сам виноват, что не соскочил и обновился, когда дистр повернул в нетуда и начал превращаться в убунту/виндовс.
Комментировать