• 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.

Portscans vermeiden Radikalkur

alter_Bekannter

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

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
Gibts eine etablierte Lösung um sagen wir eine IP die X anfragen an unbelegte Ports stellt mal für die nächsten Y Stunden einfach mal komplett mit Schweigen zu strafen?

Also auf nichts mehr reagieren egal was angefragt wird. Ich muss wie in einem anderen Thread angedeutet was laufen lassen das einfach nur unter aller Sau entwickelt ist(was es ist kann ich nicht sagen wegen NDA). Also muss ich das System drumherum abschotten wo es nur geht. Aber die Anfrage sollte ja recht trivial sein, dafür gibts sicher schon was.

Notfalls schreibe ich selber etwas großflächig auf ports lauscht und iptables pflegt.

Sollte in C++ einigermaßen überschaubar sein. Würde ich aber dennoch gerne vermeiden, Rad nicht neu erfinden und so.
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.561
Naja, ich kann dir nur so viel sagen, du mußt ja trotzdem die Anfrage "bearbeiten", selbst wenn du sie nur blockst/schweigst - man kann das Netzwerkpaket ja nicht einfach magisch "verwerfen". Es gab doch auch vor einiger kurzer Zeit diese riesen DDOS Attacke, da wurde mit Sicherheit auch gesperrt - aber die (Filter-)Hardware ist dann dafür in die Knie gegangen, soweit ich das verstanden hatte.

Also wäre wohl ein dedizierter (Firewall) Filter mit DDOS-Protection, bei zu vielen Anfragen einer IP das beste, dafür gibt es bestimmt auch etwas... die vom Rest des Systems abgekoppelt wäre und sich ausschließlich um das Problem kümmert das du schilderst. Vielleicht auch nen PI dazwischen hängen/darauf forwarden, wenn du das "daheim" mal probieren willst und alle möglichen Ports/Anfragen von außen auf das Gerät zulassen, in einer Fritzbox kann man zum Beispiel ein Gerät komplett offen setzen, damit du erkennen kannst wie nach was gescannt wird um ein paar Regeln zu erstelllen kannst und was für Pakete da gesendet werden bzw. Anfragen.

Die Pakete mitschneiden kann man wohl auch mit diverser Software, aber da ich nicht so der Admin bin, kann ich dir da nur Listen von Github empfehlen (Edit: https://github.com/n1trux/awesome-sysadmin) bzw : https://github.com/n1trux/awesome-security
 
Zuletzt bearbeitet:

alter_Bekannter

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

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
  • Thread Starter Thread Starter
  • #3
Es geht auch nicht um DDoS protection, das ich damit keine eingehende Bandbreite spare ist mir klar.;) (Und die ausgehende ist mir auch egal, es ist eben nur sinnlos bis kontraproduktiv die requests noch zu beantworten.)

Deswegen habe ich ja gesagt das es um ein schlechte Anwendung geht.(Die ich damit etwas weiter schützen möchte indem ich den Port effektiv zu einem zusätzlichen Passwort mache...)
Wie stark 4 Stellen schüützen könne wenn man nur genug Kontrolle hat sieht man ja bei Banken.

Ich kann die Angreifen zwar nicht identifizieren, aber dafür gebe ich ihnen noch weniger Infos. Mal abgesehen davon das eh keiner gezielt danach sucht.
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.561
Also auf Anwendungsebene, das wohl einfachste wäre, die Anwendung einfach nicht antworten zu lassen, ehe nicht ein Schlüssel gesendet wird, alles andere wird ignoriert so lange sich die Gegenstelle nicht eindeutig identifiziert hat als "valider User". Und vielleicht gleich IP Ranges zu sperren, die nicht in Frage kommen. Fällt mir spontan ein.
 

alter_Bekannter

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

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
  • Thread Starter Thread Starter
  • #5
Wie kommst du auf die Idee das es rentabel wäre das in Frage kommende Programm zu ändern?

Plot twist:
Es hat schon eine Loginmaske.

Das Problem an der ist halt das ich mir (zugegebenermaßen leicht übertrieben ausgedrückt) nichtmal sicher bin ob man wirklich ein Passwort eingeben muss.
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.561
Ich sage nicht das deine anderen Schutzmechanismen nicht effektiv oder sinnvoll sein könnten. Ich wollte dir nur eine Idee geben wie man es auf Anwendungsebene machen könnte. ;)
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
Du suchst sowas wie fail2ban.

