LINUX.ORG.RU

Утекает трафик через непонятный процесс

 ,


0

4

Все привет, помогите определить процесс-злодея

NetHogs дает такой вывод:

PID USER     PROGRAM                                    
?   root     192.168.0.111:80-148.251.20.134:35286             

lsof -i

COMMAND   PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
dhclient  496        root    7u  IPv4  19519      0t0  UDP *:bootpc
vsftpd    525        root    3u  IPv6  19882      0t0  TCP *:ftp (LISTEN)
ntpd      540         ntp   16u  IPv6  17494      0t0  UDP *:ntp
ntpd      540         ntp   17u  IPv4  17497      0t0  UDP *:ntp
ntpd      540         ntp   18u  IPv4  17501      0t0  UDP localhost:ntp
ntpd      540         ntp   19u  IPv6  17503      0t0  UDP localhost:ntp
ntpd      540         ntp   23u  IPv6  15167      0t0  UDP [fe80::b62e:99ff:fe62:20b7]:ntp
ntpd      540         ntp   24u  IPv4  15175      0t0  UDP muspelheim:ntp
sshd      545        root    3u  IPv4  18685      0t0  TCP *:ssh (LISTEN)
sshd      545        root    4u  IPv6  18687      0t0  TCP *:ssh (LISTEN)
exim4     933 Debian-exim    3u  IPv4  20347      0t0  TCP localhost:smtp (LISTEN)
exim4     933 Debian-exim    4u  IPv6  20348      0t0  TCP localhost:smtp (LISTEN)

Добавил

iptables -A OUTPUT -s 148.251.20.0/24 -j DROP
iptables -A INPUT -s 148.251.20.0/24 -j DROP
не помогло.

Все порты (кроме 80) закрыты еще на роутере, за которым стоит сервер. Я не опытный админ-линуксоид, понять (и выпилить) какой процесс жрет трафик не могу, помогите советом. Спасибо



Последнее исправление: pt1c (всего исправлений: 1)

Не знаю как работает NetHogs, но если pid'а нет, может и процесса нет, может просто идёт syn-флуд с этого самого 148.x.x.x. Посмотрите tcpdump'ом что у вас с трафиком на этот ip-адрес, может информация и не передаётся.

mky ★★★★★
()
Ответ на: комментарий от CaveRat

со вчерашнего дня IP атакующего (?) сменился с 148.251.20.134 на

Вывод tcpdump выглядит так

16:16:43.455554 IP 217.68.217.152.47915 > muspelheim.http: Flags [S], seq 19918033, win 29200, length 0
16:16:43.455561 IP muspelheim.http > 217.68.217.152.47915: Flags [R.], seq 0, ack 19918034, win 0, length 0
16:16:43.488831 IP muspelheim.ssh > 217.68.213.96.50466: Flags [S.], seq 2929885984, ack 1235327394, win 29200, options [mss 1460], length

Вывод netstat

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      933/exim4
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      596/mysqld
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      544/sshd
tcp6       0      0 ::1:25                  :::*                    LISTEN      933/exim4
tcp6       0      0 :::21                   :::*                    LISTEN      517/vsftpd
tcp6       0      0 :::22                   :::*                    LISTEN      544/sshd

Меня посещает смутное сомнение, а не может ли это быть cloudflare? Может он тыкает сервак на предмет активен ли http?

pt1c
() автор топика
Ответ на: комментарий от pt1c

Судя по всему, кто-то пытается пощупать твой http. После TCP Syn твой хост (muspelheim - это же ты?) отвечает TCP Rst, установления соединения не происходит, судя по всему - просто потому, что на 80 порту никто не слушает.

Интереснее выглядит вот эта строчка:

16:16:43.488831 IP muspelheim.ssh > 217.68.213.96.50466: Flags [S.], seq 2929885984, ack 1235327394, win 29200, options [mss 1460], length

Чего это твой ssh разговаривает с турецким IP?

CaveRat ★★
()
Ответ на: комментарий от CaveRat

