Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Weil es in meinem Umfeld die Tage wieder so eine Situation gab geht es heute um das Thema „Verhalten im Ernstfall“. Ein Ernstfall kann mehr oder weniger ausgepraegt sein. Auf unserem gemeinsamen Server hatten wir Anfang 2010 einen Ernstfall, denn ich mal als Notfall kategorisieren wuerde, der uns (Dirk, Hampa, mich) einige Stunden fuer die Wiederherstellung gekostet hat.

Die gemachten Erfahrungen haben Dirk und ich spaeter in einem gemeinsamen Talk auf der Ubucon 2010 verarbeiten „muessen“.

Eine Definition einer Stoerung oder Groesserem kann beispielsweise dem BSI entnommen werden. Letzlich laesst sich ein Problem nicht immer eindeutig kategorisieren. Aber halten wir uns nicht mit Definitionsdetails auf.

Was mache ich nun, wenn es zu einer Stoerung kommt? Ich versuche erst einmal einzuschaetzen wie gross der Einfluss der Stoerung ist. Ist „nur“ ein Testserver ausgefallen, der hier und da von Entwicklern genutzt wird oder ist ein Firewallcuster ausgefallen, so dass 4.000 Menschen kein Internet und damit auch keine Partneranwendungen mehr nutzen koennen? Oft zeigt das Telefon einem schon an, ob es ein wichtiges System getroffen hat oder nicht 🙂

Wir gehen mal von einem harten Fall aus, wo viele Anwender nicht mehr arbeiten koennen. Welche Moeglichkeiten habe ich als Administrator, dessen Server gerade abgestuerzt ist oder einfach nicht mehr reagiert? Da gibt es natuerlich den Klassiker frei nach den Simpsons. Ein Hinweis auf „Schau mal da hinten der Hund! Der wedelt mit dem Schwanz!“ und dem anschliessenden Geraeusch eines startenden Flugzeuges. Da viele von uns aber Familie haben gehen wir den harten und ehrlichen Weg. Wir stellen uns dem Problem.

Hier gibt es einige Punkte, die einem helfen koennen die Situation ohne Herzklappenabriss zu bestehen. Das wichtigste ist immer die Ruhe zu bewahren! Das sagt sich oft so locker und ist sicher nicht leicht, wenn um einen herum die Anwender/Vorgesetzten stehen und einen mit panischen und (in dem Moment) stoerenden Fragen immer wieder aus der Arbeit reissen. Was uns zu einem weiteren Punkt bringt, der hilft die Ruhe zu bewahren.

Sorgt dafuer, dass ihr euch auf das Problem konzentrieren koennt indem ihr alle Leute raus werft, die nicht zur Loesung des Problems beitragen koennen. Das kann man freundlich aber bestimmt machen. Ich habe bei einem Problem auch schon mal einen Vorgesetzten mit den Worten „Wenn Sie mich nicht alle fuenf Minuten unterbrechen wuerden, waere ich schon ein Stueck weiter“ dazu gebracht mich alleine zu lassen. Natuerlich habe ich meinem Vorgesetzten spaeter auch noch mal erklaert, um was es mir ging und dass es eben niemandem hilft, wenn ich alle fuenf Minuten den Stand der Situation erklaeren muss. Er hat es dann auch verstanden, auch wenn er nach meinen Rauswurf doch einen leicht roten Kopf hatte. Damit kann man natuerlich auch mal auf die Nase fallen. Aber auch der Kollege hier, der Dirk, hatte sich mal bei einer groesseren Stoerung gegenueber einem weiter ueber ihm stehenden Vorgesetzten entsprechend geaeussert.

Nicht vergessen sollte man in dem Zusammenhang so Dinge wie das Telefon. Wenn moeglich leitet nach Absprache euren Apparat auf einen Kollegen, den Chef oder, wenn es das gibt, das Service Center um. Der Kollege kann auch als Ergaenzung die Kommunikation in Richtung Anwender uebernehmen.

Kommen wir zum dritten Punkt, der wiederum prima am vorherigen Punkt anschliesst. Die Kommunikation! Vielen Leuten ist nicht klar, wie wichtig Kommunikation ist. Man selber merkt das aber oft selber, wenn man auf etwas wartet und es wird nichts kommuniziert. Sei es, dass man auf einem Amt wartet der Naechste zu sein. Oder sei es am Rechner, wo einem, wie beispielsweise bei dem Linux cp kein Balken anzeigt, wie weit er mit dem Kopieren der 10.000 Dateien ist. Das ist der Grund, weshalb man rsync -P statt cp benutzt.

Es steht ausser Frage, dass die Prozentangaben (Dirk hatte da auch eben noch was in seinem Blog) im Grunde Stuss sind. Aber sie geben einem erst einmal ein gutes Gefuehl. Und das braucht auch der Anwender und der Vorgesetzte. Die Betroffenen muessen das Gefuehl bekommen, dass sich da jemand kuemmert. Daher schreibe ich gerne mal eine Statusmail. Da verzichte ich auf die Angabe von Zeiten, so ich diese nicht vernuenftig einschaetzen kann. Aber ich gebe durch, was ich gemacht habe und was noch fuer Schritte fehlen. Das mache ich uebrigens auch bei Projekten, die sich ueber einen laengeren Zeitraum hinziehen. Jede Woche eine kleine Statusmail an den Auftraggeber. Das dauert fuenf Minuten, gibt dem Auftraggeber aber das Gefuehl, dass sein Thema/Auftrag noch in der Bearbeitung ist.

