DOS és TIME_WAIT assasination

Beküldte admin - v, 12/22/2013 - 20:51

Szakmai szekció



Aki a címet érti, az jó helyen jár. Igen, ez a cikk a következő kellemetlenségekről szól, mint például:

Webserver és/vagy mail szerver lelassul, néha elérhetetlenné válik, van értelmes tűzfal, azonban a logokban nem sok minden látszik. Illetve ami látszik, arra a neten talál az emberfia sok magyarázatot, azonban a kínált megoldások nem elegendőek.
Pl.:
Syslog: nf_conntrack table full dropping packet
Az atop-ot figyelve néha iszonyatosan felszalad a network i/o.

Látható, hogy csomageldobások vannak, a gép nem szolgáltat rendesen. Mivel a syslogban az nf_conntrack table full dropping packet azt jelenti, hogy a conntrack tábla megtelt, nézzük meg, hogy mi is találunk benne!

conntrack -L>/var/conntrack.txt


Már csak azért is fileba írtam, mert azt vártam, hogy nagy lesz. Nagy lett. Nézzünk körül benne! Láthatóvá válnak a conntrack táblában lévő aktuális kapcsolati szálak.
A hiba arra utal, hogy megtelt ez a tábla, a neten sok helyen azt lehet olvasni, hogy nosza, gyorsan emeljük meg a méretét. (Figyelem, ha valaki megemeli, akkor a hash tábla méretét hozzá kell igazítani, ennek leírását részletes leírását itt lehet olvasni.)
Nem ezt az utat jártam, mert arra gondoltam, hogy ha a szerverünk immáron másfél éve nem adott ilyen üzenetet, akkor ugyan miért is tenné? A másik gondolat pedig, hogy ha megnövelem a conntrack tábla méretét, akkor végeredményben csak memóriát vesztek, azzal meg sebességet, stb., stb.)
Erről győzött meg a conntrack tábla kiürítése is. Merthogy miközben a gépen dolgoztam a támadás hullámokban zajlott. Így megbizonyosodtam, hogy teljesen felesleges felemelni a conntrack tábla méretét, mert mire az új conntrack -L>/var/conntrack.txt kiadtam, a tábla ismét tele lett.
A conntrack használatáról itt találhatók részletek.
Közben egy a google-ban kerestem egy whois portált és pár igen sűrűn előforduló ip címet megvizsgáltam. Volt köztük pakisztáni, francia, üzbegisztáni, stb. Mivel szerverünkön alapvetően magyar célközönségnek vannak nagyrészt oldalai, úgy gondoltam, hogy ez a "érdeklődés" inkább más "huncutságra" utal.
Tehát a conntrack nem vezetett eredményre.
Azt szerettem volna elérni, hogy ezeket a kapcsolatokat fel lehessen számolni.
Tovább bogarásztam, a neten és sokan arról cikkeznek, hogy a csomagok time_out-ját és még sok mindent érdemes átállítani. Ezt a sysctl programmal tudjuk elkövetni, részletes leírását itt lehet megtalálni. Ebből én is átvettem részletek, amiket a /etc/sysctl.conf alá fel is vezettem. A sysctl program röptében is felül tudja írni ezeket az értékeket, de a conf-ba azért kell felvenni, mert akkor a legközelebbi reboot után is majd ezekkel a módosításokkal áll fel a rendszer.
Röviden a /etc/sysctl.conf végére illesztett sorok:

net.ipv4.netfilter.ip_conntrack_generic_timeout = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 54000
net.ipv4.tcp_fin_timeout=30
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_rfc1337=1
net.ipv4.conf.all.rp_filter=1


Ettől azonban nem gyógyult meg a rendszer a conntrack tábla továbbra is tele volt.

A kapcsolatok felszámolásához a neten a tcpkill programot találtam, ami a Debian alatt a dsniff csomag része. Fel is telepítettem és kipróbáltam. Ez ugyan ténylegesen kiirt egy kapcsolatot, de időigényes, tehát más utat kerestem.

A netstat -ntap vezetett eredményre. Mivel ezt is nagy méretűre vártam, az elemzéshez kiírtam a tartalmát egy file-ba. netstat -ntap>/var/netstat.txt
És ekkor jött a megvilágosodás. Tettem gyorsan mellé egy sortot is, így: netstat -ntap|sort>/var/netstat.txt
A következő sorokat láttam, ez itt most csak egy részlet:

