Как быстро проверить Linux сервер на предмет взлома

Примерно два года назад я арендовал у одного немецкого хостера не очень мощный сервер на базе Centos 5.2. На нём живут несколько вебпроектов, приносящих некоторую прибыль, и поэтому, я стараюсь присматривать за ним по мере возможности.
На Centos есть стандартный анализатор логов Logwatch, который запускается ежедневно по крону, анализирует содержимое /var/log, делает сводный отчет и присылает его по электропочте. В один прекрасный день я обнаружил в этом отчете запись:

--------------------- yum Begin ------------------------ 
 
 Packages Installed:
    lzo2 - 2.02-3.el5.rf.i386
    dnstracer - 1.8-1.2.el5.rf.i386
    openvpn - 2.0.9-1.el5.rf.i386

---------------------- yum End -------------------------


В тот момент меня она очень смутила, так как в предыдущий день на сервер я не логинился и тем более ничего не устанавливал. Первое, что пришло в голову — сервер был скомпроментирован. Себя я считал уверенным пользователем Linux, однако я растерялся. Благо в тот момент в icq был мой бывший коллега, лучший системный администратор, которого я знаю, и просто очень хороший человек.
Он помог быстро проверить систему. В результате у меня сформировалось краткое HowTo о том, как быстро проверить свой сервер на предмет взлома. Уверен, что многим Храброчитателям оно будет полезно. Предполагается, что пользователь знаком с консолью Linux/Unix.



Итак, первым делом меняем рутовый пароль:

[root@myhost etc]# passwd
Changing password for user root.
New UNIX password:
...


Далее сканируем хост на предмет подозрительных открытых портов. Сделать это можно, например, с другой юниксовой машины с помощью утилиты nmap:

[root@myhost ~]# nmap -P0 123.123.123.123

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2011-01-23 11:47 MSK
Interesting ports on myhost.myprovider.net (123.123.123.123):
Not shown: 1679 filtered ports

PORT     STATE    SERVICE
21/tcp   open     ftp
22/tcp   open     ssh
25/tcp   open     smtp
53/tcp   open     domain
80/tcp   open     http
106/tcp  open     pop3pw
110/tcp  open     pop3
111/tcp  open     rpcbind
135/tcp  filtered msrpc
136/tcp  filtered profile
137/tcp  filtered netbios-ns
138/tcp  filtered netbios-dgm
139/tcp  filtered netbios-ssn
143/tcp  open     imap
443/tcp  open     https
445/tcp  filtered microsoft-ds
465/tcp  open     smtps
620/tcp  open     unknown
993/tcp  open     imaps
995/tcp  open     pop3s
3306/tcp open     mysql
8443/tcp open     https-alt


В этом списке подозрительно выглядели 111 и 620 порты, поэтому далее смотрим, кто их слушает:

[root@myhost ~]# netstat -anp | grep LISTEN | grep 620
tcp        0      0 0.0.0.0:620                 0.0.0.0:*                   LISTEN      1710/rpc.statd


[root@myhost ~]# netstat -anp | grep LISTEN | grep 111
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LISTEN      1685/portmap


Тут оказалось всё в порядке, так как это были компоненты nfs. Далее проверяем UDP соединения:

[root@myhost ~]# netstat –anp | grep udp

udp        0      0 0.0.0.0:32773               0.0.0.0:*                               2345/named
udp        0      0 127.0.0.1:32780             127.0.0.1:32780             ESTABLISHED 2539/postmaster
udp        0      0 0.0.0.0:32783               0.0.0.0:*                               2790/avahi-daemon:
udp        0      0 123.123.123.123:53          0.0.0.0:*                               2345/named
udp        0      0 123.123.123.123:53          0.0.0.0:*                               2345/named
udp        0      0 127.0.0.1:53                0.0.0.0:*                               2345/named
udp        0      0 0.0.0.0:614                 0.0.0.0:*                               1710/rpc.statd
udp        0      0 0.0.0.0:5353                0.0.0.0:*                               2790/avahi-daemon:
udp        0      0 0.0.0.0:617                 0.0.0.0:*                               1710/rpc.statd
udp        0      0 0.0.0.0:111                 0.0.0.0:*                               1685/portmap
udp        0      0 0.0.0.0:631                 0.0.0.0:*                               2069/cupsd
udp        0      0 :::32774                    :::*                                    2345/named
udp        0      0 :::32784                    :::*                                    2790/avahi-daemon:
udp        0      0 :::5353                     :::*                                    2790/avahi-daemon:


