Ja. ufw reset stellt ja den Ausgangszustand von ufw wieder her und da ist alles dicht.
Ich weiß nicht, ob bei der Deinstallation auch die in iptables einfügten chains mitgelöscht werden. 
Was sagt iptables S | grep ufw ?
Beiträge von aRaphael
-
-
t-online blockiert offenbar zunächst mal standardmäßig alle neuen Mailserver. Zumindest war das bei meinen so, obwohl alles immer gepasst hat (rDNS, spf, DKIM, dmarc und sogar ein Impressum war immer vorhanden)
Eine eMail an die entsprechende Stelle dort (steht im maillog) mit einem Hinweis darauf hat aber dann immer, ohne Diskussion zur sofortigen Freischaltung der Mailserver geführt. (Danach hab ich das Impressum dann wieder rausgenommen
) -
Ich habe mich auch mal eine zeitlang etwas intensiver mit SEO auseinandergesetzt.
Festgestellt habe ich dabei, dass das ganze Feintuning kaum etwas fürs Ranking bringt. Google lässt sich inzwischen nicht mehr so leicht austricksen.
Das einzige, was meiner Erfahrung nach wirklich was bringt, ist guter und originärer Content. Dann spült es die Seite mit der Zeit von ganz alleine nach oben in den Suchergebnissen. (Ist die Seite Scheisse hilft auch SEO nix.
) -
...dass durch Drittanbietern (google tag manager, analytics und recaptcha) letztere davon die meiste Zeit blockiert.
Und noch mehr persönliche Zeit geht drauf, weil man für die alle einen Passus in seiner Datenschutzerklärung stricken muss.
-
Ich denke jetzt aber, das kann ich in den Griff bekommen, indem ich ModSec erstmal längere Zeit auf "Detection only" laufen lasse und mir die Logfiles ein wenig übersichtlich aufbereite.
Hab mir mal ein kleines Progrämmli dafür gestrickt:
./pamsel /var/log/apache2/error.log simt | sort | uniq -c | sort -nr
64 WARNING,920350,"Host header is a numeric IP address",OWASP_CRS/PROTOCOL_VIOLATION/IP_HOST,-
4 WARNING,920280,"Request Missing a Host Header",OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_HOST,-
1 WARNING,920100,"Invalid HTTP Request Line",OWASP_CRS/PROTOCOL_VIOLATION/INVALID_REQ,-
1 CRITICAL,942100,"SQL Injection Attack Detected via libinjection",OWASP_CRS/WEB_ATTACK/SQL_INJECTION,-
1 CRITICAL,933150,"PHP Injection Attack: High-Risk PHP Function Name Found",OWASP_CRS/WEB_ATTACK/PHP_INJECTION,-
1 CRITICAL,933100,"PHP Injection Attack: PHP Open Tag Found",OWASP_CRS/WEB_ATTACK/PHP_INJECTION,-
1 CRITICAL,932105,"Remote Command Execution: Unix Command Injection",OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION,-
...
Dabei ist mir wieder klargeworden, dass ich den ganzen IT-Krempel nur deshalb mache, weil ich dabei rumcoden darf.
-
Du könntest auch mal so was wie z.B. PageSpeed Insights verwenden um die Flaschenhälse einzugrenzen.
-
Naja, die Scans stehen im log.
Auf der anderen Seite ist in der UFW nur Port 80, 443 und eben der SSH Port offen (der eben nicht Port 22 ist). Daher verstehe ich das ganze nicht
Dass die Ports alle zu sind, verhindert ja nicht, dass jemand versucht dort reinzukommen. Das lässt sich nicht vermeiden. (Außer durch eine vorgeschaltete externe Firewall, die das abfängt)
Und diese Versuche werden halt im log protokolliert. Wenn alles dicht ist, dann ist das ja kein Sicherheitsproblem sondern nur ein kosmetisches (logs vollgemüllt)
-
Ich auch nicht, aber alternativ allem möglichen zustimmen, dem ich nicht zustimmen will.
Ich bekomme von sowas gar nix mehr mit.
Hab das Plugin "i dont care about cookies" installiert und das nickt alles automatisch ab. Diese unsäglich Cookiezustimmungsbanner bekomme ich gar nicht mehr zu Gesicht. (Möchte nicht wissen, zu was ich inzwischen schon alles zugestimmt habe
)Wenn der Tab geschlossen wird, werden auch die Cookies gelöscht (Bis auf die Ausnahmen in einer Whitelist)
Ich hatte es halt irgendwann satt.
-
Nutzt von euch jemand unter Apache ModSecurity als WAF?
"Lohnt" sich das?"
Hab mich jetzt mal ein wenig damit auseinandergesetzt und bin eigentlich recht angetan davon.
Ist ein recht mächtiges und vielseitiges Werkzeug, aber um es wirklich effektiv nutzen zu können, sollte man wohl schon mal ein wenig unter die Haube schauen.
Nach intensivem Testen mit ModSecurity bin ich nun doch davon abgekommen.
Die "False Poitives", die ich hatte, kann ich nicht in Kauf nehmen. Die wären nur wegzubekommen durch ständiges Durchforsten der errorlogs und Nachjustieren. (Die OWASP Exclusion-Rules für Wordpress funktionieren z.B. nicht wirklich gut)
Diese Zeit habe ich nicht und ich kann die Nutzer da auch nicht als Betatester missbrauchen
Mein Pro-Contra Pendel zu ModSecurity schwingt fröhlich hin und her.
Momentan wieder eher Pro.
Ich war ein wenig frustriert von den False Positives aber bei der Vielfalt der Anwendungen, die auf dem Server laufen (Moodle, Joomla, Wordpress, DokuWiki, Eigengewächse...) ist das eigentlich auch nicht verwunderlich. ("Any WAF produces false positives. If it does not produce false positives, then it’s probably dead")
Ich denke jetzt aber, das kann ich in den Griff bekommen, indem ich ModSec erstmal längere Zeit auf "Detection only" laufen lasse und mir die Logfiles ein wenig übersichtlich aufbereite. Ich sehe jetzt schon, dass es sich um gar nicht so viele verschiedene Ausnahmen handelt.
Ich werde dem Ding wohl doch noch eine Chance geben.
-
...oder wurde der Gutscheine gerade deshalb gestückelt, damit man 5 Produkte erwerben muss.
-
Ich hab auch "connections" in die USA.
-
...schreib doch mal einen eigenen Filter.
Evtl. so was in der Art:
-
Danke für diesen Hinweis auf Alternativen. (Nutze allerdings nginx nicht)
Nach intensivem Testen mit ModSecurity bin ich nun doch davon abgekommen.
Die "False Poitives", die ich hatte, kann ich nicht in Kauf nehmen. Die wären nur wegzubekommen durch ständiges Durchforsten der errorlogs und Nachjustieren. (Die OWASP Exclusion-Rules für Wordpress funktionieren z.B. nicht wirklich gut)
Diese Zeit habe ich nicht und ich kann die Nutzer da auch nicht als Betatester missbrauchen
Da bleibe ich vorerst erstmal bei den (durchaus guten) WAF-Plugins der Anwendungen (joomla, wordpress) selbst. Die sind jeweils speziell darauf zugeschnitten.
-
Ich weiss nicht, ob sich open_basedir überhaupt mit symlinks austricksen lässt:
"When a script tries to access the filesystem, for example using include, or fopen(), the location of the file is checked. When the file is outside the specified directory-tree, PHP will refuse to access it. All symbolic links are resolved, so it's not possible to avoid this restriction with a symlink."
Quelle: https://www.php.net/manual/en/ini.core.php#ini.open-basedir
-
Nutzt von euch jemand unter Apache ModSecurity als WAF?
"Lohnt" sich das?
Ja (zusammen mit dem OWASP CRS). Ja.
Hab mich jetzt mal ein wenig damit auseinandergesetzt und bin eigentlich recht angetan davon.
Ist ein recht mächtiges und vielseitiges Werkzeug, aber um es wirklich effektiv nutzen zu können, sollte man wohl schon mal ein wenig unter die Haube schauen.
-
Danke für die Rückmeldung.
Installiert (mit den OWASP core rules
) und getestet hatte ich es gestern schon mal auf einen Testserver. War mir nur nicht sicher, ob ich das nun auch tatsächlich auf den Produktivsystem einführen soll.Bisher habe ich irgendwelche WAF-Plugins in den Anwendungen genutzt (sofern es welche gab) aber eine übergreifende Lösung, wie die hier wäre mir schon lieber.
-
Nutzt von euch jemand unter Apache ModSecurity als WAF?
"Lohnt" sich das?
-
Hey!
hey.de ?
-
...wieder gelöscht...
Mangelnde Lesekompetenz meinerseits
(Die verlängerte Bearbeitungszeit ist ne feine Sache
) -
Mal was Erfreuliches für die Freunde langlaufender Verträge:
"Neue Verträge dürfen zwar, wie bisher, für bis zu 24 Monate abgeschlossen werden. Es wird nach dieser anfänglichen Laufzeit aber keine automatischen Verlängerungen mehr geben, die erst nach weiteren 12 Monaten gekündigt werden können. Haben Sie z.B. nach den 24 Monaten nicht gesagt, ob Sie kündigen oder wie Sie den Vertrag fortführen möchten, dann kommen Sie jederzeit mit einer einmonatigen Kündigungsfrist aus einem automatisch verlängerten Vertrag heraus"
Schade, dass das nicht für das Anmieten von Servern gilt.