tcp6 0 0 XXX.XXX.XXX.XXX:443 89.95.200.5:58936 TIME_WAIT -...............
tcp6 0 0 XXX.XXX.XXX.XXX:443 89.95.200.5:58941 TIME_WAIT -...............
tcp6 0 0 XXX.XXX.XXX.XXX:443 89.95.200.5:58947 TIME_WAIT -...............
tcp6 0 0 XXX.XXX.XXX.XXX:443 90.0.28.227:5589 TIME_WAIT -...............
tcp6 0 0 XXX.XXX.XXX.XXX:443 90.0.28.227:6028 TIME_WAIT -...............

Nocsak. Iszonyatos mennyiségű (több száz) azonos IP-ről származó TIME_WAIT státuszú kapcsolat van. Az érdekes benne, hogy éppen a 443-as porton kapcsolódtak, de az is látszik, hogy a kapcsolatot egymás után több portról kezdeményezték.
Ez bizony DOS, és ez bizony TIME_WAIT assasination. Erről itt lehet olvasni részletesebben.
A rendszerünkön van fail2ban, ezért a feladat innentől kezdve már világossá vált. A netstat kimenetéből kell készíteni rendszeresen egy log féleséget, amire már rá lehet húzni egy fail2ban filtert. A többit az már elintézi.
Nos rajta. Mivel időm nagyon kevés volt ezért egy nagyon egyszerű megoldást készítettem.

Írtam egy "komoly" scriptet, íme:

#!/bin/sh
day=$(date +"%b %d %H:%M:%S")
netstat -ntap|grep "TIME_WAIT"|sort|awk -v day="$day" '{t=$5} {f=length(t)} {o=index(t,":")} {w=f-o} {k=substr(t,1,o-1)} {print day "[" k "]"}'>/var/log/netstat.log


A dayre azért van szükség, mert a fail2ban szereti tudni, hogy mikor is történt a dolog, hiszen innen veszi észre, ha változik a log.
Ebből egy ilyen log keletkezik:

/var/log/netstat.log (részlet):

Dec 22 20:30:01[197.203.26.142]
Dec 22 20:30:01[197.203.26.142]
Dec 22 20:30:01[197.203.26.142]
Dec 22 20:30:01[197.203.26.142]
Dec 22 20:30:01[197.203.26.142]
Dec 22 20:30:01[197.203.26.142]
Dec 22 20:30:01[197.203.26.142]
Dec 22 20:30:01[197.203.26.142]
Dec 22 20:30:01[197.203.26.142]
Dec 22 20:30:01[197.203.26.142]

Nagyon szép! Most létrehozzuk a fail2ban szűrőt, ehhez felhasználtam egy korábbit és módosítottam:

/etc/file2ban/filter.d/ip-tw.conf:


# Fail2Ban configuration file
#
# Author: Én
#
# $Revision: 728 $
#

[Definition]

# Option: failregex
# Notes.: regex to match the password failures messages in the logfile. The
# host must be matched by a group named "host". The tag "" can
# be used for standard IP/hostname matching and is only an alias for
# (?:::f{4,6}:)?(?P[\w\-.^_]+)
# Values: TEXT
#
failregex = \[\]

# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =


Ezt követően a fail2ban local config-jához hozzáírtam a következőket:

/etc/fail2ban/jail.local végéhez ( a szűrő neve ip-tw):


[ip-tw]

enabled = true
port = http,https
protocol = tcp
filter = ip-tw
logpath = /var/log/netstat.log
maxretry = 40
findtime = 750
bantime = -1


Azért 40 a maxretry, mert végeredményben a TIME_WAIT nem tilos.
A -1 bantime azt jelenti, hogy nem eresztjük vissza többet, azt tapasztaltam, ha valamilyen időt határozok meg és jön az UNBAN, szinte azonnal előkerülnek újra.

Ezt követően már csak arról kellett gondoskodni, hogy a scriptem lefusson tíz percenként, ezt a crontabbal tettem meg.

(Én egy mycrontab szöveges file-ban tárolom a crontab bemeneti szöveges tartalmát és azt szoktam szerkeszteni)

/etc/mycrontab/mycrontab részlet:

# netstat-ip-tw log gyartasa

0 * * * * /etc/myscripts/net-ip-tw&
10 * * * * /etc/myscripts/net-ip-tw&
20 * * * * /etc/myscripts/net-ip-tw&
30 * * * * /etc/myscripts/net-ip-tw&
40 * * * * /etc/myscripts/net-ip-tw&
50 * * * * /etc/myscripts/net-ip-tw&


Az & azért kell a végére, hogy háttérben fusson.
Ezt követően crontab /etc/mycrontab/mycrontab
Aztán újraindítottam a fail2ban-t