Тут тоже всё оказалось в порядке. Попасть на сервер, скорее всего могли не через консоль, так как при логине на сервер Centos писал, что последний логин был с моего IP. Поэтому следующим пунктом нужно проверить фолдер /root/.ssh, туда могли положить ключ для ssh-клиента каким-либо образом.

[root@myhost ~]# dir /root/.ssh
authorized_keys_


Здесь оказался только файл с ключами, который я переименовал сразу после передачи хоста провайдером. Далее нужно проверить файл /etc/passwd. В нём не должно быть пользователей с uid=0, кроме root:

[root@myhost ~]# cat /etc/passwd | more
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
…


И тут тоже было всё окей. Финальным аккордом являлась проверка хоста на установленные руткиты. Для этого можно использовать бесплатную утилиту rkhunter. Скачиваем архив с последней версией, распаковываем его и запускаем инсталлер. Далее делаем его обновление и запускаем проверку:

[root@myhost ~]# ./installer.sh --install --layout /usr/local
[root@myhost ~]# /usr/local/bin/rkhunter –-update
[root@myhost ~]# /usr/local/bin/rkhunter –-check


Rkhunter в начале проверят важные системные файлы, затем ищет руткиты. После происходит проверка на различные vulnerabilities. В конце программа проверяет версии популярных продуктов, таких как Apache, OpenSSH и т.п. на предмет последних версий.

Результаты своей работы rkhunter выдает в консоль, а также формирует консолидированный лог /var/log/rkhunter.log. Можно запускать данный антируткит каждый день по крону и получать отчет о сканировании по электронной почте.

К счастью, rkhunter не обнаружил на моём сервере никаких зловредов, это позволило успокоиться и подумать, что же за странные инсталлы произошли на сервере. И тут я вспомнил, что сразу после получения сервера, я установил и сконфигурировал на этом сервере VPN сервер. Видимо, произошла какая-то ошибка в Logwatch и он добавил в отчёт данные двухлетней давности.

