weieter Schutzmaßnahmen. Login-Versuche, IDS?

pixel24

Hallo zusammen,

ich habe meine pfSense in meinem Heimnetzwerk dank Eurer Hilfe eingerichtet. Bisher gibt es von Außen lediglich zwei Zugriffs-Möglichkeiten. Per auf der pfSense installiertem OpenVPN oder per HTTPS durch den HA-Proxy auf die Hosts hinter der pfSense. Ok, eigentlich noch den dritten "Port80" für ACME der auf den lokalen HTTP geht um die Zertifikate zu aktualisieren.

Bitte entschuldigt wenn ich im nachfolgenden Text die Begrifflichkeiten durcheinander werfe oder die nötige Trennschärfe fehlt.

Immer mal wieder aufgeschnappt habe ich die Begriffe:

fail2ban
IDS
portnocking

fail2ban +
Sperrt die Quell-IP nach x fehlgeschlagenen Login-Versuchen? Das muss aber auf dem Host eingerichtet sein wo der Login-Versuch erfolgt. Sprich: Wenn ich den SSH-Port 22 auf den Server hinter der pfSense weiterleite muss auch dort fail2ban eingerichtet sein.
IDS +
Erkennt Einbruchs-Versuche. Basiert diese "Erkennung" dann auf Verhaltensmuster des Angreifers oder wie erkennt ein System das? Lässt sich das einfach auf der pfSense einrichten oder ist das eher was für Profis. Ja, der Begriff "einfach" ist relativ.
Portnocking +
Ich hoffe ich habe es richtig geschrieben. Habe ich mal im CT gelesen. Da muss der Ankommende in einem bestimmten Muster an den Ports "anklopfen", dann geht der gewünschte auf (frei aus dem Kopf). Klingt magisch. Ist so etwas noch aktuell bzw. nutzt das jemand?

Ich habe hier keine Hochsicherheits-Infrastruktur. Ich möchte mich lediglich etwas tiefer mit dem Thema Sicherheit in Verbindung mit der pfSense beschäftigen und das System noch sicherer machen.

Beste Grüße
pixel24

JeGr

Hi,

@pixel24 said in weieter Schutzmaßnahmen. Login-Versuche, IDS?:

fail2ban +
Sperrt die Quell-IP nach x fehlgeschlagenen Login-Versuchen? Das muss aber auf dem Host eingerichtet sein wo der Login-Versuch erfolgt. Sprich: Wenn ich den SSH-Port 22 auf den Server hinter der pfSense weiterleite muss auch dort fail2ban eingerichtet sein.

Korrekt, in den meisten Fällen setzt fail2ban auf Logfiles auf, somit muss man dem Tool beibringen, was gut und was schlecht ist. Also bspw. die Semantik der Logzeile wenn ein Loginversuch scheitert muss erkannt werden können. Dann kann es sich die IP merken, feststellen ob der Zugreifende nochmal innerhalb einer Zeitspanne vorbei kommt und ggf. blocken. Woanders als auf dem Host selbst ist das schwer zu machen, da die Zugriffe ja häufig verschlüsselt sind und gerade bei SSH kann man da schlecht vornedran intervenieren.

@pixel24 said in weieter Schutzmaßnahmen. Login-Versuche, IDS?:

Erkennt Einbruchs-Versuche. Basiert diese "Erkennung" dann auf Verhaltensmuster des Angreifers oder wie erkennt ein System das? Lässt sich das einfach auf der pfSense einrichten oder ist das eher was für Profis. Ja, der Begriff "einfach" ist relativ.

Nein, nicht wirklich. Klassische IDS Systeme erkennen keine Einbruchs-Versuche, sondern filtern schlichtweg jedes Paket dass eingehend durch das Interface läuft, auf dem sie konfiguriert sind. Wenn das bspw. das WAN ist, wird eben schlicht jedes Paket in die Hand genommen, was durch das WAN von außen durchläuft. Alleine daran kann man schon erkennen, dass das keine leichtgewichtige Sache für die CPU und das Processing dahinter ist.
Was dann passiert ist lediglich in den Rulesets definiert. Wenn man sich die häufig genutzten Rulesets ansieht, kann man das grob in 3 Teile unterteilen - und ja das ist simplifiziert aber zutreffend:

Simple IP Blocks: Es wird in den Rules lediglich nach Source oder Destination IP geschaut. Was ein Job ist, den die Firewall mit anderen Mechanismen wesentlich einfacher regeln könnte. Darum wird hier für kaum effektiven Mehrnutzen ordentlich Rechenzeit verbraten
Paketinhalt/Signaturen von (ur)alten Bots, Trojanern, Protokollangriffen etc.: Hier wird im Paket wirklich nach effektiver Payload gesucht, die hinterlegt wurde. Oftmals sind diese Payloads aber wenn man die Regeln anschaut relativ alt (mehrere Jahre, teils Jahrzehnte) und man muss sich fragen, ob das heute überhaupt noch aktiv (aus)genutzt wird.
Application IDs: via Snort nutzbar und sinnvoll nur auf dem LAN anzuwenden ist das die Gruppe, die heute tatsächlich einigen Sinn hat. Über OpenAppID wird versucht herauszubekommen, wenn bekannter Traffic fließt, bspw. zu Facebook. Kann somit identifiziert und im Blocking Mode (IPS) dann ggf. auch geblockt werden.

Die eigentlich gewünschte Gruppe wäre: aktuelle Angriffe / SSL Signaturen. Das ist aber eine sehr überschaubare Gruppe, aktuelle Angriffe auf unverschlüsselte Protokolle oder Versuche, problematische SSL/TLS Verbindungen zu finden und beenden. Und hier liegt die Crux an der Sache. Durch HTTPS/TLS everywhere haben wir fast überall inzwischen ordentliche Transportverschlüsselung. Heißt aber auch: das IDS kann in die Pakete nicht mehr sinnvoll reinschauen - weil die verschlüsselt sind und man sie nicht einfach ent- und wieder verschlüsseln kann. Somit ist der Sinn eines klassischen IDS heute recht beschränkt und spielt sich eigentlich eher in Richtung intern->extern mit AppID Erkennung o.ä. ab, beim eingehenden Verkehr hilft es aber oftmals kaum noch wirklich, wenn man nicht gerade selbst unverschlüsselte Dienste anbietet (Mail via SMTP, HTTP, DNS). Da muss man also sehr stark abwägen, ob es Sinn macht oder nicht.

@pixel24 said in weieter Schutzmaßnahmen. Login-Versuche, IDS?:

Portnocking +
Ich hoffe ich habe es richtig geschrieben. Habe ich mal im CT gelesen. Da muss der Ankommende in einem bestimmten Muster an den Ports "anklopfen", dann geht der gewünschte auf (frei aus dem Kopf). Klingt magisch. Ist so etwas noch aktuell bzw. nutzt das jemand?

Hach ja, gute alte Zeiten Nein, ich kenne heute niemand mehr, wo das aktiv genutzt wird, da es in den meisten Fällen wirklich einfach nur eine etwas "schönere Art" von Security through Obscurity ist. Ich verstecke was, indem ich es hinter 5 Port Zugriffen verstecke. Das war damals schon sehr umständlich, weil man irgend ein Tool gebraucht hat um die Sequenz zu senden bevor es dann wirklich losging. Die schönere Variante für sowas kam von OpenBSD mit Auth-PF + SSH. Man konnte sich per SSH zu einem Host verbinden (meist einer Firewall) und sobald man verbunden war (User+SSH Key ist ja recht sicher) wurde der Username der Verbindung + die IP von der er kommt an den Paketfilter geliefert und man konnte sie als Variablen in einem Filterset benutzen. Damit konnte man dann genau für die Zeit der Verbindung für diesen User von dessen IP genau eine Verbindung freischalten und danach wieder schließen ohne dass das jemand anderes nutzen konnte (außer er kam von der gleichen IP natürlich).
Quasi eine Art VPN light damals. Aber selbst Auth-PF gibt es heute kaum noch aktiv im Einsatz (gibt es leider m.W. eh nur auf der nativen PF Implementierung auf OpenBSD, FreeBSD hat das nicht mit übernommen).

Hoffe das hilft dir etwas weiter.

Cheers
\jens

pixel24

@jegr Lag mit Grippe flach. Deshalb die späte Rückmeldung.

Vielen Dank für die ausführliche Erläuterung!

Aktuell gewährt die pfSense folgende Zugriffe von extern:

HTTPS per HA-Proxy auf diverse Hosts im LAN
OpenVPN
SSH Portforwarding auf Host im LAN

HTTPS-Zugriff
Beim HA-Proxy finde ich, zumindest in meiner Konfiguration, noch nicht optimal dass man von extern auch auf das Admin-Interface des Hosts kommt. Beispiel: Die Groupware ist unter:

https://gw.example.com/egroupware

zu erreichen. Der HA-Proxy entscheidet anhand von:

gw.example.com

dass die Vetbindung auf dem entsprechenden internen Server landet. Lässt man nun am Ende das '/egroupware' weg kommt man auf das Admin-Interface des Servers. Kann ich das auf dem HA-Proxy unterbinden oder muss ich das mit Mod-Rewrite auf dem Zielserver machen?

OpenVPN
ich denke mal hier muss ich aktu nichts weiter unternehmen. Ich versuche mich da tiefer einzulesen. Nutze da ja im Moment "User-Auth"

SSH
Hier werde ich mir fail2ban anschauen und es auf dem Zielhost einrichten.