/etc/init.d/fail2ban restart

Természetesen vártam a csodát, és lőn, íme:

fail2ban.log (részlet):

2013-12-21 19:50:13,439 fail2ban.actions: WARNING [ip-tw] Ban 197.206.29.175
2013-12-21 19:50:13,445 fail2ban.actions: WARNING [ip-tw] Ban 96.56.205.163
2013-12-21 19:50:13,450 fail2ban.actions: WARNING [ip-tw] Ban 203.77.32.220
2013-12-21 19:50:13,454 fail2ban.actions: WARNING [ip-tw] Ban 203.106.163.24
2013-12-21 19:50:13,459 fail2ban.actions: WARNING [ip-tw] Ban 181.1.248.203
2013-12-21 19:50:13,464 fail2ban.actions: WARNING [ip-tw] Ban 94.70.248.201
2013-12-21 19:50:13,468 fail2ban.actions: WARNING [ip-tw] Ban 178.221.204.131
2013-12-21 19:50:13,473 fail2ban.actions: WARNING [ip-tw] Ban 190.239.56.254
2013-12-21 19:50:13,478 fail2ban.actions: WARNING [ip-tw] Ban 60.241.48.118
2013-12-21 19:50:13,483 fail2ban.actions: WARNING [ip-tw] Ban 5.13.137.82
2013-12-21 19:50:13,487 fail2ban.actions: WARNING [ip-tw] Ban 146.255.168.197
2013-12-21 19:50:13,492 fail2ban.actions: WARNING [ip-tw] Ban 65.7.174.37
2013-12-21 19:50:13,497 fail2ban.actions: WARNING [ip-tw] Ban 172.129.63.100
2013-12-21 19:50:13,502 fail2ban.actions: WARNING [ip-tw] Ban 200.121.134.206
2013-12-21 19:50:13,506 fail2ban.actions: WARNING [ip-tw] Ban 41.133.242.116
2013-12-21 19:50:13,511 fail2ban.actions: WARNING [ip-tw] Ban 49.159.192.191
2013-12-21 19:50:13,516 fail2ban.actions: WARNING [ip-tw] Ban 121.1.152.245
2013-12-21 19:50:13,521 fail2ban.actions: WARNING [ip-tw] Ban 109.107.23.24
2013-12-21 19:50:13,526 fail2ban.actions: WARNING [ip-tw] Ban 2.50.172.174
2013-12-21 19:50:13,530 fail2ban.actions: WARNING [ip-tw] Ban 189.251.165.232
2013-12-21 19:50:13,535 fail2ban.actions: WARNING [ip-tw] Ban 70.96.5.118
2013-12-21 19:50:13,540 fail2ban.actions: WARNING [ip-tw] Ban 82.127.26.77
2013-12-21 19:50:13,545 fail2ban.actions: WARNING [ip-tw] Ban 12.226.229.50
2013-12-21 19:50:13,549 fail2ban.actions: WARNING [ip-tw] Ban 85.97.138.212
2013-12-21 19:50:13,554 fail2ban.actions: WARNING [ip-tw] Ban 119.160.28.19
2013-12-21 19:50:13,559 fail2ban.actions: WARNING [ip-tw] Ban 186.115.89.0
2013-12-21 19:50:13,563 fail2ban.actions: WARNING [ip-tw] Ban 2.6.249.111
2013-12-21 19:50:13,568 fail2ban.actions: WARNING [ip-tw] Ban 189.231.41.8
2013-12-21 19:50:13,573 fail2ban.actions: WARNING [ip-tw] Ban 119.42.70.211
2013-12-21 19:50:13,578 fail2ban.actions: WARNING [ip-tw] Ban 186.65.41.10

A syslogban csönd lett, az nf_conntrack table full dropping packet üzenetek elmúltak.
A netstat.log mérete drasztikusan lecsökkent.

A támadást nem tudtam megszüntetni, de a támadás a csomagok eldobálás miatt csak a sávszélességet foglalja, a gépet már annyira nem. Látszik, hogy most is fel-felszökik az atop alatt a network utilization, de processzoridőt, memóriát nem zabál. A gép rendben van.
Az évek alatt azt tapasztaltam, hogy betörési kísérletek mindig vannak folyamatosan. Azonban az is látszik, hogy a kitiltás hatékony, mert ha egy-két órára a delikvens azt tapasztalja, hogy a csomagjai nem érnek célba, hogy nincs válasz, akkor szépen lassan leáll, illetve más szerver után néz.
Abban reménykedek, hogy írásommal másoknak is tudtam segíteni.

Mészáros Antal