15
Web Dienste auf Port 8090 (feddit.de)
submitted 3 years ago by to c/de_edv@feddit.de
37 comments fedilink hide all child comments
 

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
[–] 7 points 3 years ago (2 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 4 points 3 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 3 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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 3 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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 3 points 3 years ago (1 child)

    Schon mal von DoH gehört?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago (1 child)

    Ja. DoH wird über TCP transportiert, was inhärent schon einen weiteren möglichen Angriffsvektor (DNS Reflection DDoS) verhindert. Ist nett, wenn mans nutzen kann.

    Hast du schonmal in einem Unternehmensnetz gearbeitet?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago (1 child)

    Es ging um Bypassen des Unternehmens-DNS, was mit DoH direkt geht. Da kannst dich mit Portbasierten-DNS-Blockaden brausen geheb.

    Was jetzt DNS Reflection damit zu tun hat versteh ich da nicht ganz. Durch die Portblockade kannst du nur einen ausgehenden Angriff verhindern, und ob der Angreifer aus deinem Netz eine DNS Reflection DDOS fährt oder irgendeinen DDOS über HTTP(S) macht jetzt auch keinen Unterschied.

    Und ja, natürlich habe ich, und deswegen weiß ich auch, dass locker 80% der IT-Security-Leute voll auf Nonsense-Sicherheitstheater stehen, weil sie nur Checkboxen abarbeiten und von der eigentlichen Materie keine Ahnung haben.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago (1 child)

    und ob der Angreifer aus deinem Netz eine DNS Reflection DDOS fährt oder irgendeinen DDOS über HTTP(S) macht jetzt auch keinen Unterschied.

    Der Unterschied ist dass der zweite Angriff technisch ausgeschlossen ist. Ist schon ein Unterschied wenn du mich fragst.

    Und ja, natürlich habe ich, und deswegen weiß ich auch, dass locker 80% der IT-Security-Leute voll auf Nonsense-Sicherheitstheater stehen, weil sie nur Checkboxen abarbeiten und von der eigentlichen Materie keine Ahnung haben.

    Es ist nicht so dass die restlichen 20% den totalen Durchblick haben weil sie Compliance (korrekterweise) für Theater halten. Kannst du hier im Thread nachlesen. Ich fragte weil deine Art Fragen zu stellen (bzw. zu unterstellen dass du mehr weißt als der Kommentato) nach Computer-Bild und Heise-Forum riecht.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago

    Du hast gesagt, DNS per Port blockieren erhöht die Sicherheit, weil dann keiner den verpflichtenden DNS der Firma umgehen kann.

    Jeder Browser kann inzwischen DoH und viele andere Software auch. Damit kann man auch so den DNS umgehen. Das war mein Punkt.

    DNS per Port blocken bringt im Endeffekt genau gar nichts. Hat der Nutzer genug Rechte um auf seinem PC den DNS umzustellen, dann kann er auch DoH verwenden und kommt damit um deinen DNS rum.

    Deswegen halte ich das für Sicherheitstheater.

    DNS Reflection kannst du auch intelligenter blocken indem du die maximale Bandbreite für DNS pro Client limitierst.

    Sobald du Port 443 ausgehend erlaubst, ist aber so oder so eigentlich alles wurscht, weil du ohne SSL DPI keine Chance hast zu erkennen, was tatsächlich über den Port raus geht.

    Stattdessen führen solche Blockaden zu erhöhter Reibung, sorgen dafür, dass die Mitarbeiter ihre Arbeit nicht erledigen können und bringen quasi gar nichts für die Sicherheit.

  • permalink
  • fedilink
  • source
  • parent