Bogon-Filterung auf Edge-Routern

[BenutzerGa4gooPh]

Ein freundliches Hallo an alle Leser!

Früher hat man am WAN-Inteface inbound von Edge-Routern (Firmen) und Firewalls private, reservierte und nicht vergebene IPv4-Netzwerke gedropt:
http://www.team-cymru.org/bogon-dotted-decimal.html
https://wiki.mikrotik.com/wiki/BOGON_Address_List
https://de.m.wikipedia.org/wiki/IP-Adresse (Abschnitt Besondere IP-Adressen)
https://ipinfo.io/bogon

Dies diente u. a. zur Vermeidung von IP-Adress-Spoofing:
https://de.m.wikipedia.org/wiki/IP-Spoofing
ISP zumindest droppen heute noch. Normalerweise werden Bogon IPs nicht im Internet geroutet!

Einige (auf Dörfern) nutzen jedoch kleine WLAN-ISPs, die kein PPPoE sondern nur DNS-Server in einem Access-WLAN (ein IP-Subnetz für mehrere Teilnehmer) einsetzen. Das Szenario entspricht damit einem Hotspot im Internetcafe oder WLAN auf dem Campingplatz. Womit IP-Spoofing anderer Teilnehmer eventuell möglich sein könnte?!

Allerdings verwenden Firmen und wir privat auf Edge-Routern und Firewalls meist eine Stateful Inspection Firewall und NAT, womit prinzipiell erst mal nur von innen initiierte Verbindungen möglich sind.

Demzufolge Fragen zum Traffic WAN/Internet -> WAN-Interface (inbound/ingress):
Ist ein IP-Spoofing trotz Stateful-Inspection-Firewall und NAT/PAT möglich?
Ist trotz Stateful-Inspection-Firewall und NAT/PAT ein Blocken/Drop aller oben verlinkten Quelladressen (Bogon Networks) sinnvoll?
Genügt ein Blocken/Drop nur der Quelladressen, die im eigenen LAN verwendet werden?
Sind Null-Routen (Routen auf Null-Interface für Bogon-Netzwerke) performanter als ACLs? Damit wären Verbindungen in allen Richtungen (Bogon-Ziel-Netzwerke) elegant einschränkbar. Direct Connected Netzwerke kann man wohl sogar einfach in Summenrouten auf Null-Interfaces belassen, weil spezifischer als Null-Routen?

Mögliche Methoden:
iptables oder ACLs auf WAN-Interface incoming oder Routen zu Null-Interface oder Unicast Reverse Path Forwarding im Strict Mode.
https://www.digitaltut.com/unicast-reve ... forwarding
(Können Firewalls anderer Hersteller übrigens auch.)

Berücksichtigung DHCP-Client (Ausnahme nach uRPF-Check) mit uRPF Strict und (gelernter) Default-Route:

Code: Alles auswählen

interface <WAN-IF>
 ip address dhcp
 ip verify unicast source reachable-via rx allow-default 101
exit
access-list 101 permit udp any eq bootps any eq bootpc

Schönes Wochenende allen Lesern und Antwortern!
(Die Links habe ich für interessierte Leser angefügt.)

Edit: uRPF-Beispiel

[mludwig]

Als ISP: private IPs von extern werden gedroppt. Dazu werden auch private IPs nach extern entweder gedroppt oder per NAT umgesetzt. Kleine WLAN-ISPs können das vermutlich nicht so einfach, wenn sie weder intern noch extern öffentliche IPs zur Verfügung haben.

Die Variante mit Null-Route halte ich für zumindest bei privaten IPs für fragwürdig, da diese ja intern verwendet werden können. Das hängt wohl von der internen Netzstruktur ab, ob das Edge-Gerät die Routen für die internen Netze kennen muss oder nicht.

Zum Thema Spoofing: eine Absende-IP zu fälschen ist ja noch recht einfach, aber zur Kommunikation muss ja auch die Antwort wieder ankommen, was für TCP-Verbindungen Voraussetzung ist. Häufigstes Problem mit gespooften IPs habe ich daher eigentlich nur bei Protokollen wie DNS, da hier mit UDP gearbeitet wird und die Antworten bewusst auf die gefälschte Abesender-IP gelenkt werden, als DOS-Attacke mit Amplification.