Was haben wir noch?

Aus meiner Sicht fehlen hier noch drei Punkte. Zum einen die Systemdokumentation. Ab einer bestimmten Anzahl von betreuten Systemen kann ich nicht alles im Kopf behalten. Da ist eine Dokumentation erforderlich. Wichtig ist also zu wissen, wo ich die diese finde und… wo ich die Replik der Informationen finde. Denn es kann ja auch passieren, dass der Server weg ist, auf dem die benoetigten Dokumente liegen. Und bitte nicht auf die Dokumentation bestimmter Prozesse oder Punkte verzichten, weil es da einen prima Link im Internet gibt. Das Internet koennte am Arbeitsplatz auch mal nicht funktionieren.

Des Weiteren finde ich es immer hilfreich eine Liste der moeglichen Ansprechpartner zu haben. Das betrifft sowohl die internen Kollegen, als auch die Personen beim Dienstleister oder Hersteller. Bei den internen Kollegen handelt es sich durchaus nicht nur um Techniker. Gibt es auch ein IT-Stoerungsmanagement? Einen Ansprechpartner im Fachbereich, welche die Anwendung nutzt?

Abschliessend gibt es noch eine Uebersicht moeglicher Vertragsdetails. Aus denen kann ich dann alles entnehmen, was beispielsweise fuer den Austausch von defekter Hardware oder zur Ticketerstellung benoetigt wird.

Als Ergaenzung sei fuer die Zukunft auf jeden Fall noch ein Punkt empfohlen. Die Nacharbeit! Ich moechte wissen, was zum Ausfall eines Systems gefuehrt hat und es abstellen. Ich moechte auch pruefen, wo meine Vorgehensweise noch verbessert werden kann. Alleine schon um beim naechsten Problem besser vorbereitet zu sein und den Anwender schnell(er) wieder ans Arbeiten zu bekommen.

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Moeglicherweise ist ja Interesse an dem was ich die Tage eingerichtet habe. Es ging darum, dass ein Server installiert werden sollte, der Syslog Meldungen sammelt. Ich, als jemand der es gerne auch etwas sicherer hat, habe da auch an verschiedenen Stellen einiges „optimiert“, um Zugriff durch Unbefugte zu erschweren. Da durchaus mit einer groesseren Menge von Logs zu rechnen ist (>20.000/h), wollte ich, dass alles gleich in eine Datenbank laueft.

Basisinstallation und SSH
Begonnen habe ich mit der Basisinstallation eines Ubuntu 10.04.3 LTS. Da SSH eines der Administrationszugaenge ist, lege ich da natuerlich Wert auf eine ordentliche Konfiguration. Also die /etc/sshd_config geoeffnet und dort folgendes angepasst (Erklaerungen fuege ich mal aus der man-Page hinzu).

# The server disconnects after this time if the user has not successfully logged in.
LoginGraceTime 60

# Specifies whether root can log in using ssh(1).
PermitRootLogin no

# Specifies the maximum number of concurrent unauthenticated connections to the SSH daemon.
MaxStartups 3:50:10

# Wohl selbst erklaerend
AllowUsers ramon

Ergaenzend empfehle ich auch noch PasswordAuthentication no zu setzen. Voraussetzung dafuer ist allerdings, dass man fuer alle berechtigen Benutzer die Anmeldung via SSH-Keys eingerichtet hat.

Des Weiteren kann man auch, bei Einsatz von mehreren Netzwerkkarten, den SSH-Daemon mit dem Schluesselwort ListenAddress an ein Interface binden. Leider hat das bei mir dazu gefuehrt, dass der Daemon nach dem Neustart des Servers nicht automatisch mit startete. Sehr seltsam.

Davon, den Port von 22 auf einen anderen Port zu legen, halte ich persoenlich nichts. Ich betreue einige Server im privaten und beruflichen Umfeld. Wenn da jeder seinen eigenen Port verwenden wuerde, wuerde ich ja verrueckt werden 🙂 Ausserdem sehe ich hier keinen wirklichen Gewinn an Sicherheit. Aber das ist natuerlich subjektiv.

Das Netzwerk
Um zumindest noch eine weitere Huerde einzubauen habe ich ueber /etc/hosts.deny und /etc/hosts.allow den Zugriff auf ssh etwas weiter reglementiert.

root@server:/etc# cat /etc/hosts.deny
# /etc/hosts.deny: list of hosts that are not allowed to access the system.
# See the manual pages hosts_access(5) and hosts_options(5).
#
# Example: ALL: some.host.name, .some.domain
# ALL EXCEPT in.fingerd: other.host.name, .other.domain
#

sshd: ALL

