Schlagwort-Archive: ssh

syslog auf Nadeldrucker ausgeben

Da wir ja ein neues Spielzeug im fNordeingang haben, hab ich mal was gebastelt.

Ziel war es, den syslog (/var/log/messages) zu Archivierungszwecken auf einem entfernt stehenden Nadeldrucker in realtime zu sichern.  Ich habe ein paar Anleitungen gefunden wie man syslog per UDP durchs lokale Netz schickt. Habe dann aber doch was eigenes gefrickelt. Der Server läuft auf Scientific Linux der Druckerserver auf Debian.

Druckerserver (DEBIAN) einrichten

Legen Sie am besten einen extra Benutzer an und fügen Sie Ihm der Gruppe lp hinzu. Als Beispiel nenne wir mal den Benutzer drucker

# adduser drucker --ingroup lp

SSH KEY erzeugen (Scientific)

Zuerst legen wir auf dem Server / Rechner dessen syslog ausgedruckt werden soll einen SSH-Schlüssel an. Mit dem Befehl

# ssh-keygen -t rsa

legen wir einen Schlüssel an. Kein Passwort eingeben. Ansonsten kann das spätere Script nicht laufen. Den öffentlichen Schlüssel kopieren Sie mit

# ssh-copy-id drucker@druckerserver-ip

auf den Druckerserver.

Server einrichten (Scientific)

Erst einmal müssen wir ein Scipt erstellen.

# vi /usr/local/sbin/drucker.sh

Das folgende Script können Sie übernehmen.

#!/bin/bash
while [ 1=1 ]
do
tail -F /var/log/messages | ssh -i /root/.ssh/id_rsa benutzername@serveradresse "cat > /dev/lp0"  
done

(Die Schleife ist dafür da, falls einmal die Verbindung abbricht)
Speichern Sie das Script ab und machen Sie es mit

chmod +x drucker.sh

ausführbar.

Nun noch das Script an die rc.local hängen

vi /etc/rc.local

und am Ende eintragen

/usr/local/sbin/drucker.sh

Nach einem Neustart sollte der Drucker nun munter in Realtime den Log ausdrucken. Ausprobieren kann man dies auch indem man das Script von Hand zum testen startet.

Anmerkung

Das Script lässt sich natürlich auch auf andere Logs anweden. Ob es /var/log/secure ist oder ein IRC Log.

Server nur ohne angemeldeten Benutzer herunterfahren

Wie bestimmt in jedem Hackerspace oder manchen Büros stehen dort Server die eigentlich nur über den Tag hinweg genutzt werden und abends oder bei „Ladenschluss“ heruntergefahren werden können. Zwar ist es kein Problem die Einstellungen in den ACPI Config-Dateien so vorzunehmen das der Server beim drücken des Power-Knopfes herunterfährt, allerdings würden dann alle Nutzer, die noch (von extern über einen SSH Tunnel) auf dem Server sind, rausgeschmissen. Damit man trotzdem den Server per Tastatendruck ohne sich extra per ssh anzumelden herunterfahren kann gibt es eine kleine Shellscriptabfrage die man einbauen kann. Gefunden habe ich diese auf linux-club.de. Sie bewirkt, dass der Server per Tastendruck nur heruntergefahren wird wenn kein Nutzer mehr einen Tunnel zum Server offen hat. Ist dies der Fall und der Power-Knopf wird gedrückt, läuft der Server trotzdem weiter und der root bekommt eine E-Mail das der Power-Knopf betätigt wurde. Dei nötigen Schritte sind recht simpel:

Kontrollieren Sie vorher ob das Paket acpid installiert ist.

Öffnen Sie als root die Config-Datei für den Powerbutton mit dem Befehl

vi /etc/acpi/events/power_button

und ändern sie den Eintrag

action=

so ab das dort

action=sh /root/bin/poweroff.sh

steht (mit i kommen Sie in den Eingabemodus, zum speichern Esc und dann :wq). Das Script poweroff.sh erstellen wir noch später. Sie können es auch woanders speichern. In diesem Falle müssen Sie nur den Pfad ändern.

Mit dem Befehl vi /root/bin/poweroff.sh erstellen Sie das Script und öffnen gleichzeitig den Editor. Drücken Sie i um in den Eingabemodus zu gelangen und tragen Sie folgendes ein:

#!/bin/bash
r=`who -u`
if [[ $r != "" ]];
then echo "Der Powerknopf wurde gedrückt" | mail -s "Powerknopf" root@localhost
else poweroff
fi

Nun speichern Sie das Script ab (zum speichern Esc und dann :wq). Jetzt müssen Sie das Script noch ausführbar machen.

chmod +x poweroff.sh

Nun kann der Server nur noch heruntergefahren werden wenn keiner mehr auf dem System angemeldet ist. Sollte trotzdem der Powerbutton betätigt werden während noch jemand angemeldet ist wird dem root eine Mail zugeschickt, dass der Knopf betätigt wurde. Der Befehl kann aber auch einfach durch ein

exit 0

ersetzt werden, falls keine Mail erwünscht ist.

