• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

[Firewall?] LAN Port an Microserver auf Samba beschränken

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
Es geht um einen HP Microserver Gen8.

Nun wollte ich eine Netzwerkbuchse von dem Ding als Gastzugang zum SAMBA share nutzen. Ist das sicher möglich?
Konkret gehts mir um Chinaboxen oÄ denen ich nichtmal so weit traue wie ich sie werfen kann.

SAMBA ist schon so eingerchtet das ein Gast nur lesen darf.

also:
eth0: volles Netzwerk
eth1: nur Samba

Problem 1:
Beide IPs sind nur über den selben Port erreichbar, dafür keine über den anderen.
Achja, das IP Protokoll.

Update:
Beide Ports antworten mittlerweile nur noch auf die jeweils richtige Adresse, was mir halt noch Sorgen macht ist die Sicherheit.
aka: kann man das mit komischen Tricksereien zB manipulierten ARP requests von außen(als Gerät an eth1) umgehen?

Setup:
das DHCP ist statisch, kann mir also nicht um die Ohren fliegen.
Außerdem habe ich als Backup immer noch ILO Zugang den ich auch Zeitweise nutzen musste weil ich mich via Netzwerk direkt ausgesperrt habe.:D
[src=text]
# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
post-up ip route add 192.168.2.0/24 dev eth0 src 192.168.2.103 table rt1
post-up ip route add default via 192.168.2.1 dev eth0 table rt1
post-up ip rule add from 192.168.2.103/32 table rt1
post-up ip rule add to 192.168.2.103/32 table rt1

# samba only device:
allow-hotplug eth1
auto eth1
iface eth1 inet static
address 192.168.2.203
netmask 255.255.255.0
gateway 192.168.2.1
post-up ip route add 192.168.2.0/24 dev eth1 src 192.168.2.203 table rt2
# post-up ip route add default via 192.168.2.1 dev eth1 table rt2
post-up ip rule add from 192.168.2.203/32 table rt2
post-up ip rule add to 192.168.2.203/32 table rt2
[/src]
 
Zuletzt bearbeitet:

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@alter_Bekannter: Mir erschließt sich die Sinnhaftigkeit grad nicht. Üblicherweise vertraust du deinem Server, deinem Netzwerk auch aber dem Internet nicht. D. h. eigentlich solltest du eth0 auf den Router legen, den Rest des Netzes auf eth1, und dann dedizierte Durchleitungen mit NAT machen. Wenn es Clients im Netzwerk gibt, denen du nicht vertraust, kannst du die ja einfach in ein IP-Segment schubsen (mit DHCP), in dem es kein Internet gibt.

Und ja, das geht natürlich problemlos. Such mal im Forum nach iptables, ich hab da AFAIK mal ne Anleitung geschrieben...
 

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
  • Thread Starter Thread Starter
  • #3
Iptables kann nach devices filtern, ist das technisch zuverlässig?
Sowas wie hier:
https://serverfault.com/questions/475717/iptables-block-incoming-on-eth1-and-allow-all-from-eth0


IP ranges nur logisch zu trennen bringt allein schon wegen der einfachen Möglichkeit eigener ARP Pakete nichts.

Kein Internet ist nur Teil der Übung, wenn ich ein Gerät an eth1 anschließe soll das nix weiter machen könne als Lesend auf das SAMBA-Share zugreifen. Gäste sind read only, accounts mit Schreibzugriff brauchen ein Passwort.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@alter_Bekannter: Iptables hängt im Kernel, d. h. sieht die Pakete noch weit bevor dein Dienst sie bekommt. Klar ist das zuverlässig.

Und was dein ARP-Poisoning-Szenario angeht: Wie soll da die Firewall umgangen werden können? ARP-Poisoning macht man normalerweise, wenn man den gesamten Netzwerkverkehr über sich selbst leiten möchte, um schnüffeln zu können. Das Gateway bekommt dann nur noch Traffic vom Angreifer. Und der hat ne IP-Adresse im entsprechenden Bereich, den iptables nicht ins Internet lässt. Sollte ein Angreifer das also machen, hat niemand mehr Internet, und der Angreifer fliegt sofort auf. Ich verstehe daher dein Problem beim von mir vorgeschlagenen Netzwerkaufbau nicht.

