Portscans vermeiden Radikalkur

[Metal_Warrior]

@alter_Bekannter: Ich denke, dass das direkt der Kernel übernimmt (weil dort die Sockets gesetzt werden), aber das nicht explizit loggt, weil man das Log nach 10 Minuten schon nicht mehr lesen könnte.

Also nein, bau dir ne minimale iptables-Firewall, dann loggt er. Immerhin WILLST du das ja dann

 

[virtus]

Sollte nicht fail2ban genau das sein, was du suchst?

 

[alter_Bekannter]

Jo, in Kombination mit dem Kernelmod der abgelehnte Verbindungen loggt...

Wo bekomme ich den Nochmal?

Sonst bekomme ich leider:

iptables -A REJECT -j LOG --log-prefix "{prefix das in andere Datei läuft}"
iptables no chain/target/match by that name

Scheint mir irgendwie komisch das verhalten, warum kann ich vordefinierte chains nicht frei nutzen?

 

[Metal_Warrior]

@alter_Bekannter: Du hast keine gültige Chain definiert. REJECT, ACCEPT und DROP sind Spezialtargets, die sind fest und nicht änderbar. Daher baut man sich ja eine (kleingeschriebene) Logging-Chain mit zwei Statements: Log selber und REJECT.

Selbst wenn er dir REJECT hätte umdefinieren lassen, hättest du nie Logs bekommen, weil du append genutzt hast - Ans Ende hinzufügen. Vorher steht aber (gedanklich) "Verwirf jedes Paket". Macht Sinn, oder?

Schau dir mal mein Beispiel nochmal an.

 

[alter_Bekannter]

Ich sehe nicht wie das irgendwas verbessert außer der Anzahl an Logeinträgen.

 

[Metal_Warrior]

@alter_Bekannter: Poste mal dein komplettes Script...

 

[alter_Bekannter]

Dem was ich haben will scheint

iptables -A INPUT -p tcp --dport 1025ort-1 --syn -j LOG --log-prefix iptables:
iptables -A INPUT -p tcp --dport port+1:35000 --syn -j LOG --log-prefix iptables:

Am nächsten zu kommen.

 

[Metal_Warrior]

@alter_Bekannter: Also ich persönlich würde nicht mit --syn arbeiten, weil du damit nur TCP erschlägst, nicht andere Protokolle. UDP willst du üblicherweise aber auch haben...
Abgesehen davon ist dein Range-Statment unsauber bzw. unvollständig, weil ich mir ziemlich sicher bin, dass du auf Port 12 zum Beispiel nichts laufen hast.

Schreib die Firewall so:

1. Allgemeine Sachen abdecken (also established, related, invalid; ICMP)
2. Alle Anfragen, die du explizit erlauben/verbieten willst (z. B. SSH, HTTP, HTTPS, Broadcast...)
3. Monitore alles, was hier noch ankommt
4. Schmeiß alles weg, was hier ankommt

Willst du aber wirklich nur alles loggen, was über Port 1024 liegt, reicht dir eine Zeile:

iptables -A INPUT -p tcp ! --dport 1:1024 -j LOG --log-prefix "iptables: "

Das Ausrufezeichen negiert den direkt darauf folgenden Filterausdruck, in diesem Fall die Portnummer. Insbesondere weil die Ports bis 65535 gehen.

 

[alter_Bekannter]

You do not have permission to view link please Anmelden or Registrieren

stimmte allerdings nicht, Antworten auf Http request werden einem von vielen Seiten auf registered Ports geschickt, was nach meine Verständnis der Seite aber alles auf dynamic Ports gehen sollte.

Also habe ich versucht das zu kürzen, das führte aber nirgendwohin weil die Antworten quasi überll ankamen und wenn ich so schnell einen Arsch voll Ausnahmen finde verwerfe ich die Idee als nutzlos.
Nachdem ich allerdings auf SYN gefiltert habe kamen zumindest http antworten nicht mehr ins Log. Was in sofern Sinn gemacht hat als das eine Verbindung eben nur einmal mit Syn Paketen aufgebaut wird was in dem Fall ja ausgehend auf 80 war also nicht geloggt und wie erwartet.

