[discussie] Het end-to-end argument, firewalls en NAT

[QuarkuS]

Edit: Dit is een wat voorbarig begin van een discussie waarvan de startpost hier (wat verder naar beneden dus) staat

SSH schreef op 19 oktober 2004 @ 13:06:
Als je je bak goed configged heb je natuurlijk helemaal geen firewalll nodig.

Precies. Firewalls zijn ondingen die niet op het Internet thuishoren. Er zijn situaties waarbij ze eventueel te rechtvaardigen zijn, maar die zijn zeer gelimiteerd (ingress/egress filtering bijv), en op servers doorgaans niet nodig.

Maar SSH logins filteren tot alleen je eigen IP is natuurlijk nooit verkeerd.

... wat precies is waar hosts.allow en hosts.deny voor zijn uitgevonden (en je gaat er op een dag hard door gebeten worden).

Er is geen substituut voor weten wat je doet.

[ Voor 14% gewijzigd door QuarkuS op 20-10-2004 17:02 ]

[Verwijderd]

Een firewall is toch juist reuzehandig? Alles dicht en dan open gooien wat je weet dat je nodig hebt -- dan kun je ook nooit per ongeluk een service open hebben staan.

Tevens heb je dan alles wat open/dicht moet staan op een centrale plaats geconfigureerd in een enkele config file die maar een enkele format gebruikt. Dus hoef je niet te zoeken van "waar zat die service.conf nou ook alweer en hoe gaf ik ook alweer aan dat ie alleen aan die interface/naar dat ip moet luisteren.."

Of zit ik er heeeelemaal naast?

[FendtVario]

QuarkuS schreef op 19 oktober 2004 @ 18:17:
Precies. Firewalls zijn ondingen die niet op het Internet thuishoren. Er zijn situaties waarbij ze eventueel te rechtvaardigen zijn, ....

Ben ik niet met je eens. Ook al configureer je /etc/hosts.allow, stel je SSH goed in, stel je in de applicaties de ip-ranges in waarvan ze connecties mogen accepteren, een firewall kan net even dat extra stukje zekerheid brengen als dat nodig is. Met een firewall kun je bijvoorbeeld nog maatregelen nemen tegen ICMP verkeer, zodra je onder linux ethX opstart kun je de bak pingen. En als ik ping wil stoppen? Kan bij mijn weten nergens.

En dan heb je nog de applicaties die niet instaat zijn om goed te configureren, de apps die je niet beschikbaar wilt hebben op internet. Je kan je natuurlijk afvragen waarom je die dingen op een server wil zetten maar veel mensen zullen voor thuis niet in staat zijn om een heel park met DMZ aan te leggen.

Daarnaast heb je nog de mensen die Winxxx bakken aan internet hangen, die overleven ook niet lang zonder firewall (geen ervaring met SP2). Daarnaast zijn firewalls mooie tooltjes om nog het een en ander te loggen.

Als laatste nog een paar tips voor goede beveiliging:
* gebruikt degelijke wachtwoorden
* configureer groepen/gebruikers zodat een persoon of process geen toegang kan krijgen tot dingen die je niet wilt.
* laat programma's in een afgeschermde omgeving draaien (chroot).
* laat verbindingen over SSL lopen waar dit mogelijk is (POP, IMAP, SSH)

[QuarkuS]

FendtVario schreef op 19 oktober 2004 @ 21:41:
[...]

Ben ik niet met je eens. Ook al configureer je /etc/hosts.allow, stel je SSH goed in, stel je in de applicaties de ip-ranges in waarvan ze connecties mogen accepteren, een firewall kan net even dat extra stukje zekerheid brengen als dat nodig is.

Da's precies wat ik zeg Er is geen substituut voor weten wat je doet. Alleen als je denkt dat je het zelf niet goed doet, is er reden om je ongerustheid te sussen met een firewall. Dat is dan wel de verkeerde reden voor een firewall uiteraard.

Met een firewall kun je bijvoorbeeld nog maatregelen nemen tegen ICMP verkeer, zodra je onder linux ethX opstart kun je de bak pingen. En als ik ping wil stoppen? Kan bij mijn weten nergens.

Waar is dat goed voor dan? Het is zelfs hopeloos irritant dat er mensen zijn die ping blokkeren op hun machines. Weet je nooit of die machine nou down is of dat het alleen apache is die bokt.

En dan heb je nog de applicaties die niet instaat zijn om goed te configureren, de apps die je niet beschikbaar wilt hebben op internet. Je kan je natuurlijk afvragen waarom je die dingen op een server wil zetten maar veel mensen zullen voor thuis niet in staat zijn om een heel park met DMZ aan te leggen.

Dingen die je niet op het Internet wilt hebben installeer je niet op een machine die je aan het internet hangt? En anders bind je het op een interne interface?

Daarnaast heb je nog de mensen die Winxxx bakken aan internet hangen, die overleven ook niet lang zonder firewall (geen ervaring met SP2).

Ingress/egress filtering voor kwetsbare machines. Kan ik mee leven.

Daarnaast zijn firewalls mooie tooltjes om nog het een en ander te loggen.

Kan ik ook mee leven

Als laatste nog een paar tips voor goede beveiliging:
* gebruikt degelijke wachtwoorden
* configureer groepen/gebruikers zodat een persoon of process geen toegang kan krijgen tot dingen die je niet wilt.
* laat programma's in een afgeschermde omgeving draaien (chroot).
* laat verbindingen over SSL lopen waar dit mogelijk is (POP, IMAP, SSH)

Akkoord

chris schreef op 19 oktober 2004 @ 18:43:
Zorgen dat root niet kan inloggen via ssh en dat je dus alleen root kan worden via su is ook handig. En zorgen dat je alleen zelf in de wheel groep zit.

Voor zover ik weet heeft linux geen group 'wheel'. BSD's wel. Maar sudo goed instellen is inderdaad een must.

[Verwijderd]

Firewall of niet? Kun je je bij een heleboel security-solutions afvragen.... tja... simpel... je kunt het doen of laten. Doe je je raam dicht als je van huis weg gaat? Je kunt het doen of laten. Ik zou het maar doen....

Verder http://mrlee.homelinux.net/linux-security.htm vanalles bij elkaar geschraapt juist voor dit soort vragen.

[blaataaps]

QuarkuS schreef op 19 oktober 2004 @ 22:01:
Voor zover ik weet heeft linux geen group 'wheel'. BSD's wel.

de naam van de groep lijkt me hoogst irrelevant, maar die functionaliteit is met pam in 5 seconden aan te zetten op linux (behalve op gentoo staat het default meestal uit).

[Erkens]

QuarkuS schreef op 19 oktober 2004 @ 22:01:
Voor zover ik weet heeft linux geen group 'wheel'. BSD's wel. Maar sudo goed instellen is inderdaad een must.

slackware wel

[Flydude]

Gentoo heeft een 'wheel' group...

[FendtVario]

@QuarkuS; Dingen die je niet op internet wilt installeer je niet op een server, maar zoals ik ook zeg hebben de meesten thuis geen serverpark (voor bedrijven gelden natuurlijk andere regels) of DMZ. Helaas zijn er ook nog altijd dingen die je niet kunt binden aan een netwerk, die gaan dom luisteren op alles wat ze tegen komen.

Wat trouwens ook nog een mooie (maar helaas omslachtige) methode is om connecties vanaf het internet te voorkomen tenzij je daar expliciet toegang toe geeft is port knocking. Zie www.portknocking.org voor meer info of de c't van september 2004.

[ Voor 3% gewijzigd door FendtVario op 19-10-2004 22:17 ]

[Erkens]

Ik snap niet wat sommige erop tegen hebben om een extra beveiligings laag te hebben?
Daarnaast is het volgens mij onmogelijk om mbv host.deny/allow verkeer te reguleren van en naar een apache server, want dat regelt apache zelf en op dat moment is er toch een verbinding die ik niet wil hebben

[Zwerver]

QuarkuS schreef op 19 oktober 2004 @ 22:01:
[...]

Da's precies wat ik zeg Er is geen substituut voor weten wat je doet. Alleen als je denkt dat je het zelf niet goed doet, is er reden om je ongerustheid te sussen met een firewall. Dat is dan wel de verkeerde reden voor een firewall uiteraard.