root@server:/etc# cat /etc/hosts.allow
# /etc/hosts.allow: list of hosts that are allowed to access the system.
# See the manual pages hosts_access(5) and hosts_options(5).
#
# Example: ALL: LOCAL @some_netgroup
# ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
#

sshd: 192.168.150.0/255.255.255.0

Anmeldung an einem AD
Da die Maschine nicht nur von mir, sondern auch weiteren Anwendern genutzt werden soll, habe ich die Anbindung an ein AD konfiguriert. Das macht es, wenn man beispielsweise keinen Key hat, etwas leichter. Damit koennen sowohl bei der Anmeldung via SSH, aber auch beispielsweise beim sudo, einfach die Windows-Anmeldedaten verwendet werden. Die Einrichtung hierfuer geht relativ flockig von der Hand.

Im Rahmen der Installation der Pakete krb5-user, krb5-config und libpam-krb5 werden die wichtigsten Dinge soweit vorbereitet. Sollte, wie bei mir, die Abfrage wegen der Domaindaten nicht kommen kann man die Konfiguration via dpkg-reconfigure krb5-config nachholen oder die Datei /etc/krb5.conf von Hand anpassen. Die wichtigen Teile sind hier in libdefaults und realms zu finden.

[libdefaults]
default_realm = Domaene

[realms]
Domaincontroller = {
kdc = Domaincontroller
}

Als „Domaene“ habe ich den Namen der DNS-Domaene eingetragen und bei Domaincontroller den voll qualifizierten Namen eines Domaincontrollers. Damit nun die Anmeldung via SSH auch mit Windows-Anmeldedaten funktioniert muss in der /etc/ssh/sshd_config nur noch was angepasst werden.

# Kerberos options
KerberosAuthentication yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes

Bitte nicht vergessen anschliessend dem SSH-Daemon die Konfigurationsaenderung mitzuteilen. Das kann sowohl via service ssh reload, als auch via service ssh restart erfolgen. Es funktioniert auch noch ein albekanntes /etc/init.d/ssh restart bei Ubuntu. Das wird allerdings mit einer entsprechenden Meldung, dass das Script zu einem Upstart Job konvertiert wurde, kommentiert.

So, ob die Anmeldung mit AD-Credentials klappt kann man uebrigens auch wie folgt testen.

root@server:~# kinit ramon@Domaene
Password for ramon@Domaene: ****
root@server:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: ramon@Domaene

Valid starting Expires Service principal
11/10/11 10:28:51 11/10/11 20:27:43 krbtgt/Domaene@Domaene
renew until 11/10/11 20:28:51
root@server:~# kdestroy

Der Webserver
Da soweit alles fertig ist, kann mit der Installation der eigentlichen Dienste begonnen werden. Aus den Paketquellen habe ich den Apache-Server und MySQL installiert.

Bei der Installation der zwei Dienste gibt es nichts besonderes zu beachten. Also einfach ein aptitude install apache2 mysql-client libapache2-mod-php5 php5-mysql und warten. Die beiden letztgenannten Pakete werden spaeter fuer LogAnalyzer benoetigt. Die Installation ist tatsaechlich relativ unkompliziert. Aber vorab noch schnell den rsyslog konfiguriert.

rsyslog
Im Standard ist das Paket rsyslog bereits installiert, so dass wir nur noch, fuer die Nutzung von MySQL, das Paket rsyslog-mysql nachinstallieren muessen. Hier wird dann auch gleich eine Konfigurationsdatei in /etc/rsyslog.d/ erzeugt, die sich mysql.conf nennt. Im Rahmen der Paketinstallation kann die Konfiguration der Datenbank auch gleich erledigt werden. Nach Eingabe des Kennwortes fuer den Datenbankadministrator (root) kann ein Kennwort fuer den neuen Benutzer „rsyslog“, der dann Rechte auf der neuen Datenbank „Syslog“ haben wird, vergeben werden. Schaut man sich die mysql.conf anschliessend an, wird man etwas in der nachfolgenden Art finden.

root@server:/etc/rsyslog.d# cat mysql.conf
### Configuration file for rsyslog-mysql
### Changes are preserved

$ModLoad ommysql
*.* :ommysql:localhost,Syslog,rsyslog,rsyslog

Damit nun noch Logs angenommen werden muss noch die Datei /etc/rsyslog.conf angepasst werden. Fuer den Anfang reicht es aus, dass man die Module imudp und imtcp aktiviert, indem man in der genannten Konfiguration die entsprechenden Bereiche anpasst.

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

Nach dem Uebernehmen der Konfiguration (service rsyslog restart) kann man auch sehen, dass nun auf dem Port 514 was lauscht.

root@server:/etc# netstat -tulpen | grep 514
tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN 0 36860 9598/rsyslogd
tcp6 0 0 :::514 :::* LISTEN 0 36861 9598/rsyslogd
udp 0 0 0.0.0.0:514 0.0.0.0:* 0 36856 9598/rsyslogd
udp6 0 0 :::514 :::* 0 36857 9598/rsyslogd

