Vraag REJECT vs DROP bij gebruik van iptables


Is er een reden waarom ik zou willen hebben

iptables -A INPUT -j REJECT

in plaats van

iptables -A INPUT -j DROP

80
2017-07-04 09:49


oorsprong




antwoorden:


Over het algemeen gebruikt u REJECT als u wilt dat het andere einde weet dat de poort niet bereikbaar is. Gebruik DROP voor verbindingen met hosts waarvan u niet wilt dat mensen deze zien.

Gewoonlijk moeten alle regels voor verbindingen binnen uw LAN REJECT gebruiken. Voor internet, met uitzondering van ident op bepaalde servers, zijn verbindingen van internet meestal VERVALLEN.

Het gebruik van DROP zorgt ervoor dat de verbinding lijkt te zijn naar een onbezet IP-adres. Scanners kunnen ervoor kiezen om niet door te gaan met het scannen van adressen die onbezet lijken. Aangezien NAT kan worden gebruikt om een ​​verbinding op de firewall om te leiden, hoeft het bestaan ​​van een bekende service niet noodzakelijkerwijs te wijzen op het bestaan ​​van een server op een adres.

Identiteit moet worden doorgegeven of afgewezen op elk adres dat SMTP-service biedt. Het gebruik van Ident look-ups door SMTP-services is echter niet meer in gebruik. Er zijn chatprotocollen die ook op een werkende ident-service vertrouwen.

EDIT: bij gebruik van DROP-regels:  - UDP-pakketten worden verwijderd en het gedrag is hetzelfde als verbinding maken met een poort zonder poort zonder service.  - TCP-pakketten retourneren een ACK / RST die hetzelfde antwoord biedt als een open poort zonder service erop. Sommige routers reageren met en ACK / RST namens servers die niet beschikbaar zijn.

Bij het gebruik van REJECT-regels wordt een ICMP-pakket verzonden dat aangeeft dat de poort niet beschikbaar is.


72
2017-07-04 16:40



Dit is niet waar. Zelfs wanneer de regel "DROP" zegt, zal het systeem nog steeds antwoorden op het binnenkomende pakket met een TCP SYN / ACK alsof het open was. Om echt een pakket te laten vallen, moet het systeem antwoorden met een TCP RST / ACK - waarvoor geen firewallregel bestaat. Als zodanig is de beste instelling voor firewalling een instelling waarbij alleen geselecteerde poorten worden doorgestuurd. Uw DROP-regel maakt reclame voor uw firewall en poortscanners weten dat u iets firewallt en blijven hameren in de hoop dat uw firewall wordt onderschept. - Dagelf
@Dagelf Zie mijn bewerking. De RST / ACK geeft niet aan scanners aan dat u iets firewallt. Hoewel sommige hackers na dit antwoord nog steeds kunnen peilen, moet dat gebaseerd zijn op het kennen van uw services en niet op de reactie van de firewall. Het heeft absoluut het aantal en de lengte van scans die ik ervaar laten vallen. - BillThor
Mijn punt is, het is detecteerbaar van buitenaf of je firewall bent of niet, alleen al vanwege het feit dat je TCP-stack zich anders gedraagt ​​wanneer je DROP dan wanneer je geen service hebt die in de eerste plaats draait! - Dagelf
Dit neemt niet weg dat er botnets zijn die gebruikmaken van het verschil en uw poorten bewaken als gevolg. - Dagelf
@Delfelf, waar krijgt u de informatie dat DROP een reactie verzendt? Dat is groot nieuws en druist in tegen alles wat ik heb waargenomen en verteld. Heeft u een link naar de documentatie die dit gedrag beschrijft? - Score_Under


Het verschil is dat het REJECT-doel een weigeringsantwoord naar de bron verzendt, terwijl het doel DROP niets verzendt.

Dit kan bijvoorbeeld nuttig zijn. voor de ident-service. Als u REJECT gebruikt, hoeven de clients niet te wachten op een time-out.

Meer hierover: http://www.linuxtopia.org/Linux_Firewall_iptables/x4550.html


25
2017-07-04 09:59



Het DROP-doel zendt niets. Controleer mijn commentaar op het geaccepteerde antwoord en ga zelf op onderzoek uit als je geïnteresseerd bent in de details! - Dagelf


