LINUX.ORG.RU
ФорумAdmin

Если идёт брут 22 порта, возможен ли state established с атакуещем хостом


0

0

Играясь сегодня с tcpdump на vps-ке, ввёл

jugatsu@vps:~$ sudo tcpdump -i eth0 -n -nn -ttt port 22 and 'dst host 188.127.237.103 and not ( src host дом_ip and dst port 22 )'

И посыпалось over9000 пакетов с 94.155.62.146, думаю ну пусть боты пошалят, чай у меня аутентификация по ключам и к тому же парольных вход отключен как класс.

И тут думаю дай проверю соединения

root@vps:~# ss state connected 
State       Recv-Q Send-Q                            Local Address:Port                                Peer Address:Port 
ESTAB       0      0                               188.127.237.103:https                               мой_ip:36960 
ESTAB       0      32                              188.127.237.103:ssh                                94.155.62.146:52438 
ESTAB       0      48                              188.127.237.103:ssh                                 мой_ip:56842 

Это што ещё за дела:

ESTAB       0      32                              188.127.237.103:ssh                                94.155.62.146:52438 

В панике iptables -P DROP

root@vps:~# iptables -vnL INPUT --line-numbers
Chain INPUT (policy DROP 3 packets, 180 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1     6045  436K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           ctstate RELATED,ESTABLISHED 
2        0     0 ACCEPT     tcp  --  eth0   *       мой_ip         0.0.0.0/0           tcp dpt:22 
root@vps:~# w
 16:30:04 up  4:54,  2 users,  load average: 0.05, 0.06, 0.00
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
jugatsu  pts/1    dsl-мой_ip 16:11    3:16   0.10s  0.10s /bin/bash
jugatsu  pts/2    dsl-мой_ip 16:14    0.00s  0.30s  0.20s /bin/bash

Оказывается оно брутило аж с 14:58 по 16:19

root@vps:~# grep 94.155.62.146 /var/log/auth.log | wc -l
9323
[jugatsu@lenovo ~]$ geoiplookup 94.155.62.146
GeoIP Country Edition: BG, Bulgaria

Прошёлся от греха подальше rkhunter, всё, вроде, ок.

Это что было типа DoS-а на 22 порт и почему, самый главный вопрос, была state ESTABLISHED с этим хостом.

P.S.: про fail2ban и иже сними — знаю пока лог не сильно раздутый :)

Ответ на: комментарий от Sylvia

TCP SYN ->
ответ

соединенение TCP установлено

а дальше уже идет SSL handshake
устанавливается шифрованный канал
после чего идет запрос на авторизацию
если авторизация не проходит, то ssl соединение закрывается
потом закрывается TCP соединение

Sylvia ★★★★★
()

> P.S.: про fail2ban и иже сними — знаю

А коли знаешь, что не поставил?

helios ★★★★★
()

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

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

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


отвечать тем же нет никакого смысла

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

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

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

>TCP SYN ->

ответ


соединенение TCP установлено


Какое-то совсем не внятное описание TCP Espablishment =)

Объясню подробнее:
1 Этап.
Клиент желает установить соединение с сервером
Для этого он посылает серверу tcp пакет с флагом SYN (Synchronize)

2 Этап
Сервер принимает SYN пакет и отсылает клиенту ответ в виде пакета SYN,ACK (Synchronize, Acknowledgment)
На самом деле сервер, посылая пакет SYN,ACK переспрашивает у клиента: «Ты уверен? Ты действительно хочешь установить соединение со мной?»

3 Этап
Клиент, приняв от сервера пакет SYN,ACK радуется, переходит в состояние ESPABLISHED и посылает серверу пакет ACK (просто ACK),
как бы говоря : «Да я уверен , я действительно подтверждаю желание установить соединение». Сервер , приняв подтверждение переходит в состояние ESPABLISHED

Соединение считается установленным.




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

То есть выглядит это вот так:

00:20:59.750183 IP 192.168.1.51.60033 > 192.168.1.44.ssh: S 1479979308:1479979308(0) win 5840 <mss 1460,sackOK,timestamp 513972627 0,nop,wscale 6>
00:20:59.750183 IP 192.168.1.44.ssh > 192.168.1.51.60033: S 464446873:464446873(0) ack 1479979309 win 5792 <mss 1460,sackOK,timestamp 112645200 513972627,nop,wscale 5>
00:20:59.750183 IP 192.168.1.51.60033 > 192.168.1.44.ssh: . ack 1 win 92 <nop,nop,timestamp 513972628 112645200>
00:20:59.797590 IP 192.168.1.44.ssh > 192.168.1.51.60033: P 1:33(32) ack 1 win 181 <nop,nop,timestamp 112645212 513972628>

А в контексте брута?

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

Брут происходит на более высоком уровне модели OSI , tcp же отвечает за надежную доставку данных.

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

n1
()

>почему, самый главный вопрос, была state ESTABLISHED с этим хостом

ctstate NEW имеет только первый пакет в соединении, в случае TCP это SYN-пакет. Все дальнейшие пакеты, в которых собственно и идет SSL-трафик, уже ESTABLISHED.

Однако странно, почему соединения не рвались после нескольких попыток. MaxAuthTries в sshd_config установлен? sysctl net.ipv4.netfilter.ip_conntrack_tcp_loose что говорит?

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

Чего только не наворотили в этом нетфильтре)

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

> MaxAuthTries в sshd_config установлен?

К стыду, нет :)

sysctl net.ipv4.netfilter.ip_conntrack_tcp_loose что говорит?


net.ipv4.netfilter.ip_conntrack_tcp_loose = 1

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

>К стыду, нет :)

Там по дефолту должно быть вменяемое значение, обычно 6.