Die Profis unter uns nutzen natuerlich lsof, was dann wie folgt ausschauen wuerde.

root@server:/etc# lsof -i tcp:514 -i udp:514
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
rsyslogd 677 syslog 3u IPv4 3327 0t0 UDP *:syslog
rsyslogd 677 syslog 4u IPv6 3328 0t0 UDP *:syslog
rsyslogd 677 syslog 5u IPv4 3331 0t0 TCP *:shell (LISTEN)
rsyslogd 677 syslog 6u IPv6 3332 0t0 TCP *:shell (LISTEN)

LogAnalyzer
Da nun alles soweit konfiguriert ist kann der LogAnalyzer angegangen werden. Den gibt es nicht aus den Paketquellen, was aber nicht wild ist, da die Installation, wie oben schon angedeutet, nicht wirklich hart ist. Via wget wird sich das aktuelle Paket von der Herstellerseite herunter geladen und installiert.

root@server:/# mkdir /var/www/loganalyzer
root@server:~# wget http://download.adiscon.com/loganalyzer/loganalyzer-3.2.3.tar.gz
Saving to: loganalyzer-3.2.3.tar.gz

root@server:~# tar xzf loganalyzer-3.2.3.tar.gz
root@server:~# cd loganalyzer-3.2.3
root@server:~/loganalyzer-3.2.3# cp -R src/ /var/www/loganalyzer/
root@server:~/loganalyzer-3.2.3# cp contrib/ /var/www/loganalyzer/
root@server:~/loganalyzer-3.2.3# cd /var/www/loganalyzer
root@server:~/var/www/loganalyzer# chmod +x configure.sh secure.sh
root@server:~/var/www/loganalyzer# ./configure.sh
root@server:~/var/www/loganalyzer# cd ..
root@server:~/var/www# chown -R www-data:www-data loganalyzer

Soweit so… ja, fast fertig. Jetzt sollte man noch das php5-Module fuer Apache mit a2enmod php5 aktivieren. Ist das geschehen kann man den LogAnalyzer konfigurieren. Dafuer verbindet man sich einfach per Webbrowser auf http://server/loganalyzer und geht die Punkte durch.

Was habe ich noch gemacht? Ergaenzend hierzu habe ich fuer Apache SSL aktiviert und einen entsprechenden Redirect konfiguriert, so dass der Aufruf nur noch ueber https:// moeglich ist. Ergaenzend habe ich noch AuthType Basic konfiguriert, so dass tatsaechlich nur berechtigte Benutzer auf die Seite zugreifen duerfen.

Fuer eine „mal eben“-Installation ist das aus meiner Sicht schon mal recht solide. Es gibt noch ein paar Dinge, die ich verbessern kann. Fuer ssh PasswordAuthentication no setzen. Die Authentifizierung fuer Apache auch an das AD „koppeln“. RELP (Reliable Event Logging Protocol) aktivieren. Eigene Logs des Servers auf einem anderen Server ablegen, um im Falle eines Vorfalls keine modifizierten oder geloeschten Logs vorzufinden. Den Zugriff auf den Webserver ueber /etc/hosts.allow und /etc/hosts.deny weiter reglementieren.

Da ich den Beitrag quasi aus dem Kopf erstellt habe hoffe ich, dass ich keine wichtigen Dinge vergessen habe. Wenn es Fragen, Anmerkungen oder Ergaenzungen gibt, einfach die Kommentare nutzen.

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Eine Frage, die immer wieder mal gestellt wird und in „Fachzeitschriften“ regelmaessig bejaht wird ist, brauche ich zu Hause eine Firewall? Das kann man meiner Meinung nach ganz klar mit „Ja/Nein/Kann sein“ beantworten.

Vorab macht es, wie bei so vielen Dingen, Sinn sich zu fragen was man erreichen moechte. Moechte ich den Zugriff meines LANs reglementieren, so dass nur noch http(s) erlaubt ist? Oder moechte ich den Schutz meines Clients verbessern? Oder moechte ich einfach nur etwas ueber mein Netzwerk lernen? Dann ist ja auch noch die Frage, was ich unter Firewall verstehe und ob ich eine lokale oder zentrale Softwareloesung haben moechte? Oder soll es doch lieber gleich Hardware sein?

Wobei ich mit Firewall jetzt eine sogenannte Stateful Inspection-Firewall meine. Also eine Firewall, die den Netzwerkverkehr anhand einfacher Regeln (Erlaube Host A den Zugriff auf Netz A, Port 80) reglementiert. Eine detailiertere Erklaerung findet man, wie so oft, im entsprechenden Wiki-Artikel.

Wenn ich den Zugriff meines Netzwerkes auf externe Ressourcen reglementieren moechte, ist der Einsatz von Hardware vermutlich am unkompliziertesten. Es muss nicht auf jedem beteiligten Rechner eine Firewall eingerichtet und konfiguriert werden. Ich habe da, eher aus Spass an der Freude, zu Hause eine Netscreen 5GT im Einsatz. Hiermit kann ich reglementieren und protokollieren, nutze viele der Funktionen aber nicht. In der Regel bringen neuere Router auch schon ein Stueck weit Firewallfunktionalitaet mit. In diesem Szenario haelt sich der Aufwand und vor allem eine moegliche Fehlersuche etwas in Grenzen.