P.S.: iptables kann auch MAC-Filter.
 

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
  • Thread Starter Thread Starter
  • #5
Wie hilft mir ein MAC Filter weiter? die kann man doch auch beliebig ändern. Andere Schicht, selbes Problem.

Na mit falschen ARP adressen kann man sich eine passende IP machen.

Dann versuche ich mal konkretere Beispiele zu finden:
Siehe Startpost kann je nach Routingkonfiguration ein Gerät offensichtlich auch auf die falsche Adresse antworten. Also werden Anfragen zumindest da noch nicht vom System getrennt. Gerade diese seltsame Symptomatik macht mich da etwas skeptisch. Eine Verwechslungist halt auch ausgeschlossen da tatsächlich beide Adresse simultan auf dem selben Gerät gingen während das andere bei beiden stumm blieb.

Daher würde ich unter anderem gerne verstehen warum das Gerät ohne Routigtabelle irgendwie so egal sein kann.

Wäre das nichgt passiert wäre ich jetzt bei weitem nicht so unsicher.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@alter_Bekannter: Ich glaube, du hast da was völlig falsch verstanden. ARP ist ein Protokoll, das dem Host sagt, womit er welchen Rechner erreichen kann. Insbesondere bei Switches oder Routern ist das relevant, weil ein Paket für IP xy nicht an alle Ausgänge geleitet werden soll, sondern nur zu dem, welcher auch tatsächlich eine physikalische Verbindung zum Zielhost hat. ARP arbeitet dahingehend mit MAC-Adressen, und eine ARP-Table sieht üblicherweise so aus:

[src=bash]$HOSTNAME ($IP) auf $MAC [$VERBINDUNGSTYP] auf $INTERFACE[/src]

Diese Tabelle schreibt sich jeder Host selbst, d.h. ein Host kann sich natürlich eine beliebige IP geben, aber nicht, indem er seine eigene ARP-Table manipuliert. ARP wird für Routing verwendet, nicht für Netzwerkkonfiguration auf IP-Ebene. Dafür ist DHCP da.

Dein Angreifer müsste, um eine scharfe Firewall zu umgehen, die IP inklusive der MAC eines validen Gerätes kapern und diese aktiv und aggressiv allen anderen Geräten so mitteilen (das nennt man ARP-Poisoning), was zum sofortigen Netzwerkausfall für das Gerät führt, dessen Identität gekapert wurde. Das ist auch nicht sehr stabil, denn auch das so bestohlene Gerät wird immer wieder versuchen, seine Position sauber mitzuteilen.

Ganz ehrlich: Wenn du so einen Fall in deinem Heimnetzwerk hast, dann ist "Wegschmeißen" die einzige valide Option. Denn diese Geräte kann man nur in den Griff bekommen, wenn sie allein in einem physikalisch getrennten Netzwerksegment unterwegs sind (also allein an einem Netzwerkadapter der Firewall mit eigenem IP-Adressbereich hängen), denn sie werden JEDE IP kapern versuchen, die in ihrem Netzwerk unterwegs sind. Das sind dann Angriffstools, keine Clients.
 

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
  • Thread Starter Thread Starter
  • #7
Richtig, genau das habe ich unter dem ARP Problem verstanden.

Theoetisch wäre es also vermutlich einfacher, falls möglich anzugeben auf einem Port garkeine ARP Pakete zu akzeptieren. und Gegenstellen eine IP vorzusetzen die sie dann akzeptieren oder nicht. Aber das geht vermutlich so stark an den Spezifikationen vorbei das es dafür kein annähenrd fertiges System gibt.

Das ist genau das Problem vor dem ich stehe, ich ging davon aus das ein separater netzwerkport als physikalische Trennung ausreicht, was offensichtlich nicht der Fall ist. Zumindest nicht in der default Einstellung.

Dass "Wegschmeißen" eine nette Idee, aber in der Praxis nicht umsetzbar, weil Problemfälle nicht als solche ausgezeichnet werden.

Das Port IP Problem war nur der Indikator das es da noch einen Arsch voll mir unbekannter Probleme gibt. Daher die Frage: Warum passiert sowas? Ich ging davon aus wenn ich über das System Adressen zu Geräten zuweise ist das fest. Aber offensichtlich funktioniert das so nicht.

