Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > ger.ct > #222558

Re: DHCP-Kuddelmuddel

Show all headers | View raw

Michael Landenberger <spameimer052006@arcor.de>:
> Jep. Router 2 ist WAN-seitig mit Netz 1 verbunden (hat also eine WAN-IP aus
> dem Bereich 192.168.1/24). Das von ihm versorgte LAN (Netz 0) ist ein
> 192.168.0/24-Netz. Der Router hat die Aufgabe, Netz 0 mit Netz 1 zu verbinden.
>
> In Netz 1 gibt es auch einen DHCP-Server (nämlich den im Hauptrouter). Dieser
> Server soll aber nur Anfragen aus Netz 1 beantworten, nicht solche aus Netz 0.

Soweit so gut. Zwei getrennte Broadcastdomains mit jeweils einem eigenen
local DHCP und BootP Server also.

Der AP steckt im Netz 1.

> Hauptrouter, ist also physisch mit Netz 1 verbunden). Allerdings hat der AP
> eine IP aus Netz 0. Die Frage ist, ob er damit in Netz 1 in einer Art Unfug
> treiben kann, dass sich das *nur* in Netz 0 (das durch einen Router von Netz 1
> getrennt ist!) auswirkt.

Nein. Denn ohne die korrekte IP-Konfiguration (IP-range 192.168.1.0/24)
mit der IP von Router 2 als Gateway gelangen Pakete von Netz 1 in das
Netz 0. Geraete in Netz 0 bekommen vom falsch konfigurierten AP und
etwaitigen WLAN-Clients die von ihm DHCP leases bezogen haben nichts
mit.

>| gegeben sei ein LAN (192.168.1/24, nennen wir es mal Netz 1) an
>| einem zentralen Router mit DHCP-Server.
>
> so verstehen kann, dass es in Netz 1 keinen DHCP-Server gebe.

Im folgesatz hattest du vom DHCP server geschrieben dass er sich in
Netz 0 befindet. Mir war unklar, dass du damit einen zweiten DHCP
server meinst.

>> Der DHCP-Server auf dem AP in Netz 1 verteilt jetzt halt fleissig
>> falsche Leases, weil die Werkseinstellung nicht zum deinem Netz Passt.
>
> Wie gelangen diese Leases an Clients in Netz 0? Sie können meines Erachtens

Dafuer gibt es eigentlich nur eine Moeglichkeit:

die beiden Netze sind auf OSI-Schicht 2 nicht sauber getrennt (schrott-
Switch mit unsauberer VLAN-Implementierung, unbeabsichtiges bridging im
Router [z.B. weil du auf Linux irgendwelche VM-Pakete installiert hast] o.ae.)

Denn ein DHCP-RElay benoetigt eine gueltige ueber Layer-3 erreichbare
IP-Adresse des DHCP-SErvers im anderen Segemnt - was bei obiger
Fehlkonfiguration (werkseinstellung) ja genau nicht existiert.

Bei Sauberer Trennung der beiden Segmente auf (mind.) Schicht 2 gibt
es keine Moeglichkeit fuer DHCP bzw. BootP DISCOVER-Broadcastpakete
(unroutable link-local layer-2 Broadcast) von Netz 0 in Netz 1 zu
gelangen. Und ohne diese DISCOVER Broadcast kann der DHCP-Server im AP
keine Leases verteilen.

Denn directed Unicast DHCP Requests, wie sie z.B. von Clients versucht
werden die noch ein vorhergehendes Lease gecacht haben, koennen
mangels korrekter IP-Addressen von Netz 0 nicht ins Netz 1 gelangen,
denn selbst wenn die Gateway-IP die sie aus dem Lease vom AP noch
gepseichert haben mit der IP des Routers im Netz 0 uebereinstimmt,
wird dieser ein ensprechendes Paket nicht ins Netz 1 routen weil die
Ziel-Adresse ja aus dem IP-Range von Netz 0 stammt.

Es ist also nur moeglich, wenn deine beiden IP-Netze auf Schicht 2
nicht getrennt sind, entweder weil du nur einen physikalischen Switch
verwendest, dessen VLAN-Trennung schrott ist oder du garnicht mit
VLANs trennst, oder weil du noch ein anderes Geraet in beiden Netzen
hast das Bridge spielt.

> allenfalls den WAN-Port von Router 2 erreichen, denn nur der ist direkt mit
> Netz 1 und damit mit dem AP verbunden.

In der Tat.

>> Ach. Sie bekommen ja vom falschen DHCP Server falsche IP-Leases
>> zugewiesen.
>
> Durch einen NAT-Router hindurch? Das glaube ich kaum. Wenn das ginge, würden

Das Kommt Darauf An. Man kann ein Linux natuerlich so
zerkonfigurieren, dass er BOOTP Broadcasts und passende Antowrten
weiterleitet, so eine Konfig ist aber weder Default noch leicht zu uebersehen.

> ja die Clients z. B. an einem DSL-Router WAN-IPs vom DSL-Provider bekommen.
> Tun sie aber nicht, sondern sie bekommen lokale IPs vom DHCP-Server im
> DSL-Router.

Bei DHCP kommt es immer darauf an, welcher Server schneller antwortet.

Das macht Rogue DHCP Server ja so gefaehrlich.

PS: Der ISC dhcpd ist nicht besonders schnell, ein einfacher
gestrickter DHCP server in irgend einem Plastikrouter kann durchaus
mal zig millisekunden schneller antworten, und damit sogar in Layer-2
WANs den autorisierten DHCP-Server ausstechen. BTST2MT.

> verbunden, während Router 1 Netz 1 mit dem Internet verbindet. Vielleicht wird
> es klarer, wenn ich es aufmale:

Ja. Es ist bei kompliziertern Umgebungen immer besser, wenn man
einen Plan[tm] hat.

>| Router 1/ |
>|   DHCP-   |
>| Server 1  |
>|           |
>|    LAN    |
> +-----+-----+                  |
>       | Netz 1 (192.168.1/24)
>       |
>       +--- Clients
>       |    (bekommen IPs vom DHCP-Server
>       |     in Router 1
>       |
>       +--- D-Link-AP
>       |    (normalerweise feste IP 192.168.1.102
>       |     und mit deaktiviertem DHCP-Server,
> 	|     seit Reset Default-IP 192.168.0.50
>       |     und mit aktiviertem DHCP-Server)

Also der "rogue DHCP server" in Netz 1. Die Trennung ist physikalisch?

>       |
> +-----+-----+
>|    WAN    |
>|           |
>| Router 2/ |
>|   DHCP-   |
>| Server 2  |

Ich nehme an, der DHCP-Server lauscht nur auf der LAN-Schnittstelle?
(nicht default, das muss man bei ISC dhcp konfigurieren!)

>|    LAN    |
> +-----+-----+
>       | Netz 0 (192.168.0/24)
>       |
>       +--- Clients
>            (bekommen IPs vom DHCP-Server
>             in Router 2

Falls die Trennung der NEtze wie aufgezeichnet physikalisch ist, gibt
es keinen Weg an Router 2 vorbei.

Wenn dein Client in Netz 0 jetzt ein Lease vom AP bekommt (mit
Gateway-IP 192.168.0.50 was vermutlich nicht die  IP von router2 im
Netz 0 ist), so stimmt immerhin Netz und Maske, er kann also im
Netz 0 mit anderen Clients und dem Router2 als HOst kommunizieren.
Falls dein Router2 die selbe IP wie der AP hat (.50), dann kann er
sogar ganz normal wie wenn er ein Lease vom Router 2 haette
kommunizieren. Der ISC DHCPd in router 2 wird mittels DAD verhindern,
das er eine IP-Adresse die der AP einem client verpasst hat selbst
einem anderen Client vergibt, so das es idR. nicht mal zu einer
Adresskollision kommt.

Bleibt die Frage, wer die BOOTP Requests (die Broadcast DISCOVER
pakete von DHCP) aus Netz 0 an Netz 1 weiterreicht, und wer die DHCP
OFFER/ACK PAktete vom AP mit der falschen IP-Adresse im Netz 1 an die
Clients in Netz 0 weiterreicht.

Wobei, eine weitere Moeglichkeit faellt mir gerade ein:

Hast du mal die WLAN-Schnittstelle in den Clients, deren Ethernet-Port
du in Netz 0 gesteckt hast, ueberprueft?

Einige dysfunktionale Windows-Treiber (z.B. bei HP Notebooks gesehen)
mach(t)en da naemlich was ziemlich kaputtes:
Die schicken DHCP DISCOVER requests sowohl fuer die LAN-Schnittstelle
als auch den WLAN-Adapter jeweils ueber beide Schnittstellen raus,
d.h. du siehst einen DHCP-Request fuer die MAC-Adresse des
LAN-Adapters auf dem WLAN - der AP wuerde das bei dir beantworten und
ueber WLAN zurueckschicken und der kaputte Treiber packt die IP-Config
dann scheints auf den LAN-Anschluss.

Bei $KUNDE war das damals im SIEM/Network-IDS aufgefallen, weil DHCP
Requests mit MAC-Adressen die im LAN registriert waren auch auf den
Wireless-Controllern aufschlugen, und umgekehrt! Was passiert waere,
wenn diese Bogus Requests beantwortet worden waeren, konnte ich damals
allerdings nicht austesten (die DHCP Server haben diese Requests
jeweils ignoriert bzw. ge-NACK-t. Das Problem wurde soweit ich noch
weis mit einem Treiber-Update oder GPO-Richtlinien aus der Welt geschafft.
Das Problem betraf IIRC einige Modelle von HP mit bestimmten Windows-
Treibern. Falls das auch bei dir zutrifft, wuerde es erklaeren wie die
DHCP-Pakete vom AP zum Client kommen.

HTH
Juergen
-- 
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems.  (Bruce Schneier)

Back to ger.ct | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

DHCP-Kuddelmuddel "Michael Landenberger" <spameimer052006@arcor.de> - 2015-09-21 10:10 +0200
  Re: DHCP-Kuddelmuddel "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-21 10:27 +0200
  Re: DHCP-Kuddelmuddel "Juergen P. Meier" <nospam-1984@jors.net> - 2015-09-21 11:55 +0000
    Re: DHCP-Kuddelmuddel "Michael Landenberger" <spameimer052006@arcor.de> - 2015-09-21 19:45 +0200
      Re: DHCP-Kuddelmuddel "Juergen P. Meier" <nospam-1984@jors.net> - 2015-09-22 06:14 +0000
  Re: DHCP-Kuddelmuddel Daniel Pache <daniel.pache@gmx.net> - 2015-09-21 14:54 +0200
    Re: DHCP-Kuddelmuddel "Michael Landenberger" <spameimer052006@arcor.de> - 2015-09-21 18:49 +0200
      Re: DHCP-Kuddelmuddel Daniel Pache <daniel.pache@gmx.net> - 2015-09-22 09:29 +0200
        Re: DHCP-Kuddelmuddel "Michael Landenberger" <spameimer052006@arcor.de> - 2015-09-23 08:41 +0200
      Re: DHCP-Kuddelmuddel "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-22 10:44 +0200
    Re: DHCP-Kuddelmuddel Jörg Barres <news@traicon.net> - 2015-09-21 20:02 +0200
  Re: DHCP-Kuddelmuddel Jörg Barres <news@traicon.net> - 2015-09-21 19:59 +0200
  Re: DHCP-Kuddelmuddel Bernd Mayer <beam.bam.boom@knuut.de> - 2015-09-22 10:33 +0200
    Re: DHCP-Kuddelmuddel "Michael Landenberger" <spameimer052006@arcor.de> - 2015-09-23 08:45 +0200

csiph-web