Beweert ie dat dan? Je vergeet gemakshalve even dat er misschien wel een lek in een programma kan zitten waardoor die toch op de externe interface luisterd, er binnen nu en X maanden toch echt virussen voor linux systemen komen die interfaces openzetten en zo kan je nog een aantal dingen noemen. Er van uit gaan dat je systeem veilig is 'omdat jij weet wat je doet' is imho een concept wat tegenwoordig gewoon niet meer opgaat.

[...]

Waar is dat goed voor dan? Het is zelfs hopeloos irritant dat er mensen zijn die ping blokkeren op hun machines. Weet je nooit of die machine nou down is of dat het alleen apache is die bokt.

Ik wil gewoon niet dat mensen vanaf Internet bepaalde bedrijfskritische applicaties met ping gaan bestoken. Ping is niet alleen geschikt voor het testen of een server nog werkt, maar geeft ook bepaalde (imho belangrijke) informatie weg over je systeem. Wil je die afblocken dan zul je dus echt een firewall moeten hebben.

[...]

Dingen die je niet op het Internet wilt hebben installeer je niet op een machine die je aan het internet hangt? En anders bind je het op een interne interface?

Nee, jij hangt MS-SQL server niet aan het Internet als die vanaf Internet bereikbaar moet zijn... Tis maar gewoon even een voorbeeld van een applicatie die ik liever niet voor de hele Internet populatie bereikbaar wil hebben maar bijv alleen maar voor een bepaalde lokatie. En MS-SQL Server heeft in het verleden toch echt kritische bugs gehad

[...]

Voor zover ik weet heeft linux geen group 'wheel'. BSD's wel. Maar sudo goed instellen is inderdaad een must.

Uhmz, leer je stof kennen Die is er wel degelijk, staat alleen niet per definitie aan

[QuarkuS]

Erkens schreef op 19 oktober 2004 @ 22:22:
Ik snap niet wat sommige erop tegen hebben om een extra beveiligings laag te hebben?

Je kan wel een vuurmuur om je huis bouwen voor extra beveiliging, maar je kan ook gewoon de deur op slot doen. En met zo'n vuurmuur kan niemand meer naar buiten kijken.

Zwerver schreef op 19 oktober 2004 @ 23:22:
[...]

Beweert ie dat dan? Je vergeet gemakshalve even dat er misschien wel een lek in een programma kan zitten waardoor die toch op de externe interface luisterd, er binnen nu en X maanden toch echt virussen voor linux systemen komen die interfaces openzetten en zo kan je nog een aantal dingen noemen. Er van uit gaan dat je systeem veilig is 'omdat jij weet wat je doet' is imho een concept wat tegenwoordig gewoon niet meer opgaat.

Proefballonnetjes gaan hoog zeg
Dat vind ik nog steeds geen excuus om het adagium waarop het Internet gebouwd is (het end-to-end argument) te negeren en overal firewalls te bouwen. De vrijheid tot innovatie vind ik belangrijker dan het goede gevoel van paranoide netwerkbeheerders (systeembeheerders zouden geen firewalls op moeten zetten).

Ik wil gewoon niet dat mensen vanaf Internet bepaalde bedrijfskritische applicaties met ping gaan bestoken. Ping is niet alleen geschikt voor het testen of een server nog werkt, maar geeft ook bepaalde (imho belangrijke) informatie weg over je systeem. Wil je die afblocken dan zul je dus echt een firewall moeten hebben.

[...]

Nee, jij hangt MS-SQL server niet aan het Internet als die vanaf Internet bereikbaar moet zijn... Tis maar gewoon even een voorbeeld van een applicatie die ik liever niet voor de hele Internet populatie bereikbaar wil hebben maar bijv alleen maar voor een bepaalde lokatie. En MS-SQL Server heeft in het verleden toch echt kritische bugs gehad

Ik ben niet onder de indruk. OK, ik zie de redenen wel waarom je dat wilt, en pragmatisch gezien werkt een firewall uitstekend voor dit soort doeleinden, maar dat betekent nog niet dat een firewall de goede oplossing is hiervoor. Je MS-SQL server bind je op een VPN interface, en je hebt hem alleen maar vanaf 1 lokatie beschikbaar. Hm, wacht je hebt het over MS SQL. Ja, dan praat je over andere dingen. Maar als je het over bedrijfskritische applicaties hebt, dan heb je het ook over bedrijven die weten hoe je netwerken moet opzetten, met DMZ enzo. Dus eigenlijk is mijn argument dan weer niet van toepassing (ingress/egress filtering toegestaan tot op zekere hoogte).

Uhmz, leer je stof kennen Die is er wel degelijk, staat alleen niet per definitie aan

I stand corrected. Hoewel GNU su geen 'wheel' ondersteunt, en er bij debian standaard geen group wheel bestaat. Dus ik ben niet helemaal gek

[CyBeR]

QuarkuS schreef op 20 oktober 2004 @ 08:32:
[...]

Proefballonnetjes gaan hoog zeg
Dat vind ik nog steeds geen excuus om het adagium waarop het Internet gebouwd is (het end-to-end argument) te negeren en overal firewalls te bouwen. De vrijheid tot innovatie vind ik belangrijker dan het goede gevoel van paranoide netwerkbeheerders (systeembeheerders zouden geen firewalls op moeten zetten).

Hier ga je imo de mist in. Bij een firewall bestaat er nog steeds end-to-end connectivity, alleen sommige connectiviteit wordt om veiligheidsredenen tegengehouden. Jij bedoelt rfc1918 addressering en NAT. Dat is inderdaad evil.

[justice strike]

Ik moet hier toch even op zeggen dat er in bedrijfsomgevingen altijd een firewall gebruikt wordt. Ongeacht of de server freebsd, linux, solaris, windows of etc... is.

Simpelweg omdat niemand mij kan garanderen dat die ossen geen poorten open laten staan (windows bijvoorbeeld). Of omdat er nog niet ondekte lekken bestaan. (rpc lek van windows zou best kunnen bestaan in freebsd maar nog niet ondekt zijn). Het is onzinnig om te zeggen dat een firewall overbodig is.

Een firewall gebruik je niet alleen omdat je niet zeker bent van de software die je gebruikt, (en laten we wel wezen je kan je nooit permitteren vertrouwen te hebben in software) maar ook om een extra laag beveiliging te hebben tegen eventuele hackers.

Daarbij hebben firewalls ook de mogelijkheid om voortijdig bepaalde aanvallen te vermijden (syn attack?) waardoor ze ook meer doen dan alleen poorten afsluiten.

Vanuit een security point of view is er geen reden om een firewall niet te gebruiken. Sterker nog wat is het voordeel van het niet gebruiken van een firewall? die paar extra cycles dieje krijgt?

[Verwijderd]

possamai schreef op 20 oktober 2004 @ 10:14:
[...]
Volgens mij zijn die mensen die iets tegen firewalls hebben er gewoon nooit goed ingedoken en hebben er daardoor alleen maar problemen mee gehad..
Een vuurmuur is niet een muur om je huis.. de vuurmuur is je voordeur die op slot zit.. wat handiger is dan binnen in je huis appart iedere deur op slot te doen..

Ik denk dat er ook gewoon een aantal mensen is die het beu is dat zodra het over beveiliging gaat de eerste en de laatste tip/hint etc.. altijd een firewall is.

Tuurlijk werkt een firewall, en tuurlijk heeft het voordelen.
Somige dingen kunnen zelfs enkel via een firewall.

maar nog blijft een firewall het *laatste* waar ik aan denk bij beveiliging.
Immers, een firewall vangt de losse eindjes af.
De eerste stap naar een veilige bak, is zorgen dat je geen losse eindjes hebt.

[Stacium]

FendtVario schreef op 19 oktober 2004 @ 21:41:
[...]
Met een firewall kun je bijvoorbeeld nog maatregelen nemen tegen ICMP verkeer, zodra je onder linux ethX opstart kun je de bak pingen. En als ik ping wil stoppen? Kan bij mijn weten nergens.

oehh, zeg dat soort dingen nooit

code:

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

als je nu verder geen niet noodzakelijke dingen hebt openstaan, zou dit veilig genoeg moeten zijn. Zelf heb ik _en_ geen nutteloze zooi open staan _en_ een firewall draaien. Iptables gebruik ik eigenlijk vooral om poorten te mappen van m'n publiek ip naar netwerk pc's