Oder malk etwas anders aufgestellt:
Problem 1:
IPs "bleiben" nicht auf dem übers System zugewiesenen Geräten.
Hier wüsste ich gerne warum dem so ist und ob das jetzt definitv behoben ist mit den Routingeinträgen.
Der Warum Part ist mir erheblich wichtiger, ignorier den zweiten Teil wenn er dich stört.

Problem 2:
Jeder kann sich mit beliebiger MAC melden.

Problem 3:
Jeder kann sich mit beliebiger IP melden.

Deswegen wollte ich mich in keiner Hinsicht auf MAC oder IP stützen. Und Port funktioniert halt siehe Problem im Startpost offenbar auch nicht so einfach. Auch wenn mittlerweile dank der Routingeinträge beide nur nocjhh exklusiv & korrekt antworten wenn alles normal läuft.

Mein Setup sieht so aus:
eth1 Kabel Gerät X.
eth0 Kabel Router restliches Netz und Internet

Gerät X soll nirgends hin außer auf das SAMBA share das auf dem Gerät mit eth1 läuft. Auch kein Internet, garnix.
Das scheint jetzt auch zu funktionieren zumindest mit Geräten denen ich traue, aber ich weiss halt nicht warum Problem 1 besteht/bestand, darum kann ich da überhaupt nix testen.
 
Zuletzt bearbeitet:

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@alter_Bekannter: Du denkst gerade viel zu kompliziert.

1. ARP-Pakete nicht annehmen ist ne dumme Idee - die sollen durch. ARP wird eh nicht geroutet, d. h. solange du an eth0 ein anderes Netz hast als an eth1 (also einen anderen IP-Adressbereich, wie etwa 192.168.0.0/24 auf eth0 und 192.168.1.0/24 auf eth1), wird ARP nicht zwischen den Netzen durchgeschleift.

2. Du hast kein hartes DHCP eingerichtet. Die Adressen ändern sich nur, weil der DHCP-Server (dein Router) nicht ordentlich zuweist. Konfiguriere den so, dass er bestimmten MAC-Adressen nur bestimmte IPs zuordnet, dann läuft das auch. Das hat überhaupt gar nichts mit Routing oder ARP zu tun. Höchstens mit Firewalling, wenn du nämlich am Server mit eth1 die Ports 67/68 ausblockst. Dann wird der Client keine DHCP-Antwort vom Server bekommen und sich selbst eine 169.254.x.y-Adresse geben, die sog. Zeroconf-Adresse, die auch nicht gleich bleibt. Das ist normales Netzwerkverhalten. Das ist auch der Fall, wenn du Netze trennst (wie oben) und dem Netz an eth1 keinen DHCP-Server spendiert hast. Oder aber du zwei DHCP-Server laufen hast, die das Netz versorgen - dann gewinnt der schnellere, und das ist selten der Router.

3. Jeder kann sich immer eigene IPs einrichten. Das ist normal und auch nicht zu verhindern. Du kannst nur verhindern, dass diese Geräte über deine Firewall gehen, wenn du eine MAC-Filterung einsetzt.

4. Jeder kann sich eine eigene MAC geben. Das ist soweit korrekt. In der Praxis wird davon aber nur in Angriffsszenarien Gebrauch gemacht. MAC-Adressen sind weltweit einmalig (so die Idee), um Geräte einwandfrei identifizieren zu können. Wenn jeder einfach seine MAC beliebig ändert, würde das in haufenweise Netzwerken zu üblen, kaum diagnostizierbaren Fehlern kommen. Daher wird die nicht geändert. Linux lässt einen sie zwar ändern, aber das liegt in der Natur des Betriebssystems, und bei Windows ist sie AFAIK hart.

So, und ich würde vorschlagen, du lehnst dich mal zurück, betrachtest dein Netz aus einiger Entfernung, beschreibst genau, was du gemacht hast und postest hier Configs. Ich glaub nämlich, dass dein Client, den du da verdächtigst, völlig harmlos ist, du nur irgendwas in der Netzwerkconfig verkackt hast, so dass deine Clients sich alle irrational verhalten.
 

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
  • Thread Starter Thread Starter
  • #9
Wie kommst du auf die Idee das es einen konkreten Angreifer gibt?