Daher das Ende bei 35000 das hat keine Bedeutung und wird für Produktiv falls es so weit kommt auf den höchsten sinnvollen Wert geändert, derzeit wohl 49000.

Ohne Platzhalter mit korrigierten Zahlen
iptables -A INPUT -p tcp --dport 1025:1688 --syn -j LOG --log-prefix iptables:
iptables -A INPUT -p tcp --dport 1690:49000 --syn -j LOG --log-prefix iptables:

UDP interessiert mich nicht oder kann man irgendwie mit UDP Anfragen auf Dienste schließen die TCP erwarten?

 

[Metal_Warrior]

You do not have permission to view link please Anmelden or Registrieren

stimmte allerdings nicht, Antworten auf Http request werden einem von vielen Seiten auf registered Ports geschickt, was nach meine Verständnis der Seite aber alles auf dynamic Ports gehen sollte.

Du verwechselst hier grad Server und Client. Die dynamic Portrange kann dir sowas von egal sein, wenn du nach dports (destination ports) filterst. Auch Antworten sind dir egal, weil die frühstückst du über die Status RELATED und ESTABLISHED ab.

Wenn du natürlich die Hälfte der Statements aus meinem Beispiel verwirfst, ist mir schon klar, warum du Probleme hast.

UDP interessiert mich nicht oder kann man irgendwie mit UDP Anfragen auf Dienste schließen die TCP erwarten?

Mitunter. HTTP kann über UDP ausgeliefert werden, und QUIC läuft glaub auch auf 80 bzw. 443.

Und obs dich interessiert oder nicht ist völlig Banane, eine Firewall hat JEDEN Fall abzudecken, weshalb ich dir ja auch oben im Beispiel Traffic ohne Log verworfen habe, und anderen erst nach Logging.


Mal nebenbei: Bei mir läuft ne Firewall nach obigem Schema, die 4 Netze (bald 5) trennt. Ich hab sie im Querschnitt genau so wie oben beispielhaft beschrieben gebaut (nur etwas komplexer), und hab genau null Probleme mit Traffic, den ich nicht haben will. Ich logge recht ausführlich (in ca. 40 versch. Logs), es funktioniert also so wie ichs dir sag.
Poste mal dein GESAMTES Script, dann kann ich da mal drüber korrigieren und optimieren, nicht nur einzelne Snippets - ich weiß nämlich weder, was du davor machst, noch, was du danach machst. Wenn dann irgendwas nicht funktioniert, kann ich dir nur sagen, dass dieses Snippet das tut, was es soll - nicht, ob überhaupt Pakete dort ankommen und welchen State die haben. Das ist Code, keine Konfigurationsdatei.

 

[alter_Bekannter]

Nicht sehr spannend da auf der VM sonst nichts läuft:

Spoiler

Chain INPUT (policy ACCEPT)
target prot opt source destination
fail2ban-ssh tcp -- anywhere anywhere multiport dports ssh
ACCEPT all -- anywhere localhost

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere localhost

