Domande IPTables e DHCP?

Sul mio altro thread stavo parlando di alcune cose interessanti sulla politica iptables e afferma , ora vorrei capire meglio su come funziona il DHCP e come l'iptables lo capisce.

ETH0 è collegato al mio interruttore principale che riceve l'ip dinamico dal mio router per get non solo l'accesso a Internet, ma anche l'accesso alla mia networking esterna.

  • Spazio di file system disponibile utilizzando SNMP
  • Possibilità di connessione alla console di box Linux senza networking
  • come sintonizzare il client NFS su MacOS per get Linux come performance?
  • Il modo più semplice per submit file di posta elettronica tramite la row di command in * nix?
  • Tuning NFS per latenza minima
  • alternativa non cpu-intensiva al lsof?
  • ETH1 è la scheda interna collegata ad un interruttore interno where i client X ricevono il loro IPS da questo server

    La networking ETH1 è 192.168.1.0/255.255.255.0 where il server ip è 192.168.1.254.

    Da quello che ho capito, dhcp è un protocollo bootp, quindi anche se hai le tue policy firewall a DROP tutto, la tua networking avrebbe ancora ricevuto il DHCP, che nei test che ho fatto sembrava essere vero.

    Da tcpdump:

    root@test:~# tcpdump -i eth1 port 67 or 68 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 11:34:03.943928 IP 192.168.1.2.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:29:29:52:8b (oui Unknown), length 303 11:34:03.957647 IP 192.168.1.254.bootps > 192.168.1.2.bootpc: BOOTP/DHCP, Reply, length 300 11:34:06.492153 IP 192.168.1.2.bootpc > 192.168.1.254.bootps: BOOTP/DHCP, Request from 00:0c:29:29:52:8b (oui Unknown), length 303 11:34:06.506593 IP 192.168.1.254.bootps > 192.168.1.2.bootpc: BOOTP/DHCP, Reply, length 300 

    Ho fatto una regola di log semplice per vedere cosa fa iptables:

     root@test:~# tail -f /var/log/syslog Oct 15 11:30:58 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9527 PROTO=UDP SPT=68 DPT=67 LEN=311 Oct 15 11:31:43 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9529 PROTO=UDP SPT=68 DPT=67 LEN=311 Oct 15 11:33:32 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9531 PROTO=UDP SPT=68 DPT=67 LEN=311 Oct 15 11:34:03 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9533 PROTO=UDP SPT=68 DPT=67 LEN=311 

    Ecco le mie iptables le regole al momento:

     # deny all traffic $IPT -P INPUT DROP $IPT -P FORWARD DROP $IPT -P OUTPUT DROP # Use stateful inspection feature to only allow incoming connections # related to connections I have already established myself $IPT -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT $IPT -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # allow all traffic on lo interface $IPT -A INPUT -i lo -j ACCEPT $IPT -A OUTPUT -o lo -j ACCEPT 

    Quindi, anche con la PRINCIPALE POLICY per far cadere tutto ciò che ho ancora il DHCP sulla mia networking, mentre ci vuole molto più tempo per rinnovare un IP e simili.

    Se aggiungo la regola di seguito al mio firewall:

     $IPT -I OUTPUT -o $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT 

    Ci vorrà un po 'di tempo per aggiornare qualsiasi dhcp client.

    Considerando quanto sopra:

    1. perché richiede più tempo per aggiornarlo anche se non è bloccato?
    2. è ansible DROP il server dhcp a tutti senza spegnerlo?
    3. è ansible accedere al server dhcp all'interno di iptables con il BOOTP? come è fatto?

    Se conosci dei buoni collegamenti non mi dispiacerebbe prendermi molto 🙂

  • 'Rallentare' un server DHCP allo scopo
  • 3 Solutions collect form web for “Domande IPTables e DHCP?”

    Risponderò # 2: No.

    Quando si ottiene un indirizzo IP, il daemon dhcp crea un socket crudo all'interface di networking e gestisce il protocollo UDP stesso. Quindi i pacchetti UDP non passano mai attraverso iptables.

    Il motivo per cui il daemon dhcp deve implementare UDP è che il kernel può gestire solo UDP (in realtà tutta la suite TCP / IP) quando l'interface dispone di un indirizzo IP. In precedenza, i daemon dhcp fornirono innanzitutto un'interface all'indirizzo IP di 0.0.0.0 ma che non funziona più.

    Aggiunta

     $IPT -I INPUT -i $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT 

    farà l'aggiornamento DHCPD più veloce 🙂 Funzionerà entrambi i lati INPUT e OUTPUT. È ansible DROP dhcpd con ebtables, non con iptables. DHCPD ascolto a 0.0.0.0, non all'interno di IP

    La mia recente osservazione, su OpenWRT Kamikaze 7.09 = 2.4.34 e udhcpc da busybox 1.4.2:

    Ho una politica "ACCEPT" nella catena OUTPUT, e nella direzione INPUT, in origine ho fatto affidamento su questa classica regola catch-all:

     iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 

    per consentire le risposte DHCP in (al mio udhcpc) ​​nell'interface WAN. Ovvero, questo è il punto in cui il server DHCP a monte del mio ISP assegna un indirizzo IP a me.

    Tenere presente la differenza tra uno scambio DHCP iniziale (scoprire, offrire, richiedere, ack) e un rinnovo del leasing DHCP (richiesta, ack).

    Dopo l'avvio, udhcpc inizia dall'integer scambio iniziale. Quel scambio avrebbe successo. E un altro rinnovo o due avrebbe successo, solo una richiesta e un riconoscimento. Il server DHCP del mio ISP richiede tipicamente un tempo di rinnovo di circa un'ora a 1,5 ore, quindi il mio cliente DHCP chiede un rinnovo each 30-45 minuti (questo comportmento è basato sul RFC).

    Ma, circa il terzo o il quarto rinnovo, avrebbe cominciato a diventare interessante. TCPdump mostrerebbe circa tre tentativi di rinnovo, seguiti da uno scambio iniziale completo – in un tempo di pochi minuti o addirittura di secondi. Come se il viaggiatore non amasse ciò che è tornato 🙁 e finalmente si accontenterà del pieno scambio. Dopo di che, un altro rinnovo in mezz'ora avrebbe successo … e la storia ripeterà di nuovo.

    Ho capito che è forse il collegamento tra il kernel che ha qualcosa di sbagliato. Come se la voce conntrack sia scaduta dopo due ore o less, e i rinnovi DHCP successivi falliscono perché l'ACK dal server non lo fa in modo da guidare l'ascolto sul socket. Si noti che tcpdump (libpcap) ascolta l'interface raw e può vedere tutti i pacchetti in arrivo, prima che siano soggetti a iptables. Una volta che il guidatore rinuncia a rinnovamenti e, in disperazione, cerca di ricominciare da zero utilizzando uno scambio completo (a partire da DISCOVER), il kernel stabilisce una nuova voce conntrack e può capire i pacchetti correlati per un po 'di tempo …

    Abbastanza, una volta aggiunto qualcosa di simile:

     iptables -A INPUT -i $OUT_IF -p udp --sport 67 --dport 68 -j ACCEPT 

    i rinnovi sembrano funzionare per sempre.

    È ansible trovare i seguenti argomenti cmdline tcpdump utili:

     tcpdump -vv -s 1500 -i eth0.1 port 67 or port 68 

    Nota: il -vv chiede l'output del dissector verboso. eth0.1 è la mia port WAN (anche un'interface "esterna NAT").

    Un attributo interessante nei pacchetti ACK è LT: field = suggerito / massimo tempo di locazione concesso in secondi. Le richieste DHCP vengono inviate dalla port 68 alla port 67. Le risposte provengono dalla port 67 alla port 68.

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