Das habe ich absichtlich als Beispiel gehalten, das war der Plan nicht mein Verusch irgendwas rückwirkend zu fixen.
Oder anders formuliert:
Das nicht vertrauenswürdige Gerät existiert noch nicht.
Das war ein Konzept.

Wie kommst du auf die Idee das sich bei mir IP Adressen "falsch"(?) geändert hätten?

Hier ist offensichtlich irgendwas ganz falsch rübergekommen.

Öh, nein, ich habe keinen Gremlin und auch nie absichtlich einen Verdacht diesbezüglich geäußert.:D
Hier gehts um Präventivmaßnahmen.

Edit:
Problem 1 ist nix neues, das bezieht sich auf das im Startpost beschrieben Szenario: (War das der Irrtum?)
eth0 IP x
eth1 IP y
Ohne gesonderte Routing config hat eth1 auf x und y geantwortet
und eth0 auf keine
Das es irgendwie mit dem Routing zusammenhängt, klar, abner mein Problem daran war das sowas nach meinem Verständnis nie hätte passieren dürfen in der config.
Das Problem besteht nicht mehr, siehe Startpost. Denn ich habe ja jetzt ROutingeinträge angelegt und auch oben gepostet, seit dem sieht alles gut aus, ich traue nur dem Frieden nicht. Ich würde aber eben gerne wissen warum sowas überhaupt passieren kann.
 
Zuletzt bearbeitet:

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@alter_Bekannter: Ok, wir haben da anscheinend echt ordentlich aneinander vorbeigeredet, lag aber daran, dass du reale Probleme mit theoretischen Überlegungen vermischt hast.

Normalerweise tu ich mir schwer, sowas ohne Configs zu beantworten. Hier auch. Was ich erwartet hätte, wäre eine ordentliche Beschreibung, und zwar auch des Ziels, des vermuteten Angriffsszenarios (weil du willst dich ja gegen was schützen, was genau hast du aber sehr schwammig gehalten), und dann davon getrennt eine Problemstellung, die du tatsächlich hast.

Also, du hast, soweit ich verstanden habe, zwei Netze. Vermute ich. Zwei NetzwerkADAPTER bedeutet nicht zwangsläufig zwei Netze. Da du nie konkret geworden bist, hab ich jetzt zig Möglichkeiten, woran es liegen könnte, keine davon hat was mit Routingtabellen oder ARP-Paketen zu tun. Du hast auch nie gesagt, wer in dem Netz DHCP-Server ist. Also bevor ich jetzt weiter spekuliere, zeig ich dir einfach, wie man sowas normalerweise macht:

1. Der korrekte, sinnvolle Aufbau
========================

Internet (Militarized Zone; MZ) <-> Router <-> MZ <->eth0 - HP-Server - eth1 <-> Internes Netz mit allen Geräten; Demilitarized Zone (DMZ)

eth0 (192.168.0.100) - Netz: 192.168.0.0/24 (Subnetzmaske: 255.255.255.0)
eth1 (192.168.1.1) - Netz: 192.168.1.0/24 (Subnetzmaske: 255.255.255.0)

Router: möglicherweise Durchleitung bestimmter Ports zum Server, kein Vertrauen ins Endgerät (Router sind sicherheitstechnisch oft scheiße)
HP-Server: Samba (bind auf eth1), NAT von eth1 nach eth0, DHCP-Server auf beide Adapter, DNS-Server auf eth1, SSH auf beiden Adaptern (sicherheitshalber), evtl. weitere Dienste an eth1

Für DHCP/DNS empfehle ich dnsmasq, das kann beides und ist schick konfigurierbar.

Netz auf eth0: ILLEGAL; von DHCP-Server zugewiesen, ansonsten schwarzes Loch (Ausnahme: Router selbst), Kompletter Block durch Firewall mit Mail-Alerting (Honeypot für Router-Einbrüche)
Alternativ kannst du da auch dein China-Shit reinpacken, da SMB aber ein recht komplexes und fehleranfälliges Protokoll ist, empfehle ich es ausdrücklich nicht.

