Schlagwort: fail2ban

Puppet: Informationen des Nodes mit facter auslesen

prego Schreib einen Kommentar

In heterogenen Setups ist es wichtig das sich die Module und Klassen den nodespezifischen Eigenheiten anpassen. Dafuer koennen in Puppet Informationen aus facter verwendet werden.

Facter is an independent, cross-platform Ruby library designed to gather information on all the nodes you will be managing with Puppet. It is available on all platforms that Puppet is available.

Facter ist auch ein eigenstaendiges Tool. Nach dem Aufruf werden die zur Verfuegung stehenden Informationen ausgegeben.

Ein Anwendungsbeispiel ist mit einem Modul sicherzustellen, dass SSH installiert und der SSH Serverdienst auch laeuft. Auf Debian basierten Systemen heisst der Dienst ’ssh‘, waerend auf RedHat basierten Systemen der Dienst ’sshd‘ heisst. In einem Puppet Modul laesst sich das mit Informationen aus facter wie folgt abbilden:

class ssh_server {
  case $::osfamily {
    Debian: {
      $serviceName = 'ssh'
    }
    RedHat: {
      $serviceName = 'sshd'
    }
  }
 
  service { $serviceName:
    ensure => 'running',
  }

Aber nicht nur in den manifest Dateien kann man auf die Informationen aus facter zurueckgreifen, auch in den Templates stehen diese zur Verfuegung. Eine sinnvolle Modifikation des Templates jail.local.erb das ich in dem fail2ban Modul gezeigt habe ist, die Emails nicht an fail2ban@localhost sondern an fail2ban@FQDN zu verschicken. Dafuer muss die folgende Zeile geaendert werden:

  • alt: 
    destemail = fail2ban@localhost
  • neu: 
    destemail = fail2ban@<%= fqdn %>

Fail2ban: Hostname im Subject / Emails vom 01.01.1970

prego 2 Kommentare

Ich habe bei fail2ban immer die Emailbenachrichtigung aktiviert und dabei zwei Aenderungen in der /etc/fail2ban/action.d/sendmail-whois-lines.conf vorgenommen:

  1. Im Betreff habe ich den Hostnamen mit aufgenommen. Dafuer habe ich die actionstart, actionstop und actionban Zeilen so abgeaendert, dass Sie wie folgt beginnen: 
    printf %%b "Subject: [Fail2Ban] - `hostname -f` - <name>:

    Neu ist das `hostname -f`.