Um den Schutz meines Clients zu verbessern mache ich mir keine Gedanken ueber eine lokale Firewall. Da setze ich lieber an sinnvolleren Stellen an. Der Einsatz einer Personal Firewall war ja eine zeitlang extrem beliebt und wurde und wird in verschiedenen Publikationen auch immer wieder empfohlen. Das Problem ist hier nur, dass fuer einen moeglichen sinnvollen Einsatz auch ein sehr gesundes Wissen ueber Netzwerke und das eigene System mitgebracht werden sollten. Denn Meldungen wie „Der Prozess ’ssh:25738′ versucht von Adresse 192.168.100.110, Port 54721 auf die Adresse 192.168.100.1, Port 22 zuzugreifen“ muessen auch verstanden werden. Und dieses Beispiel war ja nun relativ leicht.

Vor allem am Anfang der Konfiguration solch einer Personal Firewall wird man im Zweifel mit so vielen Meldungen konfrontiert, dass bei vielen Benutzern die Gefahr besteht, im Verlauf einfach nur noch alles zu verbieten oder zu erlauben. Ersteres fuehrt dazu, dass damit bestimmte Dinge vielleicht nicht (mehr) funktionieren. Zweiteres fuehrt dazu, dass ich eventuell einen Regeleintrag habe, der nicht gewuenscht war. Hat man es dann doch geschafft ein, wie man meint, gutes Regelwerk zu erstellen, hat man den Schutz der eigenen Maschine im Zweifel aber nicht derart verbessert, dass sich der Aufwand gelohnt hat. In allen Personal Firewalls, die ich bisher so gesehen habe, gab es einen Weg nach draussen, obwohl dieser eigentlich nicht gestattet sein sollte. Ein Beispiel, welches schon was aelter ist, findet man in meinem Blog.

Interessant ist eine Personal Firewall, wenn ich schauen moechte was mein System eigentlich so macht. Da kommt man mit einer zentralen Firewall oft nicht weit, da hier der Zusammenhang zwischen den Sessions und dem Ausloeser (sprich, der Anwendung) nicht immer klar ist.

Um etwas ueber das eigene Netzwerk zu erfahren ist eine Firewall, egal ob lokal oder zentral, oft nicht der passende Ansatz. Grund ist, dass ich in der Regel nur Informationen ueber erlaubte/verbotene Sitzungen bekomme. Und sowas wie…

firewall-> get session
alloc 2/max 2064, alloc failed 0, mcast alloc 0, di alloc failed 0
total reserved 0, free sessions in shared pool 2062
id 1675/s**,vsys 0,flag 00000040/0080/0021,policy 320002,time 180, dip 0 module 0
if 2(nspflag 800601):192.168.100.15/52285->192.168.100.1/22,6,000ea62db238,sess token 3,vlan 0,tun 0,vsd 0,route 1,wsf 0
if 3(nspflag 2002010):192.168.100.15/52285<-192.168.100.1/22,6,000000000000,sess token 5,vlan 0,tun 0,vsd 0,route 0,wsf 0
id 1769/s**,vsys 0,flag 00000000/0000/0001,policy 1,time 6, dip 2 module 0
if 2(nspflag 800801):192.168.100.15/57327->188.40.57.208/1194,17,000ea62db238,sess token 3,vlan 0,tun 0,vsd 0,route 1
if 1(nspflag 10800800):192.168.0.2/1711<-188.40.57.208/1194,17,00150c73228c,sess token 4,vlan 0,tun 0,vsd 0,route 5
Total 2 sessions shown

…ist mal nett, wenn es ein Problem gibt. Aber so richtig lernen tut man da nichts. Da wuerde ich eher mal den Einsatz von tcpdump oder Wireshark empfehlen. Ich kann dann wirklich etwas vom Netzwerk und darauf befindlichen Protokollen sehen.

So oder so sollte man sich im klaren sein, dass der Einsatz einer Firewall durchaus auch Aufwand und spaetere Pflege noetig macht. Im Normalfall sind Firewallsysteme erst mal keine „Fire-and-Forget“-Systeme. Wer, wie im obigen Beispiel, eine Firewall einrichtet, da http(s) freigibt und meint, das war’s, wird schnell merken, dass Netzwerk/Internet mehr als nur Port 80 und 443 ist.

Fazit:
Mit einer Firewall alleine gewinnt man noch lange keinen Blumentopf. Vor allem in Geschaeftsumfeld sollte es meiner Meinung nach kaum noch ein Unternehmen geben, dass sensible Maschinen, die aus dem Internet erreichbar sein muessen, ausschliesslich durch eine Firewall schuetzt. Fuer jede Anwendung, bzw. Anwendungsgruppe, sollte es Vorgaben geben, wie diese abzusichern sind. Da zaehlt dann aber nicht nur alleine der Einsatz einer Firewall. Da kommen dann, je nach Auspraegung, auch so Dinge wie Patch-Management, Web Application Firewall, IDS, IPS oder auch die Beschreibung des Notfalls (Einbruch) hinzu.