Segmentierung des Netzes auf eth1:
192.168.1.0/29 (0-7): Administrative Hosts (WLAN-Hotspot, Server selbst, evtl. NAS, China-Box etc.); MAC-Filterung, scharfe Firewall, harte DHCP-Zuordnungen, extrem eingeschränkter Internetzugang (wenn überhaupt) Erreichbarkeit der notwendigsten Dienste.
192.168.1.8/29 (8-15): Administratoren, d. h. Geräte mit weitreichender Befugnis; MAC-Filterung, laxe Firewall am Server, harte DHCP-Zuordnungen, voller Internetzugang, Erreichbarkeit vieler Dienste.
192.168.1.16/28 (16-31): Weitere persönliche Geräte der Hausbesitzer, Handys etc.; MAC-Filterung, normale Firewall, harte DHCP-Zuordnungen, voller Internetzugang, Erreichbarkeit der gewünschten Dienste.
192.168.1.32/27 (32-63): Freunde, größerer Familienkreis mit Zugang zum WLAN oder zum Netz...; keine MAC-Filterung, normale Firewall, harte DHCP-Zuordnungen, voller Internetzugang, Erreichbarkeit der gewünschten Dienste.
192.168.1.64/27 (64-91): Bekannte, die nur hin und wieder mal WLAN wollen; keine MAC-Filterung, freie DHCP-Zuordnungen (mit Mail-Alerting; Honeypot für WLAN-Einbruch), beschränkter Internetzugang, Erreichbarkeit der notwendigen Dienste.
192.168.1.92/27 und 192.168.1.128/25 (92-255): ILLEGAL; von DHCP-Server nicht zugewiesen, Kompletter Block durch Firewall mit Mail-Alerting (Honeypot für IP-Selbstvergeber), kein Internet, keine Dienste - schwarzes Loch.

Wo scharfe MAC-Filterung angegeben ist, wird die Firewall IP/MAC-Übereinstimmungen abprüfen und sofort ne Mail verschicken, wenn eine IP mit falscher MAC daherkommt oder umgekehrt. Beim Netz der Bekannten hast du gleich nen Honeypot für Geräte, die das WLAN nutzen, obwohl du nichts davon weißt. Du bekommst ne Mail aufs Handy, wenn du nem Bekannten das WLAN-Passwort gibst, die erwartest du aber. Bekommst du eine, ohne selbst einen Zugang vergeben zu haben, kannst du nachsehen, wer da gerade was probiert, sei es ein Amok laufendes Gerät oder ein Angreifer (oder ein Bekannter, der das Kennwort hat und grad zufällig am Haus vorbei geht - Fehlalarme sind also eher normal). Das letzte Segment überspannt den kompletten Bereich um den Standard-DHCP-Bereich der meisten Router. Wenn ein angreifendes Gerät sich eine harte IP zuweisen will (was auch immer das bringen sollte), wird es vermutlich in diesem Bereich bleiben, wahrscheinlich sogar die 100 wählen (weil die der Startpunkt des Standard-DHCP-Bereichs ist).

Die Firewall wird so eingerichtet, dass du jedes der Netzsegmente einzeln konfigurieren kannst, nachdem die MAC/IP überprüft wurde. So kannst du gezielt einzelnen Hosts zum Beispiel Samba-Zugriff geben, oder Internet sperren etc. Auf allen legalen Bereichen muss aber UDP-67 in und UDP-68 out offen sein (DHCP). ARP und Routing kann dir gleich sein - solange eth1 auf eth0 durchleiten darf (mit NAT; das kann man in iptables einrichten) und das Gateway nur für eth0 konfiguriert ist (nämlich der Router), läuft alles. Hast du trotzdem Angst vor ARP-Poisoning, kannst du dir arpwatch installieren, und auf eth1 lauschen lassen. Der kann auch alerten, wenn was komisch wird.


2. Dein Setup:
=================

Internet (MZ) <-> Router <-> DMZ <-> eth0 - HP-Server - eth1 <-> MZ

Problem dabei: Du musst zwei Geräten vertrauen, um eine DMZ zu bekommen (Router und HP-Server)

eth0 (192.168.0.100) - Netz: 192.168.0.0/24 (Subnetzmaske: 255.255.255.0)
eth1 (192.168.1.1) - Netz: 192.168.1.0/24 (Subnetzmaske: 255.255.255.0)

Router: möglicherweise Durchleitung bestimmter Ports zum Server, volles Vertrauen ins Endgerät (sic!), WLAN, DHCP, DNS
HP-Server: Samba (bind auf beide Adapter), DHCP-Server auf eth1, DNS-Server auf eth1, SSH auf eth0, evtl. weitere Dienste an eth0

