wacken
Anmeldungsdatum: 7. Juni 2014
Beiträge: 98
|
Hallo, ich möchte die Firewall so konfigurieren, das nur dem System mitgeteilte IP-Adressen zugelassen(Eingehend) werden. Sprich:
Es sollen alle eingehenden Anfragen abgelehnt werden.
Wenn ich auf das System zugreifen möchte, muss ich meine IP-Adresse dem System mitteilen (wie das weiß ich noch nicht, da hoffe ich auf Vorschläge von euch. Eventuell Dyn.DNS Mitteilung und regelmäßige abfrage vom System).
Die wie auch immer dem System mitgeteilten IP-Adressen soll die Firewall nun zulassen.
Wie ich die IP wieder aus der Firewallregel entfernen kann ist auch noch nicht klar.(Hier spielt auch die Sperrzeit, bis meine IP wieder vergeben werden darf eine Rolle) Kann mir hier bitte jemand Ratschläge geben wie ich das am besten umsetzten kann, und wie ich es vermeide Sicherheitslücken zu öffnen, die mir nicht bewusst sind. Vielen Dank schon mal
wacken
|
redknight
Moderator & Supporter
Anmeldungsdatum: 30. Oktober 2008
Beiträge: 21736
Wohnort: Lorchhausen im schönen Rheingau
|
Möglicherweise suchst Du Port Knocking. Allerdings möchte ich darauf hinweisen, dass das kein Security Feature ist. Im Sinne von Kerckhoffs Prinzip Nr 2 sollte ein System zu seiner Sicherheit keine Geheimhaltung (sprich geschlossenen Port vor laufendem Service) erfordern. Eine ordentliche konfiguration des Service trägt da mehr zur Sicherheit bei.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
wacken schrieb: Wenn ich auf das System zugreifen möchte,...
Wie greifst Du auf das System zu?
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
wacken schrieb: ich möchte die Firewall so konfigurieren, das nur dem System mitgeteilte IP-Adressen zugelassen(Eingehend) werden.
:::: Wenn ich auf das System zugreifen möchte, muss ich meine IP-Adresse dem System mitteilen
Das wird von außerhalb des Netzwerks nicht via TCP/UDP funktionieren, weil nach Deinem Regelentwurf schlicht und einfach alles "unbekannte" verworfen wird, auch die Mitteilung Deiner IP. Allerdings gibts da eine wirksame Alternative, und zwar ganz einfach die bekannten MAC-Adressen erlauben, dabei ist es dann egal, welche IP sie haben. Den Rest sichern dann Keys und Zertifikate ab, z.B. für SSH oder VNC.
|
wacken
(Themenstarter)
Anmeldungsdatum: 7. Juni 2014
Beiträge: 98
|
redknight schrieb: Möglicherweise suchst Du Port Knocking. Allerdings möchte ich darauf hinweisen, dass das kein Security Feature ist. Im Sinne von Kerckhoffs Prinzip Nr 2 sollte ein System zu seiner Sicherheit keine Geheimhaltung (sprich geschlossenen Port vor laufendem Service) erfordern. Eine ordentliche konfiguration des Service trägt da mehr zur Sicherheit bei.
Ja Port Knocking geht genau in die richtige Richtung. Ich habe den Link nur kurz überfolgen. Geht das auch mit anderen Ports, es wurde erwähnt das es mit HTTP nicht geht. Oder geht das nur mit SSH? lubux schrieb: wacken schrieb: Wenn ich auf das System zugreifen möchte,...
Wie greifst Du auf das System zu?
Es ist momentan vorgesehen SSH, VPN und HTTP zu nutzen. TomLu schrieb: wacken schrieb: ich möchte die Firewall so konfigurieren, das nur dem System mitgeteilte IP-Adressen zugelassen(Eingehend) werden.
:::: Wenn ich auf das System zugreifen möchte, muss ich meine IP-Adresse dem System mitteilen
Das wird von außerhalb des Netzwerks nicht via TCP/UDP funktionieren, weil nach Deinem Regelentwurf schlicht und einfach alles "unbekannte" verworfen wird, auch die Mitteilung Deiner IP. Allerdings gibts da eine wirksame Alternative, und zwar ganz einfach die bekannten MAC-Adressen erlauben, dabei ist es dann egal, welche IP sie haben. Den Rest sichern dann Keys und Zertifikate ab, z.B. für SSH oder VNC.
Eine whiteliste mit MAC Adressen ist eine gute Idee. Wie kann ich das am besten realisieren?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
wacken schrieb: Wenn ich auf das System zugreifen möchte, muss ich meine IP-Adresse dem System mitteilen (wie das weiß ich noch nicht, da hoffe ich auf Vorschläge von euch. Eventuell Dyn.DNS Mitteilung und regelmäßige abfrage vom System).
Beim sshd geht das z. B. mit der /etc/hosts.allow, Dyn.DNS und einem cronjob/timer-unit:
:~ $ cat /etc/hosts.allow
sshd : /home/<user>/oipa.txt : allow
sshd : ALL : deny Es würde aber auch mit iptables funktionieren.
|
redknight
Moderator & Supporter
Anmeldungsdatum: 30. Oktober 2008
Beiträge: 21736
Wohnort: Lorchhausen im schönen Rheingau
|
TomLu schrieb: Allerdings gibts da eine wirksame Alternative, und zwar ganz einfach die bekannten MAC-Adressen erlauben, dabei ist es dann egal, welche IP sie haben.
Sobald man von außerhalb des IP-Subnetzes kommt, sieht das System nur noch die MAC des gateways, über das man in das Netz geroutet wurde. wacken schrieb: Es ist momentan vorgesehen SSH, VPN und HTTP zu nutzen.
Wenn SSH und VPN nicht sicher sind, hast Du andere Probleme als den offenen Port. Und auch HTTPS sollte man so konfigurieren, dass das komplette Netz darauf zugreifen kann. Alles andere wäre schlampig.
|
wacken
(Themenstarter)
Anmeldungsdatum: 7. Juni 2014
Beiträge: 98
|
redknight schrieb: TomLu schrieb: Allerdings gibts da eine wirksame Alternative, und zwar ganz einfach die bekannten MAC-Adressen erlauben, dabei ist es dann egal, welche IP sie haben.
Sobald man von außerhalb des IP-Subnetzes kommt, sieht das System nur noch die MAC des gateways, über das man in das Netz geroutet wurde.
Wie habe ich das zu verstehen, ich sehe sehr wohl das die Angreifer meist aus Asien kommen, dank der geloggten IP Adresse. redknight schrieb:
wacken schrieb: Es ist momentan vorgesehen SSH, VPN und HTTP zu nutzen.
Wenn SSH und VPN nicht sicher sind, hast Du andere Probleme als den offenen Port. Und auch HTTPS sollte man so konfigurieren, dass das komplette Netz darauf zugreifen kann. Alles andere wäre schlampig.
Ich gehe davon aus das der SSH Server vom System sicher ist, und der Benutzername ist nicht gewöhnlich und das Passwort ist sicher. Jedoch gefällt es mir überhaupt nicht, dass der SSH-Server mit Brute-Force Attacken angegriffen wird. Dies würde ich gerne unterbinden. Eine Whiteliste wäre hierfür meiner Meinung nach ideal. VPN ist nach meiner Meinung ebenfalls sicher. Dort sind die angriffe auch nicht annäherend so schlimm wie beim SSH-Server. Der HTTPS-Server muss nur für mich erreichbar sein, somit ist auch hier kein Zugriff für das komplette Netz erforderlich. Ich hoffe das bringt ein bisschen Licht ins dunkle warum ich mich mit dem Thema beschäftige.
|
redknight
Moderator & Supporter
Anmeldungsdatum: 30. Oktober 2008
Beiträge: 21736
Wohnort: Lorchhausen im schönen Rheingau
|
wacken schrieb: Wie habe ich das zu verstehen, ich sehe sehr wohl das die Angreifer meist aus Asien kommen, dank der geloggten IP Adresse.
Und das hat was mit der MAC-Adresse zu tun? Firewalling ist nichts, was man nach Standardrezepten macht. Wenn Du dich in dem Bereich nicht auskennst, dann machst Du mehr kaputt als Du absicherst und solltest die Finger davon lassen. Ich gehe davon aus das der SSH Server vom System sicher ist, und der Benutzername ist nicht gewöhnlich und das Passwort ist sicher. Jedoch gefällt es mir überhaupt nicht, dass der SSH-Server mit Brute-Force Attacken angegriffen wird. Dies würde ich gerne unterbinden. Eine Whiteliste wäre hierfür meiner Meinung nach ideal.
Lösung: Stell SSH auf Public-Key Login um. EAnleitung hat das Wiki: SSH VPN ist nach meiner Meinung ebenfalls sicher. Dort sind die angriffe auch nicht annäherend so schlimm wie beim SSH-Server. Der HTTPS-Server muss nur für mich erreichbar sein, somit ist auch hier kein Zugriff für das komplette Netz erforderlich.
Lösung: Aktivier den Serverdienst nur, wenn Du ihn brauchst. Wenn SSH und VPN noch offen sind, ist das ja kein Problem.
|
wacken
(Themenstarter)
Anmeldungsdatum: 7. Juni 2014
Beiträge: 98
|
redknight schrieb: Lösung: Stell SSH auf Public-Key Login um. EAnleitung hat das Wiki: SSH
Das ist leider keine Lösung. Habe ich schon mal in betracht gezogen gehabt, und dann aber wieder verworfen. Weiß aber nicht mehr genau warum. Die Whitelist mit MAC-Adressen erscheint mir doch sehr vielversprechend.
Auf was muss ich denn im speziellen achten, dass ich nicht mehr kaputt mache als ich absichere.
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
wacken schrieb: Die Whitelist mit MAC-Adressen erscheint mir doch sehr vielversprechend.
Auf was muss ich denn im speziellen achten, dass ich nicht mehr kaputt mache als ich absichere.
Sorry... tut mir leid... ich war leider zu voreilig. Ich habe das gerade auf redknights Hinweis mal geprüft und war schier baff, dass die MAC wirklich nicht enthalten ist. Das funktioniert also leider nicht. Anscheinend bin ich in die Router-Falle getappt, der meinen DynDNS einfach intern gehandhabt hat... was ich durch genaueres Hinsehen eigentlich hätte sehen müssen.... aber ich habe wohl nur auf die MAC geachtet. Schade..... Allerdings ist mir im Moment nicht so recht klar, was man grossartig kaputt machen kann. Entweder es geht gar nicht, weil zu viel oder alles gefiltert wird, oder die FW ist schlichtweg unwirksam, weil gar kein Filter match't. Was kann darüber hinaus noch passieren?
Aber dennoch glaube ich, Du solltest unbedingt rednights Rat befolgen und nicht annehmen, dass ein Paketfilter etwas ist, was man fertig von der Stange nehmen kann. Hexenwerk ist es aber auch nicht. Ich fand das sogar eigentlich ziemlich einleuchtend alles. Aber trotzdem stolpert man noch über solche Fallen, wie ich mit der MAC. Aber was wäre passiert...?... nicht viel, ich wäre von draußen einfach nicht reingekommen und hätte mir das dann abends mal angesehen.... und dann wäre das wohl aufgefallen. Die beste Alternative ist -denke ich auch- OpenVPN das Mittel der Wahl, SSH nutze ich nur intern.
Ich gehe davon aus das der SSH Server vom System sicher ist, und der Benutzername ist nicht gewöhnlich und das Passwort ist sicher. Jedoch gefällt es mir überhaupt nicht, dass der SSH-Server mit Brute-Force Attacken angegriffen wird. Dies würde ich gerne unterbinden. Eine Whiteliste wäre hierfür meiner Meinung nach ideal.
Port 22 DROP'n bzw. erst gar nicht im Router weiterleiten, dafür irgend einen exotischen Port >50000 verwenden. Dann hört das abrupt auf mit den Attacken. @rednight,
Was kann man kaputt machen... ?... darüber hinaus, dass zu viel geht oder alternativ eben gar nichts geht?
|
redknight
Moderator & Supporter
Anmeldungsdatum: 30. Oktober 2008
Beiträge: 21736
Wohnort: Lorchhausen im schönen Rheingau
|
wacken schrieb: redknight schrieb: Lösung: Stell SSH auf Public-Key Login um. EAnleitung hat das Wiki: SSH
Das ist leider keine Lösung.
Oh doch. Es löst das Problem, dass dein Passwort geknackt werden _könnte_ weil der Server schlicht Passwortauthentifizierung nicht akzeptiert. Habe ich schon mal in betracht gezogen gehabt, und dann aber wieder verworfen. Weiß aber nicht mehr genau warum.
Wenn Du ernstgenommen werden willst, solltest Du deine Entscheidungen begründen können. Wenn Du um Hilfe fragst und die dann nicht annimmst, erst recht. Die Whitelist mit MAC-Adressen erscheint mir doch sehr vielversprechend.
Auf was muss ich denn im speziellen achten, dass ich nicht mehr kaputt mache als ich absichere.
Wer Firewallen will, muss verstehen, was er/sie da tut. Lies die also die Grundlagen von Netzwerkverbindungen an. Unabhängig davon ist eine Firewall auch immer ein STück SOftware und fehlerbehaftet, sie ersetzt eine saubere Konfiguration also nicht. Wenn die Dienste sauber konfiguriert sind, ist in 99,99% der Fälle allerdings keine Firewall mehr nötig. TomLu schrieb: @rednight,
Was kann man kaputt machen... ?... darüber hinaus, dass zu viel geht oder alternativ eben gar nichts geht?
Es gibt mehrere Möglichkeiten:
Zu viel filtern - auch gewünschte Verbindungen werden nicht mehr hergestellt Zu wenig filtern, es aber nicht bemerken: Ein falsches Gefühl der Sicherheit macht sich breit und führt zu schlampigem Konfigurations- und Wartungsverhalten. Irgendwas dazwischen
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
redknight schrieb: Was kann man kaputt machen... ?... darüber hinaus, dass zu viel geht oder alternativ eben gar nichts geht?
Es gibt mehrere Möglichkeiten:
Zu viel filtern - auch gewünschte Verbindungen werden nicht mehr hergestellt Zu wenig filtern, es aber nicht bemerken: Ein falsches Gefühl der Sicherheit macht sich breit und führt zu schlampigem Konfigurations- und Wartungsverhalten. Irgendwas dazwischen
Ja, danke, das ist etwa so, wie ich mir das gedacht habe. Wenn irgendwas nicht geht, merkt man das sofort, zu wenig ge'match'ed ist die FW dann allerdings unwirksam.... nur das merkt man leider nicht sofort und wiegt sich in falscher Sicherheit. Da empfiehlt sich ein Testrechner, auf dem man gefahrlos alle Szenarien durchspielen kann... ich nutze dafür einen Raspberry PI. Und wenn man mit der Prämisse "Es ist alles verboten, was nicht ausdrücklich erlaubt ist" da ran geht, merkt man sehr schnell, was nicht geht. Bei mir war also das Ziel, dass erst mal gar nichts gehen soll, um dann langsam wieder Stück für Stück mit eindeutiger Filterbedingung zu öffnen. Genau dabei bin ich dann in meine MAC-Falle getappt... was ich aber als völlig undramatisch erachte. Ich wäre halt von draußen nicht reingekommen und hätte dann abends mit tcpdump untersucht, warum nicht. Notfalls lass ich beim debuggen dann die iptables sogar portbezogen ins Journal schreiben und zeitgleich zu tcpdump mit "journalctl -f" ausgeben. Dahinter kommt man aber immer... *fg* ... irgendwie ...
|
wacken
(Themenstarter)
Anmeldungsdatum: 7. Juni 2014
Beiträge: 98
|
redknight schrieb: wacken schrieb: redknight schrieb: Lösung: Stell SSH auf Public-Key Login um. EAnleitung hat das Wiki: SSH
Das ist leider keine Lösung.
Oh doch. Es löst das Problem, dass dein Passwort geknackt werden _könnte_ weil der Server schlicht Passwortauthentifizierung nicht akzeptiert.
Hier hast du mich falsch verstanden. Mir ist bewusst das SSH mit einem Publickey Login sicher ist. Jedoch kann ich das nicht verwenden, weiß aber nicht mehr warum. Ist schon eine weile her. Ich gucke mal, ob ich das noch was finde warum ich das nicht gemacht habe. Ich habe auch schon Geoblocking ausprobiert. Das hat bei mir aber auch nicht so recht funktioniert. Es wurden zuviele IPs nicht geblockt, die hätten geblockt werden sollen. TomLu schrieb: Port 22 DROP'n bzw. erst gar nicht im Router weiterleiten, dafür irgend einen exotischen Port >50000 verwenden. Dann hört das abrupt auf mit den Attacken.
Ja das stimmt. Aber auch hier gibt es ein Problem. Diese Ports sind oft gesperrt und ich kann dann nicht von Unterwegs auf meinen Server zugreifen. Open VPN ist sicher auch gut, aber nicht so angenehm, da immer erst noch das VPN aufgebaut werden muss. Und auch hier sind oftmals Ports geblockt.
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
wacken schrieb: Ja das stimmt. Aber auch hier gibt es ein Problem. Diese Ports sind oft gesperrt und ich kann dann nicht von Unterwegs auf meinen Server zugreifen. Open VPN ist sicher auch gut, aber nicht so angenehm, da immer erst noch das VPN aufgebaut werden muss. Und auch hier sind oftmals Ports geblockt.
Nun, in beiden Fällen täuscht Du Dich. Möglicherweise hat jemand bei einem WISP/AP tatsächlich Port 22 pauschal gedropt, aber das jemand alle Ports auch fürs Forwarding sperrt, habe ich bisher in ganz EU erst einmal erlebt, soweit ich mich erinnern kann. Das war in Arvidsjaur in Schweden, wo am Standort ein offenes Netz angeboten wurde, aber mit wirklich harten Beschränkungen. Und wenn ich ehrlich bin, habe ich Zweifel, dass das bewusst so installiert wurde, sondern das es bei der dort herrschenden Unkenntnis eher ein unerwünschter Effekt einer nicht ordentlich eingerichteten Firewall war. Erstens würde ich für SSH sowieso nicht den Port 22 verwenden, sondern einen exotischen >50000, und damit kommt man fast immer durch. Und zweitens würde ich sowieso generell nicht SSH für den Zugang von außen nutzen, sondern OpenVPN, welches ich mit Zertifkaten und Keys je Client (Roadwarrior) ordentlich "personifizieren" kann. Und auch da verwende ich nicht den Standard-Port 1194, sondern wieder einen exotischen >50000. Und mit OpenVPN war es sogar in Arvidsjaur möglich einen Tunnel nach Hause zu etablieren, zwar nicht via UDP Port n, sondern über TCP:443, der wiederum auf meinem OpenVPN-Server auf den schon zuvor genannten exotischen Port >50000 geforwarded ist. Da ich auf TCP:443 keinen nach außen lauschenden Dienst habe, gibts hier auch keine Konflikte. Hätte ich einen Dienst, würde ich das über Portsharing regeln. OpenVPN ist m.E. die beste, sicherste und immer funktionierende Lösung. Das VPN zu starten und den Tunnel zu etablieren ist ein Klick und dauert nur 3-6 Sekunden.
|