Monat: November 2011

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.