tabelle iptables – fissaggio di un errore di scrittura nella gestione

Ho trascorso un po 'di tempo oggi a controllare il mio script iptables. Sono un ingegnere software, non un guru Ops, ma ho cercato di raccogliere le basi di iptables. Ho notato qualcosa che deve essere stato rotto per lungo tempo:

# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0 -A INPUT -i lo -j ACCEPT -A INPUT -i lo -d 127.0.0.0/8 -j REJECT 

Ok, quindi, che sembra che dovrebbe essere:

 -A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT 

Destra?

Il problema è che il server esegue il traffico in diretta. Mentre questo sembra un cambiamento innocuo, tratto iptables con una giusta quantità di rispetto. Inoltre, significa che ho accettato il traffico da / 8 che viene da altre interfacce. Cosa significa in termini reali? Come potrebbe la macchina ricevere richieste da 127/8 su un'altra interface?

  • Ubuntu: Come aggiungere una regola iptables che UFW non può creare
  • Sendmail non funziona con iptables, anche se smtp e dns sono consentiti
  • Come annullare iptables-save?
  • Configurare DD-WRT per più IP esterni?
  • Centos iptables apre il port 53
  • iptables - Cancellare tutte le regole PREROUTING con un indirizzo di destinazione specifico
  • Devo utilizzare Firewalld o Iptables per Fail2ban in Centos 7?
  • le regole di fallimento non entrano in vigore
  • One Solution collect form web for “tabelle iptables – fissaggio di un errore di scrittura nella gestione”

    sembra che dovrebbe essere:

    -A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT

    Destra?

    Probabilmente sì. Lo spirito di questa regola sembra bloccare qualsiasi cosa la cui destinazione IP sia 127.0.0.0/8 che non arriva sull'interface lo (loopback).

    Vedi questa domanda sul corretto posizionamento del ! carattere: posizione di batteria di Iptables .

    Ho accettato il traffico da / 8 che viene da altre interfacce. Cosa significa in termini reali?

    Se qualcuno fabbrica un pacchetto falso, destinato alla tua macchina su una delle sue interfacce pubbliche, potrebbe essere stato risposto e in alcuni casi degenerati potrebbe avere consentito l'accesso a demoni locali e servizi solo ascoltati su un'interface di loopback. Sarò sorpreso se tale comportmento sia effettivamente verificato , e qualsiasi eventuale superficie di attacco è abbastanza remota.

    In realtà, le possibilità di sfruttare questo mi sembrano, alless per me, essere remoti. L'attaccante dovrebbe essere sullo stesso segmento di networking, come per falsificare un'intestazione IP mantenendo in tatto l'intestazione Ethernet (in particolare l'indirizzo MAC di destinazione). Gli host remoti non sarebbero in grado di sfruttare un'intestazione IP falsa, perché il pacchetto sarebbe stato eliminato senza essere inviato mentre attraversava i router nella networking. Tutti i servizi sulla macchina esplicitamente associati all'indirizzo IP dell'interface di loopback dovrebbero rispondere solo al traffico così ricevuto e non a pacchetti di spoofing che arrivano su altre interfacce, quindi io (personalmente) non lo vedo come un problema importnte per te.

    Il problema è che il server esegue il traffico in diretta. Mentre questo sembra un cambiamento innocuo, tratto iptables con una giusta quantità di rispetto.

    Proprio con una certa modifica della configuration che rischia di trasformare una macchina che sta triggersmente spostando i pacchetti in una macchina che nega triggersmente il traffico di networking, dovrebbe essere trattata con caucanvas, soprattutto se i tempi di inattività avranno implicazioni finanziarie. Dovresti anche pesare le conseguenze di qualsiasi cambiamento – le probabilità di questo errore che portno ad un exploit che port la macchina verso il basso sono sottili , ma manipolando la configuration di iptables su una macchina funzionante hanno maggiori rischi di causare tempi di inattività. Questo compromesso dovrebbe essere considerato con attenzione.

    Un cambiamento di questo tipo dovrebbe essere innocuo , ma ci sono ancora modi di errore relativamente numerosi: la fatturazione di una transazione di tastiera, fraintendendo l'interazione tra questo aspetto della configuration di iptables e alcune altre voci nel firewall, ecc.

    Per tutti i cambiamenti dei firewall non routine, in particolare quelli che trattano le regole REJECT , dovresti pianificare i tempi di inattività. Se stai eseguendo una modifica su una macchina da una postazione remota, assicurati di avere altri modi di accedere alla macchina in caso di perdita di accesso, preferibilmente, questo dovrebbe essere disponibile nella window di manutenzione in modo da evitare di violare eventuali SLA. Una connessione OOB tramite un controller IPMI a bordo o una console seriale o, in alternativa, la possibilità di accedere fisicamente alla macchina nel data center durante il periodo at risk , sarebbe qui adatta.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.