wat overigens een punt is wat naar mijn mening volledig wordt vergeten (in dit topic) is het up-to-date houden van je systeem. Als je services aanbiedt staan er altijd dingen open, zodra daar een lek in ontdekt wordt lijkt het me lichtelijk verstandig zo snel mogelijk de patch hiervoor te installeren, anders heb je nog niets aan je firewall. Jezelf op de security-mailinglist van je distro abonneren dus

[ Voor 28% gewijzigd door Stacium op 20-10-2004 12:09 ]

[QuarkuS]

CyBeR schreef op 20 oktober 2004 @ 08:53:
[...]


Hier ga je imo de mist in. Bij een firewall bestaat er nog steeds end-to-end connectivity, alleen sommige connectiviteit wordt om veiligheidsredenen tegengehouden. Jij bedoelt rfc1918 addressering en NAT. Dat is inderdaad evil.

Zowel NAT als firewalls breken end-to-end connectivity. Goed geconfigureerde firewalls in mindere mate, maar ze doen het wel.

Firewalls kunnen niet in IPsec kijken. Ze kunnen niet omgaan met Mobile IP. Ze kunnen slecht omgaan met protocollen die dynamische poorten gebruiken. Ze houden innovaties tegen (onder andere IPv6, Mobile IPv6) door poorten dicht te zetten, die je met slechts een hoop moeite door de admin weer open kan laten zetten (velen omzeilen dit probleem tegenwoordig door alles in HTTP te tunnelen. dat is dus geen oplossing, het is een workaround, en je haalt het probleem van de IP laag naar de presentatielaag, je lost het niet op). Ze hebben zeer complexe middlebox oplossingen nodig om het te laten werken.

Maar misschien moeten we een nieuw discussie-topic openen over end-to-end issues en firewalls. 't Is lichtelijk offtopic hier.

[FendtVario]

Stacium schreef op 20 oktober 2004 @ 11:38:
oehh, zeg dat soort dingen nooit

code:

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

Kijk, weer wat geleerd.

Hierbij nog een manier om de beveiliging op je linux bak flink te verhogen (mits goed ingesteld natuurlijk). Kijk een naar RSBAC, deze kernel uitbreiding geeft via een aantal modules _zeer_ uitgebreide instellingen op gebied van beveiliging. Zo worden er bijvoorbeeld ACL toegevoegd, role modellen via RC, en CAP voor capabilites toegevoegd. Zeer interessant.

[Flying_Thunder]

Zwerver schreef op 19 oktober 2004 @ 23:22:
Ik wil gewoon niet dat mensen vanaf Internet bepaalde bedrijfskritische applicaties met ping gaan bestoken. Ping is niet alleen geschikt voor het testen of een server nog werkt, maar geeft ook bepaalde (imho belangrijke) informatie weg over je systeem. Wil je die afblocken dan zul je dus echt een firewall moeten hebben.

echo 1 >/proc/sys/net/ipv4/icmp_echo_ignore_all Goed je blokt wel ietsje meer dan een gewone ping dan... Maar firewall is zeker niet nodig daarvoor.

edit:
Moet sneller typen/lezen

[ Voor 5% gewijzigd door Flying_Thunder op 20-10-2004 12:22 ]

[blaataaps]

Flying_Thunder schreef op 20 oktober 2004 @ 12:21:
[...]


echo 1 >/proc/sys/net/ipv4/icmp_echo_ignore_all Goed je blokt wel ietsje meer dan een gewone ping dan... Maar firewall is zeker niet nodig daarvoor.

Wat blok je dan nog meer behalve gewone ping? Ik wist niet dat er meer dingen onder icmp echo vielen.

[TAMW]

path MTU discovery lukt niet meer

[Zwerver]

QuarkuS schreef op 20 oktober 2004 @ 11:51:
[...]


Zowel NAT als firewalls breken end-to-end connectivity. Goed geconfigureerde firewalls in mindere mate, maar ze doen het wel.

Firewalls kunnen niet in IPsec kijken. Ze kunnen niet omgaan met Mobile IP. Ze kunnen slecht omgaan met protocollen die dynamische poorten gebruiken. Ze houden innovaties tegen (onder andere IPv6, Mobile IPv6) door poorten dicht te zetten, die je met slechts een hoop moeite door de admin weer open kan laten zetten (velen omzeilen dit probleem tegenwoordig door alles in HTTP te tunnelen. dat is dus geen oplossing, het is een workaround, en je haalt het probleem van de IP laag naar de presentatielaag, je lost het niet op). Ze hebben zeer complexe middlebox oplossingen nodig om het te laten werken.

Maar misschien moeten we een nieuw discussie-topic openen over end-to-end issues en firewalls. 't Is lichtelijk offtopic hier.

Nee hoor, dit valt namelijk wel degelijk onder de vraag: waar op te letten bij beveiliging van linux... Ik zal alleen de title een beetje aanpassen

[FendtVario]

TAMW schreef op 20 oktober 2004 @ 13:05:
path MTU discovery lukt niet meer

Dit staat niet in de Linux kernel documentation. Is er een (linux) programmatje om de path MTU te achterhalen? Wat voor invloed heeft het niet kunnen achterhalen van de MTU op je connecties, vallen die terug naar de laagste MTU of wordt de MTU van het lokale netwerk dan gebruikt?

[QuarkuS]

FendtVario schreef op 20 oktober 2004 @ 13:44:
[...]
Dit staat niet in de Linux kernel documentation. Is er een (linux) programmatje om de path MTU te achterhalen? Wat voor invloed heeft het niet kunnen achterhalen van de MTU op je connecties, vallen die terug naar de laagste MTU of wordt de MTU van het lokale netwerk dan gebruikt?

Dat is ook niet specifiek een Linux probleem. Zie RFC 1981 voor IPv6. Een stukje uit de introductie:

When one IPv6 node has a large amount of data to send to another
node, the data is transmitted in a series of IPv6 packets. It is
usually preferable that these packets be of the largest size that can
successfully traverse the path from the source node to the
destination node. This packet size is referred to as the Path MTU
(PMTU), and it is equal to the minimum link MTU of all the links in a
path. IPv6 defines a standard mechanism for a node to discover the
PMTU of an arbitrary path.

IPv6 nodes SHOULD implement Path MTU Discovery in order to discover
and take advantage of paths with PMTU greater than the IPv6 minimum
link MTU [IPv6-SPEC]. A minimal IPv6 implementation (e.g., in a boot
ROM) may choose to omit implementation of Path MTU Discovery.

Nodes not implementing Path MTU Discovery use the IPv6 minimum link
MTU defined in [IPv6-SPEC] as the maximum packet size. In most
cases, this will result in the use of smaller packets than necessary,
because most paths have a PMTU greater than the IPv6 minimum link
MTU. A node sending packets much smaller than the Path MTU allows is
wasting network resources and probably getting suboptimal throughput.

[Flying_Thunder]

blaataaps schreef op 20 oktober 2004 @ 12:23:
[...]
Wat blok je dan nog meer behalve gewone ping? Ik wist niet dat er meer dingen onder icmp echo vielen.

Mijn definitie van gewone ping is mss niet helemaal juist, maar kijk: icmp_echo_ignore_all, wil dus zeggen dat je alle icmp dingen blokkeert, en dat is mss niet je bedoeling. Verder heb je nog een icmp_echo_ignore_broadcasts oid, en dat is zo'n beetje alles dan wat je in /proc/blabla in kanstellen iirc. Met een firewall kun je nog veel specifieker wezen dan te zeggen "geen broadcasts" of "helemaal geen icmp"

[Erkens]

QuarkuS schreef op 20 oktober 2004 @ 08:32:
Je kan wel een vuurmuur om je huis bouwen voor extra beveiliging, maar je kan ook gewoon de deur op slot doen. En met zo'n vuurmuur kan niemand meer naar buiten kijken.

je leest niet goed, ik had het over een extra beveiliginslaag, dus behalve dat slot op mijn deur (en bij mij mijn ramen ook ) wil ik ook een slotgracht en een hoge muur hebben zodat ze geen eens kans krijgen om aan mijn sloten te gaan prutsen
Daarnaast kan het ook erg handig zijn om outbound verkeer te blokken, zodat er totaal geen verkeer naar buiten mag op http en email verkeer na, en ja dat kom je vaak tegen, vooral in het bedrijfsleven, al dan niet in combinatie met een proxyserver.

[QuarkuS]

Erkens schreef op 20 oktober 2004 @ 15:21:
[...]

