wat doet ip_always_defrag precies?

[xantos]

Zie boven.... iedereen gebruikt het maar nergens staat precies wat het doet.

Kan iemand me vertellen wat ik hier aan heb en of ik dit wel nodig heb voor een simpele firewall?

[Sjonny]

Dit is heel erg handig als je ip masq gebruikt. Zoals de optie zelf aangeeft, dit defragmenteerd de ip packets die bij elkaar horen (en in masq: stuurt ze daarna pas door als de te ontvangen data compleet is). Gewoon aanzetten.. altijd handig.

[Verwijderd]

Op dinsdag 26 juni 2001 12:32 schreef Sjonny het volgende:
Gewoon aanzetten.. altijd handig.

Gewoon aanzetten altijd handig?

Dat vind ik nogal ver gaan, maar ik moet toegeven dat het voor een gateway verstandig is om je server altijd te laten defragmenteren (en tevens controleren) om corrupte tcp zooi van je interne netwerk af te houden.

[Onno]

Op dinsdag 26 juni 2001 12:32 schreef Sjonny het volgende:
Dit is heel erg handig als je ip masq gebruikt.

Want? De packetsize op je inet interface zal niet groter zijn dan op je LAN interface hoor, dus wat valt er voor winst te behalen?

Op dinsdag 26 juni 2001 12:44 schreef Mainwave het volgende:
om corrupte tcp zooi van je interne netwerk af te houden.

En dat gaat nou juist bij NAT/masq weer niet op, want daarbij heb je daar sowieso al geen last van.

[Verwijderd]

Niet als flame bedoeld, maar het lijkt me dat er ook situaties zijn waarin always defrag niet gewenst is.

[Verwijderd]

Op dinsdag 26 juni 2001 12:44 schreef Onno het volgende:

[..]
En dat gaat nou juist bij NAT/masq weer niet op, want daarbij heb je daar sowieso al geen last van.

Oh, zou ook kunnen, ik meende het gelezen te hebben, mbt fragbombs en tcp sequence.

[Verwijderd]

Hmm, was het niet iets met firewall?
Dus dat je firewall werkt met gedefragde tcp packets en je daarom fragmenten moet voorkomen mbv die always defrag?
Ik zou toch zweren dat er een veiligheids reden achter schuilde.

[Sjonny]

Op dinsdag 26 juni 2001 12:44 schreef Onno het volgende:

Want? De packetsize op je inet interface zal niet groter zijn dan op je LAN interface hoor, dus wat valt er voor winst te behalen?

Nee dat niet, maar is dit anders niet de filter, als ie alleen maar frag krijgt, gaat het verder niet over naar waar het heen moest van je masq?

[Verwijderd]

http://www.realworldlinuxsecurity.com/tips.html

A Linux firewall always should defragment ("defrag") packets to protect against crackers attacking internal systems (not running recent Linux kernels, including Windows, some UNIX systems, and other vulnerable systems).

[xantos]

gebruiken jullie dit ook allemaal?

[Onno]

Op dinsdag 26 juni 2001 13:01 schreef Mainwave het volgende:
http://www.realworldlinuxsecurity.com/tips.html

A Linux firewall always should defragment ("defrag") packets to protect against crackers attacking internal systems (not running recent Linux kernels, including Windows, some UNIX systems, and other vulnerable systems).

Heel leuk, maar dat is dus gewoon niet van toepassing als je achter NAT zit. Want NAT laat alleen binnenkomende packets door die bij een al bestaande uitgaande verbinding horen. Een verbinding die je zelf hebt opgezet dus. Verder is het gewoon zo dat alleen in het eerste fragment de UDP/TCP poortnummers enzo staan, dus het *moet* wel kloppen, anders kan NAT er gewoon niks mee.

[xantos]

dus als ik het goed begrijp, heb ik er niks aan in combinatie met Masquerading?

[Creepy]

Met NAT (aka Masquerading) heeft het geen nut nee... packages die voor het eigen systeem (naar jou IP gestuurd dus) zijn worden altijd al gedefragmenteert..

die ALWAYS defrag defragmenteerd ALLE packages die langskomen, dus ook diegene die NIET voor het systeem zijn.

Als je dus een firewall/BRIDGE draait is dit dus WEL handig.. met firewall/NAT/PROXY dus niet.

[xantos]

ok, dat wilde ik even weten.

Thanx....

[Verwijderd]

Op dinsdag 26 juni 2001 13:31 schreef Onno het volgende:

[..]

Heel leuk, maar dat is dus gewoon niet van toepassing als je achter NAT zit.

Die info is echt betrouwbaar hoor, en zegt toch echt dat het dus wel betrekking heeft tot de machines achter de gateway.
Dat staat er toch gewoon?
Het betreft ook niet 'normale verdwaalde' fragments, maar gemanipuleerde en gespoofde packets, en die kunnen wel degelijk je interne net bereiken zonder die defrag optie.

[Onno]

Op dinsdag 26 juni 2001 16:40 schreef Mainwave het volgende:
Dat staat er toch gewoon?

Dat iets ergens staat is *geen* reden om er vanuit te gaan dat dat ook juist is. En verder zeg jij 'gateway', dat is wat anders dan NAT. Een gateway is een host in je eigen net die je verbindt met een ander net, NAT is een proces dat door een gateway uitgevoerd kan worden.