Wenn die Kunden-Provider dafür sorgen würden, dass aus ihren (Kunden-)Netzen nur Pakete mit den eigenen IPs als Source kämen, wäre hier schon viel gewonnen. Aber es gibt scheinbar immer noch genügend schwarze Schafe. Transit-Provider haben dann schon kaum eine Handhabe mehr, die Echtheit der Source-IPs zu bewerten.

[BenutzerGa4gooPh]

Die Variante mit Null-Route halte ich für zumindest bei privaten IPs für fragwürdig, da diese ja intern verwendet werden können. Das hängt wohl von der internen Netzstruktur ab, ob das Edge-Gerät die Routen für die internen Netze kennen muss oder nicht.

Ja, da muss man gut aufpassen. Ich habe es leicht mit 1 Router und demzufolge alles Direct Connected. Mit den Null-Routen in Kombination mit uRPF kann ich Quell- und Zielnetzwerke droppen, also zumindest für mich nicht so großer Aufwand und wohl performanter als ACLs.

Aber gut, dass ich nun weiss, das es sinnvoll ist. Weiß nur nicht, wie sinnvoll die Unterdrückung mehrerer Bogon-Netzwerke und nicht nur der eigenen, privaten Netze als Quell- und Zieadressen von und nach aussen bei Stateful Packet Inspection und NAT. Aber wenigstens Letzteres werde ich tun. Können ja auch mal Fehler/Leaks bei NAT oder VPN-Verbindungen auftreten.

Häufigstes Problem mit gespooften IPs habe ich daher eigentlich nur bei Protokollen wie DNS, da hier mit UDP gearbeitet wird und die Antworten bewusst auf die gefälschte Abesender-IP gelenkt werden, als DOS-Attacke mit Amplification.

Aufgrund deines Hinweises werde ich mich um die Absicherung von DNS noch kümmern. NTP ist wohl ein analoges Thema. Port 123 UDP.

[dufty2]

Nur damit ich's richtig verstanden habe
Mit "WLAN-ISP" meinst Du WISP resp. WIAP [1], richtig?

Das Dorf ist per (Richt-)Funk am ("eigentlichen") ISP angeschlossen und im Dorf selbst stehen ein oder mehrere AccessPoints rum.
Du hast die 192.168.0.10/24 (welche auf Deinem Router auf dessen WAN-Interface aufliegt) und Dein Nachbar die 192.168.0.11/24 und Du willst verhindern
A) dass Dein Nachbar sich die 192.168.0.10 "schnappt" (und somit Deinen Internettraffic abhört/verfälscht) und/oder
B) dass Dein Nachbar sich die 10.0.0.1/24 "schnappt", die Du selbst in Deinem Haus-internen (W)LAN verwendest (und somit Deinen Haus-internen Traffic eindringt.)
Richtig?

Das ist aber ein (W)LAN-Problem und kein Internet-Problem (dass der "eingentliche" ISP nicht mit 10er oder 192er umgehen könnte, glaube ich mal im Jahr 2017 nicht

Im LAN-Bereich nimmt man für Authentifizierung das 802.1x Protokoll (z. B. mit Radius),
sowas gibt es auch im WLAN ("WPA2-Enterprise").
Letzendlich willst Du ein "private VLAN" (die 192.168.0.10 kann nur mit dem Default-GW 192.168.0.1 kommunizieren aber nicht mit der 192.168.0.11), also wieder eine Art "PPP".
Wie weit sich das im WLAN realisieren lässt, weiß ich leider nicht

[1] https://de.wikipedia.org/wiki/Wireless_ ... e_Provider

[BenutzerGa4gooPh]

Hi dufty2!

Mit "WLAN-ISP" meinst Du WISP resp. WIAP [1], richtig?

Yepp.

Das Dorf ist per (Richt-)Funk am ("eigentlichen") ISP angeschlossen und im Dorf selbst stehen ein oder mehrere AccessPoints rum.
Du hast die 192.168.0.10/24 (welche auf Deinem Router auf dessen WAN-Interface aufliegt) und Dein Nachbar die 192.168.0.11/24 und Du willst verhindern
A) dass Dein Nachbar sich die 192.168.0.10 "schnappt" (und somit Deinen Internettraffic abhört/verfälscht) und/oder
B) dass Dein Nachbar sich die 10.0.0.1/24 "schnappt", die Du selbst in Deinem Haus-internen (W)LAN verwendest (und somit Deinen Haus-internen Traffic eindringt.)
Richtig?

