Humbug? Starke Äußerung zu einem Dienst der auf gefühlt 99% aller Unix/Linux-Server läuft.
Warum soll ein VPN mit Zertifikat sicherer sein als SSH mit Zertifikat?
Natürlich ist es humbug nur den root login zu deaktivieren.
SSH verwendest du ja - ÜBER den tunnel nicht statt.
Warum?
Weitere Sec Layer, 1 Sollte Man jede VPN Lösung nur mit min. double Auth nutzen, 2 muss Openvpn ja keineswegs ssl sein.
Fürs reguläre Login brauchst du so 1 das Certificate, 2 Login der den VPN Zugang genehmigt, 3 SSH Zugang (egal ob nun mit oder ohne Certs und oder user/pass)
Ausserdem kanns ja passieren das user shell zugriff haben von denen er gar nix weiß (zb aus Irtum, oder weil ihm mal jemand "geholfen" hat und dort user drinnen belässt, oder oder oder,.. weiterer Layer = mehr kontrolle, weitere hürde, weitere Möglichkeit fehler auszuschließen.
AD2, Ja ich nutze den Generator, das Tool ist auch keineswegs für Leute gedacht die NICHT Iptables kennen.
Allerdings wenn du nur ein klein wenig Ahnung hättest was alles so in
IPTables scripte gehört wüßtest du wie komplex Sie werden. Allein schon um die Human errer Rate zu rediuzieren, Objekte wiederzuverwenden, shadowing auszuschließen etc verwendet man so ein Tool
Ich verwendet zb zig (in simme von mehr als 40) Gruppen, mit mehr als 400 Custom Objects, hab zig zig zig interfaces zu verwalten, mit routing dazwischen, mit nat obendrauf, das ganze auf sehr vielen Boxen.
Mit dem "Generator" wie du es nennt (du kennst offensichtlich das Tool nicht) kannst du das gesamte DC von einer beliebigen Plattform managen, mit Versionierung.
Oder willst du behaupten es ist schlau xxx FIrewalls und Router, mit Branching, tagging, routing, NAT, etc manuell auf der CLI zu verwalten - na viel Spass dabei.
WEr ist hier jeztt der Troll?
@Joe
1-4 Nein Kein Nonsense du hast offensichtlich meine Post nicht wikrlich gelesen. Also nochmal für ganz langsame.
Bei SIcherheit muss du unterscheiden auf welchen LAyer wir sicherheit wollen.
Das zerlegen in verschiedene VHhosts hat sehr wohl sinn da ein kompromitiertes System nicht automatisch die anderen kompromitiert.
Beispiel, user verwendet xxx php irgendwas welches anfällig ist. Jemanden gelingt es das zu nutzen, erlangt vielleicht sogar root zugriff (wobei das behandeln wir gleich zu deinem anderen Blödsinn)
Jetzt hat er aber immernoch nur Kontrolle über eine VM, ned mehr ned weniger.
JEtzt müsste er das neue System ersat dazu benutzen andere Sicherheitslücken in den anderen VMs oder am Host zu finden.
So und hier kommen wir zum NAT und warum es sehr wohl sinnvoll ist.
Wenn weder am Host noch auf den VM´s alle Dienste in privaten Netzen laufen - nur ein DIenst (VPN) nach aussen Public kannst du nutzen was du willst du kommst nicht so einfach in die internen Dienste rein.
NAT verwendest du natürlich nicth um zb von VM1 nach aussen einen SSH Port durchzuschleusen, sondern nur die Ports die benötigt werden nach aussen. NAT Bietet hier tatsächlich einen Zusätzlichen Layer selbst wenn jemand durch die Firewall kommt
AD2 Wenn du in dieser Weise virtualisierst ist es als wäre die Hostfirewall eine externe Firewall - zumindest in Relation zu den VMS,
natürlich bleibt das Problem das Hostzugriff theoretisch zugriff auf die VMs ermöglicht. Das ist aber keineswegs trivial solange die Maschinen laufen und fällt auf (zb mit Nagios, Landscape, whatever) wenn die Überwachungssoftware div Reboots der VMs zu vermelden hat.
bzw kann man genau hier an einer Intrusion detection ansetzen. Aber stimmt natürlich wenn mal wer root zugriff auf den Host bekommt isses eigentlich schon vorbei
Genau das ist auch der Punkt.
Weiterer Vorteil der NAT variante. Sollte es Probleme mit dem FIrewall script geben, es zb nicht laufen, oder es Konditionen geben in denen es nicth läuft ist kein Dienst nach aussen offen. die ANgriffspunkte sind minimiert auf fast null
Ausserdem Arbeitet der Host dann als Bridgin Firewall und kann dir zumindest rudimentäre Isolation der VMs untereinander bieten.
Wer spass drann hat könnte auch Inter den Host zu einem Virtuellen VLAN ausbauen was bessere Isolation betrifft.
" Sobald auch nur ein einziger Kommunikationskanal zwischen den (virtualisierten) Systemen existiert, kann ich den als Angreifer ganz normal nutzen. Ob ich durch ein NAT oder einen Hypervisor, einen TCP- oder UNIX-Socket oder NTFS-Stream, ein NFS-Share, oder Sonstwas muss, spielt absolut keine Rolle."
Blödsinn so einfach ist das nicht. Es ist sehr wohl relevant welcher Kommunikationskanal das ist, welcher Dienst dort läuft und wie anfällig dieser ist bzw was passiert im Falle eines erfolgreichen Angriffs.
NAT ansich ist erstmal kein Kommunikationskanal sondern Mapping.
Ein Hypervisor auch nicht, das läuft auf Kernelebene/Hardwareebene - bring bitte nicht Äpfel mit Birnen durcheinander.
Du beschreibst hier Isolationschichten als Kommunikationskanal - du weist nicht wirklich was du hier schreibst oder?
DU hast
Public
-----------
HOST /HPV (VPN offen rest Dicht, kein Dienst ist sonst an eth0 oder ext Ip gebunden)
-----------BY NAT der DIENSTE (zb Port 80 und sonst nix) nach Intern
|
---------------
Private Netz der VMs, interne comm. etc
Alle Dienstbindungen auf die logischen Virtuellen Adapter
Alles was im Internen Netz läuft, läuft am Host intern über virtuelle Adapter auf Kernel ebene ohne Zugriff auf den Host kommst da nichtmal irgendwie ran.
Bist du in eine VM gelangt rennst du gegen die Firewall die am Host läuft - für die VM ist das wie eine Externe Firewall, du kommst da nicht ran auch wenn du den selben Physischen Speicher und CPU verwendest bleibt dir für den Angriff nur der logische Layer des Virtuellen Netzes
NAT ist nur der notwendige übergang für Dienste die man nach aussen braucht, wir arbeiten in einem internen logischen virtuellen Netz
Der HPV der dazwischen sitzt macht die Isolation spricht Schützt eine VM von der anderen. Die VMS wiederum schützen davor das ein ein Dienst nach aussen das ganze System offenlegt, jeder Zugang der zb auf Application layer erfolgt endet im bestfall in einer VM, nicht gleich im root.
So aus genug.
Ich habs einmal erklärt das muss reichen für mich ist das Thema erledigt.
PS: Zum THema Firewall am Host, natürlich ist sowas nicht das Optimum, der Threadersteller hat hier aber ganz klar von einer Box gesprochen als Deciacded Server. Die Sicherheitsbedingungen bei sowas sind NIE Ideal aber man kann das beste drauss machen.
Die Grundsatzaussage Firewall am schützenden System bringt nix ist falsch.
Es bringt einiges, natürlich sind Bulletproof und ETWAS unsicherer als eine dezitiere Firewall die hier sowieso nicht möglich ist.
Am Ende ist
1 keine FIrewall wirklcih total Sicher
2 Firewalls nur auf einem Layer aktiv aber zu mehr zu gebrauchen als simples port blocking
3 Weitere Sicherheitslayer wünschenswert in der Realität für den großteil der Netze und Rechner aber nicht machbar oder Leistbar für den Betreiber.
Wenn du ein Rechenzentrum betreibst hast du natürlich bessere Möglichkeiten, Tatsache ist wirkliche weitergehende Sicherheit sind für minilans mit 10 Clients/1 Server nicht bezhaltbar. Da kostet EIN PORT an einem gescheiten Switch meist mehr als der Server selbst. (abgesehen davon das in diesem Thread wohl kaum einer weis was er mit einen echten Managed Switch so machen muss und kann)
Also bitte die bloße Theorie die irgendwo aufgeschnappt wurde mal beiseite lassen. DIe Alternativen korrekten Lösungen sind oft weder durchführbar, noch leistbar noch findest sich so einfach jemand der euch das konfigurieren kann bzw auch noch auf langen Zeitraum managed.
))
) gelesen, dass du keine - also wirklich gar keine - iptables o.Ä. einsetzt. Im Hinblick auf das "Schließen von Ports" und anderen typischen Nonsens sind wir uns da sicher einig... Aber wie schützt du deine Server beispielsweise vor Synfloods und anderen per iptables leicht abzuwehrenden und ohne iptables leicht durchzuführenden (D)DoS-Angriffen?
