vServer Firewall

Kommt drauf an ist hier wohl die richtigste Antwort

Eine Firewall kann viel bringen, ist aber halt auch nur ein Baustein eines Sicherheitskonzeptes.

Zitat von einfachpeer

[…] oder ist NetCup dementsprechend gut genug abgesichert ?

Dein Server hängt ungefiltert (*) im Internet, was genau erwartest Du von netcup?

(* Vom DDoS-Filter mal abgesehen.)

Das typische Antwortverhalten von Hosts ohne Firewall, nämlich dass Ports, an die keine Programme gebunden sind, ICMP-Antworten zurückschicken, ist nicht mehr unbedingt, was man heute im wilden Internet haben will. Wenn man eine Firewall als "nur offen, was ausdrücklich erlaubt ist (default deny/drop)" konfiguriert, schützt das auch versehentlich aktive Dienste. Also mach die Firewall an.

Und sieh zu, dass du auch "Layer 7" schützt, also die Angriffe über den Webbrowser (SQL-Attacken etc.)

Lücken in den Anwendungen sind die größeren Einfallstore, im Vergleich zu Angriffen z.B. auf das ssh-Login.

Zitat von einfachpeer

Thema DDOS Schutz : Muss ich den anmachen oder ist das standarmäßig an ?

Der aktiviert sich automatisch sobald ein Angriff erkannt wird. Siehe: DDoS-Schutz

Zitat von NaN

ICMP-Antworten zurückschicken, ist nicht mehr unbedingt, was man heute im wilden Internet haben will.

nein? was denkst Du damit verstecken zu können?

als user will ich einen timeout nicht abwarten wollen.

Zitat von hoedlmoser

nein? was denkst Du damit verstecken zu können?

Das hat NaN doch bereits geschrieben: Fehler sind menschlich => ein versehentlich aktiver Dienst ist nur mit einer bewusst erstellten Freigabe auf der Firewall erreichbar:

Zitat von NaN

Wenn man eine Firewall als "nur offen, was ausdrücklich erlaubt ist (default deny/drop)" konfiguriert, schützt das auch versehentlich aktive Dienste. Also mach die Firewall an.

Zitat von hoedlmoser

als user will ich einen timeout nicht abwarten wollen.

Ein User der unberechtigt versucht auf einen Serverdienst von mir zuzugreifen oder ein Portscanning durchführt, darf von mir aus gerne warten bis zum Sankt Nimmerleinstag. Wenn die Clients des Users dadurch abstürzen oder seine Machenschaften ausbremst soll's mir auch Recht sein...

Zitat von Win98SE4ever

Ein User der unberechtigt versucht auf einen Serverdienst von mir zuzugreifen oder ein Portscanning durchführt, darf von mir aus gerne warten bis zum Sankt Nimmerleinstag.

Ja. Das kann ich gut nachvollziehen:

Zitat von hoedlmoser

was denkst Du damit verstecken zu können?

Nicht viel, aber mein Lieblingsbeispiel ist Wireguard: Das verhält sich genau wie eine "drop" Firewall, wenn die andere Seite den Key nicht kennt. Dann wird einfach gar keine Antwort geschickt. Wenn sich auch deine übrigen UDP-Ports taub stellen, kann ein Portscanner nicht unterscheiden, ob und auf welchem Port etwas ist oder nicht.

Ein anderer Grund, der meiner Meinung nach für das Abschalten der ICMP-Antworten spricht, ist, dass diese Antworten an die unauthentifizierte IP-Adresse der anderen Seite geschickt werden, also an eine von einem Angreifer frei wählbare Adresse. Damit ist zwar keine Amplification drin, aber Kleinvieh macht auch Mist.

Zitat von Win98SE4ever

Das hat NaN doch bereits geschrieben

Nein, eigentlich nicht. Dass eine default-drop Firewall auch versehentliche Dienste schützt, ist der zweite und wichtigere Grund für eine Firewall, aber das Ziel erreicht man auch mit default-reject. Der Unterschied zwischen reject und drop ist nicht groß und vielleicht eine Frage persönlicher Präferenz.

Zitat von Win98SE4ever

Das hat NaN doch bereits geschrieben

nein, mir gehts hier um die unterscheidung von drop und reject.

Zitat von Win98SE4ever

unberechtigt versucht auf einen Serverdienst von mir zuzugreifen

es gibt so viele arten von falschkonfiguration auf client seite (zb falscher port), da muß man die nicht noch in die offene heugabel mit einem timeout laufen lassen.

Zitat von Win98SE4ever

Portscanning durchführt,

