Web Dienste auf Port 8090 German

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ß

elmicha,

Ist dieser Web-Dienst im Internet und Ihr blockiert ausgehende Verbindungen? Oder möchten die Kollegen einen Web-Dienst anbieten, der auf Port 8090 hört?

SebMaus,

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.

CoLa666,

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.

the_third,

Naja, security by green checkmark halt, woll. Ich erlebe das öfter bei großen Kunden, dass gute Teile des IT-Sicherheitskonzepts schlicht Cargocult sind.

CoLa666,

Cargokult und Sicherheitstheater … leider. Störendster Faktor sind noch Passwortregeln, insbesondere vorgeschriebene Intervalle zum Wechsel.

taladar,

Und kurze Passwort-Maximallängen.

SebMaus,

Ja klar - aber alles was du nennst sind auch keine Web Dienste. Unsere Firewall ist recht restriktiv. Und ich würde auch nicht wollen das unsere Andwender nach außen eine MySQL Datenbank ansprechen. Für Dienste die etabliert und standardisiert sind werden dann Regeln angelegt.

elmicha,

Ok, dann leg die Regel halt an. “Kennen wir nicht, ham wir keine Lust zu” ist als Grund ein bisschen schwach. Wäre die API denn sicherer oder besser, wenn sie auf Port 80 oder 443 liefe? Da würdest Du nicht mal mitbekommen, dass jemand sie benutzt.

alphafalcon,

Die API wäre dann vermutlich nicht besser, aber mein Gefühl bei einem Dienstleister (?), der zu faul / planlos ist, seine Webservices auf Standardports ansprechbar zu machen ist nicht gut. Das riecht nach “da hat der Praktikant mal was mit nem Framework auf gebastelt und das ist jetzt produktiv”

Ist mehr ein Gesamteindruck-Bauchgefühl als eine ganz stringente Herleitung, aber ich kann OPs Bedenken durchaus nachvollziehen.

Insbesondere, weil es halt mit “Port auf” nicht getan ist. Da wollen dann noch SSL-Inspection und der Rest vom Regelwerk angepasst werden.

TeddyPolice,
@TeddyPolice@feddit.de avatar

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.

squaresinger,

Schon mal von DoH gehört?

TeddyPolice,
@TeddyPolice@feddit.de avatar

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?

squaresinger,

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.

TeddyPolice,
@TeddyPolice@feddit.de avatar

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.

squaresinger,

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.

CoLa666,

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.

the_seven_sins,
@the_seven_sins@feddit.de avatar

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.

TeddyPolice,
@TeddyPolice@feddit.de avatar

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.

___qwertz___,

Nö. Wieso sollte ich deren Arbeit erledigen, wenn die zu faul sind ein Reverse Proxy einzurichten.

Was ist das überhaupt für eine API dass du auf deiner Seite den Port öffnen musst? Das bedeutet ja, dass die API eine aktive Verbindung zu dir aufbaut.

Klingt für mich, als wüsste jemand nicht was er macht.

SebMaus,

Der Port muss ausgehend offen sein. Bei uns ist ausgehend nur 80/443 für Web Traffic erlaubt. Bei einem Standard Telekom Router würde das alles gehen. Pfusch ist es m.E. trotzdem.

BitPirate,
@BitPirate@feddit.de avatar

Bitte sag mir, dass hier wenigstens verschlüsselt wird.

___qwertz___,

Sorry, das hat mein Spatzenhirn in der früh nicht kapiert :)

Nobsi,
@Nobsi@feddit.de avatar

Warum? Komplett unnötig und macht euch nur die Arbeit schwer. Content Aware Filterung und gut ist

Janis,

genau…geile api wo du lan ports aufmachen musst…episch

the_third,

Geht um ausgehend.

Janis,

dann wohl proxy wenn du da kein wireguard raufmachen willst

Nobsi,
@Nobsi@feddit.de avatar