Разумеется, если злоумышленники всё сделают грамотно, то Logwatch никаких следов не обнаружит и хозяин сервера долго ни о чём не будет подозревать. Однако, шаги, описанные в данном HowTo, если проводить их регулярно, помогут уберечь ваши сервера от компроментации.
Метки:
Поделиться публикацией
Комментарии 105
  • +12
    Поверьте, рут взломщикам нужен далеко не всегда. В большинстве случаев им за глаза хватает доступа к каталогам, которые доступны по http. Либо доступа к отправке почты от произвольного хостнейма.

    Рут — это хорошо, но неимоверно сложно на более или менее современном дистрибутиве. Поэтому обычно никто за получение рута и не берется.
    • 0
      Рут — это хорошо, но неимоверно сложно на более или менее современном дистрибутиве. Поэтому обычно никто за получение рута и не берется.

      вы теоретик?
      представьте ситуацю: вам нужно получить доступ к /var/www/site1. вы смогли поулчить доступ к /var/www/site2, но права расставлены правильно и выйти дальше своего каталога не выйдет. как вы будите действовать без повышения привилегий? как будите подчищать логи за собой в /var/log?
      • +4
        Все зависит от квалификации злоумышленника и значимости ресурса. Все сервисы имею уязвимости, и в паблик попадает порядка 10% от того, что действительно обнаруживается.
        • +6
          Не совсем так. В паблик попадает 95%, просто когда попадает, оказывается, что им уже давно пользовались, кто знал :)
      • +8
        Во второй половине прошлого года публиковался эксплоит для ядра линукса, работал практически на всех последних ядрах и дистрибутивах- позволял получить локального рута.
        Так что если вы просто смогли бы загрузить что-то на сервер и запустить — повышение привилегий дело 5 минут.
        • +7
          Минусующие — вы хоть обоснуйте в чем я не прав…
          Тем более, то что описано выше действительно было.
          • +1
            Не минусовал, но видимо народу коммент не понравился тем, что он был в духе капитана очевидности. Эксплоиты периодически находятся и выпускаются и не только во второй половине прошлого года и не только в паблик :) И да, очевидно, что имея эксплоит, уязвимость и возможность его запустить — можно повысить привилегии.
            Это как написать «В прошлом году человека сбила машина и он попал в больницу. Так что, если вас тоже собьет машина — вы можете попасть в больницу, а то и вообще умереть».
            • +1
              Не совсем согласен с духом КО, ибо я опровергаю фразу про «неимоверно сложно».
              Да и не все следят за тем какие эксплоиты выходят в свет и какой урон могут нанести системам.
          • 0
            Пофиксили же сразу. А на тот же центос секьюрити патчи постоянно выходят для старых версий
            • 0
              позволял получить локального рута

              А какие ещё «руты» бывают? :)
              • +1
                Имелось ввиду — получить рута локально, а не удаленно.
            • НЛО прилетело и опубликовало эту надпись здесь
              • +1
                на любом «современном» дистрибутиве уже есть гора проверенных рабочих локальных рут-експлойтов: paste.pro/550014 (бубунта свежустановленная и чо то там сама обновившееся). так что заиметь рута на линуксе не составляет особых проблем. ну или как минимум на «среднестатистическом» сервере с линуксом.
              • 0
                Командой nmap лучше проверять все порты на открытость: nmap -P0 -p 1-65505 123.123.123.123
                • 0
                  Могу сказать только одно: man tripwire.
                  • +1
                    Я думал, что по tripware уже несколько лет, как справили поминки. Пациент жив?
                    В современных дистрибутивах присутствует его аналог — aide.
                  • 0
                    man auditd
                    man fail2ban
                    • +1
                      Во многих версиях logwatch есть противный баг, когда он внезапно не учитывает год. То есть присылает отчет о файлах, которые были изменены 1-2-3 года назад.
                      И просьба: объедините (поставьте рядом) сброс пароля рута и проверку лишних ключей ssh. Злоумышленник может даже не трогать рутовый пароль, чтобы не палиться, а просто влепить свой ключ и ходить через него. И смена пароля ничего не даст.
                      • 0
                        Да и некто вообще пассы рута не угоняет, сплойтом повышают привеллегии, делают грязные делишки, и заметают следы.
                      • +3
                        Вы забыли еще проверить cron. Можно запускать программы оттуда в назначенное время, например, когда злоумышленник пришел домой и поужинал.
                        • 0
                          OSSEC HIDS очень неплох для контроля за сервером
                          • 0
                            Нет там контроля, ossec отвечает только за наблюдение над целостностью и поведением системы. и клиент (защищаемый) и сервер должны быть обязательно разнесены географически. Иначе от взлома это спасет не сильно.
                            • 0
                              Например, OSSEC HIDS временно блокирует IP, которые активно пытаются достучаться до SSH или до дырок в PHP скриптах.

                              Это не панацея, но всяко лучше ручной проверки пост-фактум.

                              Если есть инструменты лучше (и такие-же простые в установке/настройке) — делитесь опытом.
                          • +2
                            зачем nmap если можно netstat -an | grep -i listen?
                            • +2
                              netstat -nlpt
                              • +17
                                на взломаном хосте, нельзя верить системным утилитам
                                • +1
                                  суть в том, что автор сначала использует nmap, потом netstat
                                  • +1
                                    Полностью с вами согласен. Всегда когда появляется подозрение на взлом сервера — оповещаю пользователей о тех перерыве в удобный для всех момент, гашу его, гружусь с надежного live-cd и уже оттуда проверяю систему, меняю пароли и т.д. Выглядит как паранойя, но сам был свидетелем подмены /bin/login и sshd (собирали пароли). Если есть подозрение — верить нельзя никому и ничему. Ни netstat, ни passwd, ни какому-либо сервису.
                                    • 0
                                      вот она, «прелесть» опенсорса…
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                        • –1
                                          К сожалению, нет. Сам бы хотел… Не потому что я ярый ненавистник опенсорса, а потому что закрытый продукт сложнее пропатчить и встроить в него какую-нибудь гадость :)
                                          • 0
                                            Полная ерунда. См. вирусы, заражающие исполняемые файлы. Например, недавний Sality.
                                            • 0
                                              Понедельник, утро… не подумал. Таки да, ваша правда. =(
                                  • 0
                                    использую netstat -pantu на Линухах
                                  • +2
                                    Спасибо за статью! Открыл для себя Logwatch.
                                    • +1
                                      Зачем netstat и grep если можно lsof -i?
                                      • 0
                                        у меня например на freebsd не стоит lsof
                                        • +4
                                          Ваша боль близка мне как никому. Напишите статью «Как быстро проверить FreeBSD сервер на предмет взлома», с интересом почитаю чего ещё у вас там нет
                                          • 0
                                            Можно и по этой статье делать, только вместо netstat -anp делать sockstat | grep "*:*"
                                            rkhunter можно поставить из портов: cd /usr/ports/security/rkhunter && make install clean
                                            • 0
                                              Кстати, как верно заметили ниже, шелл может быть настроен на ожидание соединения с определённых IP, так что лучше делать sockstat | grep ":\*"
                                              • 0
                                                Уж переписать утилиту make и важные порты, имея рута, не должно составлять труда :). Я думаю, что, как минимум, надо отключить сервер от сети и проверять жесткий диск, если уж реально хочется проверить систему на предмет взлома, не сломав при этом ничего.
                                                • 0
                                                  Сомнительно, что этим будут заниматься. Но, в любом случае, можно банально взять чистый make «у соседа», а перед установкой порта сделать, например, portsnap fetch update. Если есть возможность на время проверки вывести сервер из сети, то можно и Frenzy попользовать для проверки. В общем, вариантов очень много на самом деле.
                                                  • 0
                                                    В таком случае надёжнее будет не portsnap, а по старинке: csup/cvsup. В таком случае контрольные суммы чекаются и враг точно не пройдёт.
                                                  • +1
                                                    Да, люди забыли классику :)
                                              • +2
                                                cd /usr/ports/sysutils/lsof && make install clean
                                                • 0
                                                  мне больше нравится
                                                  make -C /usr/ports/sysutils/lsof/ install clean

                                                  или
                                                  portinstall lsof
                                            • +2
                                              если есть предположение что сервер скомпрометирован то пароли лучше менять не через passwd который может уже быть с закладкой
                                              а ручками менять хеш сразу в shadow

                                              • +4
                                                Для такого рода проверок есть rkhunter — открытые порты, изменения в системных файлах, md5 суммы и прочее.
                                                Кстати, если ваша система скомпрометирована — чтобы на 100% быть уверенным что вы закрыли все открытые «двери» нужно ее целиком переставить. иначе никак.
                                                а если вам поставили ядерный руткит — как его ловить?
                                                И кстати, смена пароля на рута не всегда вас спасет, злоумышленник при взломе может поставить патченый sshd с мастерпаролем который будет пускать его с любым логином.

                                                • 0
                                                  Про rkhunter извиняйте, не углядел в статье.
                                                  • 0
                                                    Чтобы не поставили ядерный руткит, нужно собирать ядро без поддержки модулей, а именно — отключить «Enable Loadable Module Support» и вкомпиливать все, что нужно, прямо в bzImage.

                                                    И еще. После установки ядра через «make install» желательно удалять из /boot все (config и System.map), кроме vmlinuz.
                                                    • 0
                                                      Сами пробовали? отключить поддержку модулей… и получить нерабочий звук, USB. Удалить config и System.map и получить нерабочий dkms (а информация-то вся есть в /proc/config.gz и /proc/kallsyms).
                                                      • 0
                                                        >>>отключить поддержку модулей…
                                                        Единственный способ установки ядерного руткита — подгрузка модуля. Нет модулей — нет руткитов.

                                                        >>>и получить нерабочий звук, USB
                                                        Не забывайте, что разговор идет про сервер, а не домашний комп. Звука нет (само собой), а USB (во всяком случае, флешка и внешний винт) работает прекрасно

                                                        >>>Сами пробовали?
                                                        Уже много лет так делаю на продакшене — полет нормальный. Плюс у меня там система — Gentoo-hardened.

                                                        Для чего выпиливать из бута config — понятно, а system.map выпиливается потому, что там содержатся все адреса, используемые ядром — некоторые эксплойты первым делом проверяют его наличие.

                                                        1) dkms там не нужен — это сервер, все железо заранее известно и драйверы для всего намертво вкомпилены [*] в bzImage
                                                        2) /proc/config.gz у меня нет — всегда отключал General setup->Kernel .config support и отключал General setup->Enable access to .config through /proc/config.gz
                                                        3) /proc/kallsyms у меня тоже нет — отключал General setup->Configure standard kernel features (for small systems)

                                                        А на домашнем компе — само собой, ни чего такого не отключено (а на нем — просто Gentoo, не hardened).
                                                        • +1
                                                          > Единственный способ установки ядерного руткита — подгрузка модуля. Нет модулей — нет руткитов.
                                                          Пропатчить исходники ядра и вкомпилить руткит в ядро. Ждать перезагрузки.

                                                          > Уже много лет так делаю на продакшене — полет нормальный.
                                                          Главное чтобы это было где-то задокументировано чтобы у следующего админа не возникло вопросов.

                                                          > Для чего выпиливать из бута config — понятно
                                                          Нет, не понятно. Security via obscurity?
                                                          • +2
                                                            >>>Пропатчить исходники ядра и вкомпилить руткит в ядро. Ждать перезагрузки.

                                                            Ну, как бы, оставлять на сервере исходники ядра — нонсенс.

                                                            >>>Нет, не понятно. Security via obscurity?
                                                            Для усложнения пункта 1, плюс человек может сориентироваться по опциям ядра: heap randomization и прочее.

                                                            Лично я делаю так (я ни кому не советую так делать, просто говорю, как мне удобно и как я привык):

                                                            1) Система собирается/обновляется у меня на ноутбуке в отдельной папке под чрутом, с заточкой и make+use флагами под тот процессор и железо, что на сервере. Повседневной работе на ноутбуке не мешает, так как nice установлен в 19.

                                                            2) Создается полная копия (cp -av /from /to) в отдельную папку.

                                                            3) Из копии скриптом удаляются весь gnu toolchain (gcc, binutils, make, autotools, в общем, все, без чего невозможно скомпилировать ни одно приложение), wget, питон (на нем основан emerge), все заголовочные файлы, все gentoo-utils, и так далее.

                                                            С помощью ldd в рекурсии составляется список всех библиотек, которые не влияют на загрузку системы и от которых не зависят php и mysql. Они удаляются.

                                                            В общем, все, что может хоть как-то использоваться злоумышленником. По сути остается только самый минимум из системы, плюс php, imagemagick, и mysql.

                                                            Работоспособность проверяется в виртуальной машине.

                                                            4) Эта папка, изрядно похудевшая, загоняется в tar, а потом tar — на внешний usb винт.

                                                            5) Гружу сервер с флешки (она поставлена первым загрузочным устройством в биосе) (видеокарты там нет — флешка со слаксом настроена на запуск демона ssh автоматом), бекаплю все, что нужно, форматирую корневой раздел, распаковываю в раздел tar с сохранением всех прав у файлов (tar xvpf file), заливаю бекапы, загружаю сервер.

                                                            Все. Лично мне — очень удобно, но ни кому не советую.

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

                                                            А так как я — владелец сервера, то за другого админа могу не беспокоиться.)))
                                                            • 0
                                                              > С помощью ldd в рекурсии составляется список всех библиотек, которые не влияют на загрузку системы и от которых не зависят php и mysql. Они удаляются.

                                                              И так мы оставляем за бортом все программы с плагинами, использующие dlopen().

                                                              Представляю во что выливается установка обновлений безопасности в такой среде. Я тоже этот способ никому не советую.
                                                              • +1
                                                                >>>И так мы оставляем за бортом все программы с плагинами, использующие dlopen().

                                                                В программах динамической подгрузкой плагинов пока что потребности не было — если надо расширение функционала, ни что не мешает скомпилировать отдельную программу/набор программ с измененными use флагами как пакет (банально tar), а потом его просто разархивировать на сервере.

                                                                >>>Представляю во что выливается установка обновлений безопасности в такой среде

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

                                                                Обычно все обновления безопасности/просто патчи добавляются в дерево portage довольно оперативно, и обновить систему (образ полноценной системы же хранится отдельно) — не проблема (chroot /dir, в нем: env-update && emerge --sync && emerge -uDN world).

                                                                Как раз из-за простоты мне и нравится такой подход — запускаем обновление, потом скрипт, читаем Хабр, потом просто перезаливаем систему/бекапы с внешнего винта другим скриптом.

                                                                Телодвижений ноль, все действия занимают меньше 5 минут не считая времени на сборку системы из исходников.
                                                              • 0
                                                                А похожую схему без физического доступа к серверу (и вообще он виртуальный :) ) сложно реализовать будет?
                                                                • 0
                                                                  С виртуальными серверами дела не имел, но, если можно залить образ диска и загрузиться с него — наверное, да. Фиг его знает.
                                                            • 0
                                                              > Единственный способ установки ядерного руткита — подгрузка модуля.

                                                              Не единственный. Можно через /dev/mem добраться. www.linuxjournal.com/magazine/anthony-lineberry-devmem-rootkits
                                                              • +1
                                                                Не прокатит: hardened-sources, доступ к /dev/mem запрещен через GrSecurity и PaX.
                                                        • 0
                                                          А если вшили bluepill то вообще только livecd спасет…
                                                        • +9
                                                          Если стоит ядерный руткит, то ни нетстат, ни rkhunter не помогут. Т.к. будут показывать, что все ок.
                                                          Далее, если хакер откроет доступ к своим сервисам только с определенных IP, то, соответственно, не поможет и nmap.
                                                          Какое-то нубское howto если честно :)
                                                          • 0
                                                            Смотря какой руткит. rkhunter пытается найти в lkm подозрительные вещи тоже.

                                                            В остальном да, чтобы понять, что машина скомпроментированна — нужно представлять как работает система и какие методы мог использовать взломщик. Иначе, проход по пунктам такого «how to» слабоэффективен. Особенно, если на машине изначально слушала куча сервисов, о которых владелец даже не догадывался :)
                                                            • 0
                                                              ну это естественно. вот один мой сервак недавно ломанули через proftpd, как раз была уязвимость там. ни netstat ничего не показывал, ни rkhunter. правда lsof показал, то, что не показывал netstat. но сначала через nmap увидел шел, на странном порту.
                                                              вообще я все это сказал к тому, что единственный пока известный мне способ, гарантирующий очистку системы — переустановка.
                                                              • 0
                                                                А как насчет проделать всё вышеописанное, загрузив live дистрибутив? На сервере это реально?
                                                                • 0
                                                                  На сервере, даже удалённом, это более чем реально. Но если tripware (точнее tripwire) или аналоги не установлены — то толку?
                                                                  • 0
                                                                    Сравнить все выполняемые файлы с файлами из репозитория, например.
                                                          • +7
                                                            portmap, rpc.statd и mysql слушающие в Интернет — это супер, конечно.
                                                            • –2
                                                              Почему бы мускулу не слушать? Главное права нормально настроить
                                                              • +1
                                                                Потому что, скорее всего, производственной необходимости в этом нет. И вывешивать еще один демон, без надобности, в Интернет — это не безопасно.
                                                                Если все же необходимость есть, то необходимо открыть доступ к порту только тем доверенным адресам, которые должны иметь этот доступ.
                                                                Если есть необходимость давать доступ к mysql-демону с неопределенного динамического адресного пространства, то я бы рассмотрел вариант с организацией доступа через vpn или, что скорее, пересмотрел бы дизайн решения, скорее всего в нем что-то не так.
                                                                • 0
                                                                  Если вывешивают, то необходимость явно есть, по дефолту он слушает только локальные интерфейсы (по крайней мере так в Debian/Ubuntu, из сорцов не собирал, другие дистры настолько не юзал).

                                                                  Сканирование, судя по всему, производилось с доверенного (домашнего или рабочего) компьютера, а значит ничего удивительного, что много портов. Например, когда я сканирую из дома свой VDS, то мне открыто порядка десятка портов, сканирую с работы или через 3G-модемы — 3 (22, 80, 8080), остальные дропаются. Несколько раз сталкивался с необходимостью срочно с произвольного адреса зайти на другие порты — заходил по ssh и временно открывал порты для текущего IP, потом закрывал (удалял разрешающие правила iptables).

                                                                  • 0
                                                                    Рано отправил:

                                                                    Может не оптимально, но я в конце-концов не админ, а разработчик, которого перестали устраивать вечные препинания с суппортами различных shared-хостингов, то я >5% ресурсов использую и мне аккаунт блочат без уведомления, то что-нибудь из PECL/PEAR не хотят ставить, то ещё что-нибудь.
                                                                    • 0
                                                                      Вы слишком верите в людей :) Поверьте, чаще что-то делается, когда на то совсем нет необходимости.

                                                                      В контексте этой статьи, автор предложил просканировать сервер со стороннего хоста, чтобы увидеть что торчит «наружу». Сканировать с доверенного хоста в данном случае не было смысла.

                                                                      Плюс, автор сам был удивлен наличием некоторых демонов, которые оказались легитимными, но о которых он не знал. Что вызывает некоторые сомнения в возможности адекватной защиты других компонентов системы в данном конкретном случае.
                                                              • +3
                                                                Для rpm дистров есть мощное rpm -V
                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                  • 0
                                                                    Буквально на днях друг просил сервер посмотреть, говорит что хетзнер залочил арендованный сервер за атаки.

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

                                                                    Снес exim, и запустил find / -user exim и нашел кучу перловых IRC и спам ботов.

                                                                    Кстати, rkhunter надо запускать ежедневно по крону. После инцидента он бесполезен, т.к. проверки идут относительно last state/
                                                                    • 0
                                                                      Да, еще один совет. Отключайте парольную аутентификацию по ssh. Ходите на сервер по rsa/dsa ключам, это и удобнее в разы и безопаснее. Ну или хотябы rootlogin отключайте.
                                                                    • +1
                                                                      Хорошо написано, но ни слова про jail. А если тебя сломали и всю систему имитировали в jail, то хоть до посинения меняй рутовый пароль и ищи руткиты — настоящая система всё равно остаётся «выше» и остаётся полностью в распоряжении взломщика.
                                                                      • –1
                                                                        Эм… но ведь можно узнать в джейле ты или нет. Так что будет понятно что произошло.
                                                                        • +3
                                                                          Т.е. взломщик получает рута на целевой системе, настраивает на ней какой-либо вид виртуализации, переносит весь функционал текущей машины в гостевую среду, а себе оставляет управление хост-системой? Интересный концепт. Вы встречали такое на практике?
                                                                          • +1
                                                                            На ум приходит аналогия с «Матрицей» :)
                                                                            • +2
                                                                              Тогда уж «Начало» :)
                                                                            • +3
                                                                              Встречал конечно, посмотрите на мою историю работы в IT. Некоторые годами не осознают, что сидят в джайле. Рядовой сотрудник саппорта хостинга точно не догадается.
                                                                              Взломщику незачем тревожить владельца сервера, удалять все файлы, запускать левые процессы, и совершать прочие деструктивные действия. Машина просто тихо становится гейтом к чьим-то корпоративным данным или сетям.
                                                                              • +1
                                                                                Что говорит о том, что эти некоторые годами не обновляют свои системы.
                                                                                Как уже сказали выше, определить находишься ли ты в jail или нет не сложно. Это же выявится и при попытке обновления. То есть такой вид атаки расчитан на людей со слабой кваликацией, которые не особо уделяют внимание тому, что происходит у них на сервере.
                                                                                В этом случае, зачем утруждаться настройкой jail и переносом софта и т.д., если такие владельцы сервера с таким же успехом не заметят и обычный руткит?
                                                                                • 0
                                                                                  это СОВСЕМ не jail, это KVM. А его выловить можно только по косвенным признакам, и это очень сложно.
                                                                              • +1
                                                                                Да. Я встречал. Называется bluepill (виндовый вариант — redpill). Штука очень хитрая и в удалении сложная, да и обнаружить ее черезвычайно трудно. Но и вживить в систему — тоже.
                                                                                • 0
                                                                                  bluepill это совсем отдельная тема, конечно. В данном случае оригинальный коммент был именно про jail, что и родило во мне сомнения.
                                                                            • +6
                                                                              Пароль меняем не командой

                                                                              # passwd

                                                                              а командой

                                                                              # /usr/bin/passwd
                                                                              • 0
                                                                                лично видел левый passwd в $PATH
                                                                                • 0
                                                                                  Впрочем, это всё равно не поможет, если # скомпрометирован. Тут поможет только список хеш-сумм бинарников.
                                                                                  • 0
                                                                                    Главное не на сервере его хранить, а то хеши тоже перепишут.
                                                                                    • 0
                                                                                      Угу. Я однажды разбирался с таким вот поломанным сервером. Очень основательно было сломано. Клиенту после нескольких часов разбирательств посоветовали вообще его удалить целиком и с нуля переустановить. Даже никакие файлы не брать, ибо где угодно могла быть зараза.

                                                                                      Подменено было практически всё важное, даже какие-то левые ядерные модули были подгружены.
                                                                              • +1
                                                                                Странно что никто не написал раньше меня. Руткиты любят переписывать системные утилиты, чтобы лучше маскироваться. Поэтому я, когда подозреваю что мой сервак взломали, перехожу с ls, cat, netstat, ps, top и так далее на busybox ls, busybox cat, busybox netstat, busybox ps и так далее. Странно, но про busybox руткиты почему-то забывают, а он стоит на многих линуксах по умолчанию.
                                                                                • 0
                                                                                  У меня была секретная ссылка на бинарники, которые я скачивал вгетом, они таки удобнее, чем бизибоксовые.
                                                                                • +6
                                                                                  Выполнять любые команды из-под скомпрометированной системы бессмысленно. Есть только три действительно надёжных способа выхода из ситуации:
                                                                                  1. Загрузка с внешнего носителя и проверка контрольных сумм всех системных файлов.
                                                                                  2. Восстановление из резервной копии.
                                                                                  3. Переустановка с нуля.
                                                                                  • –1
                                                                                    Только надо не забывать что при каждом обновлении системных утилит нужно так-же обновлять и их контрольные суммы в отдельном файлике хранящимся уж точно не на сервере.
                                                                                    • 0
                                                                                      Не обязательно. В Debian, например, подсчёт MD5 всех файлов происходит на уровне менеджера пакетов. На другой машине тоже можно из пакетов достать список контрольных сумм.
                                                                                      • 0
                                                                                        А кто мешает руткиту заменить мд5 суммы в стандартном файле сверки — своими?
                                                                                        • 0
                                                                                          Вы на другой машине скачаете пакеты из репозитория, проверите подписи, извлечёте из этих пакетов списки контрольных сумм.
                                                                                  • 0
                                                                                    Что и следовало ожидать: виноваты не хакеры, а конфиги софта :)
                                                                                    Имхо, большинство атак сейчас идут не на обретение рута, а на эксплуатирование незапатченных уязвимостей софта. Безусловно, ход работы был верным, но начал бы я с проверки логов приложений, работающих с сетью. А то мы долго ищем, кто у нас обрёл рута и поставил руткиты, а дефейса-то и не видим :)
                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                                      • 0
                                                                                        Еще может помочь сохранение логов на сторонний сервер, в случае попытки замести следы, оригинальные логи останутся в другом месте. Спасибо за комментарии, советы даже интересней чем в статье.
                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                          • 0
                                                                                            В вашем примере nmap не обнаружит порты с номером выше 10к, чтобы просканировать все 65 тысяч нужно писать nmap -p- что равносильно p0-6553

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