Netzwerk Konfiguration

rubricanis

rubricanis

Homo ludens
Hi everyone!

Ich habe zwar vor längerer Zeit schon mit FreeBSD etwas herumgespielt,
mir aber erst jetzt einen Server bei Hetzner geleistet; ZFS, kein Raid.
Es geht mir darum verschiedene in erlang geschriebene webserver in
Verbindung mit verschiedenen Datenbanken zu testen. Außerdem möchte ich
mich in nginx und memcached reinfummeln; kurz und gut der ganze webservice
krempel.

Um auf unterschiedliche Konfigurationen per HTTP/HTTPS zugreifen zu können
kann ich unterschiedlich ports verwenden, also z. 8000 bis 8080 oder
was immer.

Verstehe ich das richtig dass für meine IP all diese Ports automatisch offen
sind und wenn eben keiner dran schnüffelt auch nichts weiter passieren kann?
Oder muss ich die extra öffnen und wenn ja wie macht man das ?

Das Ganze sind für mich z.Z. noch Böhmische Dörfer und allzu viel kann ich it
all dem nicht anfangen; vielleicht ihr ...

Peter

PS: Sorry, sehe gerade das ich im falschen Forum bin ...
 
Zuletzt bearbeitet:
Solange kein Dienst auf einem Port bzw. Socket (also IP-Adresse + Port) lauscht, kann niemand auf den Server zugreifen.
Sobald du einen Dienst startest und diesem eine IP-Adresse zuweist, lauscht dieser auf der angegebenen IP-Adresse unter dem konfigurierten Port.
Dann ist der Dienst von außen erreichbar.

Du kannst natürlich über Firewalls oder ähnliche Maßnahmen den Zugriff auf solch "offenen" Ports weiter einschränken, dies kann jedoch im Einzelfall das Ganze erschweren.

Weiterhin rate ich dir, solche Dinge erst im privaten Umfeld mit einer Virtualisierungslösung zu testen, da du, je nach Konfiguration, schnell Opfer eines Angriffs werden kannst, welcher dann einem Angreifer die Übernahme deines Servers ermöglicht. Gerade, wenn es sich um "selbst geschriebene" Webserver handelt, die evtl. nicht durch eine große Entwicklergemeinde ausgiebig getestet wurden, solltest du mehrmals überlegen, was du genau möchtest.

Gruß
Markus
 
m4rkus schrieb:
Du kannst natürlich über Firewalls oder ähnliche Maßnahmen den Zugriff auf solch "offenen" Ports weiter einschränken, dies kann jedoch im Einzelfall das Ganze erschweren.
Zum Vergrößern anklicken....
Gut, damit werde ich mich noch beschäftigen....

Weiterhin rate ich dir, solche Dinge erst im privaten Umfeld mit einer Virtualisierungslösung zu testen, da du, je nach Konfiguration, schnell Opfer eines Angriffs werden kannst, welcher dann einem Angreifer die Übernahme deines Servers ermöglicht. Gerade, wenn es sich um "selbst geschriebene" Webserver handelt, die evtl. nicht durch eine große Entwicklergemeinde ausgiebig getestet wurden, solltest du mehrmals überlegen, was du genau möchtest.
Zum Vergrößern anklicken....
Es handelt sich dabei nicht um selbstgeschriebene webserver, in erlang gibt es da wahrlich genug. Dennoch stellt sich für mich die Frage ob ich die unerschiedlichen Konfigurationen und Datenbanken nicht in jails packe. Wie funktioniert dann die Weiterleitung von der Haupt-IP auf die einzelnen jails ???

Z:B:
jail-1 -> webserver A
jail-2 -> webserver B
jail-3 -> webserver C
....
jail-X -> DB1
jai-lY -> DB2
jail-Z -> DB3

Ich könnten dann sogar in jedem jail eine erlang-node laufen lassen und die können direkt miteinander kommunizieren. Na ja, vielleicht ein wenig viel des Guten :-)