Dazu kann ich dir leider nicht viel sagen, weil die Dienste, die ich so ins Netz lasse, so paranoid abgeschottet sind, dass Portscans eigentlich nur OpenVPN und SSH (jeweils mit Keyauthentifikation und eigener CA) finden, der Rest ist per iptables teils auf wenige Subnetze im Internet beschränkt und rejected jedes Paket eines $CRIMINAL_STATE_IP_SUBNET.
 

alter_Bekannter

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

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
  • Thread Starter Thread Starter
  • #10
Ich finde keine Möglichkeit das logging von iptables auf abgelehnte Verbindungen zu beschränken. Wenn ich im Browser versuche einen falschen Port anzufragen bekomme ich zu schnell eine Antwort das da nix ist also wird das System wohl aktiv und lehnt ab. Warum kann man das nicht loggen?

Oder in anderen Worten muss ich wirklich erst die ranges für reject eintragen um anschließend darin zu suchen?

Edit:
Ich denke ich hab die Logik jetzt kapiert:

1. Portranges in iptables zum loggen definieren
2. das angelegte Log mit fail2ban auswerten
3. künftig für Zeitraum X alle Verbindungen dieser IP's als banaction von fail2ban mit iptables rejecten

Eigentlich simpel.

iptable Regeln zum loggen:
iptables -A INPUT -p tcp --dport 1025:port-1 -j LOG --log-prefix iptables:
iptables -A INPUT -p tcp --dport port+1:35000 -j LOG --log-prefix iptables:
 
Zuletzt bearbeitet:

sia

gesperrt

Registriert
26 März 2015
Beiträge
5.931
Ort
FFM (NSFW)
@alter_Bekannter: korrekt. Ab Version 0.9 kann fail2ban auch das systemd-Journal auswerten.

Ich würde allerdings zusätzlich den Filter [kw]-m state --state NEW[/kw] hinzufügen (loggt nur die ersten SYN-Pakete), das reduziert die Anzahl an Logeinträgen bei hohem Traffic drastisch. Aufpassen, dass du die Logs auch wegrotierst, sonst läuft irgendwann /var voll…

Du möchtest ebenso auch alle Verbindungen an geschlossene Ports DROPpen und nicht REJECTen.

Hier noch eine Möglichkeit, Portscans zu erkennen: http://www.kworx.de/portscans-iptables-protokollieren/

Wenn du das "vor" fail2ban abfängst, also mit Firewall-Regeln, ist es leichter. Dann hast du nicht irgendwann hunderttausende geblockte IPs von irgendwelchen Botnetzen, sondern deren Traffic kommt einfach nicht an.
 

alter_Bekannter

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

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
  • Thread Starter Thread Starter
  • #12
Nein nach weiterer Überlegung bin ich zu dem Schluss gekommen das rejecten besser ist. Dann siehts nach einem regulären unbenutzen Port aus.

Gibts denn jetzt eigenltich wirklich keinen Weg direkt nur zu loggen was vom System schon rejected wurde? Wäre halt wesentlich einfacher, so muss ich die Prortrange stark beschränken wegen Antworten auf selbst gestellte anfragen.

Problem mit der stateprüfung:
Macht testen schwerer...

Aber SYN war in der tat eine gute Idee um die Menge false psoitives drastisch zu reduzieren. Dadurch werden antworten auf eigene requests nicht mehr geloggt.
 
Zuletzt bearbeitet:

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
So, wie du loggst, ist die Festplatte schneller voll als du schauen kannst. Sowas muss man beschränken. Außerdem hast du mehrere Optimierungs-Optionen. Ich schreib dir da mal ein Beispiel:

[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

# 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


# ==== 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 -i eth0 -p tcp -dport 22 -j ACCEPT
iptables -A INPUT -i eth0 -p udp -dport 80 -j log_reject
...

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


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

Haupt-Interesse sollten für dich die Custom Chains im Chain Setup sein. Du kannst beliebige eigene Chains erstellen, so hältst du die Wege für Pakete kurz und die Firewall effizient. Will ich loggen, schiebe ich die zu loggenden Pakete in eine eigene Chain. Da kann ich dann von hunderten Regeln die Pakete sammeln und loggen, mit nur einem einzigen Statement. INVALID-Pakete sollten grundsätzlich gedroppt werden, denn die dürften gar nicht ankommen (zum Beispiel ein TCP teardown ohne vorherige bestehende Verbindung). Dort zu rejecten macht keinen Sinn, denn die Anfrage ist illegitim, der Gegenüber wird eine Antwort gar nicht verarbeiten können. Sonst sollte man natürlich IMMER rejecten, sofern nicht ein starkes Missverhältnis zwischen Up- und Downloadgeschwindigkeit und die Gefahr eines DDoS gegeben ist.

Letztlich musst du auch nicht (wie phre4k vorgeschlagen hat) von jedem einzelnen Paket das Statement "NEW" tausende Male prüfen, wenn du alle nicht-NEW-Pakete gleich zu Beginn abfrühstückst und zulässt bzw. droppst. Dann arbeitet deine Firewall nämlich nur noch NEW-Pakete ab und wendet die Regeln auf diese an, was die Sache auch viel schneller macht. Verbindungsaufbau ist schließlich nur einmal, egal wie viele Daten fließen. Außerdem ist meineswissens die Prüfung des Packet State vergleichsweise langsam gegenüber anderen Filterregeln (input interface, IP, Destination Port etc.), daher willst du das so selten als irgend möglich prüfen.

Die Logging-Line 21 erklär ich dir mal kurz noch:
Der in Zeile 17 hinzugefügten Chain log_reject wird als erstes Element hinzugefügt, dass für 10 spezifische Ereignisse pro Tag (also 10 gleiche Verbindungsanfragen innerhalb von 24 Stunden) geloggt wird, alle weiteren Vorkommnisse fallen unter den Tisch. Dabei wird das Syslog bedient, und jede geloggte Zeile bekommt ein "[IPTables] REJECT: " vorangestellt. So kannst du dann hübsch mittels rsyslog filtern und in eigene, spezifische Logdateien schreiben lassen. Ich weiß nicht, ob man fail2ban auf eigene Chains umbiegen kann, sollte aber sicher irgendwie möglich sein. So könntest du auch weiter filtern (z. B. erst rejecten, bis fail2ban anschlägt, dann direkt droppen und diesen drop auch loggen). Damit bist du umfassend informiert, was deine Firewall so treibt. Natürlich kannst du auch ACCEPTs loggen, Prinzip identisch.

P.S.: Der Grund, warum ich 10 Anfragen pro Tag loggen ließe, ist, dass das in meinen Augen für ein externes Interface nach Angriff aussähe, und ich ab dieser Schwelle Fail2ban eingreifen lassen würde. Ab dem Eingriff brauch ich erstmal kein weiteres Logging mehr.
 
Zuletzt bearbeitet:

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@alter_Bekannter: Dann lies mal nochmal.

Wobei, ich erklärs dir, das mit den Chains ist nicht ganz so trivial, wenn mans nicht erklärt bekommt.

Ein eintreffendes Paket (Status: NEW, Interface: eth0, Protokoll: UDP, Dest-Port: 80) wandert sofort in die INPUT-Chain. Dort trifft es (ich bearbeite mal den obigen Fall) auf das erste Statement:

iptables -A INPUT -i lo -j ACCEPT
Test nach Interface lo (localhost) schlägt fehl, daher weiter in der Chain:

iptables -A INPUT -m state --state INVALID -j log_drop
Paket ist nicht INVALID, sondern NEW. Weiter:

iptables -A INPUT -p 41 -j REJECT
Paket ist keine ISATAP-Anfrage, also weiter:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Paket ist NEW, also weiter:

iptables -A INPUT -i eth0 -p tcp -dport 22 -j ACCEPT
Paket kommt an eth0 an, ist aber UDP, daher weiter:

iptables -A INPUT -i eth0 -p udp -dport 80 -j log_reject
Paket kommt an eth0 an, ist UDP, geht an den Port 80, also ein vollständiger Match auf den Test. Auszuführende Aktion ('jump'): Paket in die Chain log_reject verschieben. Dort trifft es direkt auf:

iptables -A log_reject -m limit --limit 10/day -j LOG --log-prefix "[IPTables] REJECT: " --log-level 7
Prüfung: Ist ein derartiges Paket schon mehr als 10 mal in den letzten 24h empfangen worden? Wenn nein, dann logge mit Level 7 und dem vorangestellten "[IPTables] REJECT: " ins Syslog. (Eigentlich ist der Jump in eine Chain, in der Logging gemacht wird; ist das fertig, wird zurückgesprungen nach log_reject). Damit kommen wir zur letzten Station der Reise:

iptables -A log_reject -j REJECT
Prüfung: Gibt es nicht. Alles, was hier ankommt, kommt in die REJECT-Chain (die ein ICMP Port not available verschickt und das Paket danach wegwirft). Ende der Lebenszeit des Pakets.

Dabei fällt mir auf, dass natürlich am Ende einer iptables-Firewall IMMER das Statement "iptables -A INPUT -j REJECT" stehen sollte, weil alles, was am Ende der INPUT-Chain ankommt, wird automatisch akzeptiert. Daher verwirft man die Pakete am Ende im letzten Schritt, weil sie ja offenbar nicht behandelt wurden und damit nicht auf der Gästeliste standen.
 
Zuletzt bearbeitet:

alter_Bekannter

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

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
  • Thread Starter Thread Starter
  • #16
log_reject scheint nach meine Verständnis entsprechend:
https://linux.die.net/man/8/iptables

Ein von dir willkürlich festgelegtes Label zu sein. Die manpage auf einem debian 8 system stimmt dem zu.

Welche Regel sorgt also dafür das diese chain anders behandelt wird? Gibts eine Liste mit vordefinierten? Wo finde ich die?
Soweit ich das verstanden habe sind chains doch Behandlungswege die man trennen kann, so das man für unterschiedliche Anfragen andere Wege/Behandlungsketten bauen kann.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@alter_Bekannter: Ich habs dir oben noch erklärt, da haben sich nur unsere Zeiten überschnitten. Wenn du noch Fragen hast, raus damit.

Vordefinierte Chains bzw. Targets sind (u. a.):
INPUT
OUTPUT
FORWARD
DROP
REJECT
ACCEPT
LOG
QUEUE
RETURN

Meist braucht man die letzten beiden nicht, zumindest hab ich noch keinen relevanten Anwendungsfall gefunden.

Und ja, "iptables -N " lässt dich willkürlich neue Chains anlegen, die du verwenden kannst, um bestimmte Fälle näher zu bearbeiten, ohne den ganzen Verkehr aufzuhalten. Ich nutze die zum Beispiel, um Forwarding zwischen Netzen separiert zu behandeln. Da prüfe ich zu Beginn ab, von wo nach wo es laufen soll, und schieb das in die entsprechende Chain. Dort kann ich mich dann um so Sachen wie Ports, Protokolle, genaue Ziele oder Quellen etc. kümmern.
 

alter_Bekannter

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

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
  • Thread Starter Thread Starter
  • #18
Dann habe ich die Frage wohl zu unklar formuliert:
Gibt es keine Möglichkeit auf Verbindungen zu filtern die schon ohne iptables abgelehnt wurden weil nichts auf den angefragten Port lauscht?

Irgendwas wird ja bei diesen Autorejects schon aktiv sonst müsste man ja auf einen timeout warten.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@alter_Bekannter: Ich wüsste nicht, was. Ist aber auch egal, iptables schaltet sich zwischen jeden Dienst und die Netzwerkschnittstelle. "Vor" iptables gibt es also nur noch die Hardware, ergo: iptables ist das Einzige, was dir rejected, sofern du nichts an nicht aktive Ports durchlässt.
 

alter_Bekannter

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

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
  • Thread Starter Thread Starter
  • #20
War das jetzt absicht?:D

Für alle Fälle präziser formuliert:
Gibt es keine Möglichkeit auf Verbindungen zu filtern die schon ohne explizit gelistete Regel in iptables abgelehnt wurden weil nichts auf den angefragten Port lauscht?

Geraten würde ich sagen das geschieht ddann wohl im Kernel/Netzwerktreiber?
 
Oben