maar gemanipuleerde en gespoofde packets, en die kunnen wel degelijk je interne net bereiken zonder die defrag optie.

Oh ja? Hoe dan?

[Verwijderd]

Op dinsdag 26 juni 2001 17:00 schreef Onno het volgende:

[..]

Dat iets ergens staat is *geen* reden om er vanuit te gaan dat dat ook juist is.

Wel als de bron betrouwbaar is?
Is een boek waarover zelfs Eric S. Raymond erg goed over te spreken is, tja...

Oh ja? Hoe dan?

Dat wil ik ook graag weten
Ik meen dat het wel mogelijk was.
Door een source-routed frame samen te stellen ofzo, weet ook de details er niet van.

[[eNeRGy]]

Op dinsdag 26 juni 2001 17:11 schreef Mainwave het volgende:

[..]

Wel als de bron betrouwbaar is?
Is een boek waarover zelfs Eric S. Raymond erg goed over te spreken is, tja...
[..]

Ik ben heel erg te spreken over Onno, en ik vind hem betrouwbaar, dat betekent toch nog niet dat hij _altijd_ gelijk heeft

[Verwijderd]

Verwijderd, ik ga niet mee flamen
Ik trapte er bijna in

[Creepy]

Op dinsdag 26 juni 2001 16:40 schreef Mainwave het volgende:

[..]

Het betreft ook niet 'normale verdwaalde' fragments, maar gemanipuleerde en gespoofde packets, en die kunnen wel degelijk je interne net bereiken zonder die defrag optie.

Als je gebruik maakt van NAT kan dat standaard helemaal NIET! Packages worden alleen doorgelaten naar het INTERNE net als de verbinding waarbij ze horen vanuit het INTERNE net is geinitieerd. Packages bestemt voor iets anders worden dus niet doorgelaten.... Dan heb je natuurlijk ook nog van die mensen die hun NAT machine automatisch een paar poorten naar het interne net laten forwarden.. tja.. dat moet je ook niet doen natuurlijk..

En voor dat geval heb ik wat firewall-regels toegevoegd die alle packages op m'n internet interface dropt die vanuit het interne net te lijken komen aangezien dat niet kan :-)

En zeker met een wat tragere machine scheelt dit weer, aangezien ALWAYS DEFRAG ook wat extra processorkracht en geheugen in gebruik neemt.

En nogmaals: Als je GEEN NAT of PROXY gebruikt op je firewall, maar de firewall als BRIDGE gebruikt dan is het wel handig om ALWAYS DEFRAG aan te hebben staan

[Verwijderd]

Op dinsdag 26 juni 2001 20:20 schreef Creepy het volgende:

[..]

En voor dat geval heb ik wat firewall-regels toegevoegd die alle packages op m'n internet interface dropt die vanuit het interne net te lijken komen aangezien dat niet kan :-)

Kijk hier hebben we wat aan.
Wat ik me nu nog afvraag, rp_filter biedt anti-spoofing (met de hand kan ook), dus zonder dat zou de kernel dus wel gespoofde packets accepteren en er eventueel een reply op geven, die dan toch op je interne net kunnen komen?
(of zoek ik het nu echt veel te ver

En nogmaals: Als je GEEN NAT of PROXY gebruikt op je firewall, maar de firewall als BRIDGE gebruikt dan is het wel handig om ALWAYS DEFRAG aan te hebben staan

Vraagje: wat wordt verstaan onder bridge?
Met gateway bedoel ik MASQ +eventueel firewall, en naar mijn idee is MASQ een vorm van NAT.
NAT vertaald ip adressen, met eventuele poort verplaatsing als een port al bezet is, en MASQ vertaald ze ook nog eens naar een portrange, daar ergens in de 61000+.
(Beiden houden een connection-table bij?)
Onder BRIDGE mag ik een sluis (zonder translation) verstaan?
Alvast bedankt voor de info...!

[Creepy]

MASQ maakt dacht ik gebruik van de techniek NAT om te kunnen masqueraden (adressen wordt vertaald bij verzenden en terugvertaald bij ontvangen.. vandaar Network Adress Translation )

NAT "kent" alleen de TCP/IP protocollen, terwijl MASQ de bovenliggende protocollen ook kent (ftp, http, quake, whatever.. gewoon de juiste module laden)

MASQ doet trouwens niks met ranges van poorten, je kan alleen wel zo instellen dat bepaalde ranges voor gebruik van MASQ zijn toegestaan..

MASQ laat dus ALLEEN packages door die vanuit het interne net zijn geinitieerd...
Gespoofde packages zijn met een paar simpele firewall rules te stoppen (ik kan je de ip-chains regels geven als je wilt)
Ik weet niet 100% zeker of gespoofde packages van de externe interface meteen worden doorgestuurd over de interne met MASQ, nooit getest.. maar vandaar die paar anti-spoof regels

een bridge is inderdaad een soort van sluis om 2 netwerken met elkaar te verbinden.. en de bridge geeft dus gewoon de packages door van het ene netwerk naar het andere.. op een bridge kan ook een firewall geinstalleerd zijn.