iptables, politica predefinita vs regole

C'è qualche differenza nel trascinare i pacchetti non corrispondenti con la politica predefinita rispetto -j DROPalla fine?

Piace:

iptables -P INPUT DROP
iptables -A INPUT --dport 80 -j ACCEPT

vs

iptables -A INPUT --dport 80 -j ACCEPT
iptables -A INPUT -j DROP

Il motivo per cui mi interessa è perché non riesco a creare una catena con log e assimilarlo come criterio predefinito, quindi dovrei usare il secondo esempio.

Da un punto di vista tecnico, No. Il pacchetto viene eliminato in entrambi i modi.

Ma Sirex è abbastanza corretto in quanto può essere un po 'doloroso se si dimentica qualcosa di importante quando si cambiano le regole predefinite della tabella.

Dopo aver trascorso un po 'di tempo con IPTables, probabilmente troverai una preferenza e costruirai i tuoi sistemi nel tuo ambiente.

Sì. Se si utilizza una politica di DROP, quindi ci si connette tramite SSH e si svuota la tabella ( iptables -F), ci si blocca poiché la politica di default non viene scaricata.

L'ho fatto su un sistema remoto. Mi ha fatto male.

(Altre lezioni apprese, se vuoi liberarti del firewall per un po ', usa service iptables stop, non iptables-F + service iptables reload)

Una politica di default è probabilmente più sicura dall'essere più facile da gestire. Non puoi dimenticare di aggiungerlo alla fine.

Forse un'altra cosa su questo argomento per coloro che hanno bisogno di questo po 'di informazioni proprio come me poche ore fa.

L'ultimo modo:

iptables -A INPUT --dport 80 -j ACCEPT
iptables -A INPUT -j DROP

non ti consente di aggiungere una regola in un secondo momento (poiché la regola aggiunta verrà visualizzata dopo la regola di rilascio universale e pertanto non avrà alcun effetto), dovrai inserire la regola con un'istruzione esplicita della posizione desiderata:

iptables -I INPUT 1 --dport 8080 -j ACCEPT

invece di

iptables -A INPUT --dport 80 -j ACCEPT

A seconda delle tue esigenze, la sicurezza potrebbe essere di qualche aiuto, richiedendo te o qualsiasi altra cosa che in seguito aggiunge la regola per passare davvero attraverso le regole esistenti e non semplicemente aggiungerla come al solito.

Questa conoscenza l'ho guadagnata ieri controllando per venti minuti perché il mio servizio appena installato non risponderà anche se tutto è attivo e funzionante.

I criteri predefiniti sono piuttosto limitati, ma costituiscono un buon backstop per garantire che i pacchetti non gestiti vengano gestiti nel modo corretto.

Se hai bisogno (vuoi) di registrare quei pacchetti hai bisogno di una regola finale. Questa può essere una catena che registra e applica la politica. È inoltre possibile accedere e lasciare che il criterio lo gestisca.

Considera questi approcci alla politica e la regola politica finale.

• utilizzare e accettare la politica e sovrascrivere con la politica desiderata come regola finale. Questo può proteggerti quando gestisci un host in una posizione remota. Se elimini le regole, rimani solo con la tua linea di difesa secondaria come hosts.allow. Se elimini la tua regola finale finirai in una configurazione per lo più aperta o completamente aperta.
• impostare la politica desiderata e ripristinarla con una regola politica finale. Questo può essere più sicuro quando si dispone dell'accesso fisico o della console a un host. Se elimini le tue regole, perdi l'accesso a tutti i servizi a meno che la politica non sia ACCETTA. Se lasci cadere la tua regola finale, sei ancora protetto.