Peter

PS: Klar, mit den Sicherheitsaspekten werde ich mich umgehend beschäftigen, ist nur eine ganze Menge was da auf einmal zu verarbeiten ist.
 
Schau dir mal ezjail an. Da gibt es einige gute Tutorials.

Nichts destotrotz. Die Angriffsfläche bei "schlecht" gesicherten Jails wird nicht kleiner - nur die Auswirkungen auf übrige Dienste schränkst du ein.
Wenn deine Jails im Internet hängen (ob mit einer Weiterleitung oder NAT) und diese mit diesem ungefiltert kommunizieren können, kann ein Angreifer dennoch in deinem Namen Schaden anrichten (Spam versenden, dein Jail in ein Botnet integrieren, deine IP-Adresse als Proxy missbrauchen). Im Zweifelsfall kommt er halt nur nicht an die Daten der anderen Jails / des Hosts heran.

Gruß
Markus
 
TCM schrieb:
Und den Führerschein machst du, sobald der Bedarf da ist, weil du den ersten Fußgänger geplättet hast?
Zum Vergrößern anklicken....
Meine Güte, seit doch nicht so skeptisch! Ich habe mir den o.g. Artikel durchgelesen, mir das Buch von Benedikt Nießen besorgt (und noch einiges andere herumliegen) und werde mich jetzt Stück für Stück einarbeiten. Bislang ist nichts verhackt da ich bis auf ssh und sftp nichts laufen habe, OK, ich habe das ein wenig unterschätzt, aber das macht nichts, ich habe nichts eilig. Nur schade dass es noch länger dauern wird dass ich mit dem Progrmmieren weiter komme. Aber was soll's ?

Bzgl. Führerschein: Wo und wie kann man den machen? Und wie kommt man weiter wenn man nicht (zunächst) dumme Fragen stellt. Ganz so einfach ist das Ganze ja nicht und Doku und Literatur beantworten bei weitem nicht alle Fragen. Oder sind hier nur Führerscheininhaber erwünscht? Dann laßt mich das bitte wissen...

Jetzt beschäftige ich mich erst einmal mit dem ZFS, dann Firewall und Jails und dann kann man weiter sehen ...

Peter
 
rubricanis: Dein Problem besteht darin, dass Angreifer bevorzugt die IPv4 Ranges günstiger Hoster absuchen. Ich hatte die Tage erst wieder den Spass mit lästigen Vollidioten, die meinten sie müssten sich 10 bis 20 Mal pro Sekunde bei mir einloggen in der Hoffnung ich hätte SSH Anmeldung mit Single Factor Auth per Password zugelassen.
 
Crest schrieb:
Ich hatte die Tage erst wieder den Spass mit lästigen Vollidioten, die meinten sie müssten sich 10 bis 20 Mal pro Sekunde bei mir einloggen in der Hoffnung ich hätte SSH Anmeldung mit Single Factor Auth per Password zugelassen.
Zum Vergrößern anklicken....

block in quick on $ext_if proto tcp from ! <GeoIP_DE> to ($ext_if) port 22
pass in quick on $ext_if proto tcp from ! <overload_ssh> to ($ext_if) port 22 modulate state (max-src-conn-rate 2/600, overload <overload_ssh> flush global)

o.ä.
 
Ich kenne die Spielchen um sich solche Leute vom Leib zu halten, beim Debuggen der pf.conf nerven sie weil sie rauschen auf den pflog Interfaces erzeugen.
 
Entweder spezifsch gar nicht loggen oder logs nach "Wichtigkeit" auf mehrere pflog-Interfaces aufteilen.

Ich schick z.B. alles, was mich prinzipiell nicht interessiert (z.B. 445/tcp Spam) nach pflog1. Da kann ich bei Bedarf nachgucken, aber es wird nicht auf Platte geloggt und stört pflog0 nicht.