der so vielfach gefürchtete portscan. ist vollkommen egal ob du dessen packerle verwirfst oder freundlicherweise mit einer unzustellbarkeitsmeldung beantwortest, hab das kurz getestet wie der nmap auf drop und reject reagiert. ein status filtered ist auch bei drop sehr schnell ermittelt, lediglich bei UDP gestaltet sich das schwieriger. aber eigentlich will der phöse portscanner ja gar nicht wissen was closed oder filtered ist, er bekommt von den offenen ports sowieso eine antwort auf layer 7 und kann dann in seine vulnerabilities datenbank sehen um zu wissen mit welcher attacke er weitermacht.

accept
25/tcp open smtp
123/udp open ntp

reject # scan done in 300 ms
25/tcp filtered smtp # ICMP tcp port smtp unreachable
123/udp closed ntp # ICMP udp port ntp unreachable

reject w tcp reset # scan done in 300 ms
25/tcp closed smtp # Flags [R.]

drop # scan done in 700 ms
25/tcp filtered smtp # timeout
123/udp open|filtered ntp # timeout

accept, not listening
25/tcp closed smtp # Flags [R.]
123/udp closed ntp # ICMP udp port ntp unreachable

node down # scan done in 4 seconds
25/tcp filtered smtp # timeout
123/udp open|filtered ntp # timeout

bei 'node down' hätte ich mir übrigens ein 'no route to host' oder ähnliches vom gateway erwartet, aber ist bei netcup wohl nicht so implementiert.

Zitat von NaN

[...] Wireguard: Das verhält sich genau wie eine "drop" Firewall, wenn die andere Seite den Key nicht kennt. Dann wird einfach gar keine Antwort geschickt. Wenn sich auch deine übrigen UDP-Ports taub stellen, kann ein Portscanner nicht unterscheiden, ob und auf welchem Port etwas ist oder nicht.

das ist in der tat genial. aber wieviele andere protokolle kennen wir die sich so verhalten? immerhin setzt das ein wissen voraus, vulgo pre-shared-key.

Zitat von NaN

Ein anderer Grund, der meiner Meinung nach für das Abschalten der ICMP-Antworten spricht, ist, dass diese Antworten an die unauthentifizierte IP-Adresse der anderen Seite geschickt werden, also an eine von einem Angreifer frei wählbare Adresse. Damit ist zwar keine Amplification drin, aber Kleinvieh macht auch Mist.

damit reißt du auf der gegenstelle nichtmal einen prozess auf. also das ist weniger als kleinvieh, das ist eher eine mücke.

Zitat von NaN

Der Unterschied zwischen reject und drop ist nicht groß und vielleicht eine Frage persönlicher Präferenz.

das magst du persönlich so sehen.

aber wenn du mal am troubleshooten einer IP connectivity bist, dann bist du froh wenn du auf basis der rückmeldung sagen kannst wo das problem liegt: ICMP - firewall, welche? siehe IP source des ICMP packerle; reset - layer 7.

gut zusammengefasst ist der unterschied zwischen drop und reject auch hier http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject tl;dr drop bringt keinen vorteil, lediglich den nachteil daß auf einen timeout gewartet werden muß.

Zitat von hoedlmoser

tl;dr drop bringt keinen vorteil

Die Seite kenne ich. Selbst da wird ein Grund angeführt, warum man evtl. filtern will. Einen weiteren habe ich dir genannt. Mehr Gründe brauche ich nicht. Es tut mir leid, Gesprächigkeit gehört für mich in Zeiten von Shodan und Konsorten einerseits und DDoS andererseits nicht mehr zu einer guten Konfiguration. Ich brauche keinen Portscan, um zu sehen, welche Ports offen sind, und netzseitig habe ich auch andere Möglichkeiten. Wenn ich etwas debuggen muss, habe ich einfachsten Zugriff auf das filternde System und kann genau sehen, was dort ankommt. Wenn jemand anders meint, meine Systeme "debuggen" zu müssen, muss er sich eben etwas mehr anstrengen. Du darfst selbstverständlich weiter deine Firewalls konfigurieren, wie es dir beliebt.

Kann NFTables empfehlen, läuft seit Jahren super. Muss man sich aber einarbeiten. Obacht: Ich hab kein Docker drauf, das sich damit beißen könnte.. Vielleicht bekommen wir ja mal irgendwann tree-based Networkspaces im Kernel.

Manuelle Firewall hilft super um gesprächige Installation von Diensten zu verhindern. Der blöd konfigurierte Datenbankserver, das Memcache mit global-listen oder der Minecraftserver mit internet erreichbarer Konsole..

P.S. Droppe auch by-default. Um die Antwort ist mir meine Leitung zu schade.