Chain fail2ban-ssh (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere

Die Localhost Einträge habe ich glaube ich noch selber hinzugefügt, der Rest kam mit der Installation. Ich gehe mal davon aus das kein Netzwerk dieser Welt localhost traffic netzwerkübergreifend routet.
Außerdem sehe ich keinen Sinn in den Limits, ich habe kein DDoS Problem und wills ganz sicher nichts behandeln was nicht kaputt ist. Unnötige Schritte haben die Tendenz einen später in dne Arsch zu beissen.

Auß0erdem scheitns mir nicht als ob ich da server mit client verwechselt habe, denn der kram ist im Log gelandet. Das Setup ist halt eine Test VM und wenn es auch nicht Standardkonform ist muss man dennoch mit der Realität leben. Siehe zB den filesize Header den keiner jemals setzt und den sich die Browser alle aus dem Arsch ziehen. Oder das man http Verbindungen "schnell" vervollständigen sollte weil Browser sonst ausflippen bei der "autocompletion".

 

[Metal_Warrior]

@alter_Bekannter: Das ist kein Script, das ist die Ausgabe von iptables -l, und ich hab nie verstanden, was daran übersichtlicher sein soll als an einem Script. Bestenfalls für spezielle Suche nach einem einzigen Fehler, und dazu müsste man das Script kennen. Wenn ich das grad aber richtig interpretiere (ja, ich arbeite damit eigentlich nicht), blockst du keinen Traffic. Was nützt dir das dann genau?

Und nein, Localhost-Traffic kann nicht geroutet werden, weil die IP 127.0.0.1 immer auf die eigene Maschine verweist. Ein Routing wäre sinnfrei.

Deine Verwechslung bezieht sich nicht auf das Log, sie bezieht sich auf dein Verständnis der Funktion der Firewall. Du kannst alle Ports eingehend blocken, die du nicht explizit erlaubst (d. h. REJECT auch auf die dynamic Ports), weil ausgehender Traffic davon nicht betroffen ist. Ob du loggst oder nicht spielt dann da keine Rolle, es sollte an den dynamics sowieso nie was eingehend sein.

 

[alter_Bekannter]

Unter etc ist nichts von iptables wo finde ich mehr?

Geraten würde ich sagen das setup verteilt sich durch die unendlichen weiten der initscripte.

Den Kram in memory only abzuhandeln macht ja auch irgendwie sin bei den ganzen temporären Einträgen die dsa so planmäßig durchfließen können.

 

[Metal_Warrior]

@alter_Bekannter: Sag bloß, du hast alle Befehle per Hand in die Konsole eingetippt...

 

[alter_Bekannter]

alle? Eher einen und history. Das ich dafür ein script machen kann weiss ich auch.

Ach, ne, waren 2, die localhost Dinger.

 

[Metal_Warrior]

@alter_Bekannter: Ich hab nicht umsonst von vornherein immer Script geschrieben und das Ganze mit #!/bin/bash eingeleitet. Das Script läuft am Systemstart einmal durch und ist danach fertig - du kannst aber jederzeit was dran ändern und es nochmal durchlaufen lassen, dann wird erst alles alte zerstört und die Firewall from scratch wieder aufgebaut. Grund: Den Reboot überleben temporäre Einstellungen nicht, so wie deine Konsolenspielereien. Das ist aber NICHT SINN DER SACHE! Außerdem ist Debugging an diesem Beispiel nahezu unmöglich.

Du willst was ausprobieren? Fein, an einer bestehenden Firewall, wenn man sich auskennt, mit zwei oder drei Befehlen - klar, kann man machen, hab ich auch schon gemacht. Dazu muss man sich in ihr aber wirklich auskennen. Du bist am ANFANG, du kennst nicht einmal die Basisfunktionen und die Vorgehensweise von iptables. Dann arbeite IMMER from scratch. Du wärst längst fertig mit allem und würdest auch alles verstehen, wenn du einfach nur mein Beispiel kopiert und angepasst hättest. So verschwendest du jetzt deine und meine Zeit.

Zum letzten Mal: Bau ein Script, überlegt dir die Firewall, überleg dir, wann du wo loggen möchtest, schreib alles da rein, auch Änderungen, und führ es am Ende einmal aus. Dann schau nach, was jetzt läuft und was nicht und poste das vollständige Script, deine Beobachtungen und deine Fragen dazu dann hier. DANN kann ich dir helfen. So, wie du gerade arbeitest, nicht.

 

[alter_Bekannter]

Spoiler

#!/bin/bash
# Firewall setup


# ==== Pre-Setup ====

# Deleting existing rules
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X


# ==== Chain Setup ====

# Add new custom chains
#iptables -N log_reject
iptables -N log_drop
iptables -N investigate

# Feed log_reject chain
#iptables -A log_reject -m limit --limit 10/day -j LOG --log-prefix "[IPTables] REJECT: " --log-level 7
#iptables -A log_reject -j REJECT

# Feed log_drop chain
#iptables -A log_drop -m limit --limit 10/day -j LOG --log-prefix "[IPTables] DROP: " --log-level 7
iptables -A log_drop -j DROP

# investigate suspicious connections
iptables -A investigate -p tcp ! --dport 1689 -j LOG --log-prefix "iptables: " #fail2ban stuff
iptables -A investigate -p tcp --dport 1689 -j ACCEPT #the one i actually want

# ==== Feed main chains ====

# Always accept loopback traffic
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

# Snatch invalid traffic
iptables -A INPUT -m state --state INVALID -j log_drop

# Reject ISATAP traffic without logging
iptables -A INPUT -p 41 -j REJECT

# Allow established connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Specific rules
iptables -A INPUT -p tcp ! --dport 1:1024 -j investigate


# Reject everything else without logging
iptables -A INPUT -j REJECT


# ==== This movie is over ====
exit 0

Limit habe ich rausgenommen weil ich nicht verstehe was es tut. Wie wird da gezählt? Alle Verbindungen auf Zielport X wären ja vollkommen uninteressant und wo wird festgelegt welche IP was sind die defaults von limit? Alles auf die Regel und IP wäre wohl auch unpassend so wie es aussieht.

 

[Metal_Warrior]

Limit habe ich rausgenommen weil ich nicht verstehe was es tut. Wie wird da gezählt? Alle Verbindungen auf Zielport X wären ja vollkommen uninteressant und wo wird festgelegt welche IP was sind die defaults von limit? Alles auf die Regel und IP wäre wohl auch unpassend so wie es aussieht.

Limit verhindert, dass 1000 Verbindungsversuche binnen 2 Minuten 1000 Logeinträge produzieren, indem es nach $LIMIT pro $ZEITEINHEIT einfach nicht mehr loggt. Defaults gibts da nicht, denn du legst ja eines fest, wenn du die Option nutzt.

Ich arbeite mich mal durch dein Script durch und schreib mal meine Kommentare rein (bunt geht leider nicht):

Spoiler

[src=bash]#!/bin/bash
# Firewall setup


# ==== Pre-Setup ====

# Deleting existing rules
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X


# ==== Chain Setup ====

# Add new custom chains
#iptables -N log_reject
iptables -N log_drop
iptables -N investigate

# Feed log_reject chain
#iptables -A log_reject -m limit --limit 10/day -j LOG --log-prefix "[IPTables] REJECT: " --log-level 7
#iptables -A log_reject -j REJECT
##### Für die log_reject chain gibt es einen guten Grund: Du möchtest wissen, wenn ein legitimer Verbindungsversuch fehlschlägt - sie ist dein Debugging. Außerdem kannst du sie nutzen, um Fail2Ban einen Portscan erkennen zu lassen: Werden aufsteigend von einer Quell-IP Ports angefragt, die rejected werden, siehst du das hier im Log. Und zwar sofort. Bevor Port 22 (SSH) drankommt, kann Fail2Ban bereits die IP direkt sperren.

# Feed log_drop chain
#iptables -A log_drop -m limit --limit 10/day -j LOG --log-prefix "[IPTables] DROP: " --log-level 7
iptables -A log_drop -j DROP
##### Mit dem Auskommentieren des Loggings wird diese Chain nutzlos, weil man gleich mit DROP arbeiten kann. Vermehrte Drops von einer Quell-IP auf einen dedizierten Port können aber ein gezielter Angriff auf einen möglicherweise für maligne Pakete anfälligen Dienst sein. Insofern würdest du sicher gerne auch diese IP direkt killen lassen, allerdings nach Möglichkeit schon viel früher als die normalen Portscans.

# investigate suspicious connections
iptables -A investigate -p tcp ! --dport 1689 -j LOG --log-prefix "iptables: " #fail2ban stuff
iptables -A investigate -p tcp --dport 1689 -j ACCEPT #the one i actually want
##### Das hier ist grober Unsinn. Zuerst schiebst du alles in die Chain, um es dann nachträglich nochmal zu sortieren, nach zwei Kriterien, wovon das wesentlich häufiger auftretende (NOT-dport-1689) danach wieder zurück nach INPUT geschoben wird, um dort weiter bearbeitet zu werden. Das ist unheimlich langsam und rechenintensiv. Das macht man anders, siehe unten.


# ==== Feed main chains ====

# Always accept loopback traffic
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

# Snatch invalid traffic
iptables -A INPUT -m state --state INVALID -j log_drop

# Reject ISATAP traffic without logging
iptables -A INPUT -p 41 -j REJECT

# Allow established connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Specific rules
iptables -A INPUT -p tcp ! --dport 1:1024 -j investigate
##### Hier schiebst du übrigens nur die Destination-Ports zwischen 1 und 1024 in die investigate-Chain, die hinterher den Destination-Port 1689 akzeptieren soll. Der wird da aber nicht hingeschoben, das Statment oben ist also niemals wahr und wird nie irgendwas durchlassen.

# Reject everything else without logging
iptables -A INPUT -j REJECT


# ==== This movie is over ====
exit 0[/src]

Ich schreib das mal ins Reine:

Spoiler

[src=bash]#!/bin/bash
# Firewall setup


# ==== Pre-Setup ====

# Deleting existing rules
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X


# ==== Chain Setup ====

# Add new custom chains
iptables -N log_reject
iptables -N log_drop
iptables -N f2b_preselection
##### Fail2Ban soll alle Quell-IPs mit "-j DROP" in diese Chain eintragen, die in der Chain log_drop zehn Mal geloggt wurden.
##### Ja, das geht effizienter, wenn du sie alle direkt an Stelle [1] statt dem dort stehenden Statements in die INPUT-Chain schreibst, aber da wird das Debugging etwas schwieriger und die Fehleranfälligkeit steigt.
iptables -N f2b_postselection
##### Fail2Ban soll alle Quell-IPs mit "-j REJECT" in diese Chain eintragen (mit -I, für "insert" = 'Am Anfang reinschreiben'), die in der Chain log_reject zehn Mal geloggt wurden. Damit blockierst du die portscannende IP direkt für die eigentlich offenen Ports.

# Feed log_reject chain
iptables -A log_reject -m limit --limit 10/day -j LOG --log-prefix "[IPTables] REJECT: " --log-level 7
iptables -A log_reject -j REJECT

# Feed log_drop chain
iptables -A log_drop -m limit --limit 10/day -j LOG --log-prefix "[IPTables] DROP: " --log-level 7
iptables -A log_drop -j DROP

# Accept legitimate traffic
iptables -A f2b_postselection -j ACCEPT


# ==== Feed main chains ====

# Always accept loopback traffic
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

# Block directly targeted attacks
iptables -A INPUT -j f2b_preselection ##### DAS HIER IST STELLE [1] #####
##### Hier wandern alle Pakete rein, die nicht auf das Loopback-Device laufen. Hat Fail2Ban in die Chain IPs eingetragen, und trifft ein eingehendes Paket auf diese IP zu, wird es automatisch verworfen. Alle Pakete, die nicht auf eine eingetragene IP verweisen, werden automatisch wieder zurück an diese Stelle in die INPUT-Chain geschickt. Effektiv ist es ein ausklappbares Ruleset an dieser Stelle. Die beiden Jumps (in die f2b_preselection und wieder zurück in die INPUT) verlangsamen die Firewall hier ein bisschen, aber es ist gerade in größeren Strukturen leichter überblickbar. Vor Allem hat Fail2Ban dann eine Chain, in der es nach Herzenslust rumschreiben kann, ohne dir versehentlich den Rest deiner Firewall zu zerschießen.

# Snatch invalid traffic
iptables -A INPUT -m state --state INVALID -j log_drop

# Reject ISATAP traffic without logging
iptables -A INPUT -p 41 -j REJECT

# Allow established connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Specific rules
iptables -A INPUT -p tcp --dport 1689 -j f2b_postselection
##### Du willst nur Anfragen an diesen einen Port durchlassen. Fail2Ban soll aber trotzdem noch testen, ob die durchzulassende Qell-IP nicht eingentlich nur nen Portscan durchführen will, und bei positivem Befund einen "falschen" Verfügbarkeitsstatus des Ports rückmelden.

# Reject everything else with logging
iptables -A INPUT -j log_reject
##### Irgendwoher muss Fail2Ban ja wissen, wer so alles nicht bediente Zielports anfrägt - und das läuft über das Log.

# ==== This movie is over ====
exit 0[/src]