[WORKAROUNDED]DDOS-olok, de kell a program

Fórumok

Sziasztok!

[Szerk:]
Úgy tűnik, a Quake motorban Egy feltörekvő ET modifikáció-ban (N!tmod) bug van, így DDOS-ol a szerverünk. (Érinti valamennyi erre épülő játékszervert.) (Az általunk használt mod fejlesztőjének jeleztem a hibát.)
Azt szeretném megtudni, hogy a tipikus szerver-kliens közti kommunikációt hogyan tudnám "portok" közé szorítani. Íme egy minta:

IP szervercímem.eu.27970 > kliensipje.27960: UDP, length 61
IP kliensipje.27960 > szervercímem.eu.27970: UDP, length 50

Vagyis a szerver a 27970-en fut, a kliensek pedig a 27960-on kommunikálnak. Szeretném, ha más portoknak a "27970" nem tudna csomagot küldeni.
Milyen iptables policy-t javasoltok?

A válaszokat előre is köszönöm.

Hozzászólások

"Milyen iptables policy-t javasoltok?"

Redirect arra a portra esetleg?

Szia

A kérdés utolsó kér sora alapján szerintem könnyű a válasz

iptables -A OUTPUT -p udp --sport 27970 --dport 27960 -j ACCEPT (Ha az alap policy Drop)
szerverről az udp:27971-ról mehet a csomag HA a szél UDP:27960

iptables -A OUTPUT -p udp --sport 27970 --dport !27960 -j DROP (Ha nem tüzfalazol, és alapból nyitott az ilyen jellegű kommunikáció)
Szerveren a csomag NEM mehet ha a szerver UPD:27970-ről NEM a másik gép UPD:27960-ra megy

Szintaktikai hibák lehetnek, ill ha nem értettelek meg rendesen akkor szemantikai is :).
Arra figyelni érdemes hogy ha van tüzfal szabály már, akkor esetleg contrack miatt a felépült kapcsolat már nem lesz megálítva.

No akkor további boncolgatás kell

Ki kezdeményezi a kapcsolatot, a szerver vagy a kliens. (A tcp SYN csomagját kellene elkapni) Ha a kliens kezdi a kapcsolatot akkor a szervernek az INPUT láncába kell a szabályt megcsinálni, ha a szerver kezdeményez, akkor a szerveren az OUTPUT láncot kell maszírozni.

Akkor esetleg lehet az hogy:

- contrack miatt megy át
- valahol elözöleg esetleg ip-re (subnetre) engedélyezve vannak a kliensek
- esetleg az adott udp port van elözöleg engedélyezve
- vagy maga a szabály nem match-el amit küldtem

iptables -D OUTPUT -p udp --sport 27970 --dport !27960 -j DROP -- töröljük a szabályt
iptables -I 1 OUTPUT -p udp --sport 27970 --dport !27960 -j DROP -- 1-es pozicióba beszurjuk. Ily mondjuk kikerüljük a fentebbi hibákból az első hármat.

ha nem gond akkor egy
tcpdump -ni any udp and port 27970 kimenete hasznos lehet, illetve a
iptables-save | egrep "OUTPUT|ami.meg.az.output.lancba.dob"

(persze ha nem publikálnád az érzékeny adatokat akkor a nick nevem gmail-os végződésre elküldheted, vagy valami jelszavas modszerec ftp is jó. Persze csak ha nem nem jelent neked tul nagy kockázatot)

Az -I 1 sem oldotta meg a problémát...

10:32:48.343988 IP 58.168.28.4.http > IP.IP.IP.IP.27970: UDP, length 14
10:32:48.344109 IP IP.IP.IP.IP.27970 > 58.168.28.4.http: UDP, length 1055
10:32:48.344682 IP 69.43.160.163.http > IP.IP.IP.IP.27970: UDP, length 15
10:32:48.344855 IP IP.IP.IP.IP.27970 > 69.43.160.163.http: UDP, length 1055
10:32:48.345227 IP 174.36.56.201.http > IP.IP.IP.IP.27970: UDP, length 14
10:32:48.345346 IP IP.IP.IP.IP.27970 > 174.36.56.201.http: UDP, length 1055
10:32:48.345775 IP 69.172.200.87.http > IP.IP.IP.IP.27970: UDP, length 15
10:32:48.345871 IP IP.IP.IP.IP.27970 > 69.172.200.87.http: UDP, length 1055

Látszik, hogy nem a 27960-on akarna a klienssel kommunikálni... (Mármint, ha lenne olyan online ET kliensünk.)

Nem beszélsz hülyeséget, valóban ugy kell ahogy mondtad, gondolom pepo helyesen írta be mert ha csak bemásolta volna akkot nem ette volna meg a netfilter. Ettől függetlenül igazad van. Ráadásul az -I sem jó a szám a lánc után kell, szóval ez lenne a helyes:

iptables -I INPUT 1 -p udp ! --sport 27960 --dport 27970 -j DROP

Ebből az látszik hogy sok-sok ip 80-as portjáról jön forgalom az IP.IP.IP.IP 27970-es portjára. Gonodolom az IP.IP.IP.IP az a szerver ip-je.
Nekem az jön le hogy nem a szerver kezdeményez, hanem a sok különböző ip kezdeményez a szerver felé, és a távoli gépek zaklatják a szervert. (FixMe)

iptables -I 1 INPUT -p udp --sport !27960 --dport 27970 -j DROP

Azaz ha a szerverre beérkező csomag az 27970-es portra jön, DE NEM a távoli gép 27960-as portról akkor dobja el a csomagot.

Igazad van.

Úgy tűnik, hogy DDOS támadás áldozatává és elosztójává vált a játékszerverünk. A támadást egy, a Quake III-ra épülő játékokban meglévő hiba okozza Vincent HINDERER cikke szerint. A lényeg, hogy a támadó hamis forráscímről és hamis 80-as forrásportról egy 15-byte-os "getstatus" üzenetet küld a szerver (default 27960, nálunk 27970-es) UDP portjára olyan gyakran ahogy csak tud, mire a szerver a hamis forráscím 80-as portjára egy, a kérésnél 10-30 szor nagyobb válaszüzenettel reagál, így szépen ledosolva az áldozatot.

Egy ilyen optimalizaciohoz mit szoltok?
nemkell minden packeten 3szor a string kereses (az eleg cpu igenyes), hanem minden csak egyszer van ellenorizve.

$IPTABLES -n q3prot
$IPTABLES -n q3prot_limit

$IPTABLES -A INPUT -p udp -m udp -i $EXTIF --dport 27960:27990 -j q3prot

$IPTABLES -A q3prot -m string --algo bm --string getstatus -j q3prot_limit
$IPTABLES -A q3prot -j ACCEPT

$IPTABLES -A q3prot_limit -m limit --limit 1/s --limit-burst 1 -j ACCEPT
$IPTABLES -A q3prot_limit -j LOG --log-level alert --log-prefix "ET: "
$IPTABLES -A q3prot_limit -j DROP

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!