Комментарии 55
Какие порты были открыты?
Вообще-то говоря, все те-же, что и сейчас, если Вам не сложно, запустите 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
Я-то надеюсь, что только:
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
блин, я уже запаниковал побег читать, а тут никакой инфы про взломы дебиана и не последовало.
нельзя так заголовками пугать!
нельзя так заголовками пугать!
Файл-то /etc/passwd проверили уже свой?
чист как стеклышко, ничего лишнего
Поищите суидные перл скрипты с правами 777, проверьте логи доступа по фтп и ссх, может пароль сбрутфорсили, может пароли на фтп и ссх совпадают и их выдернули с трафика или трояном. Существуют сотни других способов скомпрометировать систему без явных уязвимостей.
Если не боитесь, дайте адрес сервера, посмотрю. Обещаю по мере возможности ничего не портить.
Невнятная заметка — надо искать причину взлома, а не писать глупости. Вполне вероятно что взлом прошел через какой-нибудь баговый (возможно давно не обновляемый) софт. Поэтому автору — анализ логов и переустановка системы.
Ждем с интересом результатов.
Ждем с интересом результатов.
> переустановка системы
Вы это на полном серьёзе?
Вы это на полном серьёзе?
Переустановка системы не unix-way. Этой инсталляции больше 10 лет.
А писать глупости, извините, по-другому не могу, видимо мой ущербный интеллект не позволяет писать умности.
А писать глупости, извините, по-другому не могу, видимо мой ущербный интеллект не позволяет писать умности.
если есть подозрения на внедрение руткитов, можешь попробовать на ночь воткнуть debsums чтоб проверить целостность файлов + отдельно отследить опции sshd (permitrootlogin no естественно) и apache/php или что стоит у Вас там. Заодно проверить логи CMS, возможно уязвимый пойзон какой протолкнули (к примеру на недостаточных фильтрациях для метода PUT можно подскользнуться и так далее. Я думаю у Вас уязвимость скорее всего в скриптах на вебе, либо брутом ssh, что-то изощренное совсем для спама изобретать никто не будет, ИМХО. Еще у Вас пароль на ssh не один и тот же с почтой или какими-нибудь хабрахабрами? может ломанули какой-нить другой ресурс?
>и у меня в руках был только телефон
он байткодом шипел в трубку или как
он байткодом шипел в трубку или как
Предупреждение о взломах Debian-систем
К чему этот желтый заголовок?
P.s. Нечего на зеркало пенять, коли рожа крива
>Потом я обновил aptitude update; aptitude full-upgrade до squeeze.
testing на сервере? Да вы суровы
testing на сервере? Да вы суровы
Есть такое дело. :) Но ведь не unstable-же! Признайте мою недостаточную суровость, а не то вызову Вас на дуэль :)
>Но ведь не unstable-же!
с тестингом не так координально отличаются. Я не первый год тестинг на десктопе использую, периодически приходит мешок граблей вместе с обновлениями. Да и с безопасностью на тестинге как раз обычно хуже, чем на стейбле.
с тестингом не так координально отличаются. Я не первый год тестинг на десктопе использую, периодически приходит мешок граблей вместе с обновлениями. Да и с безопасностью на тестинге как раз обычно хуже, чем на стейбле.
для стейбла апдейты раз в полгода, кроме критики, для тестинга постоянно.
тестинг дебиана, вообще, будет постабильней многих релизов.
я серваки держу на SID'е, признаю, потенциально не безопасно, но, ИМХО, если не страдать совсем изощренной паранойей, то тоже вполне комфортно. По крайней мере синдром неуловимого Джо работает пока что, а толпу китайских ssh root брутов все равно не волнует дебиан там или виндовс.
тестинг дебиана, вообще, будет постабильней многих релизов.
я серваки держу на SID'е, признаю, потенциально не безопасно, но, ИМХО, если не страдать совсем изощренной паранойей, то тоже вполне комфортно. По крайней мере синдром неуловимого Джо работает пока что, а толпу китайских ssh root брутов все равно не волнует дебиан там или виндовс.
>а толпу китайских ssh root брутов все равно не волнует
а меня не волнуют китайские ssh бруты — iptables наше всё!
:)
а меня не волнуют китайские ssh бруты — iptables наше всё!
:)
Я придерживаюсь именно этого мнения.
>для стейбла апдейты раз в полгода, кроме критики, для тестинга постоянно.
ну вот и зачем вам на сервере постоянно самый свежий софт? Я и на десктопе иногда огребаю проблем с новыми версиями, бывает что-нибудь ломается и отваливается из-за несовместимости
>тестинг дебиана, вообще, будет постабильней многих релизов.
соглашусь, но уточню: десктопных дистров :)
ну вот и зачем вам на сервере постоянно самый свежий софт? Я и на десктопе иногда огребаю проблем с новыми версиями, бывает что-нибудь ломается и отваливается из-за несовместимости
>тестинг дебиана, вообще, будет постабильней многих релизов.
соглашусь, но уточню: десктопных дистров :)
да ладно десктопных… убунта вон на SID базируется и ничего.
для начала, у меня на серверах нету Xorg, так что отгребать неоткуда, разве что от libc раз в год и то если знаешь что она будет обновляться — проблем нету.
для начала, у меня на серверах нету Xorg, так что отгребать неоткуда, разве что от libc раз в год и то если знаешь что она будет обновляться — проблем нету.
>убунта вон на SID базируется и ничего.
ну я убунту как сервер всерьез не воспринимаю, хотя многие пользуются :)
>у меня на серверах нету Xorg, так что отгребать неоткуда
я про иксы и прочие десктопные вещи и не говорил, грабли бывают и в системных вещах. Недавно вот phpmyadmin ломался. В прошлом году огреб проблем с апачем, синтаксис конфигов слегка поменялся, но этого оказалось достаточно чтобы все сломать.
ну я убунту как сервер всерьез не воспринимаю, хотя многие пользуются :)
>у меня на серверах нету Xorg, так что отгребать неоткуда
я про иксы и прочие десктопные вещи и не говорил, грабли бывают и в системных вещах. Недавно вот phpmyadmin ломался. В прошлом году огреб проблем с апачем, синтаксис конфигов слегка поменялся, но этого оказалось достаточно чтобы все сломать.
Скорее всего, все же через web скрипты получили доступ.
иметь мэйл пользователей в системных аккаунтах просто тупо
У меня наоборот. Это тоже тупо?
Тоже тупо. И за это Вас ломанули.
Системные аккаунты это чтобы в систему входить а не чтобы почту проверять
Системные аккаунты это чтобы в систему входить а не чтобы почту проверять
Ну хрен знает, юникс это юникс, и по ssh надо заходить, и почту там свою держать. Хотя конечно оптимально сейчас свою доменную почту отдавать на корню Google
большинство современные imap/pop серверов поддерживают аутентификацию из других источников кроме системного /etc/passwd — LDAP, Mysql, passwdfiles.
Таким образом разумно использовать системные пароли ТОЛЬКО для входа в систему.
В случае использования /etc/passwd для аутентификации почтовых пользователей желательно давать им шелом /bin/nologin
Таким образом разумно использовать системные пароли ТОЛЬКО для входа в систему.
В случае использования /etc/passwd для аутентификации почтовых пользователей желательно давать им шелом /bin/nologin
обычно ломают через web, root можно получить эксплоитом.
смотри логи web сервера, на предмет PHP including.
смотри логи web сервера, на предмет PHP including.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Предупреждение о взломах Debian-систем