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.
- 5309 megtekintés
Hozzászólások
"Milyen iptables policy-t javasoltok?"
Redirect arra a portra esetleg?
- A hozzászóláshoz be kell jelentkezni
Nem gondolod komolyan...: A 27970-es portkiszolgálás a szerveren fut.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
A "iptables -A OUTPUT -p udp --sport 27970 --dport !27960 -j DROP" policy szimpatikusnak tűnik. Meglesem, köszi a tippet. Jelzem, ha "bejött".
- A hozzászóláshoz be kell jelentkezni
Sajnos ez engedi továbbra is a 27970-es felől érkező kérelmeket más portokra is.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
A szerver kezdi, tehát elvileg jónak kellene lennie, amit írtál, de még sem fogja meg a csomagokat.
- A hozzászóláshoz be kell jelentkezni
Akkor nezd meg az elotte levo szabalyokat - ha valami mar engedi, akkor elvileg el sem jut a vizsgalat eddig a szabalyig. (fixme)
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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.)
- A hozzászóláshoz be kell jelentkezni
lehet megint hülyeséget beszélek (bocs), de "--dport !27960" helyett nem inkább "! --dport 27960" ?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
log69 jelezte hogy hibás a szintaxis, ugyhogy most nekifogtam hogy szintaxis helyesen megcsináljam (mea culpa lustaság nagy úr :) ). Szóval a így kellene próbálkozni :
iptables -I INPUT 1 -p udp ! --sport 27960 --dport 27970 -j DROP
- A hozzászóláshoz be kell jelentkezni
Köszönöm, nézem.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
További infó itt:
http://kohoclan.eu/node/764
- A hozzászóláshoz be kell jelentkezni
kongrat a workaround-hoz, foleg ha ti talaltatok ki ;-)
Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara
- A hozzászóláshoz be kell jelentkezni
Csuhi alkotta meg, övé az érdem.
Mindazonáltal mindenkinek köszönöm, aki próbált segítségünkre lenni.
- A hozzászóláshoz be kell jelentkezni
Köszi!
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
Köszi, ez jó ötlet!
- A hozzászóláshoz be kell jelentkezni
Olyan mértékben megfogta csuhi + Elbandi megoldása a problémát, hogy immáron nincs fájdalmas támadásunk se befelé--> sem kifelé.
Köszönet mindenkinek.
- A hozzászóláshoz be kell jelentkezni