Bestimmten Router blockieren



  • Die meisten DHCP Clients schicken ein DHCP Request als Broadcast. Wer zuerst antwortet hat gewonnen. Man kann aber meines wissens dem dhcpcd sagen das er einen spezifischen DHCP Server nutzen soll. Das müsste dann in der dhcpcd.conf passieren.
    Denke ich. Nun kenne ich mich mit openSuSE nicht aus. Musst also nochmal schauen wie die das machen.



  • Müsste sich mit iptables blocken lassen.
    Wie genau müsste ich mir auch erst ergoogeln.



  • Keine Ahnung, was der Standard-DHCP-Client unter OpenSuSE ist, aber der ISC-dhclient hat für die Angabe des Servers die Option "-s".

    Mit iptables könntest du einfach sämtlichen eingehenden Traffic vom DHCP-Server blocken:

    iptables -A INPUT -m mac --mac-source ${BOESE_MAC_ADRESSE} -j DROP
    

    edit: Geht natürlich auch gezielter, aber du brauchst von dem Router ja wohl ohnehin nichts annehmen.



  • So langsam bin ich mit meinem Latain am Ende...

    sudo dhclient -d enp0s25 -s 8.20.0.10
    root's password:
    Internet Systems Consortium DHCP Client 4.2.6
    Copyright 2004-2014 Internet Systems Consortium.
    All rights reserved.
    For info, please visit https://www.isc.org/software/dhcp/
    
    Listening on LPF/enp0s25/00:21:cc:4a:3a:10
    Sending on   LPF/enp0s25/00:21:cc:4a:3a:10
    Sending on   Socket/fallback
    DHCPDISCOVER on enp0s25 to 8.20.0.10 port 67 interval 4 (xid=0x641798c4)
    DHCPDISCOVER on enp0s25 to 8.20.0.10 port 67 interval 5 (xid=0x641798c4)
    DHCPDISCOVER on enp0s25 to 8.20.0.10 port 67 interval 8 (xid=0x641798c4)
    DHCPDISCOVER on enp0s25 to 8.20.0.10 port 67 interval 8 (xid=0x641798c4)
    DHCPDISCOVER on enp0s25 to 8.20.0.10 port 67 interval 14 (xid=0x641798c4)
    DHCPDISCOVER on enp0s25 to 8.20.0.10 port 67 interval 20 (xid=0x641798c4)                                                                                                          
    DHCPDISCOVER on enp0s25 to 8.20.0.10 port 67 interval 2 (xid=0x641798c4)                                                                                                           
    No DHCPOFFERS received.                                                                                                                                                            
    No working leases in persistent database - sleeping.                                                                                                                               
    ls: cannot access /var/run/netconfig//enp0s25/: No such file or directory                                                                                                          
    DHCPDISCOVER on enp0s25 to 8.20.0.10 port 67 interval 2 (xid=0x435bd8bc)                                                                                                           
    DHCPDISCOVER on enp0s25 to 8.20.0.10 port 67 interval 4 (xid=0x435bd8bc)                                                                                                           
    DHCPDISCOVER on enp0s25 to 8.20.0.10 port 67 interval 8 (xid=0x435bd8bc)                                                                                                           
    DHCPDISCOVER on enp0s25 to 8.20.0.10 port 67 interval 20 (xid=0x435bd8bc)                                                                                                          
    DHCPDISCOVER on enp0s25 to 8.20.0.10 port 67 interval 18 (xid=0x435bd8bc)                                                                                                          
    DHCPDISCOVER on enp0s25 to 8.20.0.10 port 67 interval 9 (xid=0x435bd8bc)                                                                                                           
    No DHCPOFFERS received.
    

    Wahrscheinlich findet er den guten Router nicht, weil ich schon mit dem falschen Netz verbunden bin.

    Chain INPUT (policy DROP 0 packets, 0 bytes)
    pkts bytes target prot opt in out source destination 
    208 17512 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 
    33618 34M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate ESTABLISHED
    8 832 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED
    268 56741 input_ext all -- * * 0.0.0.0/0 0.0.0.0/0 
    0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix "SFW2-IN-ILL-TARGET "
    0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 
    0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 MAC E8:94:F6:3E:96:B1
    0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 MAC E8:94:F6:3E:96:B1
    

    E8:94:F6:3E:96:B1 wurde zwar in die Regel mit aufgenommen, aber nie geblockt! Evtl. muss die Regel weiter oben stehen, damit sie greift, aber wie kann ich die nach oben verschieben? Ich finde irgendwie die Config-Datei in OpenSuse nicht...

    L. G.,
    IBV

    PS: Thethering rettet mich gerade. 😛



  • iptables -I (statt -A) fügt die Regel oben statt unten ein.



  • Beim Filter steht ganz oben POLICY DROP

    Das bedeutet das alles geblockt wird und dann die Regeln die Ausnahmen definieren. Die Regeln danach erlauben dann wieder alles.
    Diese Regeln müsste man ändern.

    Ich bin hier nur gerade am Tablett da tippt sich das blöd. Falls nicht ein anderer die Änderungen parat hst geb ich nachher noch bescheid



  • Chain INPUT (policy DROP 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination         
       10  1114 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            MAC E8:94:F6:3E:96:B1
    

    Ok, jetzt steht die Regel oben und anscheinend wurden auch 10 Pakete (pkts?) geblockt, aber:

    sudo arp
    Address                  HWtype  HWaddress           Flags Mask            Iface
    192.168.1.1              ether   e8:94:f6:3e:96:b1   C                     enp0s25
    

    🙄



  • Ich glaube nicht, das die Info aus dem ARP irgendeine vernünftige Aussage macht.
    Denn der Eintrag sagt dir nur das dein Computer weiß wie IP und MAC zusammenpassen und auf welchem Interface er erwarten würde den Teilnehmer zu finden.
    So ein ARP packet kann schon eingeflogen sein bevor die IP tables initialisiert waren. Im syslog steht meiner Meinung nach von wo die DHCP requests beantwortet werden. Wenn nicht mal in messages schauen oder den DHCP client anweisen ein wenig gesprächiger zu sein.

    Dann kann es natürlich noch sein, aber so blöd können selbst die bei SuSE nicht sein, das sie die Firewall erst einrichten nachdem der dhcp request rausgegangen ist und beantwortet wurde

    Und dann kann es natürlich sein, das der Kernel mit network autoconfiguration konfiguriert wurde und auf der Kernel-Kommandline ein ip=dhcp steht.

    Also noch gibt es da vieles was nicht stimmen kann.

    Da fällt mir noch forwarding ein. Da kann es dann passieren, das die Pakete von eth0 auf lo geleitet werden. Dann kriegst du die DHCP Pakete vom loopback device.

    Forwarding wird in einer anderen Chain definiert.



  • simbad schrieb:

    Ich glaube nicht, das die Info aus dem ARP irgendeine vernünftige Aussage macht.

    Genau. Was passiert denn, wenn du jetzt noch einen frischen DHCP-Request rausjagst?

    Ich würde mal die iptables-Regeln abspeichern und auf gut Glück neustarten, dann siehst du ja, ob das auch über Reboots hinweg klappt oder nicht.



  • Kann auch sein dass es mit iptables aus irgend einem Grund nicht geht.
    Dann könnte man es noch mit ebtables probieren...



  • nman schrieb:

    simbad schrieb:

    Ich glaube nicht, das die Info aus dem ARP irgendeine vernünftige Aussage macht.

    Genau. Was passiert denn, wenn du jetzt noch einen frischen DHCP-Request rausjagst?

    Ich würde mal die iptables-Regeln abspeichern und auf gut Glück neustarten, dann siehst du ja, ob das auch über Reboots hinweg klappt oder nicht.

    Das Dumme ist, dass ich keine Ahnung habe, wie man das bei OpenSUSE abspeichert. Wenn ich danach google, stößt man auf die OpenSUSE-Firewall... Meine nächste Distri wird Fedora oder so sein...
    Aber: Ich kann mir arp -d ${IP-Adresse} den ARP-Eintrag löschen. Allerdings mit demselben Ergebnis, dass ich denselben bösen Router zugewiesen bekomme.

    L. G.,
    IBV


Anmelden zum Antworten