RootForum Community

Hallo Leute,
es geht darum diverse Server (alle beim gleichen Hoster) plus einige "Road-Warriors", also Leute in irgendwelchen Netzten über ein OpenVPN zu verbinden. Momentan läuft dazu OpenVPN über TCP. Dadurch können alle Leute mit dem Notebook von überall her verbinden softern kein Firewall installiert ist der den OpenVPN-Port blockt.

Ich würde nun gerne auf UDP umsteigen, weil ich mir dadurch eine Performance-Steigerung verspreche. Die Frage ist nur: Können die Leute mit dem Notebook immernoch von überall her verbinden? Oder muss der Router UDP-Packages durchlassen? Ist das normalerweise so möglich oder nicht?

Wer hat damit erfahrungen? Funktioniert ein UDP-Zugriff zuverlässig in den meisten Netzwerksetups?

danke
TO

Wenn Du bisher den OpenVPN Standard-Port 1194 über TCP verwendest und damit keine Probleme hast, sehe ich keinen Grund, warum das nicht auch mit dem selben Port über UDP gehen soll.

Wenn ein Router beliebige TCP-Ports ausgehend routet, tut er das normalerweise auch für UDP.

Home-Router für DSL und Co. natten für gewöhnlich sowohl TCP wie auch UDP auf allen Ports. Sollten die Anwender jedoch in fremden Firmennetzwerken sitzen, könnte es da schon eher Probleme geben.

Ich wage zu bezweifeln dass es viele Firmennetze gibt, die OpenVPN (weder via TCP noch via UDP) standardmäßig nach draußen lassen. Falls doch, gehört der CSO jedenfalls gefeuert. ;)

Ich wage zu bezweifeln dass es viele Firmennetze gibt,

D'accord. Wenn auch nicht viele, aber es gibt sie. Ich habe schon ein paar davon gesehen. ;)

Falls doch, gehört der CSO jedenfalls gefeuert.

Die sind meist so klein, da gibt es keinen dedizierten CSO. ;) Bei Großkonzernen wird's wohl in der Tat kaum ein solch offenes Netz geben.

CaptainCrunch wrote:Falls doch, gehört der CSO jedenfalls gefeuert. ;)

Findest Du? Klar wir in vielen Firmennetzen der ausgehende Traffic per Whitelist gefiltert, aber ich halte das eigentlich für eine "Cover your ass" Massnahme, d.h. der Admin kann sich gegenüber seinem Chef darauf berufen, das Netz nach "Industry Standard Best Practices" (TM) abgesichert zu haben. ;)

Wenn ich will, kann ich mein VPN doch immer noch über port 25/80/443/53/22 usw. laufen lassen. Sofern nicht jeder der offenen Ports durch einen entsprechenden Proxy läuft, oder eine genaue Analyse des Traffics nach auffälligen Mustern ("100 MB DNS traffic in 10 Minuten von $IP") durchgeführt wird, kann man das Whitelisting doch auch gleich sein lassen.

Die sind meist so klein, da gibt es keinen dedizierten CSO.

s/CSO/"Admin"/ ;)
Aber du hast natürlich Recht: ich rede von einer Idealvorstellung, die eh nur in seltenen Fällen Wirklichkeit ist.

Findest Du?

Klar, daher steht's da. Und weiterhin klar: wer fähig genug ist, seinen Traffic raustunneln zu können, wird das auch ganz ohne VPN schaffen. Möglichkeiten via ICMP, DNS und Co. gibt's ja schließlich zuhauf.

Eine "cover your ass"-Maßnahme ist "Whitelisting" trotz allem sicherlich nicht. Um mal auf deine Besipiele einzugehen, würde ich gerne meine "Lösung" aufzeigen, wie sich das von dir genannte Problem umgehen lässt:

- Port 25:
SMTP wird über ein zentrales Gateway abgefackelt. Kein anderes System sonst darf via Port 25/567 raus.

- Port 80 / 443
Jeder halbwegs vernünftige Proxy ist in der Lage, zwischen "legitimem" Webtraffic und OpenVPN zu unterscheiden. Natürlich sieht's im Fall von HTTPS-Traffic anders aus, aber selbst hierfür gibt's Maßnahmen (Balabit macht sowas z.B. mit dem kommerziellen Zorp)

- Port 53
Darf halt nur der zentrale DNS-Server, alle anderen haben diesen zu befragen

- Port 22
Wieder so ein Fall: wer SSH offen für alle nach außen öffnet, muss sich über "lustigen" Traffic im Netz nicht wundern.

So viel mehr "Standardports" gibt's nun auch nicht, und wenn, lassen sich diese immer noch bei Bedarf öffnen. In Verbindung mit der von dir schon genannten "Anomaly Detection" oder einem passenden IDS (um ganz bewusst nicht von IPS zu sprechen) geht das dann schon erheblich weiter als "cover your ass". Dass es perfekte Sicherheit niemals geben wird ist genau so klar, aber dem ordinären "Freizeithacker" und einem größeren Malware-Ausbruch lässt sich so schon erheblich besser ein Riegel vorschieben.

dustpuppy wrote:Wenn ich will, kann ich mein VPN doch immer noch über port 25/80/443/53/22 usw. laufen lassen. Sofern nicht jeder der offenen Ports durch einen entsprechenden Proxy läuft, oder eine genaue Analyse des Traffics nach auffälligen Mustern ("100 MB DNS traffic in 10 Minuten von $IP") durchgeführt wird, kann man das Whitelisting doch auch gleich sein lassen.

Wenn man HTTP/FTP/HTTPS (gut, HTTPS ist eine Lücke, aber die muss man wohl hinnehmen) über einen Proxy laufen lässt, ist der meiste andere Traffic durchaus irgendwelchen Aktion auf spezifischen Maschinen zuzuordnen[0] und damit prima über eine Whitelist abdeckbar.
Die aussage, dass man "Whitlistling doch auch gleich lassen kann" halte ich für gefährlich bis unsinnig.

---
[0]: Was passiert den in den meisten Firmennetzen (an Traffic der wirklich aus dem NEtz geht)? Der Mailserver sendet und empfängt Mails, dann sind da vielleicht noch ein paar VPNs in andere Netze und evtl. Roadwarrior die per VPN reinkommen. Ansonsten besteht das meisten aus gesurfe der Anwender, irgendwelche Virenscannern und sonstiger Software die sich updaten/nach Hause telefonieren will.
Meiner Erfahrung nach sind die meisten Firmennetze, unterhalb von Layer 4, ausgesprochen langweilig und ganz einfach über Whitlisten abdeckbar.

CaptainCrunch wrote:wer fähig genug ist, seinen Traffic raustunneln zu können, wird das auch ganz ohne VPN schaffen. Möglichkeiten via ICMP, DNS und Co. gibt's ja schließlich zuhauf.

- Port 25:
SMTP wird über ein zentrales Gateway abgefackelt. Kein anderes System sonst darf via Port 25/567 raus.

- Port 80 / 443
Jeder halbwegs vernünftige Proxy ist in der Lage, zwischen "legitimem" Webtraffic und OpenVPN zu unterscheiden. Natürlich sieht's im Fall von HTTPS-Traffic anders aus, aber selbst hierfür gibt's Maßnahmen (Balabit macht sowas z.B. mit dem kommerziellen Zorp)

- Port 53
Darf halt nur der zentrale DNS-Server, alle anderen haben diesen zu befragen

- Port 22
Wieder so ein Fall: wer SSH offen für alle nach außen öffnet, muss sich über "lustigen" Traffic im Netz nicht wundern.

So viel mehr "Standardports" gibt's nun auch nicht, und wenn, lassen sich diese immer noch bei Bedarf öffnen. In Verbindung mit der von dir schon genannten "Anomaly Detection" oder einem passenden IDS (um ganz bewusst nicht von IPS zu sprechen) geht das dann schon erheblich weiter als "cover your ass". Dass es perfekte Sicherheit niemals geben wird ist genau so klar, aber dem ordinären "Freizeithacker" und einem größeren Malware-Ausbruch lässt sich so schon erheblich besser ein Riegel vorschieben.

Nein, wenn man es "richtig" macht (s.o., Proxy hinter jedem offenen Port, IDS) ist es natürlich keine "Cover your ass" Massnahme. Sorry wenn ich mich hier unklar ausgedrückt habe.

Aber mal ehrlich, "da draußen" wird man so ein Setup bei den wenigsten Firmen finden. In vielen Fällen wird das aus Mangel an Zeit/Geld/Personal/Know-How eben nicht so gemacht, sondern einfach stur alles was nicht Web oder Mail ist, geblockt. Meistens ist die Freischaltung eines weiteren Ports dann auch unmöglich, oder mit immensen bürokratischen Hürden verbunden.
Und das halte ich für Mist, weil das gegen einen Mitarbeiter, der wirklich Daten herausschmuggeln will, schon mal gar nicht hilft ("unterschätze nie die Bandbreite einer USB-Festplatte", frei nach Tanenbaum) und gegen einen halbwegs gescheit programmierten Trojaner auch nicht. Wogegen es aber wunderbar hilft, ist gegen ehrliche Mitarbeiter, die zum Erledigen ihrer Arbeit so exotische Sachen wie ftp (böse !!!11einself!), cvs oder svn brauchen. ;)

Datenschmuggel per USB-Device ist natürlich ein großes Risiko, fällt aber erheblich eher in die Abteilung "Client-Security". Wer da schlampt, brauchst sich nicht wundern wenn seine noch so ausgeklägelten "externen" Maßnahmen nicht greifen.
Die o.g. Maßnahmen helfen übrigens wunderbar auch gegen halbwegs noch intelligenter programmierte Trojaner, auch wenn du da anderer Ansicht zu sein scheinst.

Deine letzte Äußerung hingegen kann ich noch weniger nachvollziehen. Sofern es um benötigte Arbeitsmittel geht (die nicht gegen grundlegenste Sicherheitspolicies verstoßen) dürfte sich wohl kaum ein "ernsthafter" Firewall-Admin dagegen sperren.