Es wäre z.B. ein Leichtes, hits von <overload_ssh> nach pflog2 zu schicken und einen pflogd pflog2 nach /var/log/pflog_ssh.log schicken zu lassen oder so, fall man wirklich "alles" braucht.
 
Crest schrieb:
rubricanis: Dein Problem besteht darin, dass Angreifer bevorzugt die IPv4 Ranges günstiger Hoster absuchen. Ich hatte die Tage erst wieder den Spass mit lästigen Vollidioten, die meinten sie müssten sich 10 bis 20 Mal pro Sekunde bei mir einloggen in der Hoffnung ich hätte SSH Anmeldung mit Single Factor Auth per Password zugelassen.
Zum Vergrößern anklicken....
Crest: Das verstehe ich nicht wirklich. Bedeutet dass das das einloggen via Putty mit name/pw nicht zureichend ist und wenn ja, wie macht man das besser?

Ich benutze name/pw, logge nicht als root ein sondern mache dass dann über su. Und die PWs sind eher lang. Kann ich noch mehr tun ?

Peter
 
man ssh-keygen

Dabei gleich ein grundlegendes Verständnis von public key auth aneignen, auch wenn es nur die Userseite ist (welcher Key ist wozu da, welcher muss geheimbleiben, welche Algorithmen gibt es, was sind grob ihre Eigenschaften). Kein Admin muss Mathe studiert haben, aber in der Anwendung von Crypto sollte man unbedingt sattelfest sein, wenns dann später z.B. an Zertifikatverwaltung für HTTPS geht.

Key-basierten Login bei SSH kriegt man aber zur Not noch nach Anleitung hin.
 
SSH-Zugriff mit User/PW ist meines Erachtens nach NICHT ausreichend, da dann (je nach verwendeter Passwortlänge) ein Bruteforce- oder Wörterbuchangriff auf den Zugang möglich ist.
Dies ist im vom Crest beschriebenen Fall der Grund für die vielen Login-Versuche.

Gegenmaßnahmen wären entweder, wie von TCM beschrieben zunächst mal die Geschwindigkeit der Angriffe zu reduzieren, oder aber auf SSH-Keys umzusteigen. Eine Kombination mehrerer Maßnahmen wäre auch denkbar.

Gruß
Markus
 
m4rkus schrieb:
Gegenmaßnahmen wären entweder, wie von TCM beschrieben zunächst mal die Geschwindigkeit der Angriffe zu reduzieren, oder aber auf SSH-Keys umzusteigen. Eine Kombination mehrerer Maßnahmen wäre auch denkbar.
Zum Vergrößern anklicken....

OK, werde ich mir in nächster Zeit genauer anschauen. Die Reduzierung der Geschwindigkeit macht man dann mit pf, richtig ?

Danke!

Peter
 
rubricanis schrieb:
Crest: Das verstehe ich nicht wirklich. Bedeutet dass das das einloggen via Putty mit name/pw nicht zureichend ist und wenn ja, wie macht man das besser?

Ich benutze name/pw, logge nicht als root ein sondern mache dass dann über su. Und die PWs sind eher lang. Kann ich noch mehr tun ?
Zum Vergrößern anklicken....
Es bietet sich an wo immer möglich auf Public Keys oder GSSAPI umzusteigen. Ist ein Login mit Passwort nötig sollte mehr als ein Faktor nötig sein z.B. (pam_unix || pam_ldap) && pam_googleauthenticator. Der User benötigt in diesem Fall sein Passwort und einen 8 Stelligen Code, der von einem geteilten Schlüssel und nem Timestamp/Counter abhängig ist.
 