ssh Brute Force Angriffe verhindern

Jeder, der seinen Server per ssh im Internet erreichbar macht, kennt das Problem das Bots immer wieder versuchen mit massenhaften Anfragen Zugriff auf den Server zu bekommen. Um direkt zu verhindern, dass es zu mehreren Anfragen kommen kann, können Sie mehrere Einstellungen vornehmen.

SSH Konfiguration absichern

Bei den meisten Anfragen wird versucht sich als root einzuloggen. Hier ist es dringend empfohlen, keinen root-Zugang per ssh zuzulassen. Sie können sich später als normaler Benutzer per su auch zum root machen. Dies ist weitaus sicherer, da so zwei Passwörter benötigt werden und als normaler User weniger zerstört werden kann, sollte sich jemand Zugang verschaffen. Zudem muss der Angreifer erstmal Ihren Benutzernamen herausfinden. Die meisten Anfragen kommen nicht nur als root sondern auch als typische Dienstenamen wie tomcat, apache etc. Die Einstellungen nehmen Sie in der Datei  /etc/ssh/sshd_config vor. Suchen Sie folgende Einträge und ändern Sie diese wie folgt ab:

PermitRootLogin no

und

AllowUsers detlev

(bzw. die Benutzer die sich einloggen dürfen)

Damit nicht unendlich viele ssh-Sessions auf einmal gestartet werden können nehmen Sie noch folgende Option vor:

MaxStartups 3:30:10

Sie bewirkt, ab den dritten nicht funktionierenden login, dass bei jedem weiteren nicht funktionierenden login die Wahrscheinlichkeit steigt, das die nächste Verbindung abgelehnt wird. Dies ist kein 100%iger Schutz und im Endeffekt auch nicht notwendig wenn wir mit der Absicherung fertig sind.

Sollte eine Option mit einer Raute # ausgeklammert sein, entfernen Sie die Raute einfach.

Nachdem Sie die Einstellugen vorgenommen haben starten Sie ssh neu.

IP Adressen blocken

Um die Attacken zu stoppen, ist es sinnvoll nach einer bestimmen Anzahl von Fehlversuchen die IP des Angreifers für eine bestimmte Zeit zu blocken. Wir sagen mal einfach 10 Minuten sollten reichen. Dabei würde auf der Angreiferseite die Zugriffsversuche einfach in ein timeout laufen. Um dies zu bewerkstelligen benötigen wir das Programm fail2ban. Bei openSUSE installieren Sie es einfach per
sudo zypper install fail2ban
Danach müssen Sie fail2ban noch bei jedem Systemstart mitstarten. Unter yast > System > Systemdienste (Runlevel) können Sie dies einstellen. Bei Runlevel 3 und 5 soll es mitgestartet werden.

Nun starten wir fail2ban als root mittels rcfail2ban start.

Trotzdem müssen wir noch ein paar openSUSE spezifische Änderungen an der Konfiguration durchführen. Die zu editierende Datei lautet /etc/fail2ban/jail.conf.

Die Einstellungen sind eigentlich selbstklärend. Trotzdem poste ich mal die Einstellungen so wie sie für unseren Fall aussehen sollten:

# Fail2Ban configuration file
#
# Author: Cyril Jaquier
#
# $Revision: 747 $
#
# The DEFAULT allows a global definition of the options. They can be override
# in each jail afterwards.

[DEFAULT]

# "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will not
# ban a host which matches an address in this list. Several addresses can be
# defined using space separator.
ignoreip = 127.0.0.1

# "bantime" is the number of seconds that a host is banned.
bantime = 600

# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
findtime = 600

# "maxretry" is the number of failures before a host get banned.
maxretry = 3

# "backend" specifies the backend used to get files modification. Available
# options are "gamin", "polling" and "auto". This option can be overridden in
# each jail too (use "gamin" for a jail and "polling" for another).
#
# gamin: requires Gamin (a file alteration monitor) to be installed. If Gamin
# is not installed, Fail2ban will use polling.
# polling: uses a polling algorithm which does not require external libraries.
# auto: will choose Gamin if available and polling otherwise.
backend = auto

# This jail corresponds to the standard configuration in Fail2ban 0.6.
# The mail-whois action send a notification e-mail with a whois request
# in the body.

[ssh-iptables]

enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, dest=detlev@localhost, sender=fail2ban@mail.com]
logpath = /var/log/messages maxretry = 3

Nachdem Sie die Einstellungen vorgenommen haben starten Sie fail2ban mittel<
rcfail2ban restart
neu. Nun ist es aktiv und wird nach 3 Fehlversuchen die IP des Angreifers für 10 Minuten blocken.

Interessante Links zu dem Thema

SSH-Daemon (sshd) gegen Attacken sichern > http://www.strassenprogrammierer.de/ssh-daemon-sshd-gegen-attacken-sichern_tipp_363.html
Verhindern von Brute Force Attacken mit Fail2ban auf OpenSUSE 10.3 > http://www.howtoforge.de/howto/verhindern-von-brute-force-attacken-mit-fail2ban-auf-opensuse-103/