je leest niet goed, ik had het over een extra beveiliginslaag, dus behalve dat slot op mijn deur (en bij mij mijn ramen ook ) wil ik ook een slotgracht en een hoge muur hebben zodat ze geen eens kans krijgen om aan mijn sloten te gaan prutsen

Maar het effect is min of meer hetzelfde als wat ik bedoel: niemand kan meer naar buiten dan over de brug van de slotgracht. Dat betekent dat als iemand een keer een andere manier bedenkt, dat je dan een nieuwe brug moet bouwen

Daarnaast kan het ook erg handig zijn om outbound verkeer te blokken, zodat er totaal geen verkeer naar buiten mag op http en email verkeer na, en ja dat kom je vaak tegen, vooral in het bedrijfsleven, al dan niet in combinatie met een proxyserver.

Ik ontken niet dat het vaak voorkomt; dat betekent nog niet dat ik vind dat het een goed idee is. Het probleem is met name dat je gebruikers belet om dingen te doen (het woord 'probleem' wordt door admins waarschijnlijk gelezen als 'voordeel'). Mensen achter de firewall kunnen niet meer ssh'en tenzij door een http proxy, mensen achter de firewall kunnen niet meer irc'en tenzij door een http proxy, mensen achter de firewall kunnen niet meer ICQ'en tenzij door een http proxy. Alles kan, als je maar een http proxy hebt (OpenVPN anyone ?) En het probleem is weer verplaatst van de IP laag naar een hogere laag. Opgelost ho maar.
En intussen heeft elke ontwikkelaar die een nieuw inventief idee heeft, een probleem omdat overal mensen denken firewalls te moeten plaatsen, zodat hij uit arren moede z'n inventiviteit maar botviert op de zoveelste manier van tunnelen over http.

[blaataaps]

Flying_Thunder schreef op 20 oktober 2004 @ 14:35:
[...]

Mijn definitie van gewone ping is mss niet helemaal juist, maar kijk: icmp_echo_ignore_all, wil dus zeggen dat je alle icmp dingen blokkeert,

nee, dat wil het niet zeggen

dat is mss niet je bedoeling. Verder heb je nog een i

