Firewall Logging Strategie

    Ich nutze (momentan noch) Debian 10 auf meinem Root-Server und bin schon seit längerem etwas am Hadern, wie ich meine Firewall Strategie - insbesondere bzgl. eventuelles Loggens von gedroppten Paketen handhaben soll. Bis jetzt nutze ich netfilter-persistent mit einer adaptierten Version von

    External Content gist.github.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.
    für die Firewall Regeln.


    Leider loggt mir das immer noch zu viel, weshalb ich das Logging gedroppter Packets nun ausgeschaltet habe. Viel mehr als "soo viele Bot anfragen. Was für ein ******" bringt es mir nicht.


    Wie viel oder würdet ihr überhaupt gedroppte Pakete loggen?

    Login Fehlschläge usw. kommen über fail2ban bzw. über die jeweilige Applikation - was natürlich ein Level höher ist.

    Quote from aNewUser

    Wie viel oder würdet ihr überhaupt gedroppte Pakete loggen

    Nur zum Debugging. Im normalen Betrieb würde ich das Logging komplett ausschalten. Maßnahmen kannst du automatisiert mit Fail2Ban vornehmen. Du hast da sonst viel zu viel Grundrauschen, das dich aber nicht interessiert - gerade wenn der Server im Internet steht. Ich würde das Logging nur bei Bedarf kurz aktivieren.

    Ich logge maximal bei ausgehenden Paketen dauerhaft, wenn diese abgewiesen oder verworfen werden. So bemerkte ich schneller, wenn die Firewall Dinge unabsichtlich blockiert bzw. eine Software nach einem Update plötzlich neue Bedürfnisse hat. ^^


    Ansonsten sehe ich es wie Paul, nur zum Debuggen wird wirklich alles auf gesprächig umgeschaltet. :thumbup:

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Ich persönlich bin ganz zufrieden mit den Meldungen, welche psad liefert. SSH wird außerhalb des VPN durch knock geschützt, somit gibt es da nichts zu loggen und keine IP-Adressen zu sperren.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

    Edited once, last by m_ueberall ().

    Like 2

    kurz halb-"off-topic":

    Ich persönlich halte ja eine WAF für fast noch wichtiger als die Absicherung auf Layer 2, weil der Zugriff über Web oft am löchrigsten ist.

    So manch einem, mit iptables o.ä. gut abgesicherten Sever hat dann doch ein unsicheres Wordpressplugin den Garaus gemacht. ;)

    Vielen Dank für eure Einschätzung. Habe das logging jetzt heruntergeschraubt.


    Auf dem Server läuft Nextcloud ein VPN Server und ein Mailserver. WAF = Firewall auf dem Application level? Fail2ban macht ja einen grundlegenden Brute force Schutz möglich. Blacklists vor dem Mailserver bieten Spam Schutz aber nicht viel mehr.


    Momentan läuft kein WordPress auf dem Server und ich habe es auch nicht geplant.

    Hej


    meine ersten zwei Regeln sind:

    Code
    DROP_GEOIP  all  --  anywhere             anywhere
FAIL2BAN   all  --  anywhere             anywhere


    Erstmal sehr restriktives GEO Drop - je nach dem was du auf deinem Server machst, oft genügt es sogar DACH freizugeben und den Rest zu sperren.
    Dann Fail2Ban auf alle Dienste aktivieren, wo es Sinn macht.
    Dann würde ich mir Gedanken machen, ob dich auch etwas interessiert, was gut ist - zb. "positive" Zugriffe auf deinen Webserver oder so.

    Und geloggt wird zum Schluss. Das kannst dann am Anfang auswerten und. ggfl. weitere Rules hinzufügen. Irgendwann läuft das Ding dann und die Logs interessieren dich nicht mehr wirklich.

    Gruß

    PS: fail2ban läuft bei mir zB. für folgende Dienste:

    - Jail list: apache-auth, dovecot, mysqld-auth, nginx-botsearch, nginx-http-auth, nginx-limit-req, openvpn, owncloud, postfix, postfix-rbl, sshd, webmin-auth

    Und da sperre ich ganz restriktiv 3 Versuche in 10Min für 1 Monat.