Posts by fulltilt


    warum das rad neu erfinden?...einfach die: apache-badbots.conf in fail2ban ändern/hinzufuegen...fertig. solange es fuer alle gelten soll.
    solche listen sind aber meistens veraltet oder werden nur sehr duerftig gepflegt. da ist es besser man filtert aus den logs das was beim eigenen server wirklich auftaucht und aktualisiert danach fail2ban.


    mit fail2ban haut das irgendwie nicht hin - auch bei manchen Namen habe ich keinen plan wie die regex aussehen muss ... z.b. bei
    Baiduspider/2.0
    MJ12bot/v1.4.3


    habe eine custom log dazu angelegt, die logged auch soweit ganz prächtig :D
    LogFormat "%a %{User-agent}i" ipagent
    CustomLog /var/log/apache2/useragent.log ipagent


    baduseragent

    Code
    1. failregex = ^<HOST> Mozilla/(.*) \((.*)\) Linguee/ Bot$ (geht) ^<HOST> Mozilla/(.*) \((.*)\) MJ12bot/\v1\.4\.3$ (geht nicht) ^<HOST> Mozilla/(.*) \((.*)\) Baiduspider/\2\.0$ (geht nicht)


    Code
    1. [apache-bad-user-agent]
    2. enabled = true
    3. port = 80,443
    4. protocol = tcp
    5. filter = baduseragent
    6. maxretry = 1
    7. bantime = 86400
    8. logpath = /var/log/apache2/useragent.log


    danke, ich versuchs mal zu includen ...
    wäre auch noch ein gutes Feature im CP eine Badbotlist für den Admin
    ich glaube bei c-panel gibt es so etwas ähnliches ...


    genau da habe ich auch gerade drüber nachgedacht mit dem include was machen ;-)
    aber was ist denn damit?

    Code
    1. <IfModule mod_rewrite.c> RewriteEngine on RewriteCond %{HTTP_USER_AGENT} ^LWP::Simple RewriteRule ^/.* http://%{REMOTE_ADDR}/ [L,E=nolog:1]</IfModule>


    kann das nicht einfach erweitert werden?

    Code
    1. <IfModule mod_rewrite.c>
    2. RewriteEngine on
    3. RewriteCond %{HTTP_USER_AGENT} ^LWP::Simple
    4. RewriteCond %{HTTP_USER_AGENT} ^bla
    5. RewriteCond %{HTTP_USER_AGENT} ^blabla
    6. ...
    7. RewriteRule ^/.* http://%{REMOTE_ADDR}/ [L,E=nolog:1]
    8. </IfModule>

    scheint wohl mit der Debian Installation im RZ angelegt zu werden ...
    ich weiss ja wofür diese crons da sind, aber wenn die nicht fürs Panel benötigt werden würde ich sie gerne löschen ;-)

    habe vorhin ein neues System in einem anderen RZ aufgesetzt, in der cron.daily
    finde ich hier zusätzlich:
    - mlocate
    - quota


    auf einer früheren Installation sind diese nicht in den Cronjobs
    wo ist nun der Fehler bzw. gehören die ins cron.daily?


    Gruss

    also meine Backups mache ich mit rsync und das klappt mit ionice ...
    die imscp crons also für die User Datenbanken erzeugen massig Load das ganze müsste man mal testen könnte vieleicht als Standard bei manchen Cronjobs integriert werden ...