Jouw definitie van ping lijkt wel juist, je definitie van icmp niet blijkbaar, er is veel meer icmp (zo'n 254 andere mogelijk) dan alleen ping (echo dus), wat type 8 is, zie
http://www.iana.org/assignments/icmp-parameters . Het lijkt me dat een parameter die icmp_echo_ignore heet, alle andere icmp-types ongemoeid laat.
Hier zit ook een veel voorkomend probleem, veel mensen weten dit niet, en draaien wel even een firewall inelkaar, ze hebben vaag spookverhalen gehoord dat "ping gevaarlijk is" (onzin), dat icmp ping is (ping is 1 van de 255 mogelijke types icmp) en dat je dus alle icmp maar moet droppen (wat dom is meestal, en helemaal als je niet weet waar je mee bezig bent).

[ Voor 21% gewijzigd door blaataaps op 20-10-2004 16:05 ]

[Zwerver]

QuarkuS schreef op 20 oktober 2004 @ 15:45:
[...]

Maar het effect is min of meer hetzelfde als wat ik bedoel: niemand kan meer naar buiten dan over de brug van de slotgracht. Dat betekent dat als iemand een keer een andere manier bedenkt, dat je dan een nieuwe brug moet bouwen

Dan moet die gebruiker dat op dat moment maar opnemen met de beheerder. Je kan niet van software verwachten dat het 100% veilig is, dus breng je een extra veiligheidslaag aan, net zo goed dat je een hek om je huis neer zet om indringers tegen te houden.

[...]

Ik ontken niet dat het vaak voorkomt; dat betekent nog niet dat ik vind dat het een goed idee is. Het probleem is met name dat je gebruikers belet om dingen te doen (het woord 'probleem' wordt door admins waarschijnlijk gelezen als 'voordeel'). Mensen achter de firewall kunnen niet meer ssh'en tenzij door een http proxy, mensen achter de firewall kunnen niet meer irc'en tenzij door een http proxy, mensen achter de firewall kunnen niet meer ICQ'en tenzij door een http proxy. Alles kan, als je maar een http proxy hebt (OpenVPN anyone ?) En het probleem is weer verplaatst van de IP laag naar een hogere laag. Opgelost ho maar.
En intussen heeft elke ontwikkelaar die een nieuw inventief idee heeft, een probleem omdat overal mensen denken firewalls te moeten plaatsen, zodat hij uit arren moede z'n inventiviteit maar botviert op de zoveelste manier van tunnelen over http.

Ik zie je hier irc en icq noemen, zaken die ik op een bedrijfsnetwerk gewoon zou afblokken mede omdat het geen toegevoegde waarde heeft voor het werk. Als een bepaald persoon dat wel nodig heeft voor zijn werk dan kan hij contact opnemen met me, dan zet ik het speciaal voor hem/haar open gekoppeld aan een mac of ipadres.
Er is geen probleem overigens, ondanks dat jij dat de hele tijd wil zeggen: geen enkele nadenkende developer zal zijn applicatie over http gaan tunnelen om bedrijfsfirewalls te ontlopen.

[ Voor 6% gewijzigd door Zwerver op 20-10-2004 16:11 ]

[Erkens]

QuarkuS schreef op 20 oktober 2004 @ 15:45:
Maar het effect is min of meer hetzelfde als wat ik bedoel: niemand kan meer naar buiten dan over de brug van de slotgracht. Dat betekent dat als iemand een keer een andere manier bedenkt, dat je dan een nieuwe brug moet bouwen

Niks mis mee met het bouwen van bruggen voor speciale doelen, hiermee wordt je tenminste bewust van het verkeer dat naar buiten gaat, met een klein netwerk met weinig gebruikers zal je niet vaak problemen krijgen, maar zodra je te maken hebt met grote netwerken waarbij je niet iedereen kan vertrouwen die met dit netwerk verbonden is dan zal je wel moeten, denk ook aan bijvoorbeeld virussen en andere slecht geprogrammeerde software.
In derelijk grote netwerken is het imo onverstandig om maar geen firewall te hebben alleen maar omdat de beheerder te lui is om af en toe een nieuwe brug te bouwen of een bestaande aan te passen.

Het probleem is met name dat je gebruikers belet om dingen te doen (het woord 'probleem' wordt door admins waarschijnlijk gelezen als 'voordeel'). Mensen achter de firewall kunnen niet meer ssh'en tenzij door een http proxy, mensen achter de firewall kunnen niet meer irc'en tenzij door een http proxy, mensen achter de firewall kunnen niet meer ICQ'en tenzij door een http proxy. Alles kan, als je maar een http proxy hebt (OpenVPN anyone ?) En het probleem is weer verplaatst van de IP laag naar een hogere laag. Opgelost ho maar.

waarom alles via die proxy, als iemand voor zijn werkzaamheden ssh nodig heeft dan moet je die brug open zetten, en niet via een andere brug met een vrachtauto verplaatsen om uiteindelijk bij het doel aan te komen, dat slaat nergens op.

overigens wel leuk dat je over die lagen begint, een firewall kan op een lager niveau verkeer reguleren, iets wat jouw applicatie (zoals apache) niet kan

En intussen heeft elke ontwikkelaar die een nieuw inventief idee heeft, een probleem omdat overal mensen denken firewalls te moeten plaatsen, zodat hij uit arren moede z'n inventiviteit maar botviert op de zoveelste manier van tunnelen over http.

onzin

[Zwerver]

Omdat dit stiekum best een interessante discussie is toch maar even afgesplitst van het andere topic... Nadeel hiervan is dat die nu eigenlijk naar Professional Networking & Servers zal moeten

[Erkens]

Zwerver schreef op 20 oktober 2004 @ 16:28:
Omdat dit stiekum best een interessante discussie is toch maar even afgesplitst van het andere topic... Nadeel hiervan is dat die nu eigenlijk naar Professional Networking & Servers zal moeten

offtopic:
waarom is dat een nadeel dan?

[Zwerver]

offtopic:
Omdat we deze leuke discussie natuurlijk hier willen houden

[_JGC_]

Mja, firewalls wel of niet, firewalls evil of niet, eenmaal goed strak ingesteld heb je er geen last van.

Ik zit hier nu in een bedrijfsnetwerkje waarbij kantoor en serverruimte met VPN verbonden zijn. Behalve de nodige poorten op de servers in de serverruimte (HTTP, POP3, IMAP, SMTP, etc), is er helemaal geen enkele poort opengelaten in de firewall. Er draait nu niets achter, maar wat weet je daarvan over een halfjaar als je toevallig net die ene windows update vergeten bent, of net die ene webhosting klant had met een lek PHP script vanwaaruit een trojan gestart wordt? Verder kan je windows niet wijsmaken dat poort 135-139 niet aan een interface gebonden mogen worden, zelfs een inbelverbinding bindt ie nog aan, met alle security risks die erbij komen.

Firewalls zijn leuke dingen om alles mee te beveiligen, maar om nog iets te kunnen met de servers, zal je gaten moeten slaan. Op het moment dat er achter deze gaten slecht geconfigureerde zooi draait, helpt een firewall je nog niets.
Verder moet je erop letten dat je genoeg gaten hakt om je toepassingen te kunnen blijven gebruiken.

Wat betreft het firewallen van output:
zelf vind ik dit ontiegelijk irritant. Op de school waar ik zit hebben ze poort 6667 geblokkeerd zodat de zombie IRCs niet meer konden connecten met het botnet. In plaats van je security holes oplossen (hallo zeg, Win2K SP2 zonder hotfixes ), ga je een van de vele besturingskanalen van je trojans dichtzetten. Lekker handig, maar je hebt er nix aan, ze coden speciaal voor die school met 2Gbit en honderden, zo niet duizenden lekke windows PCs wel een trojan die een andere poort gebruikt.
Output firewalling is leuk voor serverruimtes en machines waar je exact van weet wat ze moeten gaan doen. Voor een normale client PC is het gewoon niet te doen. Op dit moment hebben we nog geen enkele vorm van output firewalling op de servers, aangezien we eerst maar eens grondig moeten uitzoeken wat er allemaal geopend en gesloten moet worden.

Wat betreft het firewallen van ICMP:
Ik had een PC met WinXP die ik een upgrade gaf naar SP2 via VNC. Leuk en aardig, ik geef dat ding een reboot en vervolgens is dat hele ding dood, *dacht ik*...
Blijkt dat winxp gewoon een "iptables -P INPUT DROP" doet, inclusief pings en alles wat erbij hoort in de standaardsetup. Hadden ze me wel ff mogen vertellen voor ik de reboot knop indrukte en ping startte om te wachten tot het ding weer opkwam.

[QuarkuS]

Ik loop al een tijdje met de gedachte om hier eens een discussie over te beginnen, en dit topic liep min of meer die richting op, dus hier een aftrap voor een goede discussie

Het end-to-end argument

Eerst even een kleine introductie tot het end-to-end argument. Het end-to-end argument is voor het eerst gepubliceerd in 1981 in het paper End-to-End Arguments in System Design. Het houdt in dat de intelligentie niet in het netwerk moet zitten, maar in de eindpunten.

Abstract:

This paper presents a design principle that helps guide placement of functions among the modules of a distributed computer system. The principle, called the end-to-end argument, suggests that functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level. Examples discussed in the paper include bit error recovery, security using encryption, duplicate message suppression, recovery from system crashes, and delivery acknowledgement. Low level mechanisms to support these functions are justified only as performance enhancements.

Een aantal andere interessante links:
Rise of the Stupid Network
on the "the "end-to-end argument""
Active Networking and End-To-End Arguments

Het end-to-end argument wordt gezien als een van de belangrijkere redenen van de onstuimige groei van het Internet. Dit komt omdat het end-to-end argument stelt dat het netwerk dom is, en alleen maar pakketten moet transporteren. Het gevolg is dat iedereen die een goed idee heeft, dat kan implementeren in de eindhosts, en de toepassing kan - ongehinderd door het netwerk - functioneren.

Een interessante terugblik op het argument is te vinden in The End of the End-to-End Argument.

Tegenwoordig zijn er een aantal belangrijke ontwikkelingen gaande die het end-to-end argument aan de kant hebben geschoven: firewalls en Network Address Translators (NAT) als de meest belangrijke. Het belangrijkste probleem daarbij is dat het netwerk niet meer transparant is.

Voor de problemen die geintroduceerd worden door dit soort praktijken, is de IETF working group Middlebox Communication (midcom) opgericht. Onlangs is er ook een IETF working group opgericht (Behavior Engineering for Hindrance Avoidance (behave)) die NAT problemen probeert op te lossen. De Firewall/IDS/NAT pagina heeft een overzicht van IETF documenten over dit onderwerp.

Een van de meer geniale documenten is het Firewall Enhancement Protocol (FEP) RFC 3093.

Zoals jullie wel gelezen hebben, ben ik uit een architectonisch oogpunt tegenstander van firewalls en NAT. Ik denk dat we het in principe wel eens zijn over NAT, maar firewalls liggen wat gevoeliger geloof ik Pragmagisch gezien begrijp ik verder wel dat mensen nut zien in firewalls.

Wat zijn jullie ideeen hierover?

edit:
Misschien is het wel interessant om te vermelden dat ik als onderzoeker op netwerk gebied werkzaam ben, en dus wellicht meer vanuit een academisch oogpunt hiernaar kijk dan werkelijk realistisch is

[ Voor 4% gewijzigd door QuarkuS op 20-10-2004 17:08 ]

[QuarkuS]

Toch nog wel even een reactie hierop

Erkens schreef op 20 oktober 2004 @ 16:14:
[...]
Niks mis mee met het bouwen van bruggen voor speciale doelen, hiermee wordt je tenminste bewust van het verkeer dat naar buiten gaat, met een klein netwerk met weinig gebruikers zal je niet vaak problemen krijgen, maar zodra je te maken hebt met grote netwerken waarbij je niet iedereen kan vertrouwen die met dit netwerk verbonden is dan zal je wel moeten, denk ook aan bijvoorbeeld virussen en andere slecht geprogrammeerde software.
In derelijk grote netwerken is het imo onverstandig om maar geen firewall te hebben alleen maar omdat de beheerder te lui is om af en toe een nieuwe brug te bouwen of een bestaande aan te passen.

Jep, pragmatisch gezien wel. Theoretisch gezien belemmer je vrije ontwikkeling. Het gaat namlijk niet om 1 beheerder van 1 netwerk, maar van alle firewall-admins over de hele wereld.

waarom alles via die proxy, als iemand voor zijn werkzaamheden ssh nodig heeft dan moet je die brug open zetten, en niet via een andere brug met een vrachtauto verplaatsen om uiteindelijk bij het doel aan te komen, dat slaat nergens op.

Dat was een beetje een gechargeerd voorbeeld. Het gaat ook niet op voor alle applicaties.

overigens wel leuk dat je over die lagen begint, een firewall kan op een lager niveau verkeer reguleren, iets wat jouw applicatie (zoals apache) niet kan

Klopt, een firewall zit tussen de IP en de applicatielaag in. Maar botweg op IP laag inspecteren werkt tegenwoordig al niet meer. Firewalls moeten al in applicatie-pakketten gaan kijken om normaal te kunnen functioneren (zie FTP als simpel voorbeeld).
En, niet alle applicaties ondersteunen het, maar hosts_access is er ook nog.

En intussen heeft elke ontwikkelaar die een nieuw inventief idee heeft, een probleem omdat overal mensen denken firewalls te moeten plaatsen, zodat hij uit arren moede z'n inventiviteit maar botviert op de zoveelste manier van tunnelen over http.
onzin

't Is wederom wat gechargeerd, maar SOAP is er niet voor niets, en al die andere protocollen die over HTTP draaien.

[TAMW]

QuarkuS even kort samengevat jij bedoelt dus dit:

Geef elk apparaat dat iets op internet gebruikt of iets host een eigen adres dat door alles en iedereen rechtstreeks op zijn eigen adres benaderbaar is op elke poort tcp/udp en alle types IP?


Mijn mening: theoretish is dit idd ideaal, maar dit kan alleen in a perfect world.

[ Voor 20% gewijzigd door TAMW op 20-10-2004 17:32 ]

[QuarkuS]

TAMW schreef op 20 oktober 2004 @ 17:23:
QuarkuS even kort samengevat jij bedoelt dus dit:

Geef elk apparaat dat iets op internet gebruikt of iets host een eigen adres dat door alles en iedereen rechtstreeks op zijn eigen adres benaderbaar is op elke poort tcp/udp en alle types IP?


Mijn mening: theoretish is dit idd ideaal, maar dit kan alleen in a perfect world.

Min of meer ja. Het Host Identity Protocol is een eind op weg hiernaartoe. En IPv6 is een grote stap in de goede richting (dan kan je bijvoorbeeld ook alle GSM's een eigen IP adres geven).

Desalniettemin zijn er ook mensen die daar privacy-leeuwen en beren zien. Dat is ook wel te begrijpen; en dat resulteert dan weer in Privacy Extensions for Stateless Address Autoconfiguration in IPv6 en dergelijken (ze suggereren zelfs om Mobile IPv6 te gebruiken als privacy maatregel). Derhalve is wereldwijde connectiviteit waarschijnlijk helaas een utopie.

[Erkens]

QuarkuS schreef op 20 oktober 2004 @ 17:19:
Jep, pragmatisch gezien wel. Theoretisch gezien belemmer je vrije ontwikkeling. Het gaat namlijk niet om 1 beheerder van 1 netwerk, maar van alle firewall-admins over de hele wereld.

wat heeft een beheerder aan de andere kant van de wereld ermee te maken dat ik bepaalde poorten afsluit?
niks, helemaal niks. Dat ik iets afsluit is mijn "probleem", als een applicatie niet werkt is dat mijn "probleem" en zal ik dus die burg moeten openen.

Klopt, een firewall zit tussen de IP en de applicatielaag in. Maar botweg op IP laag inspecteren werkt tegenwoordig al niet meer. Firewalls moeten al in applicatie-pakketten gaan kijken om normaal te kunnen functioneren (zie FTP als simpel voorbeeld).
En, niet alle applicaties ondersteunen het, maar hosts_access is er ook nog.

Waarom zou je niet botweg op IP (of TCP) niveau kunnen blokken, is een redelijk effectiefe manier van alles filteren wat je niet wenst, en eventueel zou je op applicatie niveau wat meer kunnen doen om de rotte appels eruit te halen, bijvoorbeeld dmv hosts_access.

't Is wederom wat gechargeerd, maar SOAP is er niet voor niets, en al die andere protocollen die over HTTP draaien.

afaik is SOAP een manier om met XML data te versturen, wat dus net zogoed met een ander protocol gedaan kan worden ipv HTTP

[QuarkuS]

Erkens schreef op 20 oktober 2004 @ 17:57:
[...]

wat heeft een beheerder aan de andere kant van de wereld ermee te maken dat ik bepaalde poorten afsluit?
niks, helemaal niks. Dat ik iets afsluit is mijn "probleem", als een applicatie niet werkt is dat mijn "probleem" en zal ik dus die burg moeten openen.

Die beheerder heeft ermee te maken dat ik als applicatie-developer er tegenaanloop dat overal ter wereld de poorten gefirewalld zijn die ik wil gebruiken.

Waarom zou je niet botweg op IP (of TCP) niveau kunnen blokken, is een redelijk effectiefe manier van alles filteren wat je niet wenst, en eventueel zou je op applicatie niveau wat meer kunnen doen om de rotte appels eruit te halen, bijvoorbeeld dmv hosts_access.

Ik bedoel eigenlijk dat op IP /TCP niveau (poort nummers) zoveel geblokkeerd wordt, dat vaak alleen poort 80 nog open staat. Ik bedoel hier geen blokkeringen op IP adres. Het gaat om content filteren. Mensen die je niet mag, mag je voor mijn part filteren op IP adres, maar mensen met wie je zelf wilt communiceren, die moet je niet hinderen. Dat doet een filter op poort wel. Je moet bijvoorbeeld FTP paketten inspecteren om te weten welke dynamische poort gebruikt wordt, zodat je die weer kan openen. Maar het feit dat het enige waar je van uit kan gaan is dat poort 80 open staat, kan je alles over poort 80 /HTTP tunnelen.

afaik is SOAP een manier om met XML data te versturen, wat dus net zogoed met een ander protocol gedaan kan worden ipv HTTP

Maar dat doen ze niet, want dan kom je niet door firewalls heen. (wederom gechargeerd, want HTTP heeft wel andere eigenschappen dan dat het alleen maar makkelijk door firewalls heen komt )

[FendtVario]

QuarkuS schreef op 20 oktober 2004 @ 18:09:Die beheerder heeft ermee te maken dat ik als applicatie-developer er tegenaanloop dat overal ter wereld de poorten gefirewalld zijn die ik wil gebruiken.

Op het moment dat er een applicatie ontwikkeld wordt waarvoor het nodig is dat er communicatie verloopt over een bepaalde poort denk ik niet dat dit het probleem is van de ontwikkelaar. Ik vraag me af wat erger is, dat jij je als ontwikkelaar aanpast aan de firewall-situatie door communicatie bijv. via SOAP te laten verlopen (of welk ander bestaand protocol dan ook) of dat jouw applicatie niet gebruikt kan worden door onjuiste infrastructere beslissingen. De beheerder van het betreffende netwerk waar de applicatie moet gaan draaien moet de infrastructuur zo inrichten dat de vereiste applicaties kunnen draaien. De beheerder van het betreffende netwerk waar de applicatie moet gaan draaien moet de infrastructuur zo inrichten dat de vereiste applicaties kunnen draaien.

Er zullen altijd applicaties blijven die meeliften op het 'succes' van een applicatie die zo belangrijk is dat hiervoor gaten in de firewall gemaakt moeten worden. Ik denk dat dit nooit zal stoppen.

[Erkens]

QuarkuS schreef op 20 oktober 2004 @ 18:09:
Die beheerder heeft ermee te maken dat ik als applicatie-developer er tegenaanloop dat overal ter wereld de poorten gefirewalld zijn die ik wil gebruiken.

ehm, als die applicatie gebruikt moet worden dan geef je aan in je documentatie dat er bepaalde poorten open moeten

Ik bedoel eigenlijk dat op IP /TCP niveau (poort nummers) zoveel geblokkeerd wordt, dat vaak alleen poort 80 nog open staat. Ik bedoel hier geen blokkeringen op IP adres. Het gaat om content filteren. Mensen die je niet mag, mag je voor mijn part filteren op IP adres, maar mensen met wie je zelf wilt communiceren, die moet je niet hinderen. Dat doet een filter op poort wel.

Dat doet een filter op poort niet, immers als ik vind dat jij mijn server mag gebruiken dan zijn die poorten gewoon open, gewoon een kwestie van goed instellen, iets wat veel beheerders gewoon niet kunnen blijkbaar, gezien jouw ervaringen met poort filters

Je moet bijvoorbeeld FTP paketten inspecteren om te weten welke dynamische poort gebruikt wordt, zodat je die weer kan openen. Maar het feit dat het enige waar je van uit kan gaan is dat poort 80 open staat, kan je alles over poort 80 /HTTP tunnelen.

ehm, afaik heb je voor FTP maar 2 poorten nodig, 20 en 21, de commando's gaan via 21 en de data via 20. En je zorgt er natuurlijk voor dat verbindingen die gemaakt zijn gewoon blijven werken. Immers als ik met mijn browser naar een website ga dan maak ik verbinding naar poort 80 terwijl mijn eigen poort een "random" poort boven 1024 is, en je doorgaands alleen op _doel_ poorten filtert.

Maar dat doen ze niet, want dan kom je niet door firewalls heen. (wederom gechargeerd, want HTTP heeft wel andere eigenschappen dan dat het alleen maar makkelijk door firewalls heen komt )

ik vraag me af of dat de daadwerkelijke reden is, immers waarom een nieuw protocol verzinnen als de reeds bestaande protocollen volstaan, precies wat je zegt, HTTP heeft meer voordelen dan dat het vaak toegestaan is, en vergeet niet dat HTTP een laag hoger ligt dan poort 80, want in principe kan ik gewoon op poort 80 een ssh server zetten als ik dat leuk vind, of het nuttig is, dat is een ander verhaal.
Wat je wel vaak ziet is dat er een HTTP poort is geopend op een andere poort speciaal voor een bepaalde applicatie, en in de documentatie van die software is dan te vinden dat die poort open moet zijn voor ingaand HTTP verkeer. Daar dien je als beheerder rekening mee te houden als er mensen zijn binnen je netwerk die gebruik moeten maken van die applicatie op die server (in dat geval uiteraard een outbound rule).

[FendtVario]

Onhoudt het verschil tussen actieve en passieve ftp. Passive ftp maakt geen gebruik van poort 20 maar zet een poort boven de 1024 open aan de server kant om data te versturen. Een firewall en NAT-module moeten dan zeker wel _in_ de pakketten kijken wat er gebeurt.

Je kunt op de pagina ook zien dat active ftp een probleem heeft bij NAT, poort 20 maakt immers vanaf de server verbinding naar de client. Draait daar NAT maar geen ftp_masquerade module dan zal de ftp niet kunnen slagen.

Waarschijnlijk geldt hetzelfde voor het gros van de instant messaging programma, die hebben ook allemaal problemen bij het versturen van bestanden als er in het pad tussen de twee hosts gebruik gemaakt wordt van NAT. Helaas zijn er vaak geen NAT-modules voor deze programma's te krijgen. Als ze er wel zijn kunnen ze meestal niet op alle platformen worden toegepast, denk maar eens aan je standaard ASDL router.

Ik ben zeker geen tegenstander van NAT en firewalls, maar hierin moet ik QuarkuS toch gelijk geven. NAT maakt meer kapot dan je is.

[ Voor 56% gewijzigd door FendtVario op 20-10-2004 20:55 . Reden: nieuwe alinea's ]

[Flying_Thunder]

blaataaps schreef op 20 oktober 2004 @ 16:03:
[...]
nee, dat wil het niet zeggen
[...]
Jouw definitie van ping lijkt wel juist, je definitie van icmp niet blijkbaar, er is veel meer icmp (zo'n 254 andere mogelijk) dan alleen ping (echo dus), wat type 8 is, zie
http://www.iana.org/assignments/icmp-parameters . Het lijkt me dat een parameter die icmp_echo_ignore heet, alle andere icmp-types ongemoeid laat.
Hier zit ook een veel voorkomend probleem, veel mensen weten dit niet, en draaien wel even een firewall inelkaar, ze hebben vaag spookverhalen gehoord dat "ping gevaarlijk is" (onzin), dat icmp ping is (ping is 1 van de 255 mogelijke types icmp) en dat je dus alle icmp maar moet droppen (wat dom is meestal, en helemaal als je niet weet waar je mee bezig bent).

I stand corrected, je hebt gelijk ja Ik had dit kunnen weten opzich, overigens weet ik natuurlijk wel dat icmp meer is dan ping, dat bedoelde ik met "je blokt wel iets meer dan" maar er stond natuurlijk icmp_echo en dat was alleen ping, dus je blokt idd alleen ping. Kom je op hetzelfde uit, om ping te blokken heb je dus geen firewall nodig

[Wilke]

QuarkuS schreef op 19 oktober 2004 @ 22:01:
Waar is dat [het blocken van bepaalde ICMP requests] goed voor dan? Het is zelfs hopeloos irritant dat er mensen zijn die ping blokkeren op hun machines. Weet je nooit of die machine nou down is of dat het alleen apache is die bokt.

Niet iedereen is end-user. Denk nooit te snel dat omdat jij het nut ergens niet van inziet, dit betekent dat er ook daadwerkelijk geen nut is.

Misschien wil je juist wel dat 'pingen' kan, maar sommige andere ICMP requests niet. Of andersom. Dat soort dingen kunnen afhankelijk van de toepassing verschillen. Een firewall is dan toch het meest makkelijke niveau om zoiets af te handelen.

QuarkuS schreef op 20 oktober 2004 @ 08:32:
Je kan wel een vuurmuur om je huis bouwen voor extra beveiliging, maar je kan ook gewoon de deur op slot doen.

Ja, en de meeste sloten zijn achterlijk makkelijk te kraken (zoek eens op 'lock picking'). Dus hebben sommige mensen als 'extra' beveiliging bv. zo'n kettinkje aan de deur, dievenklauwen, alarm op de ramen etc.
En dat is dan wat betreft *echte* sloten, laten we maar helemaal zwijgen over wat bij veel software het 'slot' moet voorstellen. Weten dat het zuigt (zoals jij zegt: weten wat je doet) is in veel gevallen lang niet genoeg, je zult er toch mee moeten werken ook al *weet* je dat iets niet goed [genoeg] beveiligd is. Een firewall is dan een manier om het risico in te perken. Dat het een risico niet tot 0 reduceert weet natuurlijk iedereen die niet helemaal zijn verstand is verloren.

En met zo'n vuurmuur kan niemand meer naar buiten kijken.

Nee, er kan niemand meer naar binnen kijken (ok, afhankelijk van hoe je dingen instelt, uiteraard).


By the way, ik vind de scheiding tussen /etc/hosts.allow/deny, TCP-wrappers e.d. aan de ene kant en een firewall aan de andere kant een beetje kunstmatig; beide zijn dingen die ergens tussen (of in?) OS en app zitten en er voor zorgen dat niet zomaar alles bij de applicatie aankomt.

[mOrPhie]

Ik denk dat er aan belangrijk ding voorbij wordt gegaan. De beheersbaarheid. Je kan wel mooi een hoop verschillende dingen op applicatie-niveau instellen om daarmee je beveiliging op orde te stellen, het punt is dat je op een gegeven moment daar het bos de bomen niet meer ziet. Met een firewall (of dit nu een netscreen, cisco of gewoon NetFilter/Iptables is) centraliseer je het beheer van je sloten op de deur. In plaats van steeds rond te moeten lopen heb je camera's opgehangen, dat idee. Daarmee zeg ik overigens niet dat je niet meer naar je applicaties moet kijken.

Bovendien vind ik het argument dat NAT z'n functie voorbij streeft puur hypthetisch. NAT kent vele goede implementaties en het feit dat Instant-Messaging-protocollen geen understeuning kennen is omdat deze protocollen vaak zijn gemaakt zonder besef van NAT en OSI. Ik ken zelf de ins en outs niet, maar ik weet wel dat MSN veel problemen met NAT gekent heeft, maar dat ik met Jabber nog nooit een gefaalde file-transfer heb gehad, zolang je je client maar juist insteld. Ofwel, het hangt af van de implementatie of NAT goed functioneert of niet.

[ Voor 4% gewijzigd door mOrPhie op 21-10-2004 01:59 ]

[QuarkuS]

mOrPhie schreef op 21 oktober 2004 @ 01:57:
Ik denk dat er aan belangrijk ding voorbij wordt gegaan. De beheersbaarheid. Je kan wel mooi een hoop verschillende dingen op applicatie-niveau instellen om daarmee je beveiliging op orde te stellen, het punt is dat je op een gegeven moment daar het bos de bomen niet meer ziet. Met een firewall (of dit nu een netscreen, cisco of gewoon NetFilter/Iptables is) centraliseer je het beheer van je sloten op de deur. In plaats van steeds rond te moeten lopen heb je camera's opgehangen, dat idee. Daarmee zeg ik overigens niet dat je niet meer naar je applicaties moet kijken.

OK, ik kijk door een lichtelijk roze bril mijn idealistische wereld in, en daar is het zo dat firewalls geen bestaansrecht hebben. Zet ik mijn bril af, dan blijkt een firewall een vrij effectief hulpmiddel om bepaalde dingen te bereiken.

Bovendien vind ik het argument dat NAT z'n functie voorbij streeft puur hypthetisch. NAT kent vele goede implementaties en het feit dat Instant-Messaging-protocollen geen understeuning kennen is omdat deze protocollen vaak zijn gemaakt zonder besef van NAT en OSI. Ik ken zelf de ins en outs niet, maar ik weet wel dat MSN veel problemen met NAT gekent heeft, maar dat ik met Jabber nog nooit een gefaalde file-transfer heb gehad, zolang je je client maar juist insteld. Ofwel, het hangt af van de implementatie of NAT goed functioneert of niet.

Het is volgens mij wel algemeen ingezien dat NAT obsolete is met de introductie van IPv6. Het adrestekort is opgelost met IPv6. Automatische subnet-hernummering kan eenvoudig met IPv6. NAT biedt absoluut geen beveiliging, Ergo: er zijn geen goede redenen meer om NAT te gebruiken.
Dan kan je wel zeggen dat applicatie-ontwikkelaars rekening moeten houden met NAT (zodat het de fout van de applicatie is als NAT het functioneren van die applicatie tegenhoudt), maar dat is precies de wereld op z'n kop. En dat probeer ik hier al de hele tijd te beargumenteren.

[Bor]

QuarkuS schreef op 21 oktober 2004 @ 10:41:
[...]


NAT biedt absoluut geen beveiliging, Ergo: er zijn geen goede redenen meer om NAT te gebruiken.

Hmm, NAT zonder statische NAT van buiten naar binnen en niemand kan meer een sessie opbouwen naar de "beschermde" hosts toe.

Overigens is het gebruiken van een 192.168.x.x of 10.x.x.x of 172.16-172.31 reeks niet alleen de uitputting van ip adressen hoor.

Precies. Firewalls zijn ondingen die niet op het Internet thuishoren. Er zijn situaties waarbij ze eventueel te rechtvaardigen zijn, maar die zijn zeer gelimiteerd (ingress/egress filtering bijv), en op servers doorgaans niet nodig.

Waar baseer je dat op? Het slaat de plank volledig mis imho. Als je een firewall hebt moet je alsnog de hosts en servers goed beschermen. Het is geen heilige graal (zo word het helaas wel vaak gezien). Het is wel een heel goed middel om de toegang gecentraliseerd te beheren en daarbij ook nog eens te "meten" wat er gebeurt.

Tot nu toe lees ik hier bijster weinig goede argumenten van ts.

[ Voor 48% gewijzigd door Bor op 21-10-2004 11:11 ]

[QuarkuS]

Bor_de_Wollef schreef op 21 oktober 2004 @ 11:05:

Hmm, NAT zonder statische NAT van buiten naar binnen en niemand kan meer een sessie opbouwen naar de "beschermde" hosts toe.

Overigens is het gebruiken van een 192.168.x.x of 10.x.x.x of 172.16-172.31 reeks niet alleen de uitputting van ip adressen hoor.

Watvoor andere redenen kan je dan noemen? Je gebruikt het omdat het IPsec breekt? Je gebruikt het omdat het allerlei applicatie protocollen breekt?
Lees ook bijvoorbeeld eens http://infosecuritymag.te...mns_standards_watch.shtml
Dus als jij van je provider een /64 prefix krijgt, dan ga je alsnog NAT toepassen omdat het voordelen biedt? Welke voordelen kan je hier dan noemen? Verras me.

Waar baseer je dat op? Het slaat de plank volledig mis imho. Als je een firewall hebt moet je alsnog de hosts en servers goed beschermen. Het is geen heilige graal (zo word het helaas wel vaak gezien). Het is wel een heel goed middel om de toegang gecentraliseerd te beheren en daarbij ook nog eens te "meten" wat er gebeurt.

Dat is toch min of meer wat ik ook zeg. Ik probeer juist te beargumenteren dat het geen heilige graal is, en dat het pragmatisch gezien wel werkt om dingen centraal te beheren.

Tot nu toe lees ik hier bijster weinig goede argumenten van ts.

Je hebt mijn end-to-end argument verhaal niet gelezen?

[Bor]

QuarkuS schreef op 21 oktober 2004 @ 11:36:
[...]

Watvoor andere redenen kan je dan noemen? Je gebruikt het omdat het IPsec breekt? Je gebruikt het omdat het allerlei applicatie protocollen breekt?
Lees ook bijvoorbeeld eens http://infosecuritymag.te...mns_standards_watch.shtml
Dus als jij van je provider een /64 prefix krijgt, dan ga je alsnog NAT toepassen omdat het voordelen biedt? Welke voordelen kan je hier dan noemen? Verras me.

Verras je? Omdat de prive ranges niet op internet gerouteerd worden bijvoorbeeld? Daarnaast heeft de geschiedenis wel uitgewezen dat het grootste deel van de mensen (en vaak bedrijven) niet in staat zijn hun systemen goed te beveiligen. Daarnaast is 1 aanval op het "netwerk" voldoende om iedereen onbereikbaar te maken in de end to end argument.

[ Voor 18% gewijzigd door Bor op 21-10-2004 12:05 ]

[CyBeR]

Bor_de_Wollef schreef op 21 oktober 2004 @ 11:51:
[...]


Verras je? Omdat de prive ranges niet op internet gerouteerd worden bijvoorbeeld? Daarnaast heeft de geschiedenis wel uitgewezen dat het grootste deel van de mensen (en vaak bedrijven) niet in staat zijn hun systemen goed te beveiligen. Daarnaast is 1 aanval op het "netwerk" voldoende om iedereen onbereikbaar te maken in de end to end argument.

Met NAT juist nog meer. Met een normaal netwerk routeert een router lekker pakketjes door, met NAT heeft 'ie extra tabellen nodig die vrij gemakkelijk vol te krijgen zijn. Boem. Geen verkeer meer mogelijk.

Simpel gezegd: NAT zuigt. Ingres firewalls heb ik geen groot probleem mee (egress echter is wel evil). Zeker in het geval van kwetsbare windows machines die je geen garantie geven veilig te zijn.

[Verwijderd]

Stacium schreef op 20 oktober 2004 @ 11:38:
[...]


oehh, zeg dat soort dingen nooit

code:

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

--snip--

Ok, dit is leuk maar hoe werkt het met 2 netwerk kaartjes? Kun je ook per netwerkkaart opgeven wat je wilt?

[Stacium]

Verwijderd schreef op 21 oktober 2004 @ 12:45:
[...]


Ok, dit is leuk maar hoe werkt het met 2 netwerk kaartjes? Kun je ook per netwerkkaart opgeven wat je wilt?

ja, tuurlijk het is niet echt een passende oplossing. Al kan je op je andere netwerkkaart ipv6 gaan draaien

ikzelf gebruik iptables om te filteren op echo requests (rate- en size-limits)

[QuarkuS]

CyBeR schreef op 21 oktober 2004 @ 12:29:
[...]

Met NAT juist nog meer. Met een normaal netwerk routeert een router lekker pakketjes door, met NAT heeft 'ie extra tabellen nodig die vrij gemakkelijk vol te krijgen zijn. Boem. Geen verkeer meer mogelijk.

Simpel gezegd: NAT zuigt. Ingres firewalls heb ik geen groot probleem mee (egress echter is wel evil). Zeker in het geval van kwetsbare windows machines die je geen garantie geven veilig te zijn.

Egress filtering die prefixes blokkeert die niet in het netwerk thuishoren zijn weer wel goed (source address spoofing preventie), hoewel dat dan weer problemen oplevert met Mobile IP.

[CyBeR]

QuarkuS schreef op 21 oktober 2004 @ 12:54:
[...]


Egress filtering die prefixes blokkeert die niet in het netwerk thuishoren zijn weer wel goed (source address spoofing preventie), hoewel dat dan weer problemen oplevert met Mobile IP.

Mja ok. Ik bedoelde filtering die bepaalde proto's wel doorlaat en andere niet. Wat jij zegt noem ik filtering, ik had 't over firewalling

[ Voor 9% gewijzigd door CyBeR op 21-10-2004 13:04 ]

[Bor]

CyBeR schreef op 21 oktober 2004 @ 12:29:
[...]


Met NAT juist nog meer. Met een normaal netwerk routeert een router lekker pakketjes door, met NAT heeft 'ie extra tabellen nodig die vrij gemakkelijk vol te krijgen zijn. Boem. Geen verkeer meer mogelijk.

Dat hang totaal af van de NAT mode die je gebruikt. NAT zal bv voor hide mode geen entries in de NAT tabel maken als je een connectie van buiten wilt opzetten naar binnen (de gehide adressen) als er geen statische NAT rules zijn. Bovendien heb je voor dit soort zaken Intrusion Prevention. Overigens kun je ook gewoon de verbinding dichtslibben e.a. dus echt een argument vind ik het niet.

Wat jij zegt noem ik filtering, ik had 't over firewalling

Wellicht is het handig als je daarvan de definitie eens geeft?

[ Voor 10% gewijzigd door Bor op 21-10-2004 16:23 ]

[CyBeR]

Bor_de_Wollef schreef op 21 oktober 2004 @ 16:22:
[...]


Wellicht is het handig als je daarvan de definitie eens geeft?

Ken je 't verschil tussen cisco's accesslists en extended accesslists? Zo ongeveer bedoel ik dat.

[TAMW]

Mooie defenitie zeg


ps:
Extended access lists werken op laag 3 en 4 van het OSI model
standaard access lists alleen op laag 3

[ Voor 8% gewijzigd door TAMW op 21-10-2004 17:27 ]