Perché non posso usare la politica REJECT sulla mia catena OUTPUT iptables?

11

Al momento ho la mia catena OUTPUT impostata su DROP. Vorrei cambiarlo in REJECT, in modo da avere la minima idea che è il mio firewall a impedirmi di arrivare da qualche parte piuttosto che un problema con qualunque servizio sto tentando di accedere (rifiuto immediato invece di timeout). Tuttavia, iptables non sembra curarsene. Se modifico manualmente il file delle regole salvato e provo a ripristinarlo, ottengo iptables-restore v1.4.15: Can't set policy 'REJECT' on 'OUTPUT' line 22: Bad policy namee si rifiuta di caricare le regole. Se provo a impostarlo manualmente ( iptables -P OUTPUT REJECT), ottengo iptables: Bad policy name. Run 'dmesg' for more information.ma non c'è output in dmesg.

Ho confermato che la regola appropriata è stata compilata nel kernel e ho riavviato per assicurarmi che sia caricato:

# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_FILTER=y
***
CONFIG_IP_NF_TARGET_REJECT=y
***
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y

(Asterischi aggiunti per evidenziare la regola applicabile)

Tutto ciò che posso trovare afferma che REJECT è una politica / destinazione valida (in generale), ma non riesco a trovare nulla che dica che non è valido per le catene INPUT, FORWARD o OUTPUT. Il mio Google-fu non sta aiutando. Sono su Gentoo, se questo fa la differenza. Qualcuno qui ha qualche intuizione?

networking iptables gentoo

— ND Geek
fonte

Puoi mostrare le iptablesregole in questione?

— bahamat,

15

REJECTè un'estensione di destinazione , mentre una politica a catena deve essere un obiettivo . La pagina di manuale dice che (anche se non è molto chiaro), ma alcune di quelle che dice sono completamente sbagliate.

La politica può essere solo ACCEPTo DROPsu catene integrate. Se vuoi l'effetto di rifiutare tutti i pacchetti che non corrispondono alle regole precedenti, assicurati solo che l'ultima regola corrisponda a tutto e aggiunga una regola con REJECTun'estensione di destinazione. In altre parole, dopo aver aggiunto tutte le regole pertinenti, fallo iptables -t filter -A OUTPUT -j REJECT.

Vedi il thread "quali sono le possibili politiche a catena" nell'elenco netfilter per maggiori dettagli.

— Shawn J. Goff
fonte

Questo ha senso, e un REJECT generico alla fine dovrebbe funzionare. Per curiosità, la definizione dell'estensione target da qualche parte è abbastanza ovvia e me la sono persa o è uno dei bit scarsamente documentati?

— ND Geek,

1

Leggendo l'intera pagina man, è chiaro che REJECT è un'estensione di destinazione, ma la pagina man è molto lunga, quindi "TL; DR" tende ad applicarsi. Implica anche che DROP, ACCEPT e QUEUE siano obiettivi politici validi; dal codice corrente, QUEUE non lo è!

— StarNamer,

4

Non sono riuscito a trovarlo documentato, ma un riferimento qui indica che le uniche politiche consentite sono ACCETTA DROP. Ciò è confermato osservando l' origine di libiptc(che è responsabile della manipolazione delle regole) intorno alla riga 2429, dove ha il codice

2429         if (strcmp(policy, LABEL_ACCEPT) == 0)
2430                 c->verdict = -NF_ACCEPT - 1;
2431         else if (strcmp(policy, LABEL_DROP) == 0)
2432                 c->verdict = -NF_DROP - 1;
2433         else {
2434                 errno = EINVAL;
2435                 return 0;
2436         }

Il thread originale suggerisce che la cosa migliore da fare è aggiungere REJECT alla fine della catena che dovrebbe essere iptables -A OUTPUT -j REJECT.

Si noti che il codice appena prima è:

2423         if (!iptcc_is_builtin(c)) {
2424                 DEBUGP("cannot set policy of userdefinedchain `%s'\n", chain);
2425                 errno = ENOENT;
2426                 return 0;
2427         }
2428

Quindi non è possibile impostare il criterio su una catena definita dall'utente.

— StarNamer
fonte

Quel comando nel thread non è corretto; -pè per la corrispondenza su un protocollo; intendeva -Acome dice la mia risposta.

— Shawn J. Goff,

È piuttosto interessante. La curiosità in me si chiede se c'è una ragione dietro di essa, o se è così che è, forse per ragioni di semplicità (un codice più semplice significa meno punti possibili per le vulnerabilità dopo tutto). Se fossi anche uno sviluppatore moderato, potrei essere tentato di hackerarlo localmente, ma dato che non lo sono, e dato che è un pezzo di sicurezza, non lo toccherò.

— ND Geek,

2

REJECTsu OUTPUTnon ha senso; a REJECTrestituirà un pacchetto ICMP che dovrebbe attraversare una rete.

Aggiungi un nuovo -j LOGcome ultima regola (quindi prima della DROPpolitica) per vedere cosa arriva così lontano nella OUTPUTcatena.

— Aaron D. Marasco
fonte

1

Il REJECTpacchetto ICMP non può tornare sull'interfaccia lo? Sono d'accordo che a LOGsia utile per la risoluzione dei problemi, ma quello che speravo davvero è un modo per ricordarmi che "Oh, sì ... probabilmente è bloccato dal mio DROPvalore predefinito di iptables" invece di risolvere i problemi per 5 minuti chiede al collega di l'accesso al server XYZ si rende conto che è probabilmente locale , che è il mio approccio più comune, dal momento che la mia tipica giornata lavorativa colpisce raramente cose per cui non ho già aperto un buco. Certo, forse devo tenerlo a mente, ma un appartamento REJECTè più ovvio.

— ND Geek,

Non penso che vorresti che l' ethXinterfaccia generasse traffico losull'interfaccia per molte ragioni. Sono molto indipendenti; puoi facilmente far applicare le catene all'una e non all'altra.

— Aaron D. Marasco il