Fórumok
Napok óta tele van a netstat SYN_RECV-kkel különböző IP-kkel, most épp Amazonos tartományok vannak soron. Gyakorlatilag nem okoz semmi fennakadást, csak zavar. Mert nem konkrét szolgáltatás fennakadás van, csak szimplán terhelni próbálnak, csak épp a tűzfalak szépen be vannak állítva ezek ellen. Bosszankodáson kívül valami extra, amit érdemes ellenük tenni? Vagy valami hír, hogy most mitől jött el ennek a szezonja?
Hozzászólások
Szerintem a syn cookie segíthet.
Bővebben: https://www.cyberciti.biz/faq/enable-tcp-syn-cookie-protection/
"A megoldásra kell koncentrálni nem a problémára."
Ez így már eddig be volt kapcsolva a lenti szerint:
openSUSE Leap 15
Meg lehet fogni előbb mint hogy elérné a socket-et iptables SYNPROXY modullal. Ez elvben kisebb terhelést okoz,lásd:
https://people.netfilter.org/hawk/presentations/devconf2014/iptables-dd…
És egy még érdekesebb lehetőség :
https://blog.cloudflare.com/how-to-drop-10-million-packets/
Múlt hét óta megy a dolog. Ember, cég, szolgáltató, ország független a történet...
"-j DROP és/vagy -j TARPIT a barátod..."
Ahogy láttam egyenlőre még csak nyitott portok, szolgáltatások után tapogatóznak de azt határozottan és erővel.
Ha faék módszerrel akarod kidobni őket akkor....
netstat -ntu | grep SYN_RECV | awk '{print $5}' | cut -d: -f1 | sort | uniq | sort -nr | tr -s \ | cut -d\ -f3
A megfogott egyedi IP címeket egyenként lecsekkolod párhuzamos kapcsolatokra és ha X-nél több akkor mehet neki a tiltás.
Arra figyelj, hogy egyes esetekben kontraproduktív lehet a tiltás ha túl szigorúra veszed a limitet.
Ország alapú whitelist javíthat esetleg a fals-pozitív találatok szűrésében.
ui.: amúgy vegyesfelvágott a támadók IP címe. Jöttek már török, orosz, román, német, amcsi IP tartományokról
... amazon-os, digitaloceanos, ovh-s meg az égtudja milyen VPS-ekről
... ja és jönnek 200-300 connection / IP illetve 2-3 connection / IP felszorozva egy /24-es tartománnyal jellegűen is
Csak egy megjegyzés:
Ebben az UDP (-u) is benne vannak... Azok pedig nem SYN-elnek :)
Debian Linux rulez... :D
RIP Ian Murdock
Igazából a tűzfalak nem engednek be sok syn-t / ip, szóval gépet terhelni nem tudnak vele. A tűzfal meg eléggé vaskos. A nagyobb baj akkor lenne, ha a kábelt tömnék el.
openSUSE Leap 15
Nálam júliusban kezdődtek ezek a támadások egyik szerveren: szinte kizárólag :53-as portra.
A megoldás részemről egy netstat-ot figyelő script lett, amit a fail2ban vizsgál, és per időegységet meghaladó kérés esetén DROP-ra rakja az IP-ről érkező csomagokat:
while true; do netstat -n -p TCP| grep "IPVÉGE:PORT" | grep SYN_RECV | awk -F" " '{print $5}'|awk -F":" '{print $0}'| gawk '{ print strftime("%Y-%m-%d %H:%M:%S"), $0 }' >> /var/log/synflood.log ;sleep 0.1; done
Ezt a log-ot figyeli egy fail2ban filter, részlet a conf-ból:
failregex = ^%(__date_ambit)s?\s*<HOST>%(_port)s$
Volt időszak, amikor egyidőben több mint 25e különböző IP lett blockolva augusztus közepén. Eszi a CPU-t, a while true, de nem volt eredményes a DDOS támadás, lekopogom. (Nálam a rendesen szolgáltatott, előrhető portokon kívül az összes egyéb puhatolózás DROP-ot eredményez, hogy shodan és társaik ne tudjanak infókat szolgáltatni, lehet azért nem láttam egyéb portokon a jelenséget.)
Nem lehet hogy open dns resolver fut azon a szerveren? Akkor szokott általában erősebb forgalom jönni az 53-as portra, lényegében spoofolt címről küldenek open resolvereknek lekérdezéseket, és a válasszal DDOS-olnak le másokat.
vps4you.hu kupon VPS szolgáltatásra: HUP2023
Tudtommal nincs open dns resolver. Hétköznapi üzemben nincs ilyen jelenség. Külső vizsgálat alapján "not vulnerable to DNS Amplification attacks".
Percenként hostonként több száz SYN_RECV érkezett az 53-as portra, semmi más. Netdata figyelmeztetett, hogy "1m tcp syn queue cookies (was warning for 1 minute) the number of times the TCP SYN queue of the kernel was full and sent SYN cookies, during the last minute (was warning for 1 minute)". Erre lett a DROP a válasz az IP-re, hogy ne érje a szolgáltatást a fölösleges kérésekkel a fenti leírás szerint.
Nálam 80, 443, 22 nyitva, de csak a 80 és a 443 kapja az áldást. Függetlenül, hogy apache, vagy nginx van mögötte, bár egyik se írja ki, hogy mi ő.
openSUSE Leap 15
Nem fogja kiírni mivel totál random packetekkel bombázzák a portot.
Csak tippelek. Valóban nem árt paranoidnak lenni. :) A jó IT-s üzemeltető alaptlajdonsága.
Szolgáltató mit lát? (Amúgy üzleti előfiizetésnél alapból ők is védenek syn flood ellen)
BGP? (Van h szolgáltató oldali hálózati konfig hiba okozhat hasonló hibát.)
Belül nálad esetleg van-e olyan gép/service (user is, ki tudja) ami okozhat-e hasonló problémát?
---
Szijarto Zoltán
Szijártó Zoltán
Aki tud az alkot, aki nem tud az csak szövegel.
Több szolgáltató. Független, hogy magyar, vagy külföldi, hogy vps, vagy fizikai vas, csak annyi a közös, hogy mutat rá .hu-s domain.
openSUSE Leap 15