Wenn ich die INPUT-Default-Policy auf DROP setzte, hängt sich der Server ausserdem beim Booten ewig bei dieser Meldung
1 2 | iscsi: registered transport (tcp) iscsi: registered transport (user) |
auf, bevor er dann doch verfügbar ist.
(Themenstarter)
Anmeldungsdatum: Beiträge: 147 |
Wenn ich die INPUT-Default-Policy auf DROP setzte, hängt sich der Server ausserdem beim Booten ewig bei dieser Meldung
auf, bevor er dann doch verfügbar ist. |
||||||||
Anmeldungsdatum: Beiträge: 603 |
Wenn ich ehrlich bin, verstehe ich absolut nicht, was Du damit meinst, dass Du auf einen Port "draufkommst". Man kann nicht auf einen Port "draufkommen", ein Port ist nicht interaktiv, der kommuniziert nicht mit Dir, das ist NUR ein Adressmerkmal. Und wenn auf Deinem System im Kernel irgend ein Paket ankommt, adressiert auf einen bestimmten Port, wird das Paket einfach verworfen, wenn der Kernel dafür keinen Abnehmer findet, eben weil kein Dienst auf diesen Port lauscht. Und natürlich müssen auf dem System (Provider), wo Dein Server läuft, ja alle Ports offen sein, wie sollten Pakete aus dem WWW sonst an Deinem Server ankommen? Also, am Interface (und auch im Kernel) Deines Servers muss so ein Paket immer ankommen. Und wenn Du wissen willst, ob solche Pakete verworfen werden, dann schreib ne Log-Rule im Paketfilter, dann kannst Du das live beobachten. |
||||||||
(Themenstarter)
Anmeldungsdatum: Beiträge: 147 |
Soweit ich weiss sollte es beim telnet an einen bestimmen Port im Hintergrund den TCP-Handshake geben. Gelingt dieser, "ist der Port auf". Bei einem geschlossenen Port erhalte ich ein ICMP-Destination Unreachable zurück. Bei einem generellen INPUT-DROP würde ich aber erwarten, dass auch das allererste TCP-Segment mit gesetztem SYN-Flag zum Handshake verworfen wird und der Anfragesteller deshalb in ein Timeout läuft. VG |
||||||||
Anmeldungsdatum: Beiträge: 13931 |
|||||||||
Anmeldungsdatum: Beiträge: 603 |
Dann solltest Du nicht ausschließen, dass Du etwas entscheidendes nicht weisst.
"Sollte" und "würde" ist jedenfalls die falsche Grundlage für Rückschlüsse. Für verworfene TCP-Paket wird kein RST gesendet, wenn der Paketfilter aktiv ist, weil davon ausgegangen wird, dass der Paketfilter das macht ... was er bei Dir allerdings nicht tut. Das bedeutet aber nicht, dass Du auf den Port draufkommst, sondern nur, dass der Kernel die Pakete kommentarlos verwirft und Dein Telnet auf der anderen Seite ohne Antwort davon nichts mitkriegt und deswegen wartet und neue Pakete sendet ... weil es ja auch sein könnte, dass das Paket im WWW verloren gegangen ist. Das ist auch einer der Ursachen, die zur völlig unnötzen Belastung des Netzes und lokaler Ressourcen führen, weil nur Ahnungslosigkeit unreflektiert Drops durchführt. Wie ich sagte, schreib ne log-Regel und sende ein 'reject with'... und Du wirst feststellen, dass alles läuft, wie es sein muss. In der jetztigen Form arbeitet es jedenfalls exakt so, wie Du es festgelegt hast. Mit aktiven Paketfilter bin ich "auf dem Port" .... und weil ein Drop den Anrufer im Unklaren lässt, versucht der Anrufer es immer weiter... bis ich es mit strg-c abbreche tomspc:~ $ telnet 10.0.1.29 80 Trying 10.0.1.29... ^C Ohne Paketfilter sender der Kernel sofort ein RST. tomspc:~ $ telnet 10.0.1.29 80 Trying 10.0.1.29... telnet: Unable to connect to remote host: Connection refused |
||||||||
(Themenstarter)
Anmeldungsdatum: Beiträge: 147 |
Interessant: bei einem Aufruf per
erhalte ich folgenden Mitschnitt:
(4.3.2.1 ist sei die mir vom Provider zugewiesene IP meines Routers, wobei 1.2.3.4 die öffentliche IP des in der Cloud stehenden Servers ist) Telnet scheint dabei den Handshake erfolgreich zu erledigen und lässt ich anschliessend Daten senden:
Beim Portscan per
aber ich sehe kein einziges Packet im Dump :-/ |
||||||||
Anmeldungsdatum: Beiträge: 13931 |
|||||||||
Anmeldungsdatum: Beiträge: 603 |
|||||||||
Anmeldungsdatum: Beiträge: 603 |
vertan |
||||||||
(Themenstarter)
Anmeldungsdatum: Beiträge: 147 |
Der sichtbare Dump ist vom Telnet-Versuch. Da die Kommunikation unidirektional ist (wie es mit Packet-Filter auch sein sollte) wird immer wieder das gleiche Segment gesendet. Es scheint alles zu arbeiten wie gewünscht. Unverständlich ist mir der Hinweis von Telnet (escape character...), der dafür steht dass der Handshake zustande kam (was er ja aber laut Dump nicht ist). Wieso der nmap-port-scan erfolgreich ist und ich dabei überhaupt keine Anfrage sehe ist mir unerklärlich. |
||||||||
Anmeldungsdatum: Beiträge: 990 |
Telnet ist nicht besonders clever. Setze es auf einen seriellen Link und du erhältst dieselbe Meldung, obwohl nicht einmal ein Kabel angeschlossen ist. Edit: Zitat korrekt gekennzeichnet. |
||||||||
(Themenstarter)
Anmeldungsdatum: Beiträge: 147 |
Update: Ich habe jetzt gleichzeitig per Wireshark auf dem lokalen Host und tcpdump auf dem Server getrackt, während ich je ein telnet und ein nmap auf den Port abgesetzt habe. Die Pakete wurden nicht beantwortet, der Filter arbeitet also offensichtlich wie erwartet. Ich frage mich, wieso telnet, nc, und nmap die Ports aber als erreichbar deklarieren.... ?! Aber das Primär-Problem scheint damit geklärt. |
||||||||
Anmeldungsdatum: Beiträge: 13931 |
|||||||||
Anmeldungsdatum: Beiträge: 13931 |
|||||||||
(Themenstarter)
Anmeldungsdatum: Beiträge: 147 |
Die Erste Ausgabe vom tcpdump auf dem Server war schlicht leer (vielleicht ist das Packet verworfen worden). Beim 2. Versuch hatte ich dann doch die Anfrage, wie erwartet aber keine Antwort auf dem Server gesehen. |