Kategorie: Server

Ubuntu UFW logs nicht nach /var/log/syslog schreiben

Posted on by Jann Heider

Aktiviert man UFW auf Ubuntu schreibt UFW seine Logs nach:

/var/log/ufw.log
/var/log/syslog

Will man die UFW Logfiles nicht im syslog haben, einfach in

vi /etc/rsyslog.d/20-ufw.conf

und dort ein „& stop“ nach „:msg,contains,“[UFW “ /var/log/ufw.log“ einfügen, das ganze Sieht da so aus:

# Log kernel generated UFW log messages to file
:msg,contains,"[UFW " /var/log/ufw.log
& stop
# Uncomment the following to stop logging anything that matches the last rule.
# Doing this will stop logging kernel generated UFW log messages to the file
# normally containing kern.* messages (eg, /var/log/kern.log)
#& ~

Speichern und

service rsyslog restart

UFW loggt nun nicht mehr nach syslog.

Ubuntu: Apt – Manche Indexdateien konnten nicht heruntergeladen werden.

Posted on by Jann Heider

 

Ubuntu und die Deutschen Paketquellen mach hin und wieder Probleme, wie z.B. aktuell mal wieder dieses hier:

W: Herunterladen von http://de.archive.ubuntu.com/ubuntu/dists/trusty-updates/main/i18n/Translation-en fehlgeschlagen: Hash-Summe stimmt nicht überein
E: Manche Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder durch alte ersetzt.
E: Paket-Zwischenspeicher konnte nicht neu erzeugt werden

Da ich dies bei den de.* Paketquellen hin und wieder habe habe ich die de* Paketquellen nun auf all unseren Servern entfernt und durch die Standard Paketquellen ersetzt.

Das ganze geht wie gewohnt über

vi /etc/apt/sources.list

dort einfach die „de.“ bei allen Quellen entfernen und speichern

deb http://de.archive.ubuntu.com/ubuntu/ trusty main restricted

danach

rm -rf /var/lib/apt/lists/*
aptitude update

Alternativ das ganze in einfach:

rm -rf /var/lib/apt/lists/*
sed -i 's/de.archive.ubuntu.com/archive.ubuntu.com/g' /etc/apt/sources.list
aptitude update && aptitude safe-upgrade

 

 

 

SSH Sicherheit mit Fail2ban – Tipps zu Fail2ban

Posted on by Jann Heider

Fail2ban sollte eigentlich jedem Admin der Linux/Unix Server ein begriff sein, vor allem wenn er Server administriert die am www hängen.

Mit Fail2ban kann man automatisiert mit diversen Filterregeln es einem Angreifer schwer machen. Dabei schaut Fail2Ban in die entsprechenden Logfiles und erstellt anhand von Filterregeln dann Firewall-Regeln um den Angreifer auszusperren.

Bei SSH schaut Fail2Ban in die /var/log/auth.log

Versucht jemand nun jemand via SSH das Passwort vom Root User herauszufinden (Brute-Force), kann Fail2ban den Angreifer nach 3 versuchen ihn für die nächsten 24 Stunden via Firewall Regel aussperren. Das erschwert natürlich eine solche Brute-Force-Attacke.

Grundsätzlich sollten SSH Root-Logins nie via Passwort möglich sein!
(Leider gibt es hin und wieder andere Kundenwünsche und Ansichten.)

Unter Debian / Ubuntu erfolgt die Installation mit einem

apt-get install fail2ban

Danach findet man die Konfigurationsdaten unter /etc/fail2ban/… . Wir kopieren uns jetzt das Original und legen uns eine local Konfiguration an mit der wir nun fortan arbeiten.

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Die Konfigurationsdatei jail.local ist hinreichend Dokumentiert, daher werde ich dies hier nicht im Detail erläutern.

Um fail2ban für z.B. SSH zu aktivieren muss enabled auf den wert true gesetzt werden

[ssh]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3

Datei speichern und danach fail2ban neustarten.

service fail2ban restart

Danach prüfen ob die Jails angelegt wurden:

iptables -L

Und nach ein paar tagen wird man in seinen Jails schon geblockte IP-Adressen finden.

 

Wichte Tipps:

bantime so hoch wie möglich stellen z.B. auf 48 Stunden:

bantime = 172800

Was viele vergessen:
Fail2ban reagiert nur auf IP Adressen im authlog. Schreibt OpenSSH anstelle der IP-Adresse den Reverse-DNS in die Logfile wird Fail2ban nicht darauf reagieren, und selbst wenn man sich dafür einen eigenen regex baut, ist dies realativ unsicher.

Daher in OpenSSH folgende Option setzen:

UseDNS no

Somit macht OpenSSH keine Reverse-DNS und Fail2ban kann seine Arbeit machen.

Nie blind fail2ban vertrauen! Selbst ist der Admin.

Viel Erfolg ;) !

 

 

Einfache MySQL Backups mit automysqlbackup

Posted on by Jann Heider

Backups sind das mit wichtigste bei der Serveradministration. Linux Admins haben oft ihre eigenen Backupscripte, liegt wohl in der Natur eines Linux Admins alles selbst zu machen ;)

Es gibt jedoch auch nette Tools und Scripte um sich Zeit zu sparen, eines davon ist automysqlbackup und ist in den Debian und Ubuntu Paketquellen mit drin.

Automysqlbackup sichert dabei alle vorhandenen Datenbanken einzeln in täglichen, wöchentlichen und monatlichen Backups übersichtlich in einzelnen Unterordnern.

Ein einfaches

aptitude install automysqlbackup

installiert es. Die Konfiguration findet man unter

/etc/default/automysqlbackup

und sobald die wichtigsten Einstellungen wie „BACKUPDIR“ eingerichtet sind läuft das Script auch schon. Dabei sichert automysqlbackup nun täglich alle Datenbanken. Die Backups werden dann weiter in wöchentlichen und Monatlichen Backup-Verzeichnissen rotiert.

Das Script läuft täglich und wird über cron.daily gesteuert.