Auch im privaten Umfeld ist die klassische Firewall nur eine moegliche Ergaenzung zu weiteren Punkten um den Schutz der eigenen Infrastruktur zu verbessern. Und eines muss klar sein. Es gibt nicht *die Sicherheit*. Man kann versuchen den Schutz zu verbessern, wird aber im Regelfall keine 100% Sicherheit erreichen.

Ergaenzung:
Wenn zwei Personen sich unterhalten passiert es schnell, dass beide etwas anderes bei der Begrifflichkeit „Firewall“ meinen. Umgangssprachlich ist mit Firewall oft die Komponente gemeint, die den Schutz eines Systems oder einer Umgebung zum Ziel hat. Korrekter ist jedoch, dass Firewall auch mit ein Konzept meint, in dem nicht nur die Frage nach der Hardware geklaert wird.

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Vor laengerer Zeit gab es hier ja mal einen Beitrag der sich um das rudimentaere Testen eines Webservers via telnet und openssl drehte. Da war es nur konsequent, dass dem auch mal ein Beitrag folgt, der sich um das Thema Mail dreht.

Fangen wir erst mal einfach an und schauen, ob wir uns via SMTP mit unserem Mailserver verbinden und testweise mal eine Mail verschicken koennen.

ramon@client:~$ telnet 192.168.100.25 25
Trying 192.168.100.25…
Connected to mailserver.
Escape character is ‚^]‘.
ehlo client
220 mailserver NuNu 3.3(18) ipop3d (Amiga)
250-mailserver Hello client ([192.168.100.25]), pleased to meet you
250-HELP
250-SIZE 20971520
250 PIPELINING
MAIL FROM:ramon@kukla.info
250 ramon@kukla.info… Sender OK
RCPT TO:ramon@kukla.info
250 ramon@kukla.info… Recipient OK
DATA
354 Enter message, end with „.“ on a line by itself
SUBJECT:testmail
testmail
.
250 Message accepted for delivery
quit
221 mailserver SMTP Service closing transmission channel
Connection closed by foreign host.

Hat alles geklappt haben wir anschliessend eine Mail in unserem Zielpostkorb. Jetzt haben wir einen Server, der es erfordert sich vorab als berechtigter Benutzer zu authentifizieren. Da wir unsere Authentifizierung nicht unverschluesselt ueber das Netz schicken werden wir uns nun via SSL mit dem Mailserver verbinden.

Vorab noch ein Hinweis. Bei der Nutzung von openssl im folgenden Beispiel passiert es, dass bei Kommandos, wo das erste Zeichen ein R ist, ein Regonitiation initiiert wird. Das wuerde uns dann also spaetestens beim „RCPT TO:“ zum Verhaengnis werden. Daher rufen wir openssl mit der Option -ign_eof auf.

