Как у меня 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 и на серверах. Куда-то не туда повел дистрибутив араб из-под Парижа.

4.42857
Ваша оценка: Нет Средняя оценка: 4.4 (7 votes)

Много лет обслуживаю разные сервера с линуксами и другими *nix'ами, и всегда стараюсь избегать использование решений вроде netfilter-persistent. Судя по этой записи — не зря. Сохранять РУЧНЫЕ настройки файрвола при перезагрузке на боевом сервере — это очень плохая идея. Мало-ли какой руткит или прочее говно можно подцепить за 7 лет эксплуатации, так оно ещё и после перезагрузки все нужные ему порты любезно откроет из прошлой сессии.
Не буду учить автора как нужно админить сервера, но, я считаю, что нужно стремиться к ситуации, когда в системе ничего не будет сохранятся персистентно, кроме непосредственно данных самого сервиса (сайта, или базы данных). То есть — вся система и её конфигурация кроме данных серверного приложения должна быть только на чтение. При перезагрузке системы — всё кроме конфигурации и данных приложения должно очищаться. В принципе, конфигурацию на некий "базовый образ" можно накатывать непосредственно перед стартом, скажем через оверлейную ФС. и держать снимки конфигурации, в какой-нибудь VCS типа гита.
Всё это конечно, сложно, и на 100% практически не реализуемо, но моё ИМХО — к этому надо стремиться. А то искать и чистить потом сервак от всякой дряни как-то тоже не комильфо. Да и вообще — такой подход, он как TDD в программировании — даёт некую уверенность, что сейчас ваш деплой работает, и будет работать так-же и завтра и на новом сервере.

Ваша оценка: Нет Средняя оценка: 5 (3 votes)
pomodor

При перезагрузке системы — всё кроме конфигурации и данных приложения должно очищаться.

Так список блокируемых узлов и политика фильтрации — это и есть, в некотором смысле, конфигурация. Только она создается динамически. Ведь нет никакого смысла обнулять блокировку тех хостов, которые постоянно пытаются рассылать спам и создают паразитный трафик.

Но за совет спасибо. Наверное, стоит подумать об этом. Просто я даже не догадывался, что netfilter-persistent и служба обновлений настроены на такое опасное поведение. Конфиг можно действительно не хранить, а создавать на лету на время аптайма. Тем более, что это месяцы, а иногда и годы. В принципе, тот же fail2ban создает отдельные цепочки для iptables на основе логов. Если что похерится, то новые правила будут воссозданы сами по мере роста журналов.

Ваша оценка: Нет Средняя оценка: 5 (2 votes)

К сожалению, по закону подлости, оно всегда так — подобные критичные для безопасности штуки вылезают в самых казалось-бы привычных и проверенных местах. Взять тот-же bash shellshock или exec через dns. Бороться с этим можно при помощи изоляции системы от сервисов: контейнеры и виртуальные машины, описанное выше разделение системы на read-only и read-write части. Применение всяких систем ограничения доступа типа apparmor'а или selinux. А ещё можно проводить аудит безопасности и автоматизированные secuirity-check'и со внешней машины.

Ваша оценка: Нет

В дополнение к моему предыдущему комменту по поводу того что п**дец подкрадывается незаметно: на днях заметил что повреждается файловая система ext4 на одном серваке. Повреждаются данные некоторых файлов при записи, при определённом характере нагрузки на сервер. Сам сервер офисная файлопомойка с самбой, NFS, webdav и прочим. Почти 2 дня потратил чтобы стабильно воспроизвести глюк. А когда получилось, уже даже и не знал в какое спортлото об этом писать.
Сейчас вот залез на kernel.org, а там новые версии ядер (в частности 4.4.9) — смотрю, а там как раз в ченджлоге дофига багов для ext4 поправлено. Собрал новое ведро, обновился — данные повреждаться перестали. Вот тебе и глюк в испытанной системе. Так что бдительность терять нельзя... Эх. теперь вот осталось понять, сколько ещё данных могло повредиться до того как я это заметил и как долго они портились.

Ваша оценка: Нет
Texnoline

использовать jfs — религия не позволила?

Ваша оценка: Нет

стараюсь избегать использование решений вроде netfilter-persistent. Судя по этой записи — не зря. Сохранять РУЧНЫЕ настройки файрвола при перезагрузке на боевом сервере — это очень плохая идея.

Я тоже предпочитал использовать возможности ifupdown, запуская правила для интерфейса только при поднятии интерфейса, но не соглашусь с такой критикой. Насколько я понял, -persistent сохраняет настройки только если его об этом попросить командой save. Ну или если вписать её в какой-нибудь скрипт завершения работы.

Ваша оценка: Нет

Давно заметил, как только куда то протягивают свои шаловливые ручки всякие арабоиндусы, все сразу же летит в тартарары..

Ваша оценка: Нет Средняя оценка: 2.3 (3 votes)

Протяните свои.

Ваша оценка: Нет Средняя оценка: 5 (2 votes)

Там, куда я протягиваю свои, всё работает годами без сбоев

Ваша оценка: Нет Средняя оценка: 3 (2 votes)

Ну, дык тогда вперёд — OSS сообществу вас не хватает! Идите, в начальники всея дебиана, может, глядишь, и толк выйдет, и мы получим наконец дистрибутив мечты.

Ваша оценка: Нет Средняя оценка: 5 (2 votes)

Ох уж эти разработчики. В серверах не разбираются. Совсем ничего не понимают.

Ваша оценка: Нет

Билла Гейтса на них не хватает.

Ваша оценка: Нет

Часто пишут, что что Debian может работать годами стабильно и без перезагрузок.
Но один, лично со мной незнакомый человек, все же взял, да и перезагрузил.. И что-то пошло не так..

Ваша оценка: Нет

Примерно так же матерился пару недель назад, когда они при апдейте самбы отменили "security = share" и ничего об этом не сказали.

Ваша оценка: Нет

Я вообще то новичёк в линуксе, потому себе поставил линукс минт и для игр 10ку. 4 дня назад при загрузке 10ки я видел только чёрный экран. Ни sfc /scannow ни чего другог не помогло. Как ни странно backup images все исчезли. Но самое странное окозалось то, что и линукс завис на чёрном экране а через несколько рестартов на своём logo. Пришлось всё сносить и ставить 7рку .
Что это может быть?

Ваша оценка: Нет

Как ни странно backup images все исчезли.

Храните на другом разделе или внешнем носителе.

Ваша оценка: Нет

Это пипец, товарищи!

Ваша оценка: Нет
Texnoline

все что угодно:) и телепатов на данном ресурсе не наблюдается!

Ваша оценка: Нет

Я думаю проблема не в арабе, а в systemd. Debian сдался ему раньше, чем вышла 8-я версия. Т. е. автор имхо сам виноват, что не соскочил и обновился, когда дистр повернул в нетуда и начал превращаться в убунту/виндовс.

Ваша оценка: Нет
Отправить комментарий
КАПЧА
Вы человек? Подсказка: зарегистрируйтесь, чтобы этот вопрос больше никогда не возникал. Кстати, анонимные ссылки запрещены.
CAPTCHA на основе изображений
Enter the characters shown in the image.