Мой ssh вообще уже со всем миром говорит, потому что висит на 22 порту, но авторизация только по ключу. Но это не мешает всяким ботам толпами ломиться и пробовать подобрать логин\пароль. В таких случаях лучше перевесить на другой порт? fail2ban - установлен, но до ввода пароля негодяи не доходят, скидывает сразу после ввода логина.

pt1c
() автор топика
Ответ на: комментарий от pt1c

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

Если вот прямо есть необходимость в удаленном доступе, то я бы поднял VPN-сервер, и через него ходил. А то в sshd тоже, знаете ли, бывают уязвимости.

CaveRat ★★
()
Ответ на: комментарий от CaveRat

Если вот прямо есть необходимость в удаленном доступе, то я бы поднял VPN-сервер, и через него ходил. А то в sshd тоже, знаете ли, бывают уязвимости.

Странные советы Вы даете! Вместо простого и десятилетиями отлаженного и отдебаженного sshd, Вы предлагаете целый VPN, который вылизан больше чем sshd и намного меньше его по коду? И который, в отличии от sshd, заэксплоутить не возможно?

Или это был такой сарказм?

funky
()
Ответ на: комментарий от funky

Это не сарказм, это best practice.

sshd, при всей своей отлаженности, таки имеет уязвимости. Да, их оперативно закрывают, но тем не менее. OpenVPN, к слову сказать, вылизан не меньше.

Архитектурно же, не стоит высовывать во внешний мир никакие сервисы, которые используются для управления защищаемой системой. Если атакующему надо сперва атаковать VPN-шлюз, а после этого - еще и sshd, то это существенно усложняет атаку, а значит - снижает риски. Аутентификация по ключу и fail2ban - это замечательные вещи, но пренебрегать эшелонированной защитой тоже не стоит.

PS Естественно, это имеет смысл только, если VPN-шлюз вынесен на отдельную машину.

PPS

Вы предлагаете целый VPN, который вылизан больше чем sshd и намного меньше его по коду? И который, в отличии от sshd, заэксплоутить не возможно?

Тут или VPN с sshd местами перепутаны, или это аргумент в мою пользу. Правда, openVPN тоже, в принципе, можно атаковать.

CaveRat ★★
()
Ответ на: комментарий от CaveRat

sshd, при всей своей отлаженности, таки имеет уязвимости.

Можно пример опасной уязвимости за последние лет 5?

anonymous
()
Ответ на: комментарий от anonymous

CVE-2019-16905 - целочисленное переполнение и исполнение кода (проявляется пр компиляции с экспериментальными ключами), но по ней еще продолжается рассмотрение.

CVE-2018-15919 - перечисление пользователей (существенно упрощает брутфорс)

CVE-2016-10708 - отказ в обслуживании.

Это если особо не искать.

CaveRat ★★
()
Ответ на: комментарий от CaveRat

1 в дикой природе не наблюдается. 2 только с gss2 т.е. к типовой конфигурации тоже не относится. 3 роняет демона, который тут же перезапустится. Неприятно но в целом мелочь.

anonymous
()
  1. закрыть ssh, перевесив на другой порт-помогает в более чем 50% случаев, большинство ботов тупо ломиться на 22 порт. просканировать еще надо уметь и это время, и то, если настроено криво, то получится.
  2. lsof+tcpdump+strace+логирование-детально все шерстить и мониторить.
  3. iptables-рубить не только входящие, кроме нужных, но и исходящие(опционально и зависит от конкретной системы и использующихся на ней сервисов)
  4. fail2ban-уже есть, и это гуд.
  5. желателен snort-позволит рубить активность гораздо более гибко.
  6. также желательно не проигнорировать selinux-классная штука, хоть не не очень простая, особенно для новичков. но если освоишь-прочувствуешь мощь этого инструмента.
  7. можно вкрутить еще knocking портов-поможет отбивать то сильно беспокоит из внешней сети, возможно и из внутренней, при особой сноровке.
ChAnton ★★
()
Последнее исправление: ChAnton (всего исправлений: 1)
Ответ на: комментарий от funky

Странные советы Вы даете!

Вот-вот!…

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.