ramon@client:~$ openssl s_client -connect mailserver:465 -ign_eof
CONNECTED(00000003)
depth=0 /C=DE/ST=Saxonia/L=Falkenstein/O=ptlx/OU=Administration/CN=mailserver/emailAddress=admin@mailserver
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=DE/ST=Saxonia/L=Falkenstein/O=ptlx/OU=Administration/CN=mailserver/emailAddress=admin@mailserver
verify return:1
—
Certificate chain
0 s:/C=DE/ST=Saxonia/L=Falkenstein/O=ptlx/OU=Administration/CN=mailserver/emailAddress=admin@mailserver
i:/C=DE/ST=Saxonia/L=Falkenstein/O=ptlx/OU=Administration/CN=mailserver/emailAddress=admin@mailserver
—
Server certificate
—–BEGIN CERTIFICATE—–
MIIDnDCCAwWgAwIBAgIJAJLLd/ciGa54MA0GCSqGSIb3DQEBBQUAMIGRMQswCQYD
VQQGEwJERTEQMA4GA1UECBMHU2F4b25pYTEUMBIGA1UEBxMLRmFsa2Vuc3RlaW4x
DTALBgNVBAoTBHB0bHgxFzAVBgNVBAsTDkFkbWluaXN0cmF0aW9uMRQwEgYDVQQD
Ewtmb28ucHRseC5kZTEcMBoGCSqGSIb3DQEJARYNYWRtaW5AcHRseC5kZTAeFw0x
MTAyMjAxMzMxMzVaFw0yMTAyMTcxMzMxMzVaMIGRMQswCQYDVQQGEwJERTEQMA4G
A1UECBMHU2F4b25pYTEUMBIGA1UEBxMLRmFsa2Vuc3RlaW4xDTALBgNVBAoTBHB0
bHgxFzAVBgNVBAsTDkFkbWluaXN0cmF0aW9uMRQwEgYDVQQDEwtmb28ucHRseC5k
ZTEcMBoGCSqGSIb3DQEJARYNYWRtaW5AcHRseC5kZTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEA1VqGIqHj1sH8MAO8+kA2JPzb4dmEvRcnRMOvS0eCpmLsN+GX
Tz+RUZLu5/2tfB7ntggU/R0P/LozFbUsFDqckKrzTuzus21/EJGfN51p9pixpGBi
GyiXlUJ2hg3zwwckCwxEuoY+By/KlEH6sN7vGpycYj2rmaf0nBTuoL+DGoMCAwEA
AaOB+TCB9jAdBgNVHQ4EFgQUpSWQtdmGGGMs8yYIWQZbtRQbJCswgcYGA1UdIwSB
vjCBu4AUpSWQtdmGGGMs8yYIWQZbtRQbJCuhgZekgZQwgZExCzAJBgNVBAYTAkRF
MRAwDgYDVQQIEwdTYXhvbmlhMRQwEgYDVQQHEwtGYWxrZW5zdGVpbjENMAsGA1UE
ChMEcHRseDEXMBUGA1UECxMOQWRtaW5pc3RyYXRpb24xFDASBgNVBAMTC2Zvby5w
dGx4LmRlMRwwGgYJKoZIhvcNAQkBFg1hZG1pbkBwdGx4LmRlggkAkst39yIZrngw
DAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCQAvHWM1QUAw447V/l+1X+
R8+ATWJJUsj1dCtSrkrCuS9hS1mxnnLlWa/Jpe+ipRcHLdvYQ7g+iaWupujeZv8B
PqpipLSPyuaSlIlCJe38fUKbXuPbSLkx6RA8PrY6O3y32T23Rmc13HV5gwbf+8zI
/A3WXwxoOTYz/GzIA2+VMg==
—–END CERTIFICATE—–
subject=/C=DE/ST=Saxonia/L=Falkenstein/O=ptlx/OU=Administration/CN=mailserver/emailAddress=admin@mailserver
issuer=/C=DE/ST=Saxonia/L=Falkenstein/O=ptlx/OU=Administration/CN=mailserver/emailAddress=admin@mailserver
—
No client certificate CA names sent
—
SSL handshake has read 1499 bytes and written 319 bytes
—
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 6CFEC94B29AEFC1099D87B785F58631DF6D328F135B2CA75D5368566C1D3C19D
Session-ID-ctx:
Master-Key: 330430753D0F29C93467334FA9D0C43700C0B5DE6F8AD2F9D606B0A4ACD565FC9012F49DD7EEE2F7BE04AF2E0FC9137F
Key-Arg : None
Start Time: 1318419830
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
—
220 mailserver NuNu 3.3(18) ipop3d (Amiga)
ehlo client
250-mailserver
250-PIPELINING
250-SIZE 30720000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Jetzt kommt der interessantere Teil, die Authentifizierung. Diese erfolgt via AUTH LOGIN oder AUTH PLAIN. Der Unterschied zwischen den beiden Methoden ist, dass bei ersterer (AUTH LOGIN) Benutzername und Kennwort getrennt uebertragen werden, wohingegen bei AUTH PLAIN Benutzername und Kennwort „am Stueck“ uebertragen werden. Allerdings werden Benutzername und Kennwort nicht im Klartext sondern Base64-kodiert uebermittelt. Um einen solchen kodierten String zu erhalten kann man entweder einen der diversen Online-Konverter nutzen, oder ein lokales Perl mit dem MIME::Base-Modul.

amon@client:~$ perl -MMIME::Base64 -e ‚print encode_base64(„meinpasswort“);‘
bWVpbnBhc3N3b3J0
ramon@client:~$ perl -MMIME::Base64 -e ‚print encode_base64(„ramon@kukla.info“);‘
cmFtb25Aa3VrbGEuaW5mbw==

Mit Hilfe der generierten Werte koennen wir uns nun also Authentifizieren und unsere Mail senden.

AUTH LOGIN
334 VXNlcm5hbWU6
cmFtb25Aa3VrbGEuaW5mbw==
334 UGFzc3dvcmQ6
bWVpbnBhc3N3b3J0
235 2.7.0 Authentication successful
MAIL FROM:ramon@kukla.info
250 2.1.0 Ok
RCPT TO:ramon@kukla.info
250 2.1.5 Ok
DATA
SUBJECT:testmail
354 End data with .
testmail
.
250 2.0.0 Ok: queued as BAA9C19EFD6E
quit
221 2.0.0 Bye
read:errno=0

Soweit so prima. Jetzt moechten wir natuerlich noch mal schauen, wie es sich mit IMAP darstellt. Bei IMAP ist wichtig zu wissen, dass alle Kommandos von einem sogenannten Identifier angefuehrt werden muessen.

ramon@client:~$ openssl s_client -connect mailserver:993
CONNECTED(00000003)
depth=0 /O=Dovecot mail server/OU=mailserver/CN=mailserver/emailAddress=root@mailserver
verify error:num=18:self signed certificate
verify return:1
depth=0 /O=Dovecot mail server/OU=mailserver/CN=mailserver/emailAddress=root@mailserver
verify return:1
—
Certificate chain
0 s:/O=Dovecot mail server/OU=mailserver/CN=mailserver/emailAddress=root@mailserver
i:/O=Dovecot mail server/OU=mailserver/CN=mailserver/emailAddress=root@mailserver
—
Server certificate
—–BEGIN CERTIFICATE—–
MIIDJTCCAo6gAwIBAgIJAO3v57G3iscCMA0GCSqGSIb3DQEBBQUAMGsxHDAaBgNV
BAoTE0RvdmVjb3QgbWFpbCBzZXJ2ZXIxFDASBgNVBAsTC2Zvby5wdGx4LmRlMRQw
EgYDVQQDEwtmb28ucHRseC5kZTEfMB0GCSqGSIb3DQEJARYQcm9vdEBmb28ucHRs
eC5kZTAeFw0xMTAyMjAxMDQzNTBaFw0xMjAyMjAxMDQzNTBaMGsxHDAaBgNVBAoT
E0RvdmVjb3QgbWFpbCBzZXJ2ZXIxFDASBgNVBAsTC2Zvby5wdGx4LmRlMRQwEgYD
VQQDEwtmb28ucHRseC5kZTEfMB0GCSqGSIb3DQEJARYQcm9vdEBmb28ucHRseC5k
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA7CqNuyJwyDYfkhjOYsBdLouu
tLDx/QjVulAyisf+YMWwRr/ZMI5dZCoB2+VYVk+px4pP0asNjtiMD7/aKgPs3SJH
LmcaPIfXayBYVVpwi1jEFhSNowCcQjmoPHAM0PrNJNz9qVGpxJkk/kwpXd8kPdBk
Eq1b/41Xb7NDbTLZ/GUCAwEAAaOB0DCBzTAdBgNVHQ4EFgQU6q65YYtCAUMqLMDi
crAg+zYxfSIwgZ0GA1UdIwSBlTCBkoAU6q65YYtCAUMqLMDicrAg+zYxfSKhb6Rt
MGsxHDAaBgNVBAoTE0RvdmVjb3QgbWFpbCBzZXJ2ZXIxFDASBgNVBAsTC2Zvby5w
dGx4LmRlMRQwEgYDVQQDEwtmb28ucHRseC5kZTEfMB0GCSqGSIb3DQEJARYQcm9v
dEBmb28ucHRseC5kZYIJAO3v57G3iscCMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcN
AQEFBQADgYEARNxqxB3K++zRyB1mdaSU/P52yXEb03tqqaV+58lf75hfsBUHnz/8
1GUM2I98HM6r7nsqxG9WjCuNgDfvuZZ4A+5T3O1TPdJViTBZG/zAi4lvIHfalF5f
3ZmLUye2qLFlBScxCGdsvZ3RAOg/tskbJDgeKr/HaWAxqRlmcAxO1h8=
—–END CERTIFICATE—–
subject=/O=Dovecot mail server/OU=mailserver/CN=mailserver/emailAddress=root@mailserver
issuer=/O=Dovecot mail server/OU=mailserver/CN=mailserver/emailAddress=root@mailserver
—
No client certificate CA names sent
—
SSL handshake has read 1380 bytes and written 319 bytes
—
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 7DA8529181D88B345F6DF5771AA502682D534C7816F9036265D69F22A958AA50
Session-ID-ctx:
Master-Key: 4112D1CB2EE9357F5DF0226395E1D007C1C6401FD8F8EDC4D0C4E1CE0A98A3AA91BEB23165974633A8E60EAC349D2981
Key-Arg : None
Start Time: 1318426371
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
—
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
a0001 LOGIN ramon@kukla.info meinpasswort
a0001 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH] Logged in
a0003 EXAMINE INBOX
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft $label1 $label2 $label3 $label4 $label5 $Forwarded)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 23 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1249171322] UIDs valid
* OK [UIDNEXT 25979] Predicted next UID
* OK [HIGHESTMODSEQ 10887] Highest
a0003 OK [READ-ONLY] Select completed.
a0004 FETCH 14 BODY[]
* 14 FETCH (BODY[] {1467}
Return-Path: <ramon@kukla.info>
Delivered-To: ramon@kukla.info
Received: from localhost (localhost [127.0.0.1])
by mailserver NuNu 3.3(18) ipop3d (Amiga) with ESMTP id 21D0E141E0A4;
Tue, 11 Oct 2011 22:45:38 +0200 (CEST)
From: Ramon Kukla <ramon@kukla.info>
To: ramon@kukla.info
Subject: testmail
User-Agent: Yet Another Mailer (YAM) (2.6p1)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline</ramon@kukla.info></ramon@kukla.info>

testmail
—
Blog: http://ramon.kukla.info – http://adminstories.de
Software failure! Press left mouse button to continue.
Guru Meditation #8100000A.000FEA00

)
a0004 OK Fetch completed.
a0005 LOGOUT
* BYE Logging out
a0005 OK Logout completed.
closed

Soweit, so fertig. Wer nicht nur einen, sondern mehrfach Tests mit (s)einem SMTP-Server durchfuehren muss, dem sei swaks (Swiss Army Knife SMTP) empfohlen. Das erleichtert einem ungemein die Arbeit mit dem ganzen getippe.