Ich denke dann habe ich eine gute Ausgangssituation.

Beste Grüße
pixel24

mansior

@pixel24
Auch wenn es sich nicht um Hochsicherheits-Infrastruktur handelt, es dich aber interessiert, könntest du dir das Thema Netz-Segmentierung anschauen. Systeme die (z.B. über HA-Proxy) von aussen erreichbar sein, steckst du in ein eigene "Zone". Diese können z.B. durch die Firewall nicht in dein restliches Netz "greifen".... usw...

VG

pixel24

@mansior said in weieter Schutzmaßnahmen. Login-Versuche, IDS?:

Auch wenn es sich nicht um Hochsicherheits-Infrastruktur handelt, es dich aber interessiert

Ja, da gibt es definitiv keine Hochsicherheits-Anforderungen. Ich finde das Thema spannend und will mich da einfach etwas weiter entwickeln :-)

@mansior said in weieter Schutzmaßnahmen. Login-Versuche, IDS?:

könntest du dir das Thema Netz-Segmentierung anschauen.

Sind damit VLAN's gemeint oder was versteht man unter Segmenten? Ich denke mal nicht physische Netzwerk-Segmente.

@pixel24 said in weieter Schutzmaßnahmen. Login-Versuche, IDS?:

Sind damit VLAN's gemeint oder was versteht man unter Segmenten? Ich denke mal nicht physische Netzwerk-Segmente

Hallo zusammen,

Zonen oder VLANs wie man möchte Zeit und Lust und Geld hat.

HTTPS per HA-Proxy auf diverse Hosts im LAN
Wie wäre es mit einer DMZ und einem LAN?

SSH Portforwarding auf Host im LAN
Also von irgendwo müssen die Anmeldeversuche ja kommen, oder? Eventuell versucht das jemand aufgrund
dieser Einstellung?

OpenVPN
Wenn es muss dann Ok, wenn man aber etwas Zeit und
Geduld hat kann man sich auch einmal IPSec anschauen
das kann man mittels eines Radius Server Zertifikat auch
noch einmal absichern, wenn man möchte.

JeGr

@pixel24 said in weieter Schutzmaßnahmen. Login-Versuche, IDS?:

dass die Vetbindung auf dem entsprechenden internen Server landet. Lässt man nun am Ende das '/egroupware' weg kommt man auf das Admin-Interface des Servers. Kann ich das auf dem HA-Proxy unterbinden oder muss ich das mit Mod-Rewrite auf dem Zielserver machen?

kann man egal wo machen. Wenn du ne URL bzw. einen Pfad blockieren willst musst du das eben einstellen. Wo liegt ganz an dir, das kann am Host selbst oder im Proxy sein.

@pixel24 said in weieter Schutzmaßnahmen. Login-Versuche, IDS?:

Hier werde ich mir fail2ban anschauen und es auf dem Zielhost einrichten.

Extern nicht Port 22, sondern ggf. sowas wie 8022 oder 4022 o.ä. nutzen. Im Gegensatz zu "RDP o.ä. auf fremden Ports verstecken" ist das in dem Fall kein Security through Obscurity - es geht nicht um das stumpfe Verstecken des Ports in der Hoffnung dass es keiner findet - sondern darum die Standard Scanner, Bots und Trojaner die alle via tcp/22 rumkreiseln abzufischen. Dann sind die Connects, die wirkliche auf dem alternate Port ankommen, effektiv welche, wo jemand wirklich versucht sich zu verbinden - oder nen Portscan zu machen. Und da hilft fail2ban dann - ggf. ruhig in einem eher aggressiven Modus - sehr gut.

Ansonsten hilft es soweit möglich den Zugriff extern auf IPs zu beschränken die sein müssen. Wenn sich nicht "any" per SSH verbinden müssen - gar nicht erst any aufmachen. Bei OVPN eher schwierig - man weiß ja oft nicht wo man hinkommt - aber wenn möglich beschränken.

@dobby_ said in weieter Schutzmaßnahmen. Login-Versuche, IDS?:

Wenn es muss dann Ok, wenn man aber etwas Zeit und
Geduld hat kann man sich auch einmal IPSec anschauen
das kann man mittels eines Radius Server Zertifikat auch
noch einmal absichern, wenn man möcht

Und inwiefern soll nun IPsec (was eher "meh" einzurichten ist, gerade für Anfänger) in der Auth besser machen als OpenVPN?
Sinnvoll bei egal welchem VPN wäre saubere User-Auth. Und das eher nicht mit dem integrierten Local UserDB, sondern schöner mit bspw. dem FreeRadius Package. Dann packt man die User, die sich per VPN anmelden dürfen via FreeRadius3 ins System und schon kann man nicht "aus Versehen" einen User anlegen der Zugriff auf die Firewall/Dashboard hat. Geht recht flott das sowas passiert. Daher die VPN User raus und rein in die FreeRadiusDB. Hat nebenbei den Vorteil, dass man dann auf die Radius Daten per OpenVPN Zugriff hat, also auch bspw. statische IPs bei der Einwahl vergeben oder die Einwahl beschränken kann auf X gleichzeitige Zugriffe, Uhrzeiten/Werktage etc. etc.
Da bin ich gerade nicht up2date aber IMHO konnte das nach letztem Stand IPsec nicht auswerten. Selbst wenn doch - da will ich nichts unterstellen - halte ich IPsec für Client VPN für die denkbar schlechtere Wahl. Unflexibel, störrisch einzurichten gerade in hybriden Umgebungen, die nicht "nur Windows" o.ä. sind, Debugging und Fehlersuche sind ein Albtraum - sorry keine 10 Pferde bringen mich dazu ;)

Zusätzlich zu User-Auth per Radius würde ich noch Zertifikate mit rein nehmen und den Server+Clients mit Zertifikaten bespaßen. Wer dann noch eins draufsetzen will kann sein FreeRadius Password ersetzen durch PIN+TOTP mit ner App oder nem TOTP Token Generator, das kann man in FreeRadius auch recht einfach einrichten.

Cheers

pixel24

@jegr said in weieter Schutzmaßnahmen. Login-Versuche, IDS?:

Extern nicht Port 22, sondern ggf. sowas wie 8022 oder 4022 o.ä. nutzen. Im Gegensatz zu "RDP o.ä. auf fremden Ports verstecken" ist das in dem Fall kein Security through Obscurity - es geht nicht um das stumpfe Verstecken des Ports in der Hoffnung dass es keiner findet - sondern darum die Standard Scanner, Bots und Trojaner die alle via tcp/22 rumkreiseln abzufischen.

Ok, klingt logisch. Je mehr ich darüber nachdenke - was ja oft hilft - desto klarer wird mir dass ich SSH eigentlich nicht benötige. Ich bin in 99,99999% der Fälle mit einem meiner Linux-Laptops unterwegs und darauf ist die OpenVPN-Verbindung eingerichtet. Ich lasse 22 einfach zu.

@jegr said in weieter Schutzmaßnahmen. Login-Versuche, IDS?:

Sinnvoll bei egal welchem VPN wäre saubere User-Auth. Und das eher nicht mit dem integrierten Local UserDB, sondern schöner mit bspw. dem FreeRadius Package. Dann packt man die User, die sich per VPN anmelden dürfen via FreeRadius3 ins System

Das werde ich mir definitiv anschauen. Das mit dem Radius-Server habe ich schon oft gelesen. Im Moment habe ich pfSense an den im LAN vorhanden ADS/LDAP angebunden.

@jegr said in weieter Schutzmaßnahmen. Login-Versuche, IDS?:

und schon kann man nicht "aus Versehen" einen User anlegen der Zugriff auf die Firewall/Dashboard hat. Geht recht flott das sowas passiert

Das passiert mit an Sicherheit grenzender Wahrscheinlichkeit hier nicht. Wenn ich irgend etwas teste habe ich fast die gesamte Umgebung innerhalb einer virtuellen Umgebung lokal auf einem Rechner.

@jegr said in weieter Schutzmaßnahmen. Login-Versuche, IDS?:

Da bin ich gerade nicht up2date aber IMHO konnte das nach letztem Stand IPsec nicht auswerten. Selbst wenn doch - da will ich nichts unterstellen - halte ich IPsec für Client VPN für die denkbar schlechtere Wahl. Unflexibel, störrisch einzurichten gerade in hybriden Umgebungen, die nicht "nur Windows" o.ä. sind, Debugging und Fehlersuche sind ein Albtraum - sorry keine 10 Pferde bringen mich dazu ;)

Das kann ich technisch nicht beurteilen aber bei OpenVPN will ich bleiben. Das nutze ich schon lange und funktioniert hier auf allen Plattformen (Linux, Windows, Apfel) ohne Probleme.

@jegr said in weieter Schutzmaßnahmen. Login-Versuche, IDS?:

Zusätzlich zu User-Auth per Radius würde ich noch Zertifikate mit rein nehmen und den Server+Clients mit Zertifikaten bespaßen. Wer dann noch eins draufsetzen will kann sein FreeRadius Password ersetzen durch PIN+TOTP mit ner App oder nem TOTP Token Generator, das kann man in FreeRadius auch recht einfach einrichten.

Das werde ich mir anschauen. Gerade bei den Zertifikaten habe ich noch beträchtliche Wissenslücken :-(

Ich kann mich nur ein weiteres mal für deine ausführliche Erläuterung bedanken!!!!!

Beste Grüße und ein schönes Wochenende