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

Комментарии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментировать

Filtered HTML

  • Доступны HTML теги: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote> <strike> <code> <h2> <h3> <h4> <h5> <del> <img>
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Строки и параграфы переносятся автоматически.

Plain text

  • HTML-теги не обрабатываются и показываются как обычный текст
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Строки и параграфы переносятся автоматически.