Discussione:
in iptables è meglio DROP o REJECT
(troppo vecchio per rispondere)
Luca
2004-05-18 06:53:16 UTC
Permalink
se devo rifutare rifiutare dei pacchetti è meglio usare DROP o REJECT?

che differenza c'è tra i 2?

grazie
markus
2004-05-18 07:12:52 UTC
Permalink
Post by Luca
se devo rifutare rifiutare dei pacchetti è meglio usare DROP o REJECT?
che differenza c'è tra i 2?
drop=un pacchetto lanciato verso una o più porte di un host viene rifiutato
ma senza emettere nessuna risposta, ergo il mittente non saprà mai che fine
ha fatto il pacchetto; reject=respinge il pacchetto al mittente che cmq
saprà che l'host verso cui il pacchetto era destinato esiste ed è
funzionante anche se 'al momento' rifiuta i pacchetti... più o meno...

markus
Dario Basile
2004-05-18 12:19:49 UTC
Permalink
Post by Luca
se devo rifutare rifiutare dei pacchetti è meglio usare DROP o REJECT?
che differenza c'è tra i 2?
La differenza ti e' stata spiegata benissimo da Markus, io
aggiungo che (almeno fino a poco tempo fa) c'era una discreta
polemica su quale fosse meglio tra i due: REJECT segue gli RFC,
DROP ha il vantaggio di permettere all'host di sfuggire agli
scan di massa, rendendo meno probabile il DoS non mirato. C'e'
da dire pero' che subire un DoS non mirato e' gia' abbastanza
improbabile di per se'.

Se io conosco l'IP dell'host che voglio attaccare DROP e REJECT
si equivalgono, quindi l'invisibilita' fornita da DROP e' solo
fittizia. Va bene per un sistema casalingo, a IP dinamico per
intenderci, per un server i due sono perfettamente alternativi
e probabilmente e' meglio usare REJECT.

- --
Dario Basile
- ----------------------------------------------------------------
Scopa me, scopabo te.
ouz
2004-05-18 13:09:26 UTC
Permalink
Il Tue, 18 May 2004 08:53:16 +0200, nel NG it.comp.os.linux.iniziare,
Post by Luca
se devo rifutare rifiutare dei pacchetti è meglio usare DROP o REJECT?
Se hai un'indirizzo dinamico in genere e` meglio droppare, spesso
risparmi banda.

In alcuni casi e` meglio pero` fare REJECT, visto che droppando
dovresti attendere un timeout.

Esempio: ti connetti in IRC e il server, prima di connetterti lancia
una richiesta al tuo demone identd. Se hai un firewall che droppa, il
server deve aspettare il timeout della connessione, se invece al
server arriva un reject (ICMP port unreachable) la connessione parte
subito.
--
Vuoi fare colpo su di lei con me?
Fai colpo su di lei con me! Fai colpo su di lei con me!
[Dr. Gonzo : Paura e delirio a Las Vegas]
Renaissance
2004-05-18 14:04:39 UTC
Permalink
Post by Luca
se devo rifutare rifiutare dei pacchetti è meglio usare DROP o REJECT?
che differenza c'è tra i 2?
Aggiungo:

DROP semplicemente scarta il pacchetto, che finisce nel
"dimenticatoio". L'host che ha inviato la richiesta non
sapra' mai con sicurezza se essa e' stata effettivamente
rifiutata. Inzomma, "cade nel vuoto".
Rallenta di molto i port scanning, perche' il programma
che effettua il port scanning deve decidere in base ad un
suo... personale timeout se la porta e' chiusa o filtrata.
Se l'obbiettivo e' un firewall, ci si avvantaggia anche del
fatto che, se tutte le porte sono filtrate, difficilmente
chi fa lo scanning potra' conoscere informazioni come
sistema operativo e versione, che possono essere utili ai
fini della ricerca di un eventuale exploit.
REJECT invece esplicita il fatto che la connessione e' stata
rifiutata rimandando indiestro al mittente un pacchetto icmp
"icmp-port-unreachable", il quale appunto sapra' che la
porta non risulta disponibile. Questo e' il comportamento
normale di un qualunque stack tcp/ip. Lo svantaggio e' che, come
detto prima, puo' palesare con piu' o meno precisione il sistema
che c'e' dietro, attraverso l'analisi dell'header del pacchetto,
anche se non e' detto che ci si riesca sempre...
Come gia' detto, REJECT puo' invece tornare utile con certi
servizi tipo "auth" o "ident", per evitare fastidiose attese
del timeout in un servizio che "rimbalza" una richiesta ident.

bye G.L.
--
« E' assolutamente evidente che l'arte del cinema
si ispira alla vita, mentre la vita si ispira alla TV »
(Woody Allen)
Loading...