Meestal wil je dat negeren sondeert van aanvallers naar bepaalde poorten, waarmee ik bedoel dat je niet de 'geweigerde verbinding' wilt terugsturen. 'Verbinding geweigerd' betekent: 'hier is een server' en geeft mogelijk meer informatie weg, terwijl het weglaten van een pakket geen aanwijzingen geeft over softwareversies, mogelijke kwetsbaarheden of zelfs het feit dat een server naar je luistert bij IP.

Het bovenstaande is een van de belangrijkste redenen om DROP te gebruiken in plaats van REJECT.


8
2017-07-04 13:09



Zonder iptables regels, standaard een gesloten poort om te VERWERPEN. Als je elke poort DROP is het een goed alternatief (je host verschijnt), maar als je alleen specifieke poorten laat dALEN, geef je ze eigenlijk meer informatie dan REJECT. Als iemand een algemene probe als nmap gebruikt, zullen specifieke poorten die pakketten laten vallen als 'gefilterd' worden weergegeven, wat betekent dat ze weten dat je een service hebt die je verbergt. - Raptor007


Ik zie hier veel tegenstrijdige antwoorden en gezien dit is het eerste artikel in Google met de juiste zoekwoorden; hier is de juiste uitleg.
Het is makkelijk:

DROP doet helemaal niets met het pakket. Het wordt niet doorgestuurd naar een host, het wordt niet beantwoord. De manpage van IPtables zegt dat het het pakket op de grond laat vallen, d.w.z. het doet niets met het pakket.

REJECT verschilt naar DROP dat het een pakket terugstuurt, maar het antwoord is alsof een server zich in het IP bevindt, maar de poort niet in een luisterpositie heeft. IPtables stuurt een RST / ACK in het geval van TCP of met UDP een ICMP-bestemmingspoort onbereikbaar.


6
2018-01-11 12:29



+1 van mij, maar de antwoorden zijn niet echt oneens. Ze zijn het er allemaal mee eens, voor zover ik kan zien, behalve Dagelf - die ongelijk heeft. - MadHatter
Oké, hier is een kleine truc voor jou: doe een "nmap localhost". Kies nu elke poort die niet "open" is ... en voeg een regel toe die "niets doet", bijv .: "iptables -I INPUT -p tcp --dport 888 -j DROP". Nu "nmap localhost" opnieuw. Wat zie je? ... - Dagelf


Als je het bestaan ​​van je machine volledig wilt verbergen, -j DROPis gepast. U kunt dit bijvoorbeeld gebruiken om een ​​zwarte lijst te implementeren.

Als u probeert te verbergen dat een poort open is, moet u het gedrag nabootsen dat zou optreden als de poort niet open was:

  • TCP: -p tcp -j REJECT --reject-with tcp-reset
  • UDP: -p udp -j REJECT --reject-with icmp-port-unreachable

Als een poortscanner ziet dat een paar poorten pakketten laten vallen, terwijl de meeste deze weigeren, kan het ervan uitgaan dat de gevallen pakketten op open maar verborgen poorten staan.


3
2017-08-13 01:29



Wat als je een paar poorten opent (bijvoorbeeld 22, 25, 53, 80, 443) en dan al het andere DROP? Of ik nu MySQL, PostgreSQL, SQLite of Cassandra heb ... de scanner kan het niet zeggen, toch? - Alexis Wilke
@ AlexisWilke In dat geval is de enige aanvullende informatie die u aan de poortscanner geeft, dat u een firewall op zijn plaats hebt met een standaard DROP-beleid. - Raptor007


Ondanks veel goede antwoorden, alleen mijn twee cent:

Hier is een korte PoC FW.IDS-DROP-vs-REJECT van mij aan het onderwerp met betrekking tot de regels voor ban-systeem (firewall, IDS, enz.).

kort:

  • DROP kan worden gebruikt voor recidive indringers, als alle poorten worden verbannen (dus het lijkt erop dat de server zich aan de indringerzijde bevindt)
  • REJECT --reject-with tcp-reset is de beste keuze voor verbieden met meerdere poorten, omdat het zich lijkt te gedragen als een echte gesloten poort
  • als sommige poorten antwoorden (indringer weet dat de host in leven is), DROP en REJECT (zonder tcp-reset) geeft de indringer een "signaal" dat er iets blokkeert (dus dat zou hem kunnen stimuleren om de "aanval" voort te zetten in de hoop op enig moment de vereiste gegevens te verstrekken)