  2. Weiter gibt es das Problem, das die Mails immer am 01.01.1970 verschickt werden. Dafuer existiert auch ein Bugreport auf Github, der Bugfix ist aber auf meinen Systemen noch nicht angekommen, weswegen ich ihn von Hand eingepflegt habe. In der Zeile unter den oben bereits erwaehnten habe ich hinter den date Aufruf jeweils ein –rfc 2822 eingefuegt. Die Zeile sieht nun bei mir wie folgt aus: 
    Date: `date --rfc-2822 -u +"%%a, %%d %%h %%Y %%T +0000"`

Puppet: Service bei Aenderung neu starten / fail2ban

prego Schreib einen Kommentar

Heute moechte ich mein fail2ban Modul vorstellen. Neu dabei ist, dass der Service neu gestartet wird, wenn sich eine Datei aendert. Das ist wichtig, damit die Einstellungen auch uebernommen werden.

Die Verzeichnisstruktur sieht wie folgt aus:

├── files
│   └── etc
│       └── fail2ban
│           └── action.d
│               └── sendmail-whois-lines.conf
├── manifests
│   └── init.pp
└── templates
    └── jail.local.erb

In der init.pp ist wird in dem file Abschnitt ein „notify“ in Richtung des Services aufgerufen. Das fuehrt dazu, dass wenn die Datei auf dem Node geaendert wird, auch der Service benachrichtigt wird damit dieser neu startet. Siehe dazu auch „Restart service when file changes“ aus dem Puppet CookBook. Folgendermassen sieht die init.pp aus:

# class to configure fail2ban
 
class fail2ban (
  $jails       = [],
  $sshport     = 'ssh',
  $apacheport  = 'http,https',
  $proftpdport = 'ftp,ftp-data,ftps,ftps-data',
  $postfixport = 'smtp,ssmtp',
  $dovecotport = 'smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s',
  ) {
 
  package { 'fail2ban':
    ensure => installed
  }
 
  service { 'fail2ban':
    ensure => running,
    enable => true,
  }
 
  file { '/etc/fail2ban/jail.local':
    ensure  => 'present',
    content => template('fail2ban/jail.local.erb'),
    owner   => 'root',
    group   => 'root',
    mode    => '0644',
    notify  => Service['fail2ban'],
  }
 
  file { '/etc/fail2ban/action.d/sendmail-whois-lines.conf':
    ensure  => 'present',
    source  => 'puppet:///modules/fail2ban/etc/fail2ban/action.d/sendmail-whois-lines.conf',
    owner   => 'root',
    group   => 'root',
    mode    => '0644',
    notify  => Service['fail2ban'],
  }
 
}

Mein Template jail.local.erb ist wie folgt:

#############################################################################
#                                                                           #
# !!! This file is managed by puppet, all manual changes will be lost !!!   #
#                                                                           #
#############################################################################
 
 
 
#
# Local Fail2Ban configuration file.
#
 
 
[DEFAULT]
ignoreip = 127.0.0.1/8
bantime  = 600
maxretry = 3
backend = auto
destemail = fail2ban@localhost
 
 
 
#
# ACTIONS
#
 
banaction = iptables-multiport
mta = sendmail
protocol = tcp
chain = INPUT
action_mwl = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
               %(mta)s-whois-lines[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s, chain="%(chain)s"]
action = %(action_mwl)s
 
 
 
 
#
# JAILS
#
 
[ssh]
enabled  = <%= scope.lookupvar('fail2ban::jails').include? "ssh" %>
port     = <%= sshport %>
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 6
 
 
 
[ssh-ddos]
enabled  = <%= scope.lookupvar('fail2ban::jails').include? "ssh-ddos" %>
port     = <%= sshport %>
filter   = sshd-ddos
logpath  = /var/log/auth.log
maxretry = 6
 
 
 
[apache]
enabled  = <%= scope.lookupvar('fail2ban::jails').include? "apache" %>
port     = <%= apacheport %>
filter   = apache-auth
logpath  = /var/log/apache*/*error.log
maxretry = 6
 
 
 
[proftpd]
enabled  = <%= scope.lookupvar('fail2ban::jails').include? "proftpd" %>
port     = <%= proftpdport %>
filter   = proftpd
logpath  = /var/log/proftpd/proftpd.log
maxretry = 6
 
 
 
[postfix]
enabled  = <%= scope.lookupvar('fail2ban::jails').include? "postfix" %>
port     = <%= postfixport %>
filter   = postfix
logpath  = /var/log/mail.log
 
 
 
[dovecot]
enabled = <%= scope.lookupvar('fail2ban::jails').include? "dovecot" %>
port    = <%= dovecotport %>
filter  = dovecot
logpath = /var/log/mail.log

Auch im Template gab es den scope.lookupvar Aufruf bisher nicht. Die Rueckgabe ist true oder false und so kann man nur die Dienste aktivieren, die auch manuell definiert wurden. Weitere Informationen gibt es in der Puppetlabs Doku unter Out-of-Scope Variables.

Definiert wird das ganze dann in der sites.pp wie folgt:

node 'node1.example.org' inherits default {
  class { 'fail2ban':
    jails   => [ 'ssh', 'ssh-ddos', 'apache' ],
    sshport => '2222',
  }
}

Zu der sendmail-whois-lines.conf gibts noch nen separaten Blogeintrag

HowTo: https beim Anmelden an WordPress Blog Backend + Schutz gegen Brutforce

prego Schreib einen Kommentar

Bei meinem Blog hatte ich vor kurzem zwei Dinge die ich Aendern wollte:

  1. Der Blog soll ueber http:// lesbar sein, aber Anmelden soll grundsaetzlich immer https:// sein, damit das Passwort nicht unverschluesselt durch das Netz schwirrt
  2. Der Login Bereich soll gegen Brutforce Attacken abgesichert sein

Anmelden an Blog Backend nur ueber https://

Viele Menschen lesen diesen Blog oder finden hier hin. Ich bin immer wieder erstaunt darueber. Die Verbindung soll grundsaetzlich unverschluesselt sein, aber das Anmelden wollte ich – egal was ich eingebe – immer auf https:// landen, damit das Passwort nicht unverschluesselt durchs Netz uebertragen wird. Dafuer habe ich im vhost der auf Port 80 lauscht die folgende Rewrite Regel hinzugefuegt:

RewriteEngine On
RewriteCond %{REQUEST_URI}  ^/wp-login.php$
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^(.*)$ https://blog.pregos.info/wp-login.php/%1? [R=302,L]

So werde ich immer auf https weitergeleitet ohne das ich darauf achten muss, das was ich eingebe. Es ist wichig mit mod_rewrite zu arbeiten und nicht nur einen Alias zu setzen, da wenn man sich aus dem Backend abmeldet man dann auch auf den Anmeldebildschirm zurueckgeleitet wird. Da haengen GET Parameter dran. Ein Alias wuerde dann nicht mehr greifen, die mod_rewrite Regel oben tut es hingegen.

Schutz gegen ungewollte (Brutforce) Anmeldeversuche am Blog Backend

Nach vielen vielen Jahren den ich diesen Blog nun schon schreibe bin ich auf das Plugin WP fail2ban gestossen. Es loggt fehlgeschlagene Loginversuche ins Backend mit, so das man diese mit fail2ban auswerten und behandeln kann. Ich habe mit ein bisschen schlechten Gewissen das Plugin installiert und mal geschaut was so passiert. Von der Anzahl der Attacken war ich echt ueberrascht. Teilweise Skriptkiddies die ueber Stunden hinweg von der gleichen IP probieren, teilweise aber auch Brutforce Attacken mit ueber 16000 Loginversuchen in ~3h.

Spannend zu sehen was mir vorher alles entgangen ist, aber so richtig gut fuehlt sich das nicht an, dass von tausenden von Hosts probiert wird und die immer erst nach drei Versuchen gesperrt werden. Deswegen ist es am einfachsten, wenn man das Backend mit einem Benutzernamen und Passwort direkt im Apache sichert. Das habe ich auf die folgende Art und Weise im vHost getan:

<Location /wp-admin/>
        AuthName "Wordpress Login"
        AuthType Basic
        AuthUserFile /var/www/pregos.info/htpasswd-blog
        Require valid-user
</Location>

Da die Angreifer einfach per POST Daten an die wp-login.php schicken habe ich die Datei selbst auch noch explizit wie folgt abgesichert:

<FilesMatch "wp-login.php">
        AuthName "Wordpress Login"
        AuthType Basic
        AuthUserFile /var/www/pregos.info/htpasswd-blog
        require valid-user
</FilesMatch>

In wieweit das Passwort ein komplexes Zufallspasswort oder ein einfacher zu merkendes ist, ist jedem selbst ueberlassen. Es hilft aber erstaunlich einfach und effizient gegen die Attacken auf meinen Blog.