Hallo
bei Kunden habe ich folgendes Problem zugriff von Extern auf SFTP:
Regel:
Qulle:Gruppe --> Ziele Interner Server Dienst: SFTP Aktion: Accept Zone DMZ3
Mit dem zuerst angeleten Gruppenmitglied funktioniert der Zugriff auf den Zielserver einwandfrei.
Ich sehe im Livelog eine Grün hiterlegten eintrag das die Regelgezogen hat. Nun soll der Zugriff vom
einen weiteren Gruppenmitglied erfolgen. Da sehe ich im Live Log keinen Eintrag zu diesem Zugriff.
Und der Zugriff schlägt fehl.
Per TCPDUMP habe ich aber gesehnen das die Anfrage an die Firewall gestellt wird.
Gruß Ove
Kein Eintrag im Livelog
Moderator: Securepoint
Sehen Sie denn im Livelog ein geDROPtes Paket?
TL;DR: Rufen Sie einfach an und halten Sie die Zugangsdaten für die Firewall bereit.
Wenn nicht: prüfen Sie, ob das Paket überhaupt an der FW ankommt:
Möglichkeit 1: Nichts kommt an -> fertig
Möglichkeit 2: SYN-Paket ist zu sehen -> weiter gehts
Möglichkeit 3: SYN+SYNACK zu sehen -> fertig
die Reihenfolge beim Portforwarding in den iptables ist (grob gesagt):
nat-Table/PREROUTING-Chain -> filter-Table/FORWARD-Chain
Um zu sehen, an welcher Stelle das Paket verloren geht, prüfen Sie zuerst die nat/PREROUTING-Chain:
Die erste Spalte ist die Anzahl der Pakete, die von dieser Regel gematcht wurden. Steht da "0"... nunja... dann hat das Paket andere Eigenschaften, als Sie annehmen, dass es hat.
Sollte diese Regel schonmal gematcht haben, geht es weiter mit der filter/FORWARD-Chain:
Gleiches Spiel... steht in Spalte 1 eine "0" ist die FW-Regel inkorrekt.
Traf diese Regel hingegeben zu, schauen Sie mit tcpdump auf dem Internen Interface, ob das Paket da rausgeht:
gibt vier Möglichkeiten:
1. Nichts zu sehen -> passt nicht mit der matchenden FORWARD-Regel zusammen -> EVIL THINGS ARE HAPPENING -> Appliance mit Weihwasser besprühen -> fertig
2. ARP-Requests zu sehen -> der Server ist "aus" oder auf Layer 2 unsichtbar -> fertig
3. SYN-Pakete () zum Server sichtbar, kein SYNACK ([S.]) sichtbar -> der Server antwortet nicht -> fertig
4. SYN + SYNACK sichtbar -> weiter gehts
Es kommt also ein Antwortpaket an der FW an, aber die Verbindung kommt trotzdem nicht zustande. Es gilt zu prüfen, wo das Paket hin geroutet wird. Jetzt wird es anstrengend...
Da steht im Idealfall, dass über das Interface geroutet wird, über dass die Verbindung auch rein kam.
Hier muss geprüft werden, ob der Server (entweder die Quell-IP der Verbindung ODER die Interne IP des Servers [unwahrscheinlich]) vielleicht irgendwo anders hin geroutet wird.
Hier sind die eingerichteten Rule-Routen und Source-Routen hinterlegt. Wohin geroutet wird, kann man mit folgendem Befehl geprüft werden. Die <TABLE-ID> ist dabei die letzte Zahl in der jeweiligen Zeile (ip rule).
Finden Sie auf diese Art und Weise auch keinen Fehler bleibt nur noch die EVIL TRACE MAGIC!!!1111
Dazu aktivieren Sie das Tracing der Pakete mittels
(Tauschen Sie das "-s" gegen ein "-d" sehen Sie entsprechend die Antwort-Pakete)
ACHTUNG: Vergessen Sie die Einschränkung auf die Quell-IP oder passiert da zu viel, wird das Syslog sehr voll werden...
Der Befehl um das Tracing zu deaktivieren ist:
Bei aktiviertem Tracing wird für jedes (!) Paket, welches auf die TRACE-Regel matcht jede (!) durchlaufene iptables-Regel ins Syslog geschrieben. Das ist viel Output. Sehr viel. Aber spätestens dort sieht man dann, an welcher Stelle das Paket verloren geht oder aus welchem Interface es fälschlicherweise geroutet wird.
TL;DR: Rufen Sie einfach an und halten Sie die Zugangsdaten für die Firewall bereit.
Wenn nicht: prüfen Sie, ob das Paket überhaupt an der FW ankommt:
Code: Alles auswählen
# tcpdump -i <EXTERNES-INTERFACE> -nnp host <IP-DER-GEGENSTELLE>
Möglichkeit 2: SYN-Paket ist zu sehen -> weiter gehts
Möglichkeit 3: SYN+SYNACK zu sehen -> fertig
die Reihenfolge beim Portforwarding in den iptables ist (grob gesagt):
nat-Table/PREROUTING-Chain -> filter-Table/FORWARD-Chain
Um zu sehen, an welcher Stelle das Paket verloren geht, prüfen Sie zuerst die nat/PREROUTING-Chain:
Code: Alles auswählen
# iptables -t nat -nvL PREROUTING | grep <INTERNE-IP-DES-SERVERS>
Sollte diese Regel schonmal gematcht haben, geht es weiter mit der filter/FORWARD-Chain:
Code: Alles auswählen
# iptables -t filter -nvL FORWARD | grep <INTERNE-IP-DES-SERVER>
Traf diese Regel hingegeben zu, schauen Sie mit tcpdump auf dem Internen Interface, ob das Paket da rausgeht:
Code: Alles auswählen
# tcpdump -i <INTERNES-INTERFACE> -nnp host <INTERNE-IP-DES-SERVERS>
1. Nichts zu sehen -> passt nicht mit der matchenden FORWARD-Regel zusammen -> EVIL THINGS ARE HAPPENING -> Appliance mit Weihwasser besprühen -> fertig
2. ARP-Requests zu sehen -> der Server ist "aus" oder auf Layer 2 unsichtbar -> fertig
3. SYN-Pakete () zum Server sichtbar, kein SYNACK ([S.]) sichtbar -> der Server antwortet nicht -> fertig
4. SYN + SYNACK sichtbar -> weiter gehts
Es kommt also ein Antwortpaket an der FW an, aber die Verbindung kommt trotzdem nicht zustande. Es gilt zu prüfen, wo das Paket hin geroutet wird. Jetzt wird es anstrengend...
Code: Alles auswählen
# ip route get <IP-DER-GEGENSTELLE>
Code: Alles auswählen
# ip route
Code: Alles auswählen
# ip rule
Code: Alles auswählen
# ip route show table <TABLE-ID>
Dazu aktivieren Sie das Tracing der Pakete mittels
Code: Alles auswählen
# iptables -t raw -I PREROUTING -s <IP-DER-GEGENSTELLE> -j TRACE
ACHTUNG: Vergessen Sie die Einschränkung auf die Quell-IP oder passiert da zu viel, wird das Syslog sehr voll werden...
Der Befehl um das Tracing zu deaktivieren ist:
Code: Alles auswählen
# iptables -t raw -F PREROUTING