0
2017-09-20 16:49





Ja, het gebruik van DROP is zinloos. Gebruik REJECT.

Zelfs wanneer de regel 'DROP' zegt, reageert het systeem nog steeds op een binnenkomende SYN met een TCP RST / ACK - het standaardgedrag voor poorten zonder draaiende services. (tcpdump et al registreert dit niet.)

Als een service wordt uitgevoerd, wordt de SYN ontvangen met TCP SYN / ACK.

Omdat de DROP niet normaal reageert met een TCP SYN / ACK, maar met een RST / ACK in plaats daarvan, adverteert uw DROP-regel voor uw firewall en poortscanners zullen weten dat u iets firewallt en kunnen blijven hameren in de hoop van het vangen van je firewall.

Dit is nu nmap kan "gefilterd" rapporteren in plaats van "gesloten", bijvoorbeeld:

$ nmap localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-14 00:21 SAST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000060s latency).
Not shown: 986 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http

Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds

$ iptables -I INPUT -p tcp --dport 1111 -j DROP
$ nmap localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-14 00:21 SAST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000060s latency).
Not shown: 986 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http
1111/tcp filtered lmsocialserver

Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds

$ iptables -D INPUT 1

Als zodanig is de enige "onzichtbare" firewalling-instelling er een waarbij een speciaal apparaat tussen uw apparaten zit en alleen selectief poorten doorstuurt.

Als u echt wilt knoeien met de basisscanners, kunt u TARPIT tcp-verbindingen gebruiken, waardoor het TCP-venster op 0 wordt ingesteld, zodat geen gegevens kunnen worden overgedragen nadat de verbinding is geopend, waarbij verzoeken om de verbinding te sluiten worden genegeerd, wat betekent dat de scanner moet wachten om de time-out voor de verbinding te laten optreden, als het zeker wil zijn. Maar het is triviaal voor een aanvaller om dit te detecteren en zijn time-out erg kort te maken.

Alles bij elkaar genomen, kunt u waarschijnlijk het beste alleen REJECT gebruiken - of een speciaal port-forwarding-apparaat plaatsen tussen uw server en internet.

Of gewoon services uitvoeren op uw internet-gerichte machines die geen firewall vereisen.

Over het algemeen is REJECT het beste voor webservers, omdat elke dienst die het probeert te benaderen (waarschijnlijk vaker wel dan niet, u) snel antwoord krijgt en gebruikers of andere services niet wachten om zich af te vragen of er een netwerkstoring is.


-3



Dit antwoord is onjuist. Het kan eenvoudig worden getoond met tcpdump dat de DROP-regel ertoe zal leiden dat het systeem ELK antwoord niet verzendt - zoals men zou verwachten. En je verklaring "Om echt een pakket te laten vallen, moet het systeem antwoorden met een TCP RST / ACK" heeft geen zin, omdat het beantwoorden van iets natuurlijk niet "echt een pakket laten vallen" is. Als je een pakket echt "laat vallen", antwoord je gewoon niet en dit is aantoonbaar het effect van de DROP-regel. - Juliane Holzt
Kunt u een bron voor die bewering opgeven? DROP zal een uitgeven SYN/ACK? Ik heb dit nooit op mijn machines gezien. - motobói
@Dagelf Uw artikel zegt wel "DROP (aka DENY, BLACKHOLE) Verbied een pakket door te geven. Stuur geen reactie." - JeanT
Het verzendt niet de normale reactie, maar stuurt er één zoals uitgelegd, ongeacht. - Dagelf
Het document waarnaar je linkt, zegt "DROP ... Stuur geen antwoord", en ondersteunt, voor zover ik kan zien, uw claim niet DROP geeft a terug SYN/ACK. Ik heb dit gedrag nog nooit onder welke versie dan ook gezien iptables. Als u een bron heeft die uw claim ondersteunt, zou het het meest nuttig zijn om het te zien; zeker, de pakketstortingen die ik zojuist heb gedaan, ondersteunen uw claim niet. - MadHatter