Crest schrieb:
rubricanis: Dein Problem besteht darin, dass Angreifer bevorzugt die IPv4 Ranges günstiger Hoster absuchen. Ich hatte die Tage erst wieder den Spass mit lästigen Vollidioten, die meinten sie müssten sich 10 bis 20 Mal pro Sekunde bei mir einloggen in der Hoffnung ich hätte SSH Anmeldung mit Single Factor Auth per Password zugelassen.
Zum Vergrößern anklicken....
Wenn mit langweilig ist mache ich das auch :hihihi
Und ich hab schon locker 10-15 Server gehabt, bei denen man sich mit root root einloggen konnte...
Daher kann man den denen nicht verübeln.
 
So, mit ein wenig Mühe habe ich das login mit public-key hinbekommen. Zusätzlich habe ich in /etc/ssh/sshd_config PermitRootLogin auf "no" gesetzt. Abgesehen von der Auswahl eines anderen Ports anstatt vonn 22 habe ich ansonsten alle defaults belassen.

Allerdings tue ich mich schwer PW-Auth ganz abzustellen denn wenn mal irgend etwas nicht funktioniert bin ich ausgesperrt. Immerhin muss ein Angreifer erste einmal in den normalen user account reinkommen und dann noch an das PW von root kommen um wirklich etwas anzustellen. Und die PWs sind keine Leichtgewichte...

Zunächst mal OK so damit ich mich mit den service-jails befassen kann ?
 
Zuletzt bearbeitet:
PasswordAuthentication könntest du noch ausschalten in der sshd_config und dann auch prüfen, dass das nicht mehr geht. Mittels AuthenticationMethods könntest du auch festlegen, dass Key _und_ Passwort nötig sind.
 
Du kannst ruhig PW-Auth abstellen: Du kommst im Notfall immer noch über KVM (kostet glaub ich 20€ für x Minuten bei Hetzner) auf die Konsole - und dan funktioniert das Root-PW.
Habe ich bei Webtropia auch - PW-Login nur über Konsole - Rest über Keys.
Gruß
Markus
 
Hin und wieder mal KVM kostet bei Hetzner nichts. Man kann über deren Webinterface nen Ticket aufmachen für min. 2 Stunden nen KVM Interface angeschlossen zu bekommen. Bis jetzt wurden diese Tickets bei mir immer in unter 30 Min. bearbeitet. Die KVM Interfaces brauchen leider für ihren Java Webstart Schrott Linux oder Windows (vllt. geht auch MacOS). Der javaws File enthält eine Whitelist der unterstützten Betriebssysteme und Pfade zum Native Code für diese.
 
Crest schrieb:
Hin und wieder mal KVM kostet bei Hetzner nichts. Man kann über deren Webinterface nen Ticket aufmachen für min. 2 Stunden nen KVM Interface angeschlossen zu bekommen. Bis jetzt wurden diese Tickets bei mir immer in unter 30 Min. bearbeitet. Die KVM Interfaces brauchen leider für ihren Java Webstart Schrott Linux oder Windows (vllt. geht auch MacOS). Der javaws File enthält eine Whitelist der unterstützten Betriebssysteme und Pfade zum Native Code für diese.
Zum Vergrößern anklicken....

OK, dann mache ich das so! Crest was meinst du mit dem OS. Muss ich dann Java auf meinem Eisen installiert haben (Win7) ?

Danke an Alle!

Peter

PS: Und wenn alle Stricke reißen mache ich eben alles neu. Nur Übung mach den Meister ;-)
 
Ohne JVM wird es schwer JARs aufzuführen egal ob sie schon auf der Platte liegen oder per HTTP(S) nachgeladen werden.
 
Wesentlich einfacher ist es jedoch über das selbe Webinterface ins Rescue System zu booten. Wie viele anderer Hoster auch unterstützt Hetzner es ein Notfallsystem per PXE zu booten. Im Gegensatz zu den meisten anderen Billighostern bietet Hetzner jedoch auch FreeBSD Rescue Images an. Mit diesem kannst du dein System mounten und reparieren. Solltest du es hinreichend automatisiert haben ist es vllt. schneller neu zu installieren oder ein Backup einzuspielen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben