Den SSH Zugang absichern
Die erste Absicherngsmethode ist immer, den Standardport von SSH abzuändern. Das geht über die Konfigurationsdatei in /etc/ssh/sshd_config. Ändern Sie dort den WErt von Port von 22 auf einen Port Ihrer Wahl, der nicht von anderen Diensten belegt wird.
Danach sollten Sie konfigurieren, dass Sie mit einem anderen User als root Befehle auf root-Berechtigungsniveau ausführen können. Das geht mit Hile von sudo.
Danach sollten Sie konfigurieren, dass Sie sich mit diesem User ohne Passworteingabe einloggen können. Je nachdem, welches Betriebssystem Sie zu hause haben, möchten Sie sich von einem Linux Client oder von einem Windows Client aus einloggen.
Am schluss sollten Sie konfigurieren, dass sich der User root selbst nicht mehr per SSH einloggen kann. Das geht wiederum über /etc/ssh/sshd_config. Geben Sie ein
DenyUsers root
Als nächstes wollen wir per E-Mail benachrichtig werden, sobald siche in User per SSH auf unseren server einloggt. Dazu erstellen wir ein ausführbares Skript mit Namen /opt/shell-login.sh mit folgendem Inhalt:
#!/bin/bash
echo "Login auf $(hostname) am $(date +%Y-%m-%d) um $(date +%H:%M)"
echo "Benutzer: $USER"
echo
finger
und einem chmod von 755. Damit die e-Mail mit ideser Nachricht erstellt wird, müssen wir die folgende Zeile in die datei /etc/profile eintragen.
/opt/shell-login.sh | mailx -s "SSH Login auf abusemyskill.ddns.net" info@dafrk-blog.com
zu guter letzt installieren wir noch denyhosts. es überwacht das ssh authentication log auf dem system. gibt es nun beispeislweise eine verdächtige anzahl an fehlgeschlagenen Anmeldeversuchen, blockiert es automatisch die adresse.
eventuell müssen Sie mailx noch über das Paket mailutils sowie finger nachinstallieren. wählen Sie dann, wen Sie gefragt werden, erstmal „keine konfiguration“ aus.
automatische Systemupdates
Um die sicherheit zu gewährleisten, müssen wir regelmäßig sicherheitsupgrades installieren. Das machen wir über das paket unattended-updates oder über cron.
Lösung über unattended-upgrades
sudo apt-get install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
es wird die Datei /etc/apt/apt.conf.d/20auto-upgrades erstellt mit folgendem inhalt
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
wenn wir wollen, dass falls nötig das sysdtem nach einem update automatisch neu gestartet wird, dann
Unattended-Upgrade::Automatic-Reboot "true"
sowie installation von
apt-get install update-notifier-common
desweiteren wird die Datei /etc/apt/apt.conf.d/50unattended-upgrades mit folgendem inhalt angelegt:
// Automatically upgrade packages from these (origin, archive) pairs
Unattended-Upgrade::Allowed-Origins {
// ${distro_id} and ${distro_codename} will be automatically expanded
"${distro_id} stable";
"${distro_id} ${distro_codename}-security";
"${distro_id} ${distro_codename}-updates";
// "${distro_id} ${distro_codename}-proposed-updates";
};
// List of packages to not update
Unattended-Upgrade::Package-Blacklist {
// "vim";
// "libc6";
// "libc6-dev";
// "libc6-i686";
};
// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. The package 'mailx'
// must be installed or anything that provides /usr/bin/mail.
//Unattended-Upgrade::Mail "root@localhost";
// Do automatic removal of new unused dependencies after the upgrade
// (equivalent to apt-get autoremove)
//Unattended-Upgrade::Remove-Unused-Dependencies "false";
// Automatically reboot *WITHOUT CONFIRMATION* if a
// the file /var/run/reboot-required is found after the upgrade
//Unattended-Upgrade::Automatic-Reboot "false";
Lösung über cron
Wir erstellen ein Skript, welches wöchentlich ausgeführt werden soll. dazu erstellen wir im Ordner /etc/cron.weekly ein Skript namens apt-security-updates mit folgendem Inhalt:
echo "**************" >> /var/log/apt-security-updates
date >> /var/log/apt-security-updates
aptitude update >> /var/log/apt-security-updates
aptitude safe-upgrade -o Aptitude::Delete-Unused=false --assume-yes --target-release <Leerzeicehn> `lsb_release -cs`-security >> /var/log/apt-security-updates
echo "Security updates (if any) installed"
Führen Sie diese Befehle jetzt einmal manuell aus, um sicherzugehen, dass sie funktionieren. Falls es ein Problem mit dem kommando lsb_release -cs gibt, dann sollten Sie anstatt des Befehls einfach die Ausgabe des Befehls in das skript selbst schreiben
Diese Logdatei, die geschrieben wird, könnte theoreitsch irgendwann zu groß werdne. Deswegen müssen wir sicherstellen, dass sie ausrotiert wird. Das machen wir über logrotate. Wir erstellen dazu die datei /etc/logrotate.d/apt-security-updates mit folgendme inhalt:
/var/log/apt-security-updates {
rotate 2
weekly
size 250k
compress
notifempty
}
die Datei muss noch ausführbare gemacht werden
chmod +x /etc/cron.weekly/apt-security-updates
Zusätzlich können in regelmäßigen Abständen manuelle Upgrades gemacht werden über
sudo apt-get update
sudo apt-get upgrade
Darüber werden auch upgrades installiert, die nicht als „sicherhitsupgrade“ eingestuft werden. _dadurch können Sie auch release-wechsel machen. Vor solch einem update sollten Sie jedoch in der Regle ein allumfassendes Backup Ihres Systems machen, da solche Nicht-Secuirty-Updates immer ein Risiko für das system sind. Falls der Server virtualisiert ist, machen Sie einen Snapshot.
zu guter letzt wollen wir uns noch über verfügbare Systemupdates benachrichtigen lassen. Auf Ubuntu geht das mit dem Paket apticron.
Alle nicht benötigten Ports sperren
Mit einer sogenannten Whitelist lassen Sie nur Verbindungen aus dem Internet auf Ports zu, die explizit für Ihren Server gebraucht werden.
Einen super uide zu iptables und über die Basiskonfiguration bietet ihnen mein entsprechender blogpost
Um festzustellen, welche Ports derzeit von Ihren Diensten gebraucht werden, nutzen Sie den Befehle
netstat -an | egrep 'Proto|LISTEN'
Zum Schluss checken wir nochmal mit
netstat -tupan
netstat -tulp
sowie mit
nmap -p <IP-Adresse der Netzwerkschnittstelle>
nmap -sU <IP-Adresse>
nmap -sT
#beispiel
nmap -p 127.0.0.1
nmap -p 192.168.2.20
nmap -p 80.37.56.23
nmap -sS -v -O ip.address.on.network
#selbiges mit nmap -sU
ob noch irgendwelche unerwünschten Ports offen sind.
um die services zu deaktivieren, geben Sie ein:
service <servicename> stop
chkconfig <servicename> off
Hinweis: Unter einigen Linux-distributionen gibt es Ports, die standardmäßig offen sind, aber in der regel nicht gebraucht werden. Solche ports sind beispielsweise
- RPCBind 111. Muss zwar im lokalen netzwerk angeboten werden, muss aber nicht nach außen in das öffentliche netzwerk online sein.
- cups
Nicht genötige Dienste schließen / deinstallieren
auf einem Server laufen häufig Dienste, die in der Standardinstallation einer Linux-Distribution mitgeliefert werden, auf diesem jedoch nicht gebraucht werden. Solche Dienste sind beispielsweise
- cupsd auf Port TCP/631. Wenn Sie keinen Druckserver betreiben, sollten Sie den dienst deaktivieren.
service cups status
service cups stop
service cups status
chkconfig --list cups
update-rc.d cups disable
update-rc.d cups remove
falls das nicht funktioniert, müssen Sie den Service über die cups-config-datei deatkiivieren.
einige erweiterte Netzwerksicherheit
es ist empfehlenswert, den Hostnamen der maschine abzuändern, wenn er bisher noch auf dem Standard-Hostnamen sitzt.
Bearbeiten Sie dazu, falls vorhanden, zunächst die Datei /etc/sysconfig/network und ändern dort den Parameter HOSTNAME. Dort können sie, falls sie ken IPv6 verwenden, auch gleich den Paramter NETWORKING_IPV6 auf no setzen.
Dann ändern Sei den Hostnamen noch in der Datei /etc/hostname, in der /etc/hosts beim Eintrag für die loopback-Adresse 127.0.0.1 und ganz am Schluss über de kommandozeilen Befehl
hostname <neuer hostname>
Falls Sie eine Top Level Domain oder zumindest einen DynDNS-hostnamen verwenden, sollten Sie hostnamen auf den Hostnamen ändern, den sie dort festlegen wollen. Wenn Sie beispielsweise ein DynDns auf den namen meinblog.dyndns.org haben, dann ändern Sie den hostnamen auf meinblog.
Wenn Sie ganz sicher kein IPv6 brauchen, können Sie IPv6 ganz einfach deaktivieren, indem Sie die beiden Dateien /etc/modprobe.conf und /etc/sysconfig/network bearbeiten. in erstere Datei geben Sie ein install ipv6 /bin/true, in die letzetere aktualisieren Sie hinein
NETWORKING_IPV6=no
IPV6INIT=no
und starten das sytem neu.
Wenn Sie außerdem sicher sind, dass dieser Linux Server nicht als Firewall oder Gateway genutzt wird, um IP-Netzwerkverkehr zwsicehn verschiedenen netzwerken zu steuern und Achtung: dieser Server nie als VPN-Server fungieren wird, dann können Sie in der Datei /etc/sysctl.conf foglende Zeilen hinzufügen:
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.tcp_max_syn_backlog = 1280
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.accept-source_route = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.icmp_echo_ignore_boradcasts = 1
net.ipv4.icmp_ignore_bogus_error_messages = 1
net.ipv4.tcp.syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.tcp_timestamps = 0
TCP Wrapper
TCP wrapper können eine schnelle und einfache methode darstellen um Zugriff auf mit ihnen verbundene Applikationen zu erhalten. Solche Applikationen sind beispielsweise sshd, ftp und portmap. Je nachdem, mit welchen Tools Sie TCP Wrapper bnenutzen können, können Sie alle anderen Applikationen aussperren. Das folgende beispiel blockt alle Appliaktionen außer den SSHd
echo "ALL:ALL" >> /etc/hosts.deny
echo "sshd:ALL" >> /etc/hosts.allow
Nehmen wir jetzt einmal an, Sie durchstöbern mal eines ihrer Logs ioder bekommen von einem der oben geannnten Skripte eine e-Mail geschickt, dass ein Loginversuch, ein Verbindungsaubfau o. Ä. von einer bestimmten Ip-Adresse geblockt wurde.
Was sie jetzt tun können, ist, einen reverse lookup auf diese Ip-.Adresse über http://mxtoolbox.com/ReverseLookup.aspx vorzunehmen. Eventuell erhalten Sie einen Hostname zu dieser IP-Adresse. Handelt es sich um einen Server, bleibt die Ip-Adresse vermutlich immer statisch. sie können dann diesen expliziten Host in die hosts.deny hinzufügen und damit Verbindungen von diesem Host künftig nicht mehr zulassen. Desweiteren können sie eine iptables-Regel festlegen, die Verbindungen von diesem Host abweist.
iptables -I INPUT <position> -s <ip-adresse>/255.255.255.255 -j DROP
Wenn Sie keinen Hostname bekommen, können Sie zumindest noch schuaen, welchem Internet Service Provider oder welchem Unternehmen diese IP-Adresse gehört. Wenn Sie sicher sind, dass Kunden von einem russischen ISP beispielsweise nichts auf ihrer in deutscher Sprache geschriebenen Seite zu suchen haben, können sie schauen, welche Ip-Adressen in deren Pool sind – und diese range dann theoretisch sperren. Meistens ist dies aber overkill und Sei sollten sich in solchen Fällen auf das an anderer Stelle vorgeschlagene fail2ban verlassen.
Was Sie jedoch auf jeden fall machen können, sit , dass Sie Verbindungsversuche von einer einzelnen IP oder von einer IP-Range loggen lassen können. dazu fügen Sie in die hosts.deny folgende Zeile
ALL : <ip-adresse oder ip-netz> : spawn /bin/echo `date` %c %d >> /var/log/intruder_alert
Sie können zusätzlich zu den Logs, die Sie über iptables anlegen lassen, außerdem Logs über TCP wrappers für Verbindungsversuche auf kritische Services anlegen lassen. Beispieslweise könnten Sie Verbindungsversuche auf den port 23 (Telnet) loggen lassen, idnem sie folgende Zeile in die hosts.deny eintragen:
in.telnetd : ALL : severity emerg
vermehrte sicherheit mit xinet.d
xinet.d ist ein Superserver. Das heißt, es handelt sich hier um einen Daemon, der andere daemons steuern soll.
Daemons von beispielsweise Webservern oder FTP-Servern sind in der regel gut darin, ihren Job zu tun: Nämlich einen entsprechenden Dienst bereitzustellen. Das problem dabei: diese Dienste haben in der Regel viele nützliche Funktionen nicht integriert. solche sinnvollen Funktionen wären beispielweise
- einen Dienst zeitgesteuert zur Verfügung zu stellen. Nehmen wir einmal an, sie hosten einen FTP-Server für eine community und Sie können sicher sein (oder haben aus der auswertung von Logs erfahren), dass nach 23 Uhr kein User der community den FTP-Server mehr benutzt. Das heißt von 23 Uhr bis beispielsweise 07 Uhr morgens läuft der server umsonst und frisst einerseits unnötig Performance und Strom und andererseits stellt er in dieser Zeit eine unnötige mögliche sicherheitslücke dar, da Sie evtl. schlafen und nicht auf Attacken reagieren können. Daher wäre es beispieslweise sinnvoll, den Server in diesen Zeiten abzuschalten
- einen Dienst nur auf Anfrage zur Verfügung stellen. Manchmal macht es Sinn, einen Serverdienst nur auf Anfrage zur Verfügugn zu stellen, also wenn ein User eine konkrete verbindung zu diesem Serverdienst aufbaut. Denn ohne Anfrage läuft der Serverdienst sinnlos im hintergrund und stellt einen unnötigen Performance- und Stromfreser sowei eine unnötige Sicherheitslücke dar. Es wäre sinnvoll, zu warten, bis ein User eine Verbindung zum Port des Daemons aufbaut und dann SErver kurzfrisitg zu straten. Nachdem die Verbindung getrennt wurde und eine gewisse Zeitspanne nach der trennung keine neue Anfrage mehr kommt, wird der Daemon wieder gestoppt.
- bestimmte IP-Adressen, Hostnamen und Verbindungsanfragen zu blocken. Wenn Sie beispieslweise wissen, dass ihr Server immer wieder von ein und dersleben IP-Adresse angegriffen wird, wäre es sinnvoll, dass der Daemon bereits eien Möglichkeit bietet, Verbindungsanfragen davon zu blockieren.
- Daemon-seitiges Logging. Es wäre cool, wenn der Serverdienst selbst bereits dazu in der Lage ist, Verbindungsanfragen auf seine Diesnte zu loggen, um somit eine Möglichkeit zum Nachvollziehen von möglichen Angriffen oder zum Verhalten von Usern zu ermöglichen.
- Verteidigungsmechanismen gegen Denial of Service Attacken und Portscans. Viele Server Daemons sind nicht dazu in der Lage, anhand von Verhaltensmustern von Client-Anfragen auf die dienste des Daemons zu erkennen, ob es sich um eine ernstgemeinte anfrage oder um eine sinnlose Denial of Service Attacke oder etwa einen Portscan handelt.
Immer, wenn Dienste solche nützlichen Funktionen nicht bieten, kommt ein superserver ins Spiel. Der superserver ist sozusagen dann das Fundament, auf dem die eigentlichen Daemons gestartet und gestoppt werden. die eigentlichen Daemons werden vom superserver gewartet und verwaltet. Dabei bietet er die oben aufgeführten begehrenswerten Funktionen, obwohl die eigentlichen Daemons diese von Hause aus nicht bieten.
Der xinet.d ist eine sichere Weiterentwicklung des inet.d. Der Vorgänger inet.d sollte generell nicht mehr genutzt werden.
Konfiguriert wird der xinet.d über die datei /etc/xinetd.conf. Diese wird eingeteilt in eine default-Sektion, die standardmäßig für die mit dem xinet.d kontrollierten Daemons gitl, und Sektionen für bestimmte Daemons, die enie davon abweichende Konfiugration bekommen sollen. gängige Praxis ist es jedoch, anstelle einer neuen Sektion in der /etc/xinetd.conf eine Datei im ordner /etc/xinetd.d für einen bestimmten Dienst aufzumachen und diese Datei dann über include in die Hauptkonfiguration einzubinden.
Nach einer Konfigurationsänderung muss der xinet.d nicht neu gestartet werden. Er kann seine Konfiguration dynamisch neu einlesen über
/etc/init.d/xinetd reload
Ein sinnvoller defaults-Block in der xinetd.conf wäre beispielsweise
defaults
{
# Was geloggt werden soll:
log_type = SYSLOG daemon
log_type FILE /var/log/xinetd.log
log_on_success = HOST PID EXIT DURATION
log_on_failure = HOST USERID
instances = 25
# Pro Client max. 5 parallele Verbindungen zu jedem Service:
per_source = 5
}
die direktive log_type legt fest, wohin xinet.d Zugriff auf seine Daemons protofokollieren soll. Wir wählen SYSLOG – damit könnten wir nicht nur in eine log-Datei, sondern auch in eine syslog-facility loggen lassen. Für den fangn reicht uns aber eine Datei, die wir mit log_type FILE angeben.
Mit log_on_success legen wir dann fest, welche informationen bei einem erfolgreichen Verbindungsaufbau protokolliert werden sollen. Das Beispiel loggt die prozess-ID des gestarteten serve-rprozesses, die IP des zugreifenden clients und en Statuscode nach Beenden des servers sowie die dauer der vebridnung.
mit log_on_failure legen wir fest, wa sbei einem geschieterten Verbidnugnsversuch protkolliert wird. Neben der IP wird auch versucht, eien Ident-abfrage nahc dem benutzer zu machen. Bei Erfolg wird die entfernte Benutzer-ID angegeben.
Mit der Direktive instances ist es möglich, festzulegen, wie viele Serverprozess-Instanzen ein Dienst gleichzeitig laufen lassen kann. Das ist sinnvoll bei Serverprozessen, die für jede Verbindung eine extra Serverprozessinstanz aufbauen. Das können Sie überprüfen, indem sie sich mit mehr als einer vebrindung auf einen der Serverprozesse verbinden und beim hinzukommen einer weiteren Verbindung über ps -ef prüfen, ob ein prozess hinzugekommen ist oder nicht.
die per_soruce einstellungen hilft z. B. ein wenig, eine denial of service attacke abzuwehren, indem nicht mehr so viele aprallele verbidnungen von der selben IP auf einem service sein können.So eine Einstellung macht natürlich beispielsweise auf einem Webserver wenig sinn,wenn mehr als 5 user gleihczeitig online sein sollen. Sollten Sie den Web-Daemon über den xinet.d steuern, müssen sie hier entsprechend eine abweichende einstellung konfigurieren.
Wenn Sie sich dazu entschieden hbaen, für die Services, die per xinet.d verwaltet werden sollen, Serviceblöcke in die hauptkonfiguration zu zu schreiben, müssen Sie diesen in diesem Format erstellen:
service <name>
{
socket_type = stream
protocol = tcp
port = 3000
type = UNLISTED
wait = no
user = nobody
server = /bin/echo
server_args = Hallo Welt!
disabled = yes
}
#Beispiel
service finger
{
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = /usr/sbin/in.fingerd
}
der name, den Sie für den Service eingeben müssen, ist der name, der in der datei /etc/services steht. Wenn es einen Dienst sowohl über UDP als auch über TCP gibt und Sie beide varianten verwalten wollen, brauchen sie auch zwei Blöcke mit einem jeweils anderen protocol-Parameter.
Mit der option disabled = yes können Sie einstellen, dass ein Service von xinet.d nicht gestartet werden soll, auch wenn man den Befehl dazu eingibt
die Option interface gibt an, auf welcher Schnittstelle der Dienst lauschen soll. somit könnte man beispielsweise sensible Dienste auf das interne Interface eines Routers beschränken, sodass von außen nicht darauf zugegriffen werden kann.
Mit der option id können Sie zwei ansonsten gleichnamige Serviceblöcke unterschieden – beispeislweise wenn Sie einen Serviecblock für UDp und einen für TCP erstellt hbaen, vergbene Sie in den zwei SErviceblöcken einfach die IDs
#serviceblock TCP
id <servicename>-stream
#serviceblcok UDP
id <servicename>-dgram
Mit der option only_form haben Sie die möglichkeit, nur bestimmten Hosts den Zugriff auf den SErvice zuzulassen. no_access verweigert hingegen den Zugriff. Findet sich ein Host in beiden Optionen, gilt die spezifischere. die Angaben können dabei folgendermaßen aussehen:
only_from 192.168.1.1 192.168.1.0/24 jesus.de
no_access gully.to 192.168.1.254
Die Option no_access macht noch mehr sinn, wenn man mit ihr hosts vebrietet, welche eine Portscan-Attacke auf das System ausführen. Diese Hosts kann man vom xinetd erkennen lassen. Dazu bietet der xinet.d die option SENSOR. dieser springt an, sobald eine Verbindung auf diesen port aufgbeaut wird. Es macht daher nur Sinn, SENSOR auf einen Service anzuwenden, den man von Haus aus nicht nutzen möchte. Dabei beitet sich das Protookoll telnet an, da viele automatiiserte Portscan-Attacken erstmal den telnet-Port probieren, da dieser Dienst in der Regel das schwächste Glied in einer Serverkonfiguration ist. Deswegen geben wir in einem SErviceblock für den telnet Dienst ein:
telnet {
flags = SENSOR
deny_time = 30
disable = no
}
Das ganez funktioniert so: Der Angreifer ist ein Cracker, der ein automatisches Skript füpr seine Angriffe benutzt. DAs Skript sieht zuerst nach, welche Diesnte auf dem System laufen, und führt dann für einen Dienst, für den es eine Sicherheitslücke ist, ein automatisches Skript aus, das diese Lücke ausnutzt. Durch die obige Einstellung suggerieren wir dem Angreifer, dass wir auf unserem System den telnet-Dienst laufen haben. Der angreifer wird dadurch fehlgeleitet, da dieser dann versucht, das telnet-Skript gegen unseren Server auszufürehn. das SENSOR-Flag sorgt dafür, dass die weiter uten stehenden Einstellungen aktiviert werden, sobald eine Verindung auf den telnet-Port eingeht. die Einstellung deny_time sorgt erstmal dafür, dass für die nächstne 30 Minuten keine weiteren Verbindungen vom angreifenden Host auf diesen telnet-Port möglich sind. Das ist an sich noch nichts spekakuläres, da ein Portscan die Ports in der regel sowieso nur einmalig abgreifen will – es verhindert aber die Ausführung des gegnerischen telnet-Skritps gegen diesen Port. der xinet.d legt dann einen Eintrag in unserenserver-Logs an, welcher die KIp-Adrese des hosts beinahltet, der uns attackieren wollte.
Mit der option access_times können sie festlegen, zu welchen uhrzeiten der Service den Benutzern offen stehen soll. Außerhalb der zeit kann auf den SErivce nicht zugegriffen werden
access_times 07:00-19:00
außerdem gibt es noch ein poaar sinnvolle Paramter zur einschränkung von Ressourcen
- cps <nzahl der verbindungen > <wartezeit> – beschränkt die Rate der eingehenden Verbidnungen. Anzahl der verindungen regelt, wie viele Vebridnungen pro Sekunde gehandled werden können. Wenn die Rate der eingehenden Verbidnugnen höher ist, wird der service temporär deaktiviert. Die Zeit der Deaktivierung wird dahinter angegeben.
- instances – kennen Sie bereits. Anzahl der gesamten gleichzeitigen Vebridnugenna uf einen SErvice, die erlaubt sind.
- per_source – kennen sie. anzhal der vebridnugnen, die pro host elraubt sind.
- rlimit_as = <zahl>[K|M] gibt die Menge an Arbeitsspeicher an, den ein Service in Kilobyte oder megabyte belegen kann.
- rlimit_cpu = <nummer> gibt in sekunden die Menge an Zeit ein, die ein Service von der CPU auf einmal beanspruchen kann.
Diese oben geannnten Parameter können – clever gewählt – eine Denial of Service Attacke verhindern. Schlecht gewählt können Sie jedoch den Service oder das ganze System lahm legen.
Ports eventuell lokal horchen lassen
Einige ports auf Ihrem System sind offen, müssen aber in der regel nur intern über den Loopback-Adapter aufgerufen werden. Beispiel: sie haben eine Website, beispieslweise eine webbasierte monitoring-Lösung, installiert, die auf Port 80 lauscht. Wenn sie in der port-konfiguration von apache nachsehen, werdden sie allerdings feststellen, dass der Service auf Port 80 für alle IP-Adressen lauscht. Das können sie ändern
sudo vi etc/apache2/ports.conf
Listen 127.0.0.1:80
Jetzt horcht der Apache nur noch auf Port, wenn die Verbindungsanfrage vom Loopback-Adapter kommt. Aus dem Interent ist nun keine Verbindung mehr auf diesen Port möglich.
Ähnlcihe Konfigurationen können Sie auch auf anderen Ports vornehmen, die Sie nur lokal brauchen.
In den meisten Fällen brauchen Sie auf ihrem server auch kein Wirless. Deswegen werden wir im Foglenden alle Wireless-Treiber deaktiiveren. Dazu könnten wir theoretisch durch die inahtle von /lib/modules für dena ktuellen ekrnel gehen und alle Wireless Treiber löschen. Das ist jedoch keine permanente lösung, da die Treiber in einer neuen Kernelversionw eider vorahdnen sidn. Statdessen machen wir eine kleine Schleife über eine Blacklist in /etc/modprobe.d
for i in $(find /lib/modules/`uname -r`/kernel/drivers/net/wireless -name "*.ko" -type f) ; do echo blacklist $i >> /etc/modprobe.d/blacklist-wireless ; done
netfilter regeln
arp tabellen einträge
txqueuelen, mtu
icmp replies, icmp redirects
ECN
slow-start
nichtgenutzte ports deaktivieren
scannen Sie nach schwachen Passwörtern
mit dem Tool „John the Ripper“ können Sie nach schwachen Passwörtern auf ihrem System suchen.
nicht benötigte Software deinstallieren
Die installierte software, die sie auf Ihrem System installiert haben, können Sie sich mit den verschiedenen Paketmanangern anzeigen lassen – abhängig davon, welchen Sie benutzen, müssen Sie dazu einige der folgenden kommandos eingeben
yum list installed
yum grpulist
rpm -aa | sort
dpkg -list
dpkg -l
dpkg-query -W -f='${PackageSpec}\t${version}\t${Description}\n'
dpkg --get-selections | grep -v deinstall
aptitude search '~i!~M'
( zcat $( ls -tr /var/log/apt/history.log*.gz ) ; cat /var/log/apt/history.log ) | egrep '^(Start-Date:|Commandline:)' | grep -v aptdaemon | egrep '^Commandline:'
das entfernen geht dann je nachdem folgendermaßen:
yum erase <paketname>
apt-get remove <paketname>
desweiteren solltet ihr unter ps -ef und evtl. mit
rpm -qfi <pfad zum fraglichen prozess-binary>
schauen, welche Prozesse / Daemons laufen und ob ihr wirklich alle davon braucht.
das entfernen geht, wie oben schonmal gezeigt, über
service <servicename> stop
chkconfig <servicename> off
Häufig nicht benötigte Services sind beispielsweise
- X-Windows
yum groupremove „X Window System“
editieren Sie außerdem die Datei /etc/inittab und setzen Sie das Runlevel auf 3. Somit steht auf gar keinen Fall eine grafische oberfläche zur Verfügung.
Sicherheit durch ordentliche Partitionierung#
Es ist ebenfalls der Sicherheit des systems zuträglich, wenn Sie die Systemdateien von Userdateien trennen, indem sie das System rodentlich partitionieren. Ein guter Partitionierungsplan ist beispielsweise, extra Partitionen für die folgenden Mountpoints einzurichten
- /boot
- /usr defaults
- /home defaults,nosuid, (noexec siehe unten),nodev
- /var. defaults,nosuid,(noexec)
- /var/www – defaults,nosuid,nodev,(noexec).
- /var/tmp defaults,nosuid, noexec, nodev
- /sys defaults
- /dev/pts defaults
- /dev/shm defaults,nosuid, noexec, nodev
- /tmp. defaults,nosuid, noexec, nodev
- /root defaults,nosuid,(noexec),nodev
- /proc defaults
- swap defaults
- rest des speicherplatzes auf /
In diesem Zusammenhang können wir jetzt die datei /etc/fstab editiern und – speziell auf den Partitonen /home udn /root, aber auch auf allen anderen Partitionen in denen binaries nichts zu suchen haben – das ausführen von binärdateien verhindern. Denn diese haben in der Regel nur in Ordnern /usr etwas verloren. Desweiteren kann amn verhindern, dass die log-Dateien, die sich unter /var befinden, die gesamte festplatte vollschreiben und somit das System lahm legen. Gleiches gilt für die Home-Verzeichnisse von gekaperten Useraccounts, die ggf. mit Müll-Dateien vollgespammt werden. Der mountpoitn /dev/pts enthält Pseudo-Terminals, die nach einem SSh-login geöffnet werden. Es ist daher von interesse, diese pseudo-terminals ebenfalls in einem extra dateisystem einzuschließen. /dev/shm ist das shared memory segment – also ein Speicherteil, den sich programme miteinander teilen, wenn Sie gerade die gleichen Daten verarbeiten. Das ist desöfteren der Fall bei relationalen Datenbankmanagementssytemen, bei Virtualisierungssoftware und dergleichen. Wenn sie shared memory nutzen, legen Sie dafür eine entsprechende Extrapartition an. Das Verzeichnis /proc ist kein wirkliches Dateisystem, sondern eine Schnittstelle zum Kernel – sie dient dem Auslesen von Prozessinfomrationen.n Aus diesem Grund sollte /proc ebenfalls abgetrennt werden. /var/www KANN noexec sein, beeinflsust jedoch cgi-basierte applikationen und server-seitige includes. Sie können das noexec-Bit für /var/www testen – und wenn es nicht klappt, einfach wieder entfernen.
Das noexec-bit für das /home-Laufwerk sollten Sie nicht setzen, wenn Sie Weboberfläcehn wie beispieslweise cPanel nutzen. Denn dann ist in den Home-Laufwerken der jeweiligen angelegten Kunden eine ausführbare Datei im /home-Einhängepunkt auf Ausführrechte angewiesen. Desweiteren sollten Sie das Bit nicht setzen, wenn Ihre User beispeislweise über einen Webserver wie easyapache von Ihrem home-Laufwerk aus .php oder .cgi-Skripte ausführen können sollen.
Das bezwecken wir durch dei folgenden optionen in der /etc/fstab:
- noexec – verhindert das ausführen von binaries auf dem jeweiligen gemounteten dateisystem
- nodev – verhindert das interpretieren von zeichen- oder block special devices auf dem dateisystem. Nützlich auf servern mit dateisystemen die special devices für andere serverarchitekturen enthatlen
- nosuid – verhindert das setzen des user_identifierr oder group-identifier-bits für Dateien.
Eine Besonderheit: Wenn Sie die möglichkeit haben, LVM einzusetzen, um somit die Größe von Partitionen frei wählen zu können, sollten Sie nicht allen restlichen Speicherpaltz auf den Einhängepunkt / geben, sondern ein zusätzlcihes logisches Volume erstellen – beispielsweise /free – von dem sie sich später Speicherplatz klauen, wenn Sie irgendwann mal eines der anderen LVMs vergrößern müssen. Das hat ebenfalsl wieder einen Sicherheitsvorteil, weil dann die Festplatte von keinem der anderen Einhängepunkte aus vollgeschrieben werden kann. Wenn Sie /free dann noch ohne Schreibrechte mounten, darf darin auch niemand schreiben und Ihr Festplattenspeicherplatz ist gerettet.
Dienste vor Brute-Force-Attacken schützen.
das geht mit dem Tool Fail2bain
apt-get install fail2ban
wir bearbeiten die config-Datei:
vi /etc/fail2bain/jail.confg
und setzen den inhalt
ignoreip = 127.0.0.1
bantime = 3600
maxretry = 3
Eine IP-Aresse wird nun für 3600 Sekunden geblockt, sobald 3 Fehlversuche durchgeführt wurdne. wir müssen aber noch die dienste konfigurieren, für die fial2bain greifen soll.
Mit diesen _Zeilen aktivieren wir fail2ban für den SSH Daemon
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
Zum schluss müssen wir fail2ban neu starten, damit die Änderungen übernommen werden
/etc/init.d/fail2ban restart
sich vor rootkits schützen
mit dem Tool rkhunter wird der Server reglemäßig auf rootkits untersucht. Dieser versucht dann auch gleich, diese zu entfernen
aptitude install rkhunter
Wir tragen noch unsere Mailadresse ein unter /etc/rkhunter.conf
MAIL-ON-WRANING="meine@email.tld"
Erster check von rkhunter mittels
rkhunter --check
Wenn Sie wissen, dass ein Skript, eine Datei oder ein verstecktes Verzeichnis hierbei als falsch positiv angesehen werden, können Sie foglendermßaen whitelistes definieren:
ALLOWHIDDENDIR=/dev/.mdadm
RTKT_FILE_WHITELIST=/etc/init.d/.depend.boot
SCRIPTWHITELIST=/etc/init.d/hdparm
Installieren Sie einen Vulnerability Scanner
Der bekannteste ist Nessus and VLAD. Alternativen sind SAINT und OpenVAS. openSCAP + OVAL, tiger
Installieren sie ein Auditing Tool
Lynis
auditd
aide. Checkt regelmäßiog das system gegen einen Hash von Schlsüseldateien nach modifikationen.
snort
Zwei sehr empefehlenswerte audit rules sind
auditctl -a always,exit -F arch='arch' -S creat -S open -S openat -S truncate -S ftruncate -F exit=-EACCES -F auid\>\=500 -F auid\!\=429467295 -k ids-exec-hi
auditctl -a always,exit -F arch='arch' -S creat -S open -S openat -S truncate -S ftruncate -F exit=-EPERM -F auid\>\=500 -F auid\!\4294967295 -k ids-exec-hi
User und File Security
verhindern Sei, dass sich der user Root direkt in das System einloggen kann. Das sollten sie natürlich erst machen, nachdem sie sudo eingerichtet haben.
In der Regel reicht es, wenn Sie in der konfiguration des SSH verhindern, dass sich der User root einloggen kann. Das haben wir bereits in der Überschrift „den SSH Zugang absichern“ in den dort verlinkten posts beschrieben.
Wenn Sie jedcoh komplett auf nummer sicher gehen wollen oder auch verhindern wollen, dass sich der User root lokal (also direkt vor dem Server sitzend) anmelden kann, dann ändern Sie die Standard-Shell des root-Accounts zu /sbin/nologin in der Datei /etc/passwd..
Wenn Sie hingegen wollen, dass der User root sich effektiv NUR lokal an am Server anmelden kann udn auf gar keinen Fall per Remote, dann können sie zusätzlich zur Verhinderung des Logins in der SSH-Konfiguration noch
echo "tty1" > /etc/securetty
eingeben. Die Datei /etc/securetty enthält alle Konsolen, auf die sich der User root anmleden darf. Standardmäßig enthält diese Liste nur die tty-Konsolen (die lokalen Konsolen) und nicht die pty-konsolen, also dei pseudokonsolen, auf die sich user per SSH einloggen.
Sie könenn desweiteren jetzt festlegen, dass sich der User root nur auf einer einzigen lokalen shell anmelden darf, indem sie die Datei /etc/securetty bearbeiten und dort alle lokalen shells bis auf eine auskommentieren
tty1
#tty2
#tty3
#tty4
#tty5
#tty6
#tty7
#tty8
Desweiteren sollten Sie sichergehen, dass nur der User root selbst Zugriff auf seinen Ordner hat.
chmod 700 /root
Es ist außerdem eine gute idee zu wissen, welche SUID und SGID dateien auf dem Server sind
find / -perm +4000
find / -perm +2000
schaut euch die einzlenen dateien an und deaktiviert wenn nützlich SUID/SGID.
Außerdem sollten Sie nach sogenannten wordl-writable files suchenl. das sind Dateine auf ihrem System, die von jedem x-beliebiegen User geschrieben und bearbeitet werden können. Mit diesem kommando können Sie diese Dateien und Ordner finden
find / -type f \{ perm +o=w -o -perm +g=w \} -exec ls -lg {} ';'
#ordner finden
find / -type d \{ -perm +o=w -o -perm +g=w \} -exec ls -lg {} ';'
#find orphaned files
find / -nouser -o -nogroup -print
Als nächstes wollen Sie vielleicht, dass alle administrativen aktionen, die ein User durchführt, geloggt werden.
Eine sehr gute möglichkeit dafür ist das pam_tty_audit PAM modul. Wenn durch dieses modul das TTY auditing aktiviert ist, wird es bei allen prozessen geerbt die durch diesen User gestartet werden. Um alle administrativen tätigketein zu verfolgen, fügen wir diese Zeile in /etc/pam.d/su und /etc/pam.d/sudo
session required pam_tty_audit.so disable=* enable=root
somit werden alle Befehle geloggt, die über su und sudo ablaufen
Um uns den Audit trail anzsuehen, geben wir ein:
ausearch -m USER_TTY | grep USER_TTY | grep -v \* | awk-F\* {print $7"0A"} | xxd -r -p | more
das funktioniert nur,w enn wir das an anderer Stelle empfohlene auditd konfiguriert haben.
Desweiteren sollten Sie einstellen, dass man zwingend ein Passwort für den user root braucht, wenn man das system in den single user mode bootet
echo "# Require the root pw when booting into single user mode" >> /etc/inittab
echo "~~:S:wait:/sbin/sulogin" >> /etc/inittab
echo "Don't allow any nut to kill the server"
perl -npe 's/ca::ctrlaltdel:\/sbin\/shutdown/#ca::ctrlaltdel:\/sbin\/shutdown/' -i /etc/inittab
Auf einigen Systemen könenn Sie mit folgendem Befehl die Passwort-protection über sha512 anstelle von md5 handzuhaben
authconfig --passalgo=sha512 --update
Der nächste Tweak setzt die umask des Systems für alle User auf 077. Demnach werden neu angelegte dateien und Verzeichnisse so angelegt, dass Sie standardmäßig nicht von anderen Benutzern des Systems gelesen oder geschrieben werden können. Für die meisten Server ist diese Einstellung in Ordnung. Wenn auf Ihrem Server jedoch aus welchem Grund auch immer verschiedene Betriebssystembenutzer zusammen an einer Datei arbeiten, dann müssen jedesmal die Rechte über chmod umgeändert werden, was für Ihre User eine echte Drecksarbeit werden kann. Die meisten Lösungen zum kooperativen Arbeiten an Dateien jedoch sind ohnehin als SErverlösung realisiert. Das heißt der serverdienst läuft imer mit dem selben User und die Mitarbeiter laden sic die benötigten Daten über einen Service lokal auf ihren Rechner, wo sie dann entsprehcend Schreib- und Leserechte haben. Nach der Bearbeitung werden die daten dann wieder auf den Server hochgeladen. Wenn Sie so arbeiten, was ja auch empfehlenswert ist, dann können Sie die umask von 077 ruhig auf dem Server setzen.
Diese einstellungen sollten Sie in den Dateien /etc/bashrc und in die Datei /etc/profile schreiben. Wenn einige Ihrer User außerdem die corn shell nutzen, dann sollten Sie auch die /etc/csh.cshrc editieren (im Zweifel einfach machen)
und legen Sie fest
umask 077
die änderungen werden beim nächsten Login des jeweiligen users wirksam. Ein User kann jedoch mit dem umask-Kommando (sofern er es ausführen darf – wie Sie das verhindern können, habe ich im Post zum konfigurieren von sudo beschrieben) oder über seine Konfiguratiosndateien im /home-Verzeichnis (etwa ~/.bashrc, ~/.profile usw.) überschreiben. Wenn Sie ganz sicher gehen wollen, dass Ihnen diese Einstellung also erhalten bleibt, müssten Sie theoretisch diese Profildateien zur bearbeitung von den jeweiligen Usern über entsprechende chmod- und chown-Regeln sperren. Das ist jedoch meistens overkill.
weitere Sicherheit können Sie hinzufügen, indem Sie – falls vorhanden – die Datei /etc/pam.d/system-auth bearbeiten. In dieser Datei können Sie beispeislweise folgende Zeilen festlegen (falls noch nicht geschehen):
auth required pam_securetty.so
Sorgt dafür, dass wenn sich ein User als root einloggen will, diese tty in der Datei /etc/securetty aufgelistet wird, sofern die Datei existiert.
auth required pam_unix.so shadow nullok try_first_pass
dieses modul fragt den user nach einem Passwort und prüft das Passwort anhand der infomrationen in /etc/passwd und, falls diese nicht exisitert, anhand der iformationen in /etc/shadow. Die pam_unix.so erkennt und nutzt schattenpasswörter um user zu authentifizieren. Wenn Sie den Parameter nullok weglassen, werden keine leeren Passwörter zugelassen. das Weglassen des Arguments try_first_pass erzwignt das Modul, den User jedesmal nach einem Passwort zu fragen, auch wenn andere Module zuvor bereits das Passwort vom User erhalten haben.
auth required pam_nologin.so
dieses modul prüft ob die /etc/nologin exisitert. Wenn die Datei nologin nicht exisitert und der User nicht root ist, scheitert die authentifzierung.
account required pam_unix.so
prüft, ob das Passwort des users abgelaufen ist.
password required pam_cracklib.so retry=3
wenn ein Passwrot abgelaufen ist, fragt die Passwortkomponenten von pam_cracklib.so nach einem neuen Passwort. Das neu erstellte Passwort wird dann getestet auf die Widerstandsfähigekit gegen Wörterbuchangriffe. Der User darf dann dreimal versuchen, ein stärkeres Passwort zu setzen.
password required pam_unix.so shadow nullok use_authtok
diese zeile sagt aus, dass wenn das programm das userpasswort ändert, die passwortkomponenten von pam_unix.so dazu genutzt wird. Das passiert nur, wenn der auth-teil von pam_unis.xo erkannt hat, dass das Passwort geändert werden muss. Das Argument sahdow sagt dem modul, dass es schattenpasswörter erstlelen soll, wenn ein user-Passwort geändert wird. Das arugment nullok sat dem modul dass es dem User erlauben soll sein Passwort VON einem leeren Passwort zu ändern (nicht ZU) – andeerenfalls würde ein leeres Passwort als gesperrter Accout interpreiert werden. Das letzte Argument ist use_authtok, welches dem modul sagt den user nicht nach einem neuen Passwort zu fragen, wenn bereits durch ein zuvor greifendes modul ein Passwort übergbeen wurde. So müssen alle neuen Passwörter die pam_cracklib.so und deren tests passieren, damit diese akzepteirt werden.
session required pam_unix.so
sagt aus, dass das pam_unix.so modul die Session des Users verwalten soll. Dieses moduls loggt den usernamen und den servicetyp nach /var7log7meseages zu Beginn und zum Ende einer jeden Session.
sie können sich im weiteren Verlauf noch weiter über den Linux pam.d informieren. Eine von mir empfohlene konfiguration:
touch /var/log/tallylog
cat << 'EOF' > /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
auth required pam_tally2.so deny=3 onerr=fail unlock_time=60
account required pam_unix.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so
account required pam_tally2.so per_user
password requisite pam_cracklib.so try_first_pass retry=3 minlen=9 lcredit=-2 ucredit=-2 dcredit=-2 ocredit=-2
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok remember=10
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
EOF
Jetzt wollen wir noch fogelndes machen: wir kicekn alle User, die derzeit angemeldet und idle sind. Kann ja sein, dass sich irgendein benutzer irgendwie mal in der vergangenheit eingeloggt hat, dessen session nie beendet wurde. Dazu nutzen wir eine bash-variabel in /etc/profile.
echo "Idle users will be removed after 15 minutes"
echo "readonly TMOUT=900" >> /etc/profile.d/os-security.sh
echo "readonly HISTFILE" >> /etc/profile.d/os-security.sh
chmod +x /etc/profile.d/os-security.sh
Als nächstes gilt es die Frage zu klären, ob Sie auf Ihrem System einen servergestützen Dienst zur Userauthentifizierung wie beispielsweise LDAP nutzen wollen. FAlls ja, sollten Sie LDAP antürlich aktiviert lassen und so schnell wie möglich konfigurieren, da dies sogar zuträglich für die sicherheit ihres systems ist. Falls sie jedoch LDAP nicht verwenden wollen,s ollten Sie LDAP-Authentifizierung im Linux-System gänzlich deaktivieren, da die Möglichkeit zur LDAP-Authentifzierung ansonsten grundsätzlich eine mögliche sichehreitslücke darstellt.
Zum deaktivieren führen sie aus
authconfig --disableldapauth --disableldap --enableshadow --updateall
die meisten Server verwenden keine USB-Speichermedien, sondern beispielsweise eSATA, SAS oder SCSI. Deswegen können Sie bei den meisten Servern getrost den USB-Device-Treiber deaktivieren. Dieser Treiber wird einfach als Kernelmodul deaktivieren. Dies verhindert dass der Kernel automatisch den USB-Treiber lädt – jedoch kann der User root das modul wieder aktivieren, davor schützt es also nicht
deaktivieren über modprobe:
# echo 'install usb-storage : ' >> /etc/modprobe.conf
#oder
echo "Disabling USB Mass Storage"
echo "blacklist usb-storage" > /etc/modprobe.d/blacklist-usbstorage
komplettes entfernen des Storage Treibers:
# ls /lib/modules/$(uname -r)/kernel/drivers/usb/storage/usb-storage.ko
# mv /lib/modules/$(uname -r)/kernel/drivers/usb/storage/usb-storage.ko /root
Sie können zusätzlcih USB im BIOS des Servers deaktiiveren und den USB Kernel Support über Grub deaktivieren. Beabreiten sie dazu die Datei /boot/menu.lst bzw. /boot/grub.conf und fügen Sie ein:
kernel /vmlinuz-2.6.18-128.1.1.el5 ro root=LABEL=/ console=tty0 console=ttyS1,19200n8 nousb
Manchmal wollen eure Administratorkollegen, dass der root-Nutzer oder andere trusted user dazu in der Lage sind, Cronjobs oder geplante Skripte mit at auszuführen. Um das zu unterbinden, müssen wir cron.deny und at.deny Dateien in /etc mit den namen aller geblockten user reinschibeen. Eine einfache methode dafür ist es, die /etc/passwd zu durchwandern und sich von der alle usernamen zu klauen. das folgende skript verhindert das ausführen von cronjobs und at-jobs druch den user root und alle user, die der gruppe root angehören
echo "Locking down Cron"
touch /etc/cron.allow
chmod 600 /etc/cron.allow
awk -F: '{print $1}' /etc/passwd | grep -v root > /etc/cron.deny
echo "Locking down AT"
touch /etc/at.allow
chmod 600 /etc/at.allow
awk -F: '{print $1}' /etc/passwd | grep -v root > /etc/at.deny
in einigen Linux-Distribtuionen finden Sie die datei /etc/permissions, welche ihnen eine Liste von Dateien gibt, die suid-Rechte haben sollten. diese Liste können Sie nicht nur checken, sondern Sie können auch alle suid-Rechte auf diese estnadardeinstellung zurücksetzen, wenn sie folgenden Befehl ausfhren
chkstat -set /etc/permissions*
eine weitere theoretischer Sicherietslücke sind sogennante magic SysRq Keys. ein magic SysRq key ist eine Tsatenfolge die es erlaubt, einige Kommandos direkt an den Kernel zu shicken. Kernel-Softwareentwickler nutzen diese Schnittstelel, um ihre software zu debuggen. Diese Schnittstelle kann jedoch auch von Angreifern genutzt werden, um ein serversystem unsauber zu rebooten. Desweiteren dienen Sie als Angriffsfläche für eine Denial of Service attack. Für Server, die ja nicht zur Kernelsoftwarentwicklung genutzt werden, können die SysRq-Keys geschlossen werden.
wir können die schnittstelel deaktivieren indem wir eine Kernelvariable setzen. dazu schreibenw ir einfach eine 0 in die Datei /proc/sys/kernel/sysrq. Altenraitv können wir auch das sysctl-kommando nutzen
sysctl -w kernel.sysrq=0
damit das dauerhaft bleibt, schreiben wir in die /etc/sysctl.conf
# Disables the magic SysRq key
kernel.sysrq = 0
ACLs
Logserver
Falls es ihnen möglich ist (Administratoren, die nur einen Server zur Verfügung haben oder deren Server über das web als VServer gehostet ist, verfügen nicht über die Ressourcen oder den Luxus eines zweiten Servers als Logserver), sollten Sie einen zentralisierten log Server nutzen – dies erhöht nicht nur die performance und Leistungsfähigkeit ihrer systme, sondern acuh die sicherheit. Denn so:
- können sichehritsrisiekn wie fehlgeschlagene Loginverusche, Port scans etc. erkannt werden
- troubleshooting von user login problemen wird leichter
- es spart speicherplatz
- wenn die festplatte auf anderen Hosts von Anrgeifern gelöscht wird oder defekt ist, können alte Logs immer noch vom zentralisierten Logserver aus aufgerufen werden.
Secure Boot
Secure boot ist entwickelt worden um zu verhindern, dass ein nicht vertrauenswürdigder Code vor dem Start des Betriebssystems ausgeführt wird. Warum ist das so wichtig?
Nun, wenn ein Schädling es schafft, sich vor dem Start des Betriebssystems auszufürhen, kann er den Kernel des Betriebssystems beim Bootvorgang kompromittieren. Dies ermöglicht es dem Schädling, sämtlcihe sicherheitsvorkehrungen des Betriebssystems auszuschalten. Somit kann sich der Schädling dann Zugriff zum System verschaffen, obwohl dieses eigentlich sehr sicher konfiguriert wäre.
die heir angesprochenen Sicherheitseinstellungen können Sie nur machen, wenn sie über eien möglichkeit verfügen, auf den Server per Remote zuzugreifen, bevor er in das Betriebssystem bootet. Solceh möglichkeiten sind beispielsweise vorhanden, wenn der server virtualisiert ist und sie ihn daher beispielsweise mit dem vsphere Client administrieren können, oder wenn Sie über einen KVM over IP-Switch bereits während des bootvorgangs per Remote auf den Server zurgeifen können.
Eine Maßnahme ist beispielsweise, ein Passwort für den Bootloader zu vergeben. Dazu bearbeiten Sie die datei /boot//grub/menu.lst und schreiben unter die Zeile timeout folgendeS:
password <ihr zukünftiges Bootloader-Kennwort>
dieses kennwort dürfen Sie natürlich niemandem geben, dern nicht dazu in der Lage sein soll, das System aus eigenen Kräften zur bootzeit zu manipulieren. Also unter Umständen nicht mal ihre administrationskollegen, die evtl. nur auf dem betriebssystem arbeiten können sollen und nicht auf dem Betriebssystem.
Sie sollten desweiteren ein BIOS Passwort vergeben und verhindern, dass der Server von einem Medium wie etwa einer Cd oder von einem USB-Stick booten kann. Entsprehcende einstellungen vergeben Sie im BIOS / UEFI des Systems.
Um das sicherzustellen, nutzt man sogeannnte Signed Bootloaders, signed Firmware drives usw. Das bedeutet, dass die Echtheit des Bootloaders und der firmware, die vor dem Betriebssystem-Boot geladenw erden, unfälschlicherweise bestätigt werden kann.
verschlüsselter datenverkehr
SSH
SFTP
HTTPS
SCP
Rsync
Stunnel
datenaustausch mit GnuPG
Installieren Sie Netzwerkanalysemethoden
beispielsweise nmap oder Wireshark
Scannen Sie webserver und datenbank nach Schwächen und optimieren Sie die Betriebsssystemkonfiguration
mit nikito und brup suite.
auch nützlich: ein baseline analyzer wie bastille prüfen die konfigurationd es Betreibssystems und versuchen, es zu optimieren.
andere nützliche Tools sind SELinux, AppArmor oder grsecurity. Diese erzwingen Beschränkungen von Netzwerkdiensten oder -programmen.
Installieren sie ein intrusion Detection System
Tripwire dient zur Überwachung und Anzeige von Datenänderungen und dient der sicherheit der Datenintegrität auf dem system.
Tripwire erkennt beispielsweise jedesmal, wenn sich die konfigurationsdatei eines Server-Dienstes ändert. Wenn Tripwire dabei etwas verdächtiges findet, dann kann tripwire
Port scan activity detector (psad) ist ein Intrusion detection system welches pakete loggen und netzwerkverkehr in echtzeit analysieren kann.
AIDE ist ein open soruce host-bsaiertes intrusion detection system. es leifert osfater integritätschecks und erkentn eien intrusion
dienste mit monit überwachen
Das tool Monit überwacht ihre dienste und sendet ihnen eine Mail, wenn ein Dienst nicht mehr erreichbar ist oder von Monit zur Reinitialisierung neu gestartet wurde. Neben Dienstesn können Sei auch Ports und den freien Platz auf Festplatten überwachen
aptitude install monit
wir ändern noch in der Datei /etc/default/monit
startup=1
in die Datei /etc/monit/monirc müssen wir nun die dienste eintragen, die überwacht werden sollen.
Beispielkonfiguration
set daemon 60 // der Monitor überprüft alle 60 Sekunden
set logfile syslog facility log_daemon // standort der logdatei
set mailserver localhost // Mailserve rüber den Benachrichtigungsmails verschickt werden
sert mail-format { from: absender@email.tld } // Mailadresse des absenders
set alert empfänger@email.tld // mailadresse empfänger
check system localhost // diesen Server überwachen
Mit folgenden Zeilen prüfen wir die Arbeitsspeicherauslastung
if loadavg (5min) > 1 then altert // Loadavergae über 5 Minuten hinweg über 1 ist, benachrichitgen)
if memory usage > 75%% then alert (wenn mehr als 75% speicher benötigt, benachrichtien)
Mit folgenden Einstellungen klassen wir CPU-auslastung für User, das geastems Ystem und im Leerlauf überwachen
if cpu usage (user) > 70% then alert
if cpu usage (system) > 30% then alert
if cpu usage (wait) > 20% then alert
Mit foglenden zeilen überprü+fen wir den Dienst SSHd
check process sshd with pidfile /var/run/sshd.pid
start program "/etc/init.d/ssh start"
stop program "/etc/init.d/ssh stop"
if failed port <dein Port> protocol ssh then restart
if 5 restarts within 5 cycles then timeout
Mit folgenden Zeilen prüfen wir den mysqld
check process mysql with pidfile /var/un/mysql/mysql.pid
group database
start program = "/etc/init.d/mysql start"
stop program = "/etc/init.d/mysql stop"
if failed host 127.0.0.1 port 3306 then restart
if 5 restarts within 5 cycles then timeout
andere Monitoring-Lösungen
Nagios, Ganglia, psacct oder acct, monitorix, suricata, collectl, glances, sarg, apache status monitoring mod_status, sysstat, lcinga, observium, PHP Server Monitoring, linux-dash, munin,
Interessante Stellen in Logs per e-Mail empfangen und logs analysieren
logcheck ist dafür zuständig, dass Ihnen interessante passagen in Ihren Logs per e-Mail zugestellt werden.
sudo apt-get install logcheck
Neben logcheck sollten Sie auch logwatch nutzen – eine anpassbare Lösung zur loganalyse. Logwatch geht durhc die system Logs und erstellte Reportanalyseberichte.
festplattenstatus mit smartmontools überwachen
aptitude install smartmontools
in der Datei /etc/default/smartmontools kommentieren wir folgende Zeile ein
start_smartd=yes
Nun wird der Dienst bei Systemstart gestartet.
Nun müssen wir die zu prüfenden Festplatten in die Datei /etc/smartd.conf
wir kommentieren folgende Zeile aus
DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner
und setzen stattdessen darunter (beispiel: zwei festplatten verfügbar)
/dev/sda -n standby -a -I 194 -W 6,50,55 -R 5 -M daily -M test -m meine@mail.tld
/dev/sdb -n standby -a -I 194 -W 6,50,55 -R 5 -M daily -M test -m meine@mail.tld
Automatisches Update-Skript schreiben
Habe ich in diesem Post bereits beschrieben.
Configuration Management
puppet, chef, cfengine, salt, grsecurity
Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!