net.ipv4.netfilter.ip_conntrack_tcp_loose = 1

Лучше установить в ноль. Тогда, при блокировке INVALID-пакетов на уровне iptables, можно в реальном времени убивать TCP-соединения через iptstate. С точки зрения TCP-подсистемы оно останется (в ss будет), но передать по нему данные уже не получится - придется устанавливать новое.

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

Однако странно, почему соединения не рвались после нескольких попыток. MaxAuthTries в sshd_config установлен?

MaxAuthTries

Specifies the maximum number of authentication attempts permitted per connection. Once the number of fail‐ ures reaches half this value, additional failures are logged. The default is 6.

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

В том то и дело, что при логине по ssh, естественно, сначала установиться соединение (ESTAB), что будет видно ss state established затем приглашение на ввод пароля (либо сразу отказ, если стоит только publickey, как у меня). Даже в случае аутентификации только по ключам в лог будет занесена запись

Aug 25 20:25:15 vps sshd[12300]: Invalid user joe from 94.155.62.146

то есть засирание лога имеет место быть :)

Существует тысячи способов уменьшить размер auth.log :) я пока установился на fail2ban.

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

anton_jugatsu> O.K. спасибо

fixed> спасибо K.O.

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

2 Этап

Сервер принимает SYN пакет и отсылает клиенту ответ в виде пакета SYN,ACK >(Synchronize, Acknowledgment)

На самом деле сервер, посылая пакет SYN,ACK переспрашивает у клиента: «Ты уверен? Ты >действительно хочешь установить соединение со мной?»


Для точности, исторически возможно разделение SYN,ACK, это не запрещено стандартами, но усложняет распознование NEW соеденений.

tux2002
()

странный ты чувак- такое знаешь iptables -t mangle -I FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

а какого-то бота испугался

лично я на своем vps cначала банил эти хосты, порт поменял, непужный импут дропал и даже icmp, а теперь забил. у меня там всего 2 пользователя имееют доспутп по ssh + пароль на рут сильный, а как звать второго пользователя еще узнать надо))).... подбор пароля на ssh довольно медленный - короче я не парюсь

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

странный ты чувак-

Чего мне боятся — у меня аутентификация по ключам :) Меня эти боты умиляют :) Сказать честно, чуть-чуть испугался, поскольку тупанул — «забыл», что, собственно, сначала должно утановиться соединение (ESTAB), думал, сразу sshd отбрасывает :) Ну не чё, потом сразу tcpdump в зубы и проанализировал на виртуалке :)

лично я на своем vps cначала банил эти хосты, порт поменял, непужный импут дропал и даже icmp, а теперь забил

Я знаю тысячи способов борьбы с ботами и разрастанием auth.log, пока остановился на fail2ban (чуть позже подойду более комплексно)

root@vps:~# tail /var/log/fail2ban.log 
2010-08-25 20:34:47,059 fail2ban.actions: WARNING [ssh] Ban 85.173.213.241
2010-08-25 20:44:47,089 fail2ban.actions: WARNING [ssh] Unban 85.173.213.241
2010-08-26 05:02:43,850 fail2ban.actions: WARNING [ssh] Ban 117.34.79.133
2010-08-26 05:12:43,888 fail2ban.actions: WARNING [ssh] Unban 117.34.79.133
2010-08-26 18:05:55,970 fail2ban.actions: WARNING [ssh] Ban 66.0.19.155
2010-08-26 18:15:56,016 fail2ban.actions: WARNING [ssh] Unban 66.0.19.155
2010-08-27 16:38:03,187 fail2ban.actions: WARNING [ssh] Ban 69.59.18.198
2010-08-27 16:38:15,215 fail2ban.actions: WARNING [ssh] Ban 79.98.142.30
2010-08-27 16:48:03,253 fail2ban.actions: WARNING [ssh] Unban 69.59.18.198
2010-08-27 16:48:15,278 fail2ban.actions: WARNING [ssh] Unban 79.98.142.30

Вот щас например тоже висит соединение с ботом

root@vps:~# ss state connected
State       Recv-Q Send-Q                            Local Address:Port                                Peer Address:Port   
ESTAB       0      48                              188.127.237.103:ssh                                 мой_ip:54918   
FIN-WAIT-1  0      1                               188.127.237.103:ssh                                 79.98.142.30:39705   
ESTAB       0      0                               188.127.237.103:https                               мой_ip:60778   
root@vps:~# grc tail /var/log/auth.log 
Aug 27 16:38:15 vps sshd[6259]: Invalid user admin from 79.98.142.30
Aug 27 17:15:22 vps sshd[6286]: Invalid user ftp from 79.98.142.30
Aug 27 17:15:23 vps sshd[6289]: Invalid user gameserver from 79.98.142.30
Aug 27 17:15:23 vps sshd[6291]: Invalid user gameservers from 79.98.142.30
Aug 27 17:15:24 vps sshd[6293]: Invalid user gastftp from 79.98.142.30
Aug 27 17:15:25 vps sshd[6295]: Invalid user gasttest from 79.98.142.30
Aug 27 17:15:26 vps sshd[6297]: Invalid user gdm from 79.98.142.30
Aug 27 17:15:26 vps sshd[6299]: Invalid user guestftp from 79.98.142.30
Aug 27 17:17:01 vps CRON[6308]: pam_unix(cron:session): session opened for user root by (uid=0)
Aug 27 17:17:01 vps CRON[6308]: pam_unix(cron:session): session closed for user root
root@vps:~# iptables -vnL fail2ban-ssh --line-numbers
Chain fail2ban-ssh (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1       18  1192 DROP       all  --  *      *       79.98.142.30         0.0.0.0/0           
2    21742 1620K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
root@vps:~# 
anton_jugatsu ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.