Fast richtig. Ganz richtig ist wohl so: http://www.was-ist-malware.de/allgemein/ip-spoofing/ Müsste B) entsprechen. Ein mit Spoofing verdeckter DOS-Angriff auf den Router selbst wäre so wohl auch möglich.

Allerdings gibt der WISP eigene CPE (nicht managebar vom Kunden) aus. Ich habe also einen DHCP-Ethernet-Anschluss. Die CPE sind neuerdings Router. Es existieren jedoch im WLAN-Access-Netz des WISP auch CPE, die reine Ethernet-WLAN-Bridges sind. Hatte ich bis kürzlich auch. DHCP-Server ran, Internet-Zugang zur Verfügung stellen und ich hätte hübsch sniffen können.

An drahtloser Sicherheit (WPA2-Enterprise) kann ich nichts verändern, das WLAN-Access-Netz einschließlich Netzabschlussgeraete (CPE) liegt in der "Managementhoheit" des WISP. PVLANs oder ein VPN-Tunnel pro Kunde wären schon die richtige Technologie - aber das kann ich nicht beeinflussen. Ein VPN zu einem gemieteten vServer oder einem VPN-Anbieter wäre möglich - aber zu "aluhuetig". So versuche ich, meinen drahtgegundenen Router weitgehend zu sichern. Spaß macht es mir auch.

[bluestar]

Hi Jana,
du solltest mal deinen WISP auf die Thematik Routerfreiheit ansprechen, ergo müsste er dir die Zugangsdaten zu seinem Netz geben und dir erlauben ein kompatibeles CPE nach deinen Wünschen einzusetzen.

[BenutzerGa4gooPh]

Hi bluestar!

... du solltest mal deinen WISP auf die Thematik Routerfreiheit ansprechen, ergo müsste er dir die Zugangsdaten zu seinem Netz geben und dir erlauben ein kompatibeles CPE nach deinen Wünschen einzusetzen.

Wenn ich mich in die Lage des WISPs versetze, müsste ich dann wegen Authentifizierung/Autorisierung/Zugangsgebühren WPA2-Enterprise (RADIUS) einsetzen/vorschreiben. Damit nur Profi-CPEs einsetzbar. Nix mit Fritzbox"verkehrt rum" (WLAN = WAN). Und Hotline für die Laien mit Profi-CPEs möchte ich nicht machen. Der WISP will keinen öffentlichen Hotspot mit Quersubventionierung (Einkaufszentrum, Campingplatz) betreiben, dessen WLAN-Accessnetz auf vielen Dächern/Dachböden in mehreren Dörfern war/ist teuer. Friendly Customers befreit von Zugangsgebühren wegen Stromkosten auf ihre Rechnung. Dafür auch keine USV. Wir haben dann Romantik, Kerzen und Kartenspiele.

[BenutzerGa4gooPh]

So, ich habe mal noch etwas "geforscht" und bin auf einige leicht verständliche Websites gestoßen:
http://www.was-ist-malware.de/allgemein/ip-spoofing/
http://de.ccm.net/contents/742-vortaeus ... g-spoofing
https://www.elektronik-kompendium.de/si ... 412101.htm
Best Practices sind darin auch beschrieben - und wurden nachfolgend verwendet.

Dann habe ich konfiguriert:
(Teilkonfiguration bezüglich Thema des Thread ohne Firewall. Routen mit Masken 240.0.0.0 lassen sich leider nicht konfigurieren. Dafür ACLs.)

Code: Alles auswählen

interface Null0
 no ip unreachables
exit

ip route 0.0.0.0 255.0.0.0 Null0
ip route 10.0.0.0 255.0.0.0 Null0
ip route 100.64.0.0 255.192.0.0 Null0
ip route 127.0.0.0 255.0.0.0 Null0
ip route 169.254.0.0 255.255.0.0 Null0
ip route 172.16.0.0 255.240.0.0 Null0
ip route 192.0.0.0 255.255.255.0 Null0
ip route 192.0.2.0 255.255.255.0 Null0
ip route 192.168.0.0 255.255.0.0 Null0
ip route 198.18.0.0 255.254.0.0 Null0
ip route 198.51.100.0 255.255.255.0 Null0
ip route 203.0.113.0 255.255.255.0 Null0

ip access-list extended WAN-inbound
 remark Bogon Networks mit Maske < 255.0.0.0: Null-Routen nicht konfigurierbar.
 10 permit udp any eq bootps any eq bootpc
 20 deny   ip 224.0.0.0 15.255.255.255 any log
 30 deny   ip 240.0.0.0 15.255.255.255 any log
 40 permit ip any any
exit

ip access-list extended WAN-outbound
 remark Bogon Networks, Maske < 255.0.0.0: Null-Routen nicht konfigurierbar.
 remark Nur valide Quelladressen nach NAT: WAN-Subnet vom WISP per DHCP 
 10 permit udp any eq bootpc any eq bootps
 20 deny   ip any 224.0.0.0 15.255.255.255 log
 30 deny   ip any 240.0.0.0 15.255.255.255 log
 40 permit ip 192.168.xxx.xx 0.0.0.31 any
 50 deny ip any any log
exit

interface GigabitEthernet8
 description "Internet"
 no ip dhcp client request domain-name
 no ip dhcp client request dns-nameserver
 ip dhcp client hostname none
 ip dhcp client lease 365 0 0
 ip address dhcp
 ip access-group WAN-inbound in
 ip access-group WAN-outbound out
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nat outside
 ip virtual-reassembly in
 ip verify unicast source reachable-via rx allow-default 101
 zone-member security Internet
 duplex auto
 speed auto
 no keepalive
 no cdp enable
exit

Alles funktioniert bestens. Aufgrund Vorzuges speziellerer Routen (Most Match) ist ein Ausklammern intern verwendeter Netzwerke nicht notwendig. Selbst die Default-Route funktioniert noch.

Code: Alles auswählen

sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is 192.168.xxx.xx to network 0.0.0.0

S*    0.0.0.0/0 [254/0] via 192.168.xxx.xx
S     0.0.0.0/8 is directly connected, Null0
S     10.0.0.0/8 is directly connected, Null0
      100.0.0.0/10 is subnetted, 1 subnets
S        100.64.0.0 is directly connected, Null0
S     127.0.0.0/8 is directly connected, Null0
S     169.254.0.0/16 is directly connected, Null0
S     172.16.0.0/12 is directly connected, Null0
      172.25.0.0/16 is variably subnetted, 7 subnets, 2 masks
C        172.25.10.0/24 is directly connected, Vlan10
L        172.25.10.1/32 is directly connected, Vlan10
C        172.25.11.0/24 is directly connected, Vlan11
L        172.25.11.1/32 is directly connected, Vlan11
C        172.25.20.0/24 is directly connected, Vlan20
L        172.25.20.1/32 is directly connected, Vlan20
C        172.25.200.1/32 is directly connected, Loopback200
S     192.0.0.0/24 is directly connected, Null0
S     192.0.2.0/24 is directly connected, Null0
S     192.168.0.0/16 is directly connected, Null0
      192.168.xxx.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.xxx.xx/xx is directly connected, GigabitEthernet8
L        192.168.xxx.xx/32 is directly connected, GigabitEthernet8
S     198.18.0.0/15 is directly connected, Null0
S     198.51.100.0/24 is directly connected, Null0
S     203.0.113.0/24 is directly connected, Null0
gw#

Ein traceroute zeigt keine Hops mehr mit vom WISP-Provider genutzten privaten Adressen. (WISP-Gateway ins öffentliche Netz mit NAT.) Das lokale CPE (Router-Modus) wird angezeigt, da direct connected (spezifische Route). Ping darauf möglich.

Persönliche Einschätzung:

Entsprechend der oben verlinkten Dokumente ist mein internes Netzwerk gegen IP-Spoofing und der Router an sich gegen DoS-Angriffe aus Bogon-Netzwerken geschützt. Damit auch gegen Angriffe aus dem Access-Netz des WISP. Der Router kommuniziert weder abgehend (Null-Routen) noch ankommend (uRPF-Check gegen Null-Routen) mit Bogon-Netzwerken.

Das Autosecure-Feature von Cisco konfiguriert entsprechend der "rausgepickten" Konfiguration, die ich im Eingangsbeitrag (Codeblock) gepostet habe. Vgl. a. http://www.firewall.cx/cisco-technical- ... ature.html
Natürlich werden mit "Automatismen" keine Spezialfälle (WISP) berücksichtigt, nur IP-Spoofing des internen Netzes.

Bei Einsatz mehrerer Router und dynamischen Routingprotokollen mit Redistribution statischer oder asymmetrischen Routing zu mehreren ISPs wird es kompliziert, siehe Beitrag von @mludwig. Evtl. dedizierte(n) Firewall/Gateway nur mit statischem Routing.

Wer Lust/Paranoia hat, kann das Unicast Reverse Path Forwarding mit Null-Routen durch ACLs / iptables mit Quelladressen in Richtung inbound ersetzen. Null-Routen (outbound) kann wohl jeder vernünftige Router und Linux. Nachteil ACLs: Performance geringer.

Empfohlene Best Practices in den Links sollte man ruhig mal lesen.

Sachlich editiert.

[mludwig]

Nur der Neugierde halber, mit dem Blocken von 224.0.0.0 etc ist multicast gemeint? Was dann (u.a.) auch Telekom Entertain beträfe? Ist bei einem WLAN-Provider vermutlich egal, aber falls das jemand so für sein T-Com VDSL mit Entertain übernehmen möchte ...

[BenutzerGa4gooPh]

Yepp, "Multicaster" sollten aufpassen. Welche Adressen für "Entertain" speziell verwendet und so ausgeklammert werden müssen, weiss ich nicht, sind ja viele Multicast-Adressen reserviert: 224.0.0.0/4 = 224.0.0.0 bis 239.255.255.255
https://tools.ietf.org/html/rfc3171
(War noch kein Thema für mich.)

[BenutzerGa4gooPh]

Ich weise mal besser noch darauf hin, dass Null-Routen ohne nachgeschaltetes CPE im Routing-Modus Verbindungen zu Hosts im Access-Netz eines Providers (auch WISP) zulassen, da direct connected Netzwerke und speziellere Routen bevorzugt werden. Dies betrifft damit den Zugang zu öffentlichen WLANs mittels WLAN-Karten (Laptop). Statt Null-Routen ACLs bzw. iptables nutzen.

Dies betrifft nicht den Zugang mit WLAN-Routern (Nano-Router). Es wird ein dediziertes Transfernetz zwischen Host und Router ohne weitere Geräte gebildet, Null-Routen für private Netze dahinter (einschl. privates Accessnetz des Providers) sind nicht vorrangig vor Null-Routen.

Cisco-Nutzer haben die Möglichkeit, entsprechende ACLs am WAN-Interface zu konfigurieren oder diese in die Policies der Zone Based Firewall zu integrieren.

Wesentlich gegen IP-Spoofing ist wenigstens das Verhindern von ankommenden Verbindungen mit Quelladressen, die im eigenen LAN verwendet werden. Mit einer Stateful-Packet-Inspection-Firewall ohne offene Ports müssten diese Verbindungen aus dem LAN initiiert worden sein (Malware?!). Cisco-Nutze verwenden wenigstens Unicast Reverse Path Forwarding im Strict Mode. (DoS)-Angriffe auf die externe Adresse eines Routers aus dem privaten Accessnetz von Providern sind so möglich.