Re: Sicherheitskonzept eines neuen Servers
Gruesse!
* Ace Dahlmann <ace@hs-media.net> schrieb am [21.11.05 13:54]:
> Hi!
>
> > > Zunächst mal werde ich zwei NICs einbauen, um die Ports schön nach
> > > Interfacce zu trennen.
> >
> > Hält die externe NIC die Verbindung zum Provider-Gateway oder ist noch
> > ein Router zwischengeschaltet? Ich gehe aber von ersterem aus. Auf
> > jedenfall vernünftig.
>
> Der Server hängt (bisher) am Switch und dahinter kommt dann noch der
> DSL-Router.
Ah, der Router wäre also der "Angriffspunkt". Und es ist dein
Heim-Netzwerk, zu dem du nur ab und an von außerhalb an dein Home bzw.
deine Mail im Home per ssh ran willst. Sonst hast du definitiv nicht
vor, andere Dienste ins Internet anzubieten? Dann...
> Ich bin noch am Überlegen, ob ich die beiden Verdindungen der beiden
> NICs einfach mit an den Switch hänge und am Router nur die Verbindung
> der externen NIC des Servers freigebe,
würde ich wahrscheinlich dies tun. Und da nur zu Port 22 (sshd).
> oder ob ich den Server gleichzeitig als Gateway konfigurieren soll,
> sprich, dass an der internen NIC der Switch hängt und an der exterenen
> NUR der Router...
> Ich weiß momentan aber auch nicht, ob mein DSL-Router das kann, denn
> wenn ich nicht irre, muss der Router dafür eine nach innen gerichtete
> Default-Route definieren können!? Oder reicht es, den Server im Router
> als DMZ anzugeben? Weiß er dann, wo er die Daten nach innen weiter
> routen muss?
Mit Routing würde das IMHO sicher gehen, würde aber dem DMZ Prinzip
widersprechen, innere und äußere Dienste physikalisch und logisch zu
trennen. Dein Rechner in der DMZ wäre aber gleichzeitig Server für
Clients im LAN und (per sshd) fürs Badland.
> > > Den SSH würde ich zum einen
> >
> > Und überlegen AUTH nur per Key zuzulassen und Passwort-Auth zu
> > disablen.
>
> Ehrlich gesagt habe ich es bisher nie wirklich hin bekommen, Auth per
> Key vernünftig zu konfigurieren.
Ist dann sicher ein seperates Problem, zu dem es auch genügend Doku
gibt. Deinen Public Key mußt du dann halt immer dabei haben.
> > Mit xringd ist da sehr gut etwas zu machen. Hat die gleichen
> > umfangreichen Möglichkeiten wie portknocking (halt "Tonsequenzen"
> > statt knock key), dafür brauchst du halt nur ein Telefon/Modem/... als
> > Client.
>
> Ich hätte eine ISDN-Karte (passiv) übrig (und freue mich dann jetzt
> schon auf die Konfiguration dieser mit dem 2.6er Kernel. :rolleyes: Bei
> meinem Vater hatte ich es mit dem 2.6er vor ein paar Monaten nicht
> hinbekommen)
xringd geht (vons Haus aus) IMHO auch mit Modems (serial connections).
Nachtrag zu dem Gedanken mit xringd etc. von fremder Hardware daheim
Dienste zu starten: z.B. bei einfachem <Telefonnummer>+Keynummern nicht
vergessen, dieses z.B. aus der Wahlwiederholung rauszunehmen. Nichts ist
peinlicher seine "Spuren" in irgendwelchen Historys für die "Nachwelt"
zu erhalten ;-)
> > Wie du es ansprichst und auch weißt: der "internen" Absicherung (auch
> > der angeschlossenen Clients) ist mindest genausoviel Aufmerksaamkeit
> > zu schenken wie du es nach außen ins Badland betreiben willst - eher
> > mehr.
>
> Daher die Idee, den DSL-Router ggf. nach "außen" zu setzen. Dann könnte
> ich auch mit reinem Gewissen die WLAN-Funktion dessen nutzen.
>
> > Trügerisch. Es gibt sicher "bessere" Möglichkeiten Rechner _im_ LAN zu
> > capturen als ein sshd.
>
> Oha! Wie denn z.B.?
Ich meinte damit, _wenn_ ein Angreifer auf deinen Server gelangt dann
kann er wie ein normaler Client agieren (z.B. nfs, smb, eigene Dienste
starten, ...)
> > Ich würde lediglich, wie
> > oben angesprochen, darauf achten daß _du_ (jetzt und später) jederzeit
> > verstehst Was Wie und Warum passiert. Vor allem wenn du verschiedene
> > externe Konzepte einsetzt. Also lieber _ein_ gutes Schloß an der Tür
> > als 15 verschiedene.
>
> Ok, tnx. Bzw: Was sagst Du denn zu der Thematik iptables oder nicht?
Das alte Thema personal firewalls... ;-)
Du kannst definitiv darauf verzichten wenn kein Dienst von außen zu
erreichen ist. Kein lauschender Dienst am Port = kein Angriff. Beim sshd
willst du ja von außen zugreifen können, also würdest du diesen in einer
FW-Konfig auch öffnen. Aber: würdest du Rolläden an Außenwände setzen wo
gar keine Fenster sind?
Sich um die vernüftige Absicherung der Server/Clients zu kümmern ist
wesentlich sicherer, als sich auf eine vermeintlich mit der Anzahl der
bunten Bilder oder der Regeln steigende Abwehr zu verlassen.
Außerdem: deine Firewall-Konfig findet doch auf dem Router statt? Eine
zusätzliche auf dem Server wäre unsinnig. Ich finde allerdings die
Logging-Möglichkeiten bei z.B. iptables hilfreich, um z.B. Art,
Zeitpunkt und Häufigkeit diverser Zugriffe zu protokollieren um diese
dann ggf. mit "Auffälligkeiten" im LAN zu kombinieren.
Sinnvoll als Sicherheit auch, um z.B. _vom_ LAN nur bestimmte Dienste
z.B. zum Server bzw. ins Internet zuzulassen. Wichtig IMHO weil z.B.
vermehrt Trojaner über "legale" Dienste (mail) ins LAN geschleppt
werden. Und wenn jetzt die FW so konfiguriert ist: von Innen nach außen
alles erlauben, dann gute Nacht. Obwohl wir von außerhalb ja nie
angreifbar waren...
Und als ultima ratio würde ich z.B. iptables gegenüber Außen auch noch
einrichten, um mich vor eigenen Fehler beim Konfigurieren bzw.
Inbetriebnahme eines Dienstes zu schützen.
> Best regards...
> Ace Dahlmann
Gruß
Gerhard
--
Linux ist wenn es trotzdem geht...
Reply to: