Назад | Перейти на главную страницу

как проверить снифферы в Ubuntu?

Кто-то обвиняет меня в том, что моя машина linux ubuntu могла быть источником атаки на сервер.

Их метод заключался в замене исходного ssh на этот исправленный ssh ​​и, как таковой, устранял всю информацию для регистрации и отладки sshd, позволяя при этом входить в любую учетную запись пользователя при наличии специального пароля; Кроме того, в некоторых случаях они устанавливали связи между этим поддельным ssh2 и исходным ssh. Это объясняет, почему я обнаружил, что ключ хоста ssh изменился. Кроме того, они помещают некоторые другие вещи в / tmp /, / var / tmp /, /dev/.lib1/ и / dev / shm /, /dev/.lib1/ и / dev / shm /.
, /dev/.lib1/ и / dev / shm /

Любые идеи, если это возможно. У меня не было других отчетов, и я подключаюсь через ssh как минимум к десятку других серверов. как проверить снифферы в Ubuntu? как я могу проверить, действителен ли мой ssh?

Самый безопасный вариант - создать резервную копию ваших конфигураций, отформатировать систему, затем выполнить новую установку и убедиться, что она полностью обновлена ​​как можно скорее, предпочтительно в автономном режиме.

Однако похоже, что это было просто обвинением со стороны кого-то в Интернете. Какие у них есть доказательства? Есть ли что-нибудь подозрительное, что вы видите на своей машине?

Тем не менее, одна вещь, которую вы можете попробовать, - это передать свое сетевое соединение через другую систему и отслеживать трафик, идущий к ней и от нее. Что-то вроде ntop или эфир может помочь.

Любые идеи, если это возможно.

Да, это возможно. :)

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

С взломанным ssh? Ой!

как проверить снифферы в Ubuntu?

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

Если ваш ssh процесс взломан, для этого есть только одно решение: ВЫКЛЮЧИТЕ МАШИНУ СЕЙЧАС! Просто вытащите вилку, чтобы не запускать сценарии выключения. и снова расслабься :)

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

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

Как сказал pehrs, вероятно, вы не заинтересованы в обнаружении сниффера. (Даже если кто-то обнюхивает вашу сеть, это не имеет смысла, потому что ваш поток зашифрован. Он должен провести автономный анализ, который займет время / недели / месяцы / годы в зависимости от вашего пароля).

Но, если вы спросите, как вы можете определить, что что-то изменилось, взгляните на Ossec. Это действительно ggoooood инструменты для обнаружения вторжений. Его можно использовать для многих вещей.

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

ура

Это что-то вроде rkhunter (http://www.rootkit.nl/) ты ищешь? Он доступен как пакет deb (aptitude install rkhunter)

Вы пытаетесь подтвердить свой sshd?

Если да, то вы могли бы сделать две вещи: 1) проверить официальную контрольную сумму и вашу (кто-то сказал это раньше) 2) использовать lsof, чтобы проверить, какие файлы открыты sshd. Одна из распространенных вещей - это изменить sshd, сохранить где-нибудь пароли, а затем, используя бэкдор, удалить файл.

Как правило, я предлагаю временно заменить sshd другой версией, но оставить «взломанную» версию для дальнейшего тестирования (если она взломана и вы ничего не изменили в своей системе, значит, вы все еще уязвимы, поэтому изучите sshd может вам помочь)

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

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

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