this post was submitted on 05 Aug 2023
15 points (100.0% liked)

de_EDV

3805 readers
1 users here now

Ableger von r/de_EDV auf Lemmy.

News, Diskussionen und Hilfestellung zu Hard- und Software

Diese Community dient als Anlaufstelle für alle IT-Interessierten, egal ob Profi oder blutiger Anfänger. Stellt eure Fragen und tauscht euch aus!

Weitere IT Communitys:

[email protected]

[email protected]

[email protected]

[email protected]

founded 2 years ago
MODERATORS
 

Servus an alle,

würde mal gerne die Kollektivmeinung hören.

Ich hatte diese Woche die Anforderung "Wir nutzen einen Web Dienst und da steht in der Beschreibung 'Geben Sie an der Firewall Port 8090 zu api.xxx.xxx frei sonst funktioniert das nicht'"

Nun blockt unsere Firewall das natürlich. Der "einfach Weg" wäre jetzt einfach eine Regel zu machen. Ich sehe da aber das große Ganze, wenn jeder Website Betreiber solche "Extras" wollen würde, wäre der Aufwand enorm.

Wie seht Ihr das? Hättet Ihr einfach die Firewall angepasst? Seht Ihr zwingende Gründe warum das so sein muss. (IP Knappheit ließe sich m.E. mit einem Reverse Proxy besser lösen)

Schönen Gruß

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 0 points 2 years ago (16 children)

Der Dienst ist im Internet und auf Port 8090 ansprechbar. Wir erlauben an der Firewall für Web nur 80/443 ausgehend. Das ganze Web spielt sich ja im Prinzip auf 80/443 ab.

[–] [email protected] 13 points 2 years ago (15 children)

Diese Logik habe ich noch nie verstanden. Also insbesondere das Blocken von ausgehenden Ports. Es gibt genug Dienste, die auf anderen Ports laufen. z. B. MySQL 3306, Postgres 5432, MongoDB 27015 etc. Klar kann man das alles über einen Reverse-Proxy lösen, aber genau deswegen macht es ein System ja nicht sicherer. Malware wird natürlich nur über 80/443 Daten exfiltrieren.

[–] [email protected] 7 points 2 years ago (8 children)

Also insbesondere das Blocken von ausgehenden Ports.

Outbound NTP erlaubt: NTP reflection attacken funktionieren von deinem Netz aus

Outbound DNS erlaubt: Deine internen DNS-Filter können nun gebypasst werden

Outbound SMTP erlaubt: Deine public IP ist nun auf einer Blacklist weil sie Spam verschickt hat

Hat schon seine Daseinsberechtigung für bestimmte Dienste.

[–] [email protected] 4 points 2 years ago (2 children)

Alle deine angeführten Beispiele erfordern, dass das User-System bereits korrumpiert ist. Du kannst den Traffic auf diesen Ports ja monitoren um zu erkennen, dass ein Botnet in deinem Netzwerk läuft und dann regieren. Aber präventiv Outbound-Ports zu sperren schützt dich nicht vor einem Botnet.

Outbound-DNS zu sperren ist auch absurd. DNS-over-HTTPS ist einfach im Browser einstellbar. Sicherheitstheater.

[–] [email protected] 2 points 2 years ago

Alle deine angeführten Beispiele erfordern, dass das User-System bereits korrumpiert ist.

Ein korrumpiertes User-System würde ich als Gegebenheit betrachten, mit der das Netzwerk genauso fertig werden muss wie mit irgendeinem kaputten Netzteil. Soll nicht vorkommen, wird es aber und wenn es soweit ist soll der Impact so klein wie möglich sein. Wenn ich sicher weiß, dass ich Outbound-SMTP nicht brauche, warum soll ich es zulassen und ein Risiko eingehen? Und sei es bloß das jemand Spam verschickt.

[–] [email protected] 1 points 2 years ago

Aber präventiv Outbound-Ports zu sperren schützt dich nicht vor einem Botnet.

Hat zum Glück auch niemand behauptet. Aber: Wenn du keine Maßnahmen für den Fall der unausweichlichen Kompromittierung triffst, ist das halt auch scheiße. Wenn du mir nicht glauben willst steht es dir natürlich frei, das durch eigene Schmerzen zu lernen.

load more comments (5 replies)
load more comments (11 replies)
load more comments (11 replies)