deleted_by_moderator

    •
    Janis,

    gähn

    TeddyPolice,
    @TeddyPolice@feddit.de avatar

    Was ist das überhaupt für eine API dass du auf deiner Seite den Port öffnen musst? Das bedeutet ja, dass die API eine aktive Verbindung zu dir aufbaut.

    Das gibt OPs post nicht her. Was der hergibt ist dass man, wenn man auf tcp/8090 mit einem Dienst reden will, man sich auf seiner eigenen Firewall nicht outbound tcp/8090 wegfiltern sollte. Das ist aber kaum ungewöhnlich.

    Deine Arroganz hast du dir nicht verdient - wenn du andere in die Pfanne hauen willst weil du es besser weißt, stell bitte zuerst sicher dass du es tatsächlich besser weißt.

    ___qwertz___,

    Wenn du mir auch noch die Arroganz nimmst, bleibt mir wenig :(

    the_third,

    HTTP ausgehend auf zwei Ports zu beschränken hat keinen Sicherheitseffekt aber nervt in solchen Fällen. Und weißt du, dass da nur HTTP rausgeht auf den Ports? Eben. Wenn ihr in HTTP reinschauen wollt, braucht ihr eh einen Proxy der TLS aufmacht, da habt ihr nochmal ganz andere Sorgen mit den Clients die keine Desktops sind.

    Aber, es is wie es is und du wirst es nicht ändern, deswegen bau dir eine Automatisierung für die FW-Regeln wo du eine Liste von Ausnahmen reinwirfst und ab da ist sowas minimaler Aufwand, fertig.

    squaresinger,

    Das kann man nicht laut genug sagen.

    Ausgehende Portfilterregeln existieren nur um die Mitarbeiter zu erinnern, dass die Sicherheitsabteilung existiert. Die bieten keinen Sicherheitsvorteil und sorgen nur dafür, die Reibung zu erhöhen und zu verhindern, dass die Mitarbeiter ihre Arbeit erledigen können.

    taladar,

    Einzelne Regeln können sinnvoll sein, z.B. SMTP zu beschränken damit alles über den Firmen-Mail-Server läuft wo es vernünftige Chancen gibt nicht auf allen möglichen Blacklists zu landen. Aber das sollte dann nur ein paar Ports betreffen.

    CoLa666,

    Dein Firmenmailserver sollte nicht auf der selben IP laufen wie dein Outbound-Webtraffic just sayin’.

    Nobsi,
    @Nobsi@feddit.de avatar

    Sollte, gibt es aber in 99% der Fälle nicht so. Kaum eine Firma hat mehr als eine IP Addresse. Erstrecht nicht wenn es keine IT Bude ist.

    crispy_kilt,

    Ausgehende Firewalls sind eh nicht für viel. Solange du irgend ein Protokoll irgendwohin erlaubst, kann beliebiger Verkehr darüber geschlauft werden. Alles was ein abgehender Port Filter dir bringt ist die Mitarbeitenden zu nerven, weil sie 30 sek länger brauchen. Über 443/tls beliebigen Verkehr zu leiten ist trivial.

    Ausgehende Ports filtern erhöht die Sicherheit etwa gleich wie ein Parkverbot Unfälle verhindert.

    Nobsi, (edited )
    @Nobsi@feddit.de avatar

    Einen Port zu genau einer Endaddresse? Fein. Rein famit in den Filter. Dein Gegenüber wird sich die Arbeit nicht machen die perfekte Lösung zu finden. Mach dir deine Arbeit einfach. Du hast eine Begründung warum der Port offen ist, also macht auch die Versicherung keine faxen.

    Edit: Der Aufwand ist auch nicht enorm. Der ist recht klein. Wie viele Betreiber fordern das von euch?

    shadeless,
    @shadeless@discuss.tchncs.de avatar

    Was habt ihr für eine Firewall? Mit einer, die auf Anwendungsebene filtern kann, würde ich einfach “HTTPS” freigeben, unabhängig vom Port.

    Es passiert leider oft genug, dass Anwendungen auf alternativen Ports angeboten werden, da hast du schon ziemliche Einschränkungen nur mit 80/443.

    SebMaus,

    Könnte ich machen (Palo Alto) - dazu müsste ich aber die Standard Anwendungseigenschaften überschreiben. Palo Alto ist auch der Meinung das der Standard Port für SSL/HTTPS 443 ist.

    taladar,

    Ohne Verschlüsselung aufzubrechen kannst du nicht sagen ob da HTTPS oder irgendein anderes TLS verschlüsseltes Protokoll läuft.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • random
  • wartaberita
  • uselessserver093
  • Food
  • aaaaaaacccccccce
  • [email protected]
  • test
  • CafeMeta
  • testmag
  • MUD
  • RhythmGameZone
  • RSS
  • dabs
  • TheResearchGuardian
  • Ask_kbincafe
  • KbinCafe
  • Testmaggi
  • Socialism
  • feritale
  • oklahoma
  • SuperSentai
  • KamenRider
  • All magazines
    •