OT?: Ports blockieren ausser 443, 80, 8080 - gibt's einen Grund?
-
Hi, blöde Frage:
Gibt es einen vernünftigen Grund, eine Firewall so einzustellen, dass HTTP nur über Port 443 und Port 80 funktioniert? Wenn ja, welchen?Hintergrund: ich habe auf dem Server verschiedene Webserver am laufen (für verschiedene Zwecke). Damit die erreichbar sind, ist jeweils an der URL ein Port mitzugeben: z.B. "http://xx.xx.xxx.xx:2345".
Aus zwei Firmennetzwerken ist die URL nicht erreichbar - nach Kontaktaufnahme mit dem "Firewalldienstleister" musste Port 2345 freigeschaltet werden, dann ging alles normal.Ich verstehe nicht, wo der Sicherheitsgewinn liegt?
(Ist eigentlich kein PFSense-Thema, aber hier gibt's vielen Leute, die Kompetent sind, und sich nicht zu schade sind, eine Antwort auf eine dumme Frage zu geben)
Danke
E -
TL;DR = Dienste auf nicht spezifizierten Ports zu betreiben ist generell eine eher doofe Idee, wenn man möchte, dass möglichst alle Teilnehmer damit zurecht kommen. Deshalb gibt es ja Zuordnungen von DIenst X zu Default Port Y.
– Langfassung:
Weil die Ports schlicht und ergreifend nicht dafür definiert sind: Alle Ports >1024 sind non-specific und haben dementsprechend nichts mit HTTP(S) zu tun. Warum sollte ich die rein/rauslassen für ganz normalen Betrieb?
Wenn du irgendwelche (nicht böse gemeint) Bastelwebserver auf Fremdports XY aufsetzt, dann ist das deine Sache und du hast sicher deine Gründe dafür, aber die Ports sind nicht spezifiziert und könn(t)en alles mögliche sein, nur nicht HTTP(S). Deshalb erkennt ein Browser ja nunmal auch http = 80 und https = 443 und keiner muss einen Port angeben bei einer URL.
Warum sollte ich die Ports nicht blocken, wenn die Firmenpolicy bspw ist: Erlaubt: HTTP(S), SMTP, POP3S/IMAPS und sonst nichts? Wie soll ich solch eine Policy sonst spezifizieren wenn nicht über die definierten Ports der Protokolle?
Es ist IMHO völlig normal irgendwelche 0815 Ports abgehend zu blocken, da es in den allermeisten Fällen Software ist, die ich NICHT im Unternehmen haben möchte. Das kann bei Messengern anfangen, über P2P Software weitergehen bis hin zu irgendwelcher Malware, die sich zur Botsteuerung auf einen Port verbinden möchte. Da man noch dazu unter allen OSen != Windows zum Binden an Ports <1024 noch dazu Root Rechte braucht, sind oftmals irgendwelche Bots, Trojaner o.ä. gerne auf High-Ports >1024 zu Hause, da sich diese auch über Schwachstellen in Software auf einem System mit "nur" Userrechten einnisten können und dann sich eben nicht an Port 80/443 binden, sondern irgendwas freies brauchen.Somit ist es heute sehr oft so, dass von intern nach außen nicht mehr platt einfach alles aufgemacht wird. Schon alleine zur Schadensbegrenzung, wenn tatsächlich mal ein großes Oops passiert.
Grüße
Jens -
Danke für die ausführliche Antwort.
Gruss
E(was ist denn dann die vernünftigste Möglichkeit verschiedene Webserver (Bastelwebserver ;-)) unter einer einzigen IP-Adresse anzubieten, vor allem wenn diese auf verschiedenen Maschinen innerhalb des LAN (DMZ) liegen?)
-
Danke für die ausführliche Antwort.
Gruss
E(was ist denn dann die vernünftigste Möglichkeit verschiedene Webserver (Bastelwebserver ;-)) unter einer einzigen IP-Adresse anzubieten, vor allem wenn diese auf verschiedenen Maschinen innerhalb des LAN (DMZ) liegen?)
Wenn du einen Apache hast mach das mit VirtualHosts
Da schaut der Webserver dann welche Domain aufgerufen wurde
http://httpd.apache.org/docs/2.4/vhosts/examples.html
so kannst du mehere Webseiten auf einem Server mit einer IP und einem Port betreiben. Ist ganz normal sowas.Oder ein Reverse Proxy (Kann die PfSense mit Squid) der dann schaut welche Adresse bzw. welcher Pfad aufgerufen wurde und leitet dies dann an die entsprechende IP und Port weiter.
-
Oder ein Reverse Proxy (Kann die PfSense mit Squid)
Oder HAProxy
-
Wenn du einen Apache hast mach das mit VirtualHosts
Da schaut der Webserver dann welche Domain aufgerufen wurde
http://httpd.apache.org/docs/2.4/vhosts/examples.html
so kannst du mehere Webseiten auf einem Server mit einer IP und einem Port betreiben. Ist ganz normal sowas.Würde ich gerne mit VirtualHosts machen, habe aber das Problem, dass dazu eine funktionierende DNS-Auflösung von aussen Voraussetzung zu sein scheint.
Meine "internen" Server können aber nur innerhalb des LAN über den eigenen DNS-Server aufgelöst werden.
(Grund dafür: ich habe einen Webserver für die "normale Webpräsenz" bei einem Hoster stehen und trage bei diesem Hoster Subdomains in die DNS-Config ein, über die ich gerne Server in meinem LAN zugänglich machen würde …).
Damit geht vermutlich dann auch die Lösung über HAProxy eher nicht (weil bei einer Weiterleitung dann die interne IP, bzw. der Hostname in der URL stehen würde ...).Gruss
E -
Das ist richtig. VirtualHosts geht über DNS.
Wenn du den DNS nicht anfassen kannst oder willst hast du noch die möglichkeit deine hosts Datei anzupassen und da die Einträge zu machen. -
Hallo Edgar,
das ist mir ein wenig unklar, weshalb das nicht via DNS gehen sollte? Deine internen Server werden momentan nur über den eigenen DNS aufgelöst. Wahrscheinlich mit einem "internen" Namen der ggf. nicht extern eingetragen werden kann? (also .local oder sowas?)
Was spräche denn dagegen, ihnen zusätzlich noch einen anderen DNS Namen zu geben, den du extern eintragen kannst? Habe ich sowohl bei mir in der Firma als auch in anderen Konstellationen schon mehrfach so erlebt. Intern haben die VHosts dann meistens Entwicklungsnamen wie <kunde>.<devdomain>.de oder <projekt>.<domain>.intern und extern dann sowas wie <kunde projekt="" kurzzeichen="">.dev.<domain>.de.
Also bspw. in einem Windows AD Netz kenne ich Konstellationen wie:
test.firma.local / test.firma.intern (interner DNS)
test.ext.firma.de / test.dev.firma.de (externer DNS)Da aber inzwischen selbst intern ja "normale" Domains verwendet werden sollen und keine Dummies mehr (wie .local oder .intern oder .firma) weil man für diese keine SSL Zertifikate (mehr) bekommt, ist das inzwischen immer weniger ein Problem. Manchmal werden auch * Domains eingetragen, die auf die externe IP der Firma zeigen wie *.ext.firma.de oder *.dev.firma.de, damit der arme Admin nicht ständig irgendwelche neuen Projektdomains in den DNS klöppeln muss ;)
Grüße</domain></kunde></domain></projekt></devdomain></kunde>
-
Hallo,
vielleicht versteh' ich's nicht richtig:
So ist der Stand:
beim Provider liegt der Hauptwebserver mit der registrierten Domain mydomain.com (Für die ganz normale Webpräsenz).
In der Config auf dem Providertool ist eingetragen, dass die Subdomain mytest.mydomain.com per A-Record auf die (offizielle, externe) IP meines LANs zeigen soll also xx.xxx.xxx.xx.
Funktioniert soweit auch. Wenn ich im Browser mytest.mydomain.com eingebe, lande ich auf meinem "internen webserver1" (Port 80 - ganz normal).Jetzt häte ich gern die Subdomain mytest2.mydomain.com auf einen internen webserver2 gelegt. (Subdomain ist analog beim Provider registriert und zeigt auf die gleiche IP).
auf webserver1 habe ich:
-
in der /etc/hosts eingetragen: 192.168.100.66 webserver2 [ping von webserver1 auf webserver2 funktioniert]
-
in der http.conf
<virtualhost *:80="">ServerName mytest2.mydomain.com
redirect / http://webserver2</virtualhost>
Wenn ich innerhalb des LANs nun die URL mytest2.mydomain.com eingebe lande ich auch webserver2.
Von "ausserhalb" kann aber webserver2 nicht aufgelöst werden (logisch) und ich bekomme einen Timeout.Gruss
E -
-
dann müsstest du einen Proxy einsetzen durch den dann alle Verbindungen gehen und dieser entscheidet dann anhand der Subdomain an welchen Server das Ganze weitergeleitet wird.
Ob du nun Squid oder HAProxy nimmst bleibt dir überlassen.
-
Gibt es irgendwo eine verständliche Anleitung für HAproxy? (ich meine das Paket für pfSense).
Das LoadBalancing brauche ich ja eigentlich nicht, nur den Proxy. Allerdings finde ich es äusserst schwer verständlich, was da an Terminologie in der GUI d'rin ist. Mir fehlen da die Grundlagen …
Danke
E -
auf webserver1 habe ich:
das ist völlig wurscht :) und noch dazu nicht richtig ;) In der Konfiguration auf deinem Webserver machst du überhaupt keine Umleitung, der weiß nämlich nix davon.
mytest.mydomain.com
mytest2.mydomain.com
mytest3.mydomain.com
…sollen alle auf die gleiche IP (deiner externen LAN IP) zeigen. Das kannst du in deinem Providertool auch reinbasteln. Wenn es gut ist, kannst du da auch (bspw.) *.dev.mydomain.com reinmachen, dann kannst du alles mögliche statt dem * schreiben und musst nicht immer nen neuen A Record eintragen. Aber egal.
Dann wirfst du HAProxy oder Squid oder auch Apache Reverse Proxy auf deine pfSense. Bei HaProxy definierst du entsprechend ein Frontend (auf welche IP und welchen Port soll haproxy hören) und ein Backend (an welche/n Server soll er Sachen verteilen). Um mehrere Hosts auf das gleiche Backend zu schicken, legst du einfach weitere Frontends an, wählst gleiche IP/Port aus und den Haken bei Shared Frontends rein (soweit ich mich recht erinnere). Dann in jedem Frontend unter ACLs einen Eintrag machen mit "Host matches:" und dort die Domain die er erfassen soll, also bspw. mytest2.mydomain.com
Für jeden Host ein Frontend mit ACL und dann sollte das fluppen.
-
… das macht's jetzt schon klarer (die Variante mit HAproxy würde ich nehmen).
Die Einträge habe ich gemacht.
Allerdings stehe ich komplett auf dem Schlauch wenn ich lese:"NOTE: You must add a firewall rule permitting access to this frontend!"
Mir ist kompett schleierhaft, wie die Regel aussehen muss ...
Sorry für meine Dummheit.
E
-
Je nachdem auf welcher IP und welchem Port dein HAProxy lauscht musst eben dort eine Regel einrichten.
Wenn er z.B. auf dem WAN Interface auf dem Port 80 lauscht musst du hierfür eine Regel anlegen die das erlaubtSource Any| Dest. IP -> Wan IP | Dest Port -> 80
-
(Vielleicht sollte man einen neuen Thread aufmachen?)
Sorry - ich bekomm's nicht hin:
Nach den Hinweisen von JeGr habe ich ein Frontend definiert:
- "Listen address" => meine externe IP-Adresse Port 80
ACL => Host contains "mytest.mydomain.com"
und ein Backend:
- "Forwardto" => interne IP-Adresse vom mytest (192.168.0.251) und Port 80
Ausserdem noch die Regel auf dem WAN Interface:
Source Any| 192.168.0.251 -> externe IP-Adresse| Port 80 -> 80
Wenn ich versuche mytest.mydomain.com aufzurufen bekomme ich nur einen TimeOut.
Sollte aber doch klappen?
Gruss
E - "Listen address" => meine externe IP-Adresse Port 80
-
Okay ich gebe zu die Regel war doof beschrieben ;)
hier nochmal die Regel die auf dem WAN Interface (also das auf welchem deine externe IP-Adresse liegt)ID Proto Source Port Destination Port Gateway Queue Schedule Description
IPv4 TCP * * WAN Adress 80 * noneWAN Adress wäre dann bei dir deine externe IP-Adresse
auch mal versuchen von extern zu testen nicht das es da Probleme gibt weil du auch hinter der selben Firewall sitzt die Proxy macht
-
… ich weiss, ich nerve langsam, aber ich weiss nicht mehr weiter:
Die Regel habe ich lt. Angabe formuliert.
Im HA-Frontend habe ich die externe IP eingetragen (WAN VIP for CARP config) mit Port 80
in der ACL steht "myserver1" -> Host contains: myserver1.mydomain.comIm HA-Backend steht:
Name "test", Forwardto "Address + Port" Address: 192.168.xx.xxx Port: 80Alles Weitere habe ich gelassen wie's ist (das meiste leer).
Ein Ping auf myserver1.mydomain.com bringt die (richtige) externe IP-Adresse (die providerseitige Weiterleitung stimmt also).
Das Logging habe ich auf dem HAproxy aktiviert - allerdings kommt ausser "Proxy test startet" (bzw. stopped) nichts weiter an.
Die Eingabe von myserver1.mydomain.com (von einem externen Rechner) endet mit einem Timeout.
Woran kann's denn noch liegen?
Gruss
E -
wie sieht denn der Hacken "WebGUI redirect Disable webConfigurator redirect rule " unter System: Advanced bei dir aus?
kannst du mal einen Screenshot der Regeln machen die du erstellt hast?
-
die Checkbox bei WebGUI redirect ist nicht aktiviert!
Regeln gibt's relativ viele. (Ich habe einige Portforwardings eingestellt - eben die möchte ich ja ersetzen!)
Allerdings habe ich diese immer zum Testen deaktiviert. (Was die Testerei nicht eben einfacher macht …).Stimmen denn die Einstellungen die ich beim HAproxy gemacht habe grundsätzlich?
Gruss
E -
zum HA Proxy kann ich leider nicht viel sagen. Die Regeln wären da erst mal wichtiger.
Mit dem NAT ist so eine Sache da sollten vorher die States der PfSense mal gelöscht werden.
Wenn das Ding schon produktiv ist kannst du das natürlich nicht so einfach machen.