Übrigens: Wenn Samba auf beide Adapter binded, wird es dir auch auf die IP-Adresse des anderen Adapters antworten (wenn du iptables nicht scharf konfiguriert hast), weil er ja merkt, dass er gemeint ist. Die Standardeinstellung von Samba ist ein Bind auf alle Adapter.

Segmentierung kannst du machen, bringt aber wenig, zumal der Router das scheiße konfigurierbar macht, sofern du ihm DHCP nicht nimmst und selber via dnsmasq machst. Aber: Du kannst dein China-Gerät an eth1 sauber abschotten, einfach ein REJECT für alle Verbindungen, die nicht UDP 53 (DNS), UDP 67/68 (DHCP) oder TCP 445 auf 192.168.1.1 sind. Von woher die dann genau kommen, kann dir eigentlich scheißegal sein. So schottet man Angreifer, wenn man das unbedingt möchte.



So, ich hoffe, ich konnte dir etwas helfen. Oder anderen.

Und nochmal:

In keinem dieser beiden Setups brauchst du Routingregeln.
 

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
  • Thread Starter Thread Starter
  • #11
Welche Configs willst du denn?

Im Startpost stehen sie doch.

Erzähl mir doch was du brauchst wo ich angeblich nicht konkret war, wieviel konkreter als die config posten kann ich noch werden?

falls es wirklich an kreativität fehlt sich die config ohne routingzeug vorzustellen:
iface eth0 inet dhcp

# samba only device:
allow-hotplug eth1
auto eth1
iface eth1 inet static
address 192.168.2.203
netmask 255.255.255.0

Problem dabei: Du musst zwei Geräten vertrauen, um eine DMZ zu bekommen (Router und HP-Server)
Kein Thema, gegeben. Wo im Thread habe ich mich so ausgedrückt das es darüber Zweifel gibt, hilf mir für die Zukunft.
 
Zuletzt bearbeitet:

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@alter_Bekannter: Ne Config ist nicht nur die Config des Netzwerkadapters, auch die Config des DHCP-Servers (und wer das übernimmt - aus deiner Config raus ist der Router wahrscheinlich, aber nicht zwingend), die Samba-Config, evtl. DNS-Config und natürlich auch, welches Verhalten du erwartest und welches du beobachtest.

Aber grundlegend eins noch: Zwei Netze = zwei IP-Adressräume. Verhindert haufenweise Probleme. Und dein Gateway darf eigentlich da nicht angegeben werden.

Kurzum: Du hast es verkackt. Auf vielen Ebenen, und das Routing ist ein hässlicher Workaround.
 

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
  • Thread Starter Thread Starter
  • #13
DHCP Server: Gammelrouter vom Provider = kein Zugang
Welche DNS Config? Wo kommt das hier ins Spiel?
Ich kann beim besten willen nicht erkennen wo hier irgendwas mit DNS zusammenhängt.

Am ehesten könnte ich da wieder auf den Gammelrouter und kein Zugang verweisen.

Der einzige Test der seltsame Ergebnisse geliefert hat wurde auf IP Ebene durchgeführt. (Und das war vor der routing Konfiguration und nur dann. Wie gesagt, derzeit sieht aslles so aus als würde es tun was es soll, deshalb frage ich mich warum du meiner Frage ausweichst.)

Der Fall in dem Anfragen exklusiv von eth1 beantwortet wurden. Anfragen über eth0 wurden offenbar gedroppt, ich konnte nur auf Timeouts warten.

das einzige was ich sonst noch angefasst hätte wäre die rt_tables, aber die Änderung ist übersichtlich und hat keine Probleme verursacht sondern gelöst.
rt_tables schrieb:

Was ich noch zum erwarteten und beobachteten Verhalten sagen soll wüsste ich jetzt auch nicht, was davon war unklar und warum?

samba, auch wenn mir hier das warum wieder nicht klar ist, damit gabs doch keine Probleme:
Code:
[NAS]
path = /media/NAS/ 
comment = NAS
browsable = yes
guest ok = yes
read only = yes
read list = guest
write list = PC
Okay, die ist vermutlich so unsauber das es ein Wunder ist das es so klappt wie ich das will, aber es klappt. Das sollte aber keinen Einfluss auf das restliche Netzwerk haben oder?
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@alter_Bekannter: Ich glaub, das was mich am meisten irritiert hat, war, dass du reale Probleme mit theoretischen Überlegungen zusammengewürfelt hast, und erstere dann für Beendet erklärt hast ohne weitere Erklärung. Vielleicht wars für mich auch einfach nur spät.

Bzgl. Router:
Da solltest du eigentlich Zugriff haben. Zumindest soweit, dass du grundlegende Netzwerkeinstellungen verändern kannst. Wenn das nicht der Fall ist, würde ich mir an deiner Stelle nen anderen Router zulegen. Vertrauen würde ich ihm jedenfalls auf keinen Fall.

DNS kommt ins Spiel, wenn du Adressen im Netzwerk nicht nur über IPs auflöst, sondern auch über Namen. In Windows-Heimnetzwerken gibt es dafür NetBIOS, das geht auch mit samba. Wenn du dnsmasq laufen hast, und der jedem Gerät im Netzwerk sowieso eine IP zuweist, kann er auch direkt nen Domainnamen anhängen und das ganze voll DNS-kompatibel machen (dann sind sich ändernde IPs für Mobilgeräte auch kein Problem mehr).

Zur Samba-Config: Die ist nicht unsauber, nur unvollständig. Klar, man könnte jetzt auch noch die Adressen beschränken, von woher welcher User arbeiten darf, aber darum gehts mir gar nicht: Es fehlt, wie der Server selbst konfiguriert ist, auf welche Netzwerkadapter er binded etc.

Darüber hinaus bin ich mir etwas unschlüssig, ob du genau das erreicht hast, was du erreichen wolltest, nämlich dass deine China-Box nur den Adapter erreichen kann und sonst nix. Denn wenn es so wäre, würde sie auch kein DHCP können (das ja laut deiner Aussage nur vom Router kommt, d. h. wir haben hier einen Netzsprung, den du eigentlich ja nicht haben willst. Das war der Grund, warum ich dir vom Routing abgeraten und die Netztrennung so vorgestellt habe, wie ich es gemacht hab. Mit iptables, nicht mit rt_tables.

Nochmal: Gib deinem eth1 einen anderen /24-Bereich. Installier dir dnsmasq und lass es zumindest die DHCP-Verteilung an eth1 übernehmen. Dann lösch die Routen, die brauchst du gar nicht. Mit iptables kannst du dann auch noch hübsch den Adapter absichern:

[src=bash]# Erlaube initiierte Verbindungen auf allen Adaptern in beide Richtungen
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Erlaube DHCP auf eth1
iptables -A INPUT -i eth1 -p udp --sport 68 --dport 67 -j ACCEPT
iptables -A OUTPUT -o eth1 -p udp --sport 67 --dport 68 -j ACCEPT

# Erlaube Samba auf eth1
iptables -A INPUT -i eth1 [-s CLIENT-IP] -p tcp --dport 445 -j ACCEPT

# Verweigere allen anderen Traffic auf eth1
iptables -A INPUT -i eth1 -j REJECT[/src]

Damit bist du dann fein raus, weil du nicht künstlich eine Verbindung zwischen den Adaptern geschaffen hast, um bestimmte, nicht gefirewallte Protokolle doch kommunizieren zu lassen.
 

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
  • Thread Starter Thread Starter
  • #16
@Metal_Warrior:
Wo habe ich künstlich eine Verbindung zwischen den devices geschaffen?

Das war exakt das verhalten das ich nicht wollte und vermeintlich nach den routing einträgen auch nicht mehr auftritt.

Genau deswegen bin ich darüber ja so besorgt, ohne routing ist das passiert. Und genau das macht mir Sorgen, ich verstehennicht im geringsten wie sowas passieren konnte bevor ich irgendwas am routing angefasst habe.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@braegler: Nein, in OUTPUT kann man keine incoming devices deklarieren, nur outgoing ;)


@alter_Bekannter: Gut, ich glaub, wir reden noch immer aneinander vorbei.

Läuft deine China-Box mit dem DHCP vom Router, oder hat sie eine feste?

Wenn Router-DHCP: Dann gibt es eine Verbindung zwischen den Devices. Entweder, weil du sie via Routing geschaffen hast, oder weil du irgendwann mal während deinem Rumprobieren "echo 1 > /proc/sys/net/ipv4/ip_forward" gemacht hast. Wenn letzteres, ist das bei nächsten Neustart wieder weg und deine China-Box läuft nicht mehr (weil sie kein DHCP mehr bekommt).
Wenn feste IP, dann ist alles (soweit ich sehe) in Butter. Müsstest halt mal schauen, ob du von der China-Box auf den Router kommst bzw. vom internen Netz die China-Box erreichen kannst. Nur weil du den Adapter nicht ansprechen kannst, bedeutet das nicht, dass du das Netzwerk dahinter nicht kontaktieren kannst.
 
Zuletzt bearbeitet:

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
  • Thread Starter Thread Starter
  • #18
Feste IP, wenn ich irgendwo von DHCP gesprochen habe im Kontext um das fragwürdige Gerät dann mit statischem DHCP vergeben vom Microserver(Nur eine Idee, zu keinem Zeitpunkt umgesetzt oder angefangen). Ganz sicher nichts durchgeleitetes.

Daher nochmal die Frage:
wie konnte es passieren das der Microserver nur über eth1 kommuniziert hat aber beide Adressen darüber erreichbar waren?

Das war wohlgemerkt bevor ich die Routingregeln definiert habe, jetzt gehts nicht mehr.
Subnetz hin oder her hat eth1 auf eine Adresse gehorcht die nicht zugewiesen war und eth0 dafür auf keine.

War dein ein Missverständnis wie die devices config funktioniert?

Zu dem Zeitpunkt sah die so aus:
Code:
# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
 
# samba only device:
allow-hotplug eth1
auto eth1
iface eth1 inet static
        address 192.168.2.203
        netmask 255.255.255.0
        gateway 192.168.2.1

Der Rest scheint zu funktionieren, daher hat das Problem erstmal Prio.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@alter_Bekannter: Ich bin mir ziemlich sicher, dass es daran liegt, dass beide IPs im selben /24er Netz sind und du via DHCP nicht die Subnetmask so vergibst, dass Adapter eth1 davon ausgeschlossen wird (was du auf der anderen Seite natürlich manuell ebenfalls machen müsstest). Linux ist an der Stelle clever - es hat auch sehr wahrscheinlich nicht der Adapter eth1 geantwortet, sondern der Kernel in Vertretung für den Adapter, weil selbes Netz.

Daher die Aufforderung: Verschiedene /24-Netze.
 

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
  • Thread Starter Thread Starter
  • #20
Also ist das ein dokumentiertes Feature für diese art von Fehlkonfiguration und ich kann mich drauf verlassen das sowas nicht passiert wenn ich den Adaptern unterschedliche Netze zuweise?

In dem fall werde ich dann gleich nochmal probieren die Routing Sachen zu entfernen. Jetzt habe ich ja unterschedliche Netze zugewiesen.

Ergebnis:
Pinging 192.168.2.103 with 32 bytes of data:
Reply from 192.168.2.201: Destination host unreachable.
Reply from 192.168.2.201: Destination host unreachable.
Reply from 192.168.2.201: Destination host unreachable.
Reply from 192.168.2.201: Destination host unreachable.

Erklär mir das.:D

Vielleicht erkunde ich hier auch nur das Gebiet seltsamer Windows Netzwerkbugs.

Unter anderem habe ich ja vor kurzem gelernt das bis einschließlich WIn7 nur einen Samba Verbindung zu jedem Gerät aufbauen kann:
https://superuser.com/questions/95872/sambawindows-allow-multiple-connections-by-different-users

Update:
Okay, sieht nach einem Debian Netzwerk Bug aus. Nach einem Reboot scheints zu tun.

Kurzfassung:
"/etc/init.d/networking restart" führt zu absirden Fehlersituationen wie hier im Thread beschrieben.
Wenn ich raten müsste läge es wohl daran das es nicht alle Netzwerkbezogenen Caches und Konfigurationen Aufräumt.
Wodurch dann der Konfigurationstand super inkonsistent wird und allerlei unberechnbares Verhalten auftritt. Die Lektion die ich daraus ziehe: wenn das Netzwerk sich nicht verhält wie es sollte nach Konfigänderung: erstmal rebooten.
 
Zuletzt bearbeitet:
Oben