Предупреждение о взломах Debian-систем

[@Drakula2k]

Какие порты были открыты?

[@trak]

Вообще-то говоря, все те-же, что и сейчас, если Вам не сложно, запустите nmap на меня :)

Я-то надеюсь, что только:

iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A block -m state --state NEW -p tcp --dport 20 -j ACCEPT
iptables -A block -m state --state NEW -p tcp --dport 21 -j ACCEPT
iptables -A block -m state --state NEW -p tcp --dport 22 -j ACCEPT
iptables -A block -m state --state NEW -p tcp --dport 25 -j ACCEPT
iptables -A block -m state --state NEW -p tcp --dport 53 -j ACCEPT
iptables -A block -m state --state NEW -p udp --dport 53 -j ACCEPT
iptables -A block -m state --state NEW -p tcp --dport 79 -j ACCEPT
iptables -A block -m state --state NEW -p tcp --dport 80 -j ACCEPT
iptables -A block -m state --state NEW -p tcp --dport 110 -j ACCEPT
iptables -A block -m state --state NEW -p tcp --dport 113 -j ACCEPT
iptables -A block -m state --state NEW -p tcp --dport 1138 -j ACCEPT
iptables -A block -m state --state NEW -p tcp --dport 2706:2716 -j ACCEPT
iptables -A block -m state --state NEW -p tcp --dport 4662 -j ACCEPT
iptables -A block -m state --state NEW -p tcp --dport 4662 -j ACCEPT
iptables -A block -m state --state NEW -p udp --dport 4663 -j ACCEPT
iptables -A block -m state --state NEW -p udp --dport 4663 -j ACCEPT
iptables -A block -m state --state NEW -p tcp --dport 5900:5910 -j ACCEPT
iptables -A block -m state --state NEW -p udp --dport 30269 -j ACCEPT
iptables -A block -m state --state NEW -p udp --dport 16698 -j ACCEPT
iptables -A block -m state --state NEW -p tcp --dport 27359 -j ACCEPT
iptables -A block -m state --state NEW -p tcp --dport 20498 -j ACCEPT

[@BaBL]

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

нельзя так заголовками пугать!

[@trak]

Файл-то /etc/passwd проверили уже свой?

[@BaBL]

чист как стеклышко, ничего лишнего

[@trak]

Я эту статью тут и писал только для того, чтобы все причастные проверили свой /etc/passwd, спасибо!

[@jj_killer]

Поищите суидные перл скрипты с правами 777, проверьте логи доступа по фтп и ссх, может пароль сбрутфорсили, может пароли на фтп и ссх совпадают и их выдернули с трафика или трояном. Существуют сотни других способов скомпрометировать систему без явных уязвимостей.

[@trak]

Да вроде стоит монитор изменений суидный файлов! Кто-то очень ушлый был.

[@amarao]

Если не боитесь, дайте адрес сервера, посмотрю. Обещаю по мере возможности ничего не портить.

[@trak]

trak.spb.ru

[@amarao]

Какие-то мелочи видны (ошмётки исталляшки durpala), но ничего крамольного ни nikto, ни ovs не нашли.

[@trak]

В том-то и дело, что странно все это. Ну сломали-бы веб-сервер, но ведь он не от рута работает!

[@trak]

Поясню. Смотрите, у меня не было мыслей, что подсунули нового юзера. Я подумал, что моя дочка или сын поставили себе пароль из разряда love/sex/123/god

поэтому это первое, что пришло в голову. Да и на телефоне трудно просмотреть весь файл /etc/passwd :)

[@rtzra]

Невнятная заметка — надо искать причину взлома, а не писать глупости. Вполне вероятно что взлом прошел через какой-нибудь баговый (возможно давно не обновляемый) софт. Поэтому автору — анализ логов и переустановка системы.
Ждем с интересом результатов.

[@spanasik]

> переустановка системы

Вы это на полном серьёзе?

[@rtzra]

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

[@trak]

Там достаточно много всего установлено. И несколько некоммерческих сайтов крутится. Причем, хозяева некоторых вообще не в России живут.

[@BaBL]

мусье не знает толк в линуксах?

[@RainFall]

??
Слить систему на другой диск посекторно для анализа и полностью переустановить то, что есть — это нормально.

[@trak]

Да, нормально. Когда это время кто-то оплатит. А это мой домашний сервер.

[@trak]

Переустановка системы не unix-way. Этой инсталляции больше 10 лет.
А писать глупости, извините, по-другому не могу, видимо мой ущербный интеллект не позволяет писать умности.

[@BaBL]

если есть подозрения на внедрение руткитов, можешь попробовать на ночь воткнуть debsums чтоб проверить целостность файлов + отдельно отследить опции sshd (permitrootlogin no естественно) и apache/php или что стоит у Вас там. Заодно проверить логи CMS, возможно уязвимый пойзон какой протолкнули (к примеру на недостаточных фильтрациях для метода PUT можно подскользнуться и так далее. Я думаю у Вас уязвимость скорее всего в скриптах на вебе, либо брутом ssh, что-то изощренное совсем для спама изобретать никто не будет, ИМХО. Еще у Вас пароль на ssh не один и тот же с почтой или какими-нибудь хабрахабрами? может ломанули какой-нить другой ресурс?

[@Homakov]

>и у меня в руках был только телефон
он байткодом шипел в трубку или как

[@Homakov]

буду знать, я думал только под кпк есть. набор команд выше займет минут 10

[@trak]

Извините, у меня андроид с ssh. Выполнение этих команд, плюс postsuper -d ALL заняло около двух минут, стоя в очереди у кассы Ашана.

[@DuskMan]

Предупреждение о взломах Debian-систем

К чему этот желтый заголовок?

P.s. Нечего на зеркало пенять, коли рожа крива

[@trak]

Благодарю за ценное и полезное замечание относительно моей рожи. Просто я с этим Дебианом живу примерно с 1998 года, и думал, что имею некоторое право кривить свою рожу. Извините, что побеспокоил.

[@DuskMan]

некоторое право кривить свою рожу

Ваше право, только это была пословица, ничего личного.

[@trak]

Золотые слова, золотые слова.

[@trak]

В общем да. Всякие nethack и прочие, у них файлы scoreимели хозяина games, а файл игры был suid. Только вот зачем ему /bin/sh, а не /bin/false — загадка!

[@adminimus]

>Потом я обновил aptitude update; aptitude full-upgrade до squeeze.
testing на сервере? Да вы суровы

[@trak]

Есть такое дело. :) Но ведь не unstable-же! Признайте мою недостаточную суровость, а не то вызову Вас на дуэль :)

[@adminimus]

>Но ведь не unstable-же!
с тестингом не так координально отличаются. Я не первый год тестинг на десктопе использую, периодически приходит мешок граблей вместе с обновлениями. Да и с безопасностью на тестинге как раз обычно хуже, чем на стейбле.

[@BaBL]

для стейбла апдейты раз в полгода, кроме критики, для тестинга постоянно.

тестинг дебиана, вообще, будет постабильней многих релизов.

я серваки держу на SID'е, признаю, потенциально не безопасно, но, ИМХО, если не страдать совсем изощренной паранойей, то тоже вполне комфортно. По крайней мере синдром неуловимого Джо работает пока что, а толпу китайских ssh root брутов все равно не волнует дебиан там или виндовс.

[@AusTiN]

>а толпу китайских ssh root брутов все равно не волнует
а меня не волнуют китайские ssh бруты — iptables наше всё!
:)

[@trak]

Я придерживаюсь именно этого мнения.

[@adminimus]

>для стейбла апдейты раз в полгода, кроме критики, для тестинга постоянно.
ну вот и зачем вам на сервере постоянно самый свежий софт? Я и на десктопе иногда огребаю проблем с новыми версиями, бывает что-нибудь ломается и отваливается из-за несовместимости

>тестинг дебиана, вообще, будет постабильней многих релизов.
соглашусь, но уточню: десктопных дистров :)

[@BaBL]

да ладно десктопных… убунта вон на SID базируется и ничего.

для начала, у меня на серверах нету Xorg, так что отгребать неоткуда, разве что от libc раз в год и то если знаешь что она будет обновляться — проблем нету.

[@adminimus]

>убунта вон на SID базируется и ничего.
ну я убунту как сервер всерьез не воспринимаю, хотя многие пользуются :)

>у меня на серверах нету Xorg, так что отгребать неоткуда
я про иксы и прочие десктопные вещи и не говорил, грабли бывают и в системных вещах. Недавно вот phpmyadmin ломался. В прошлом году огреб проблем с апачем, синтаксис конфигов слегка поменялся, но этого оказалось достаточно чтобы все сломать.

[@BaBL]

Для этого обновления сначала на тестовом сервере проводят.

phpmyadmin к дистрибутивным вещая я отнести не могу, всегда используют с оф сайта.

[@uran238]

Скорее всего, все же через web скрипты получили доступ.

[@trak]

Пользователь web-data не имеет рутового доступа. А nginx запущен от него и php-fpm, и apache2!

Так что вообще осталось загадкой, что это было. Думаю, ломанули кого-то из локальных пользователей, а потом нашли локальный exploit.

[@slimlv]

иметь мэйл пользователей в системных аккаунтах просто тупо

[@trak]

У меня наоборот. Это тоже тупо?

[@slimlv]

Тоже тупо. И за это Вас ломанули.
Системные аккаунты это чтобы в систему входить а не чтобы почту проверять

[@trak]

Ну хрен знает, юникс это юникс, и по ssh надо заходить, и почту там свою держать. Хотя конечно оптимально сейчас свою доменную почту отдавать на корню Google

[@slimlv]

большинство современные imap/pop серверов поддерживают аутентификацию из других источников кроме системного /etc/passwd — LDAP, Mysql, passwdfiles.
Таким образом разумно использовать системные пароли ТОЛЬКО для входа в систему.
В случае использования /etc/passwd для аутентификации почтовых пользователей желательно давать им шелом /bin/nologin

[@aspel]

обычно ломают через web, root можно получить эксплоитом.
смотри логи web сервера, на предмет PHP including.