Toon posts:

[FreeBSD] SYN/ACK rate limiting

Pagina: 1
Acties:
  • 114 views sinds 30-01-2008
  • Reageer

Verwijderd

Topicstarter
is er een slimme manier waar op ik poortje 80 op mijn systeem kan rate limiten, zodat een ip-adres dat bijvoorbeeld >15 concurrent connections open gooit naar poort 80, automatisch ge-nullroute wordt?

zenks!

  • Arno
  • Registratie: Juli 2000
  • Laatst online: 15-05 20:13

Arno

PF5A

Heb je zelf al wat research gepleegd, zoals de freebsd website :?

"Supercars are made to mess around with G-forces, hypercars are made to mess around with G-strings"
Jeremy Clarkson


Verwijderd

ga maar ens speulen met dummynet... en inderdaad zelf zoeken.

  • Predator
  • Registratie: Januari 2001
  • Laatst online: 15-05 23:05

Predator

Suffers from split brain

PNS -> NOS

Everybody lies | BFD rocks ! | PC-specs


Verwijderd

Topicstarter
Heb je zelf al wat research gepleegd, zoals de freebsd website :?
duh, uiteraard, anders zou ik het hier toch niet vragen?
ga maar ens speulen met dummynet... en inderdaad zelf zoeken.
heb ik inderdaad naar gekeken, maar na een lange tijd google'n ben ik niet verder dan het bandwidth shapen van m'n interface, en dat is dus NIET de bedoeling... ik heb 100mbit tot m'n beschikking, en 't zou zonde zijn om dat af te knijpen op 20mbit om maar wat te noemen.

waar ik naar opzoek ben ik het volgende:
alles draait gewoon 'normaal', alleen als iemand >15 connecties opent naar port 80 op m'n FreeBSD, moet die persoon ge-nullroute worden.

Ik heb namelijk regelmatig lamers/leechers op m'n bak die met downloadmanagers (useragent gefaked) >150 connecties openen naar Apache, die kan dat allemaal wel aan, maar ik kan zo wel aan de gang blijven met 't ophogen van m'n MaxClients (en op een gegeven moment is m'n geheugen/cpu ook op)

mod_limitipconn werkt niet voor mij, de server heeft gemiddeld zo'n 300 downloads openstaan, en doet +/- 2 tot 3 requests/sec, zodat er echt helemaal geen cpu meer overblijft. (dit heb ik uiteraard uitvoerig getest, maar zonder die mod_limitipconn ben ik echt beter af)

ook mod_throttle is helaas geen oplossing bij dit probleem.


is dit echt op te lossen in ipfw, of moet ik naar een andere oplossing gaan zoeken?

Verwijderd

ja idd met ipfw kun je wel zulke opties inbouwen dacht ik..
je zou toch een rule kunnen maken die teld hoevaak iemand een een syn/ack stuurt en als dat hoger dan 15 is kun je het verder null-routen

misschien is een cron job ook een optie. die laat je alle 5min draaien en die verbreekt alle verbindingen die hoger dan 15 zijn

lijkt mij :)

[ Voor 74% gewijzigd door Verwijderd op 31-12-2002 14:38 ]


Verwijderd

Topicstarter
Verwijderd schreef op 31 december 2002 @ 14:26:
ja idd met ipfw kun je wel zulke opties inbouwen dacht ik..
je zou toch een rule kunnen maken die teld hoevaak iemand een een syn/ack stuurt en als dat hoger dan 15 is kun je het verder null-routen

misschien is een cron job ook een optie. die laat je alle 5min draaien en die verbreekt alle verbindingen die hoger dan 15 zijn

lijkt mij :)
oke, maar waar zie ik dan hoeveel syn/acks er per ip gestuurd zijn?

voor zover ik weet is dat alleen te bewerkstelligen via tcpdump, en dat is nou niet echt cost-effective...

offtopic:
(overigens, men roept hier wel heel snel dat je zelf beter moet zoeken, terwijl ik toch echt m'n best gedaan heb...)

[ Voor 12% gewijzigd door Verwijderd op 31-12-2002 16:53 ]


  • Prozaq
  • Registratie: Juni 2000
  • Laatst online: 13-04 16:25
ummm in 5.0 zit dat standaard in ipfw als ik me niet vergis. Misschien dat je een scriptje zou kunnen maken dat de output van netstat -an verwerkt, als er meer dan X connecties van iemand openstaan naar je poort 80 dan voeg je een firewall regel toe (niet vergeten deze na een tijdje weer te flushen). Mij klinkt het niet echt als een lekkere oplossing...

Verwijderd

Topicstarter
Prozaq schreef op 31 December 2002 @ 17:02:
ummm in 5.0 zit dat standaard in ipfw als ik me niet vergis. Misschien dat je een scriptje zou kunnen maken dat de output van netstat -an verwerkt, als er meer dan X connecties van iemand openstaan naar je poort 80 dan voeg je een firewall regel toe (niet vergeten deze na een tijdje weer te flushen). Mij klinkt het niet echt als een lekkere oplossing...
tis een dirty hack, maar dat maakt niet uit zolang 't werkt :)

ik heb nu de volgende ipfw regel (ik gebruik Fbsd 4.7 trouwens):
code:
1
02000       106         4808 pipe 10 tcp from any to any tcpflags syn,ack


maarja, dat telt alleen de totale SYN/ACK's, en niet per ip ge-groupeerd oid...

  • serkoon
  • Registratie: April 2000
  • Niet online

serkoon

mekker.

SYNs limiteren schiet niet echt op. Juist met webservers heb je veel connecties die opgebouwd en weer afgebroken worden. Als je SYNs gaat limiteren schiet dat opbouwen dus niet echt op.

Ikzelf heb een tijdje terug eens een 30MB grote .zip aangeboden op een 100mbit apache webserver. Dat liep niet echt fijn met apache, daarom heb ik een rewrite rule gemaakt zodat de file op ip:81 opnieuw geprobeerd zou worden. Op poort 81 draaide thttpd die de zipfile serveerde. Bij een piek van 2MB/s constant leverde dat een CPU-belasting van 0.2% op.

Misschien dat je een dergelijke setup kunt proberen?

Verwijderd

Topicstarter
serkoon schreef op 31 december 2002 @ 17:21:
SYNs limiteren schiet niet echt op. Juist met webservers heb je veel connecties die opgebouwd en weer afgebroken worden. Als je SYNs gaat limiteren schiet dat opbouwen dus niet echt op.

Ikzelf heb een tijdje terug eens een 30MB grote .zip aangeboden op een 100mbit apache webserver. Dat liep niet echt fijn met apache, daarom heb ik een rewrite rule gemaakt zodat de file op ip:81 opnieuw geprobeerd zou worden. Op poort 81 draaide thttpd die de zipfile serveerde. Bij een piek van 2MB/s constant leverde dat een CPU-belasting van 0.2% op.

Misschien dat je een dergelijke setup kunt proberen?
hmm nou, momenteel gebruik ik een .htaccess file met +/- 1800 "Allow from" en dan een route, rechtstreeks uit onze Juniper M20 gehaald... zodat we dus alleen downloads toestaan over peeringroutes.

thttpd zou dan ook zoiets moeten aankunnen :/
Pagina: 1