[iptables] drop of reject

[FendtVario]

Zoals de titel al zegt twijfel ik bij het gebruik van iptables tussen drop en reject, ik heb de volgende redenatie voor gebruik van danwel drop of reject:

drop: gooi het pakketje meteen weg, weinig/tot geen processor tijd en geen pakketje terug (wat bij veel aanvragen natuurlijk bandbreedte scheelt). Laat de andere kant maar wachten, totdat deze een time-out heeft, echter, deze zal blijven proberen om te connecten.

reject: stuur een icmp-prohibited terug, de client weet meteen dat ie geen toegang heeft en zal hopelijk z'n poging staken. Wel verkeer terug wat misschien niet handig is.


Wat is jullie mening over het gebruik van deze twee opties? De meeste firewalls gebruiken DROP als standaard regel. Ik hou deze voorlopig ook als standaard, maar zou wel eens willen weten waarom

[Verwijderd]

Hoeveel verkeer denk jij te verwerken?

Denk maar niet dat je zoveel verkeer te verwerken krijgt, dat je een dergelijke keuze ook daadwerkelijk in je traffic-stats duidelijk terug zult gaan zien. Wat die processor-tijd valt het ook allemaal reuze mee hoor.

[mpol]

Nou ja, je kunt natuurlijk geddost worden door iemand. Als je dan 400 Kbytes aan data te verwerken krijgt, waarbij die data complete bagger is...
Wat volgens mij een goed alternatief is, is om met match en limit te gaan werken. Op de eerste 10 nieuwe connecties een reject geven. Alles wat meer is dan dat gewoon droppen.
Op zich kost dat ook processortijd. Wat wel scheelt is dat je upload het niet zo zwaar krijgt. In 400 Kbytes passen veel pakketjes. Als je daar allemaal een reject op wilt gaan doen, terwijl je upload maar 16 Kbytes is dan wordt hety wel erg benauwd.
Maar ja, mocht het zover komen dat je zwaar geddost wordt dan is dit ook maar een druppel op een gloeiende plaat...

[Verwijderd]

Ik stel alles wat ik _niet_ door mijn firewall laat gaan standaard op DROP. Dit doe ik omdat iedereen die ik niet doorlaat op mijn firewall uberhaupt daar niks van wil laten weten. Voor "hun" kom je dan over als een soort zwart gat in plaats van dat je netjes een reply terug stuurd (en daarmee de zekerheid heeft dat er _iets_ op dat ip luisterd). Aan de andere kant ontkom je hier ook weer niet helemaal aan (port-unreachable voor m'n ident poort)

[ Voor 11% gewijzigd door Verwijderd op 27-01-2003 18:08 ]

[Verwijderd]

Volgens mij is het beste om je vuurmuur zo te configureren dat het lijkt alsof je geen vuurmuur draait. Dus als je geen services draait, zou ik alles op DROP zetten. Dan lijkt het zelfs alsof je computer uit staat. Aan de andere kant, als je bijvoorbeeld een webserver draait, zou ik poort 80 openzetten en de rest van de poorten een nette reject laten versturen. Als je alles behalve poort 80 zou droppen, dan weet een eventuele aanvaller dat je een firewall draait. Overigens zou ik de boel dan wel loggen. Volgens mij staat hier ook informatie over ergens op netfilter.org.

[morphje]

Ook wel een leuke toevoeging is dat je bijvoorbeeld op pakketten kan selecteren en daar verschillende regels op toe kan laten
iptables heeft namelijk patch-o-matic en daar kan je een hoop leuke patches op los laten

bijvoorbeeld limit van hoeveelheid pakketten binnen een tijdseenheid, dus laat 2 icmp requests per seconden door, laat de rest rejecten met een tcp-reset
Ook bijvoorbeeld limit op grote van bijvoorbeeld icmp packets (welke je voor bovenstaande regel zet uiteraard ) dat packets groter als x kilobytes gedropped worden.
30% random drops van icmp requests zijn ook leuk

Op deze manier (en vele andere manieren uiteraard) kan je een hele leuke firewall opzetten, leuk om mee te spelen en best handig om toch een goede net-tizen te spelen zonder dat je te veel toelaat

dat laatste is misschien ook nog wel iets waarvan ik van mening van ben dat je dat moet zijn. Je moet eigenlijk bepaalde soorten packets doorlaten. (de rest uiteraard droppen)

leuke volgorde dus
icmp groter als x kilobytes droppen
30% random reject met tcp-reset van icmp
limit 2/sec reject met tcp-reset van icmp

[FendtVario]

Ik heb een simpele adsl lijn (comfort van planet , nooit meer doen, misschien moeten we maar eens een poll maken met de gemiddelde uptime van een adsl verbinding). Heel veel verkeer gaat er niet overheen, en ik heb ook nog niet gemerkt dat iemand zit te dos-sen. Al heb ik wel het idee dat het instellen van een goede firewall wel steeds belangrijker wordt.

Ik ga denk even kijken naar die patch-o-matic en het limit verhaal. Heb er al eens iets over gelezen maar zie het nu ter nog niet helemaal van. Ik dacht limit te gaan gebruiken om bandbreedte af te dwingen (aan bijvoorbeeld kazaa, niet meer dan 10kb/s), maar dit gaat tegenwoordig over poort 80 dus dat werkt niet meer.

Dat 30% random rejecten zie ik nog niet zo zitten, lijkt me niet echt wat je wilt. Dat zou beteken dan ook connecties naar de pc die 'veilig'/'goed' zijn worden afgewezen, ssh draait hier bijvoorbeeld ook, maar daar wil ik geen restricties aan opleggen omdat ik overal vandaan er toegang wil hebben.

[Verwijderd]

icmp != ssh etc

Als er hierboven gesproken wordt over icmp dan kan je daarvoor in de plaats icmp echo_request en echo_reply (ofwel ping/pong) lezen.

[FendtVario]

Ja, moet toch eens beter opletten op school als het over netwerken gaat Icmp = Internet Control Message Protocol. Zo ver ben ik ook, en je gebruikt het voor o.a. router en netwerk informatieberichten, detectie voor netwerk vertraging, time stamps (ping), aanbieden van router info (icmp-redirect).

Moet er eens rustig voor gaan zitten. Ik bedenk nu om voor alle poorten die ik niet gebruik (of waarvan niet bekend hoeft te zijn dat er iets achter zit) ik DROP gebruik, en voor een paar andere een tcp-reset of icmp-prohibited ga sturen.

Iemand nog een tip voor die logs van iptables? Mijn logs komen direct op m'n prompt, in de iptables FAQ staat dat dit komt omdat mijn syslog.conf verkeerd is, maar heb ff zitten proberen en het wil nog niet lukken. Ik moet geloof ik deze regel veranderen:
*.emerg *

Heb in man syslog gekeken, maar het wou nog niet zo lukken.

[miniBSD]

FendtVario: voor iptables moet het 'kern.warn' zijn en poort 113 (ident) kun je het beste met een tcp-reject beantwoorden.

[FendtVario]

miniBSD schreef op 27 January 2003 @ 19:35:
FendtVario: voor iptables moet het 'kern.warn' zijn en poort 113 (ident) kun je het beste met een tcp-reject beantwoorden.

Werkt niet hoor. Ik heb nu in m'n syslog.conf staan
kern.warn *

en de iptables log zijn loglevel 4. Moet ik nog niets veranderen?

edit: krijg 'm nu zelfs door m'n ssh shell heen, dat was eerst nog niet

[ Voor 12% gewijzigd door FendtVario op 27-01-2003 20:28 ]

[miniBSD]

'--log-level warn' is opgenomen bij het LOG statement dat je gebruikt ?

Schiet me te binnen: je klogd level moet ook 4 zijn.

[ Voor 34% gewijzigd door miniBSD op 27-01-2003 20:36 ]

[mpol]

kern.warn *
Dit betekent dat hij kernel warnings naar alle log ontvangers stuurt, dus ook je tty devices.
Waarschijnlijk wil je hem laten loggen naar een bestand:
kern.warn /var/log/kern.log

[FendtVario]

Mijn syslog.conf:

kern.* -/var/log/kern.log
kern.warn *


Een iptable regel:
iptables -j LOG --log-prefix="test log "

Dit resulteert in loglevel warn, als ik dan --log-level 5 mee geef veranderd het in notice, maar ik zie ze nog steeds op m'n prompt (en nog steeds ook in de ssh-sessies). Als ik --log-level 3 meegeeft veranderd het in error.

[FendtVario]

mpol schreef op 27 January 2003 @ 20:40:
kern.warn *
Dit betekent dat hij kernel warnings naar alle log ontvangers stuurt, dus ook je tty devices.
Waarschijnlijk wil je hem laten loggen naar een bestand:
kern.warn /var/log/kern.log

niet in alle gevallen, soms wil je juist wel dat een log message naar je toe gestuurd wordt over de console (bijvoorbeeld als je schijf journal op hol slaat), maar niet naar ssh-sessies en ftp.

[miniBSD]

Dit moet zijn:

kern.warn -/var/log/kern.log

Anders zie je niet direct wat er gelogd wordt. Wat betreft de meldingen op het schermen, je moet de kernel logger ('klogd' daemon) met de optie '-c 4' opstarten. Kijk even in sysinit of dit ook gebeurd.

[ Voor 6% gewijzigd door miniBSD op 27-01-2003 20:57 . Reden: type vaudt ]

[morphje]

FendtVario schreef op 27 januari 2003 @ 18:44:
Dat 30% random rejecten zie ik nog niet zo zitten, lijkt me niet echt wat je wilt. Dat zou beteken dan ook connecties naar de pc die 'veilig'/'goed' zijn worden afgewezen, ssh draait hier bijvoorbeeld ook, maar daar wil ik geen restricties aan opleggen omdat ik overal vandaan er toegang wil hebben.

Heb ik nog een leuke voor je
tcp verbindingen hebben zoiets als controle op packets. Komen ze dus niet aan worden ze vanzelf weer opnieuw opgevraagt cq verstuurt. Best leuk om te zien om dat te doen met random www packets bijvoorbeeld, je pagina komt nog steeds naar boven op een goede manier

geweldig he dat tcp

[FendtVario]

miniBSD schreef op 27 januari 2003 @ 20:56:
Dit moet zijn:

kern.warn -/var/log/kern.log

Anders zie je niet direct wat er gelogd wordt. Wat betreft de meldingen op het schermen, je moet de kernel logger ('klogd' daemon) met de optie '-c 4' opstarten. Kijk even in sysinit of dit ook gebeurd.

Het lijkt nu te werken, de optie -c 4 werkte, de syslog.conf staat weer in oude staat hersteld. Ik krijg de iptables berichten iig niet meer op m'n prompt (ook niet meer op het loginscherm van de pc zelf!!) Thanx.

Nu moet ik er nog ff een leuk verhaaltje van maken hoe dit op te lossen en dan kan alles in m'n knowlegde base.

[FendtVario]

morphje schreef op 27 January 2003 @ 21:10:
[...]


Heb ik nog een leuke voor je
tcp verbindingen hebben zoiets als controle op packets. Komen ze dus niet aan worden ze vanzelf weer opnieuw opgevraagt cq verstuurt. Best leuk om te zien om dat te doen met random www packets bijvoorbeeld, je pagina komt nog steeds naar boven op een goede manier

geweldig he dat tcp

Heb wel eens een vriend zitten zieken met een redirect, had alle aanvragen van zijn ipadres naar mijn http-port geredirect naar linux.com

[morphje]

FendtVario schreef op 27 January 2003 @ 21:19:
Heb wel eens een vriend zitten zieken met een redirect, had alle aanvragen van zijn ipadres naar mijn http-port geredirect naar linux.com

man, ik ga naar jouw website blijk je linux.com te hosten. COOL MAN!!!!
smerig truukje hoor

[FendtVario]

heb nog een site gevonden die hetzelfde probleem behandeld:
http://logi.cc/linux/reject_or_deny.php3