Konfiguration einer Firewall mit Linux

Standardkonfiguration

Um ein annähernd realistisches und komplexes Testszenario nachzustellen, wird ein Netzwerk bestehend aus 5 Rechnern in unterschiedlichen IP-Netzwerksegmenten aufgebaut. Aufgrund mangelnder Hardwareunterstützung wird lediglich ein Hub für das interne Netz verwendet, was dazu führt, daß mehrere IP-Netzwerksegmente auf einem Ethernetsegment parallel betrieben werden. Die Hardwarekonfiguration sieht wie folgt aus:

    __________                   __________                         
   |          |  Ethernet-      |          | 
   | Internet |-----------------| Firewall |
   |__________|  segment 1      |__________|          
                                     |           _______________
                                     |          |               |
                                     +----------+ Public Server |
                    ____________     |          |_______________|
                   |            |    |
                   | interner   +----+           __________
                   | Fileserver |    |          |          |
                   |____________|    +----------+ Client 1 |
                    ____________     |          |__________|
                   |            |    | 
                   |  Client 2  +----+
                   |____________|      Ethernetsegment 2

  

Die IP-Konfiguration der Rechner und deren Einteilung in IP-Subnetzwerke gestaltet sich folgendermaßen:

    __________                   __________                         
   |          | 183.1    183.15 |          | 185.1       185.xxx    Client
   | Internet |-----------------| Firewall |-------------------- ?  Workgroup
   |__________|                 |__________|          
                                  |   |
                          184.129 |   | 184.1
   Intranet     +-----------------+   +--------------------+  Public Servers
   Servers      |                     |                    |
                | 184.130             | 184.15             | 184.xxx
             ___|________        _____|____                |
            |            |      |          |
            | fileserver |      | Solaris7 |               ?
            |____________|      |__________|  
  

Auf Basis der zur Verfügung stehenden Hardware werden verschiedene Rechnersysteme und Betriebssysteme verwendet. Auf die Konfiguration der einzelnen Systeme soll hier jedoch nicht im Detail eingegangen werden, sondern lediglich die wichtigsten Aspekte der verwendeten Hard- und Software genannt werden. In der folgenden Tabelle sind die verwendeten Systeme aufgeführt und deren wichtigten Eigenschaften aufgezeigt:

# pkgadd -d /path/to/package/package-name
        

pop3    stream  tcp     nowait  root /usr/local/etc/popper.normal
        

kill -HUP `ps -ef|grep "[i]netd"|awk '{print $2}'`
        

Quellen:

• RedHat Linux
• SuSE Linux
• Sun Microsystems
• Sunfreeware.com - Kostenlose Solarissoftware
• Apache Webserver
• Samba Server
• Squid Proxy Server
• ipmasqadm - Programm für erweitertes Masquerading mit Linux 2.2
• SSH - Secure Shell

Firewall Konfiguration

Alle aufgezeigten Befehle sind in ihrer Reihenfolge in einem Shell-Skript zusammengefaßt und können somit leicht zur Ausführung gebracht werden.

Routing

Zunächst müssen die einzelnen logischen Netzwerksegmente dazu gebracht werden miteinander zu kommunizieren. Dazu muß das Routing auf dem Firewall-Rechner aktiviert werden und auf allen Rechnern die DEFAULT-Route auf den Firewall-Rechner gesetzt werden.

Default-Router (der Firewallrechner) in den einzelnen Netzwerksegmenten sind:

Routing auf dem Firewall-Rechner aktivieren:

Syntax:

        [01]# echo 1 > /proc/sys/net/ipv4/ip_forward
  

Zusatz:

Da die genannten Netze alle von einem einzigen physischen Netzwerkadapter am Router abgedeckt werden und somit in einem physischen Netzwerksegment gefahren werden, löst der Router beim Zugriff von einem logischen Netzwerksegment auf ein anderes einen ICMP-Redirect aus, welches zur Folge hat, daß die folgenden Pakete vom Sender nicht mehr über den Router geleitet werden, sondern direkt an den Empfänger gesendet werden. Dieses kann und muß (um die Firewall-Funktionalität zu gewährleisten) man umgehen, indem man auf dem Firewallrechner eine 0 (Null) in die Datei /proc/sys/net/ipv4/route/redirect_number schreibt. Damit wird das Auslösen eines ICMP Redirects vom Firewall-Rechner aus verhindert.

Syntax:

        [02]# echo 0 > /proc/sys/net/ipv4/route/redirect_number
  

Diese Lösung wurde empirisch gefunden, da keine Informationen über das Verhindern von Redirects gefunden wurde.

Masquerading

Da die Netzwerke 141.45.184.0/25, 141.45.184.128/25 und 141.45.185.1/24 nicht vom Router 141.45.183.1 (Defaultrouter des Firewallrechners) geroutet werden, muß eine Adreßumsetzung stattfinden. Bei dieser Adreßumsetzung wird die Quelladresse eines Rechners aus dem nichtgerouteten Bereich durch die Adresse des Masquerading-Rechners (in diesem Fall die Firewall) ersetzt, wobei sich dieser merkt welches Paket er maskiert hat. Das maskierte Paket versendet der Masqeradingrechner dann an die Zieladresse das Paketes und sollte das Ziel nicht im Segment 141.45.183.0/24 liegen, wird das Paket an den DEFAULT-Router des Masqueradingrechners gesendet.

Konfiguration auf dem Masqueradingrechner:

Syntax:

      [03]# ipchains -P forward DENY
      [04]# ipchains -A forward \
                 -s 141.45.184.128/25 \
                 -d 141.45.184.0/25 \
                 -j ACCEPT  
      [05]# ipchains -A forward \
                 -s 141.45.184.0/25 \
                 -d 141.45.184.128/25 \
                 -j ACCEPT
      [06]# ipchains -A forward \
                 -s 141.45.185.0/24 \
                 -d 141.45.184.128/25 \
                 -j ACCEPT  
      [07]# ipchains -A forward \
                 -s 141.45.185.0/24 \
                 -d 141.45.184.0/25 \
                 -j ACCEPT  
      [08]# ipchains -A forward \
                 -s 141.45.184.128/25 \
                 -d 141.45.185.0/24 \
                 -j ACCEPT  
      [09]# ipchains -A forward \
                 -s 141.45.184.0/25 \
                 -d 141.45.185.0/24 \
                 -j ACCEPT  
      [10]# ipchains -A forward \
                 -i eth0 \
                 -s 141.45.184.0/25 \
                 -d 0.0.0.0/0 \
                 -j MASQ  
      [11]# ipchains -A forward \
                 -i eth0 \
                 -s 141.45.184.128/25 \
                 -d 0.0.0.0/0 \
                 -j MASQ
      [12]# ipchains -A forward \
                 -i eth0 \
                 -s 141.45.185.0/24 \
                 -d 0.0.0.0/0 \
                 -j MASQ
  

         141.45.184.128/25 -> 141.45.184.0/25
         141.45.184.0/25   -> 141.45.184.128/25
         141.45.185.0/24   -> 141.45.184.128/25
         141.45.185.0/24   -> 141.45.184.0/25
         141.45.184.128/25 -> 141.45.185.0/24
         141.45.184.0/25   -> 141.45.185.0/24
     

Dokus:

• http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO/index.html
• http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html

Port Forwarding

Da Rechner in Netzen stehen können, die nicht geroutet werden (speziell 192.168.0.0/16), können diese aus dem Internet nicht angesprochen werden. Das ist so auch ganz gut und sicher, wenn man jedoch nicht ein paar Dienste anbieten möchte. Z.B. ist der Rechner Solaris7 ein Webserver (HTTP Port 80) (den Start von Apache vorausgesetzt), jedoch wird das 141.45.184.0/25 Netz nicht geroutet. Ein Zugriff soll dennoch auf den Port 80 des Rechners aus dem Internet herraus möglich sein.

Lösung:
Alle Pakete die bei der Firewall ankommen und auf ihre Adresse 141.45.183.15 und den Port 80 adressiert sind, sollen an einen anderen Rechner im lokalen Netz weitergeleitet werden, d.h. die Zieladresse des Paketes wird durch die des Rechners im lokalen Netz maskiert und das Paket an den entsprechenden Rechner gesendet (ueber das Routing und Forwarding des Kernels). Dieser bearbeitet die Anfrage und sendet an die ehemalige Quelladresse zurück, da das Paket durch die Firewall muß wird die Quelladresse des lokalen Rechners wieder auf die Adresse von der Firewall gesetzt. Kompilieren des Programmes ipmasqadm nötig. Kernel-Modul ip_masq_portfw muß aktiv sein. Weiterhin werden die Dienste SMTP (für die E-Mail-Zustellung), POP3 (für die Abholung von E-Mails) und FTP (für öffentlich zugägliche Dateien) an die Solaris7 weitergeleitet.

Syntax:

       [13]# ipmasqadm portfw -a -P tcp \
                              -L 141.45.183.15 80 \
                              -R 141.45.184.15 80 
       [14]# ipmasqadm portfw -a -P tcp \
                              -L 141.45.183.15 25 \
                              -R 141.45.184.15 25 
       [15]# ipmasqadm portfw -a -P tcp \
                              -L 141.45.183.15 110 \
                              -R 141.45.184.15 110 
       [16]# ipmasqadm portfw -a -P tcp \
                              -L 141.45.183.15 21 \
                              -R 141.45.184.15 21 
  

Dokus und Software:

• http://juanjox.kernelnotes.org
• http://www.ox.compsoc.org.uk/~steve/portfw-2.2.html

Dienste unterdrücken

Das Hauptproblem beim Anbieten von Diensten ist, daß die Dienste oft nicht fehlerfrei implementiert sind und durch unglückliche Umstände Tätigkeiten mit den Diensten ausgeführt werden können zu denen der Benutzer normalerweise nicht authorisiert ist. Daher ist es nicht unerläßlich nur den Rechnern Dienste anzubieten, die diese auch nutzen dürfen und den vertraut werden kann. Weiterhin sollten potentielle Angriffspunkte eingekappselt werden, ohne das von diesen Punkten weitere Angriffe erfolgen können. Grundsätzlich sollte ein Zugriff auf die internen Rechner vom Internet aus nicht möglich sein, da die Adressen der internen Netze maskiert werden und somit die Firewall als einziger Rechner von außen zugänglich ist. Zur Konfiguration der Firewall wird das Programm IPCHAINS verwendet, welches zum Programmumfang fast jeder Linux-Distribution gehört. Die Unterdrückung der Pakete findet bereits schon beim Erreichen der Firewall statt, somit können Fehler in den Routingalgorithmen des Kernels nicht durch fehlerhafte Pakete ausgenutzt werden. Es wird davon ausgegangen, daß Clients eine Verbindung zum Server generell von einem Port mit einer Portnummer größer als 1023 aus aufbauen. Vor der Verwendung von ipchains sollte man sich mit dessen Verwendung mit Hilfe der Manpages (man ipchains) vertraut machen. IPCHAINS wird hier häufig so verwendet, daß eine Berechtigung des Zugriffes auf einen bestimmten Rechner von der IP-Adresse und des TCP/UDP-Ports sowohl des sendenden, als auch des empfangenden Rechners abhängig gemacht wird.

• alle eingehenden Packete unterdrücken, alles verbieten, was nicht expliziet erlaubt ist

       # ipchains -P input DENY
      
  

• neue Firewall-Regelkette erstellen

       # ipchains -N fire
      
  

• diese Kette an "input" binden, alle eingehenden Packete werden mit der Kette "fire" verglichen

       # ipchains -A input -j fire
      
  

• "dns" von Firewall, Workgroupnetz, öffentlichen und internen Servernetz an den Nameserver 141.45.1.1 und vom Nameserver zurück zur Firewall zulassen

       # ipchains -A fire -s 141.45.184.0/25 -d 141.45.1.1 domain -p udp -j ACCEPT
       # ipchains -A fire -s 141.45.184.128/25 -d 141.45.1.1 domain -p udp -j ACCEPT
       # ipchains -A fire -s 141.45.185.0/24 -d 141.45.1.1 domain -p udp -j ACCEPT
       # ipchains -A fire -s 141.45.1.1 domain -d 141.45.183.15 -p udp -j ACCEPT
       # ipchains -A fire -s 141.45.184.0/25 -d 141.45.5.100 domain -p udp -j ACCEPT
       # ipchains -A fire -s 141.45.184.128/25 -d 141.45.5.100 domain -p udp -j ACCEPT
       # ipchains -A fire -s 141.45.185.0/24 -d 141.45.5.100 domain -p udp -j ACCEPT
       # ipchains -A fire -s 141.45.5.100 domain -d 141.45.183.15 -p udp -j ACCEPT
      
  

• POP3 von Internet auf Firewall zulassen, Antwort auf POP3 kommt von internem Server, also von 141.45.184.15 ins Internet zulassen

       # ipchains -A fire -s 0.0.0.0/0 1024: -d 141.45.183.15 110 -p tcp -j ACCEPT
       # ipchains -A fire -s 141.45.184.15 110 -d 0.0.0.0/0 1024: -p tcp -j ACCEPT
      
  
  

• HTTP von Internet auf Firewall zulassen, Antwort auf HTTP kommt von internen Server, also von 141.45.184.15 ins Internet zulassen

       # ipchains -A fire -s 0.0.0.0/0 1024: -d 141.45.183.15 80 -p tcp -j ACCEPT
       # ipchains -A fire -s 141.45.184.15 80 -d 0.0.0.0/0 1024: -p tcp -j ACCEPT
      
  

• SMTP von Internet auf Firewall zulassen, Antwort auf SMTP kommt von internen Server, also von 141.45.184.15 ins Internet zulassen

       # ipchains -A fire -s 0.0.0.0/0 1024: -d 141.45.183.15 25 -p tcp -j ACCEPT
       # ipchains -A fire -s 141.45.184.15 25 -d 0.0.0.0/0 1024: -p tcp -j ACCEPT
      
  
  

• FTP und FTP-Daten von Internet auf Firewall zulassen, Antwort auf FTP kommt von internen Server, also von 141.45.184.15 ins Internet zulassen

       # ipchains -A fire -s 0.0.0.0/0 1024: -d 141.45.183.15 21 -p tcp -j ACCEPT
       # ipchains -A fire -s 141.45.184.15 21 -d 0.0.0.0/0 1024: -p tcp -j ACCEPT
       # ipchains -A fire -s 0.0.0.0/0 1024: -d 141.45.183.15 20 -p tcp -j ACCEPT
       # ipchains -A fire -s 141.45.184.15 20 -d 0.0.0.0/0 1024: -p tcp -j ACCEPT
      
  

• Proxy-Zugriff vom Clientnetzwerk auf den Proxy 141.45.184.15 erlauben.

       # ipchains -A fire -s 141.45.185.0/15 1024: -d 141.45.184.15 3128 -p tcp -j ACCEPT
       # ipchains -A fire -s 141.45.184.15 3128 -d 141.45.185.0/15 1024: -p tcp -j ACCEPT
      
  

• Zugriff auf das Internet (HTTP) wird nur vom Proxy-Server gestattet.

       # ipchains -A fire -s 141.45.184.15 1024: -d 0.0.0.0/0 80 -p tcp -j ACCEPT
       # ipchains -A fire -s 0.0.0.0/0 80 -d 141.45.184.15 1024: -p tcp -j ACCEPT
      
  

• Zugriff auf das Internet (FTP) wird nur vom Proxy-Server gestattet.

       # ipchains -A fire -s 141.45.184.15 1024: -d 0.0.0.0/0 21 -p tcp -j ACCEPT
       # ipchains -A fire -s 0.0.0.0/0 21 -d 141.45.184.15 1024: -p tcp -j ACCEPT
      
  

• Zugriff auf das Internet (FTP-DATA) wird nur vom Proxy-Server gestattet.

       # ipchains -A fire -s 141.45.184.15 1024: -d 0.0.0.0/0 20 -p tcp -j ACCEPT
       # ipchains -A fire -s 0.0.0.0/0 20 -d 141.45.184.15 1024: -p tcp -j ACCEPT
      
  

• Vom Clientnetzwerk darf auf den internen Server zugegriffen werden, wenn eine SMB-Anfrage bearbeitet werden soll.

       # ipchains -A fire -s 141.45.185.0/24 1024: -d 141.45.184.130 139 -p tcp -j ACCEPT
       # ipchains -A fire -d 141.45.184.130 139 -s 141.45.185.0/24 1024: -p tcp -j ACCEPT
      
  

• Das Clientnetwerk hat ebenfalls Zugriff auf den POP3- und SMTP-Dienst vom öffentlichen Server, um E-Mails zu senden und zu empfangen.

       # ipchains -A fire -s 141.45.185.0/24 1024: -d 141.45.184.15 110 -p tcp -j ACCEPT
       # ipchains -A fire -d 141.45.184.15 110 -s 141.45.185.0/24 1024: -p tcp -j ACCEPT
       # ipchains -A fire -s 141.45.185.0/24 1024: -d 141.45.184.15 25 -p tcp -j ACCEPT
       # ipchains -A fire -d 141.45.184.15 25 -s 141.45.185.0/24 1024: -p tcp -j ACCEPT
      
  

• Um die Erreichbarkeit von Rechnern von jedem einzelnen Segment auf ein anderes prüfen zu können muß ICMP Echo-Request (ping) und ICMP Echo-Reply (pong) für jeden Rechner freigegeben sein.

       # ipchains -A fire -s 0.0.0.0/0 -d 0.0.0.0/0 -p icmp --icmp-type echo-request -j ACCEPT
       # ipchains -A fire -s 0.0.0.0/0 -d 0.0.0.0/0 -p icmp --icmp-type echo-reply -j ACCEPT
      
  

Im Normalfall sollte ein Remote-Zugang zum Firewall-Rechner selbst nicht möglich sein, ist dies jedoch nicht vermeidbar sollte dieser Zugang ausschließlich per ssh (verschlüsselt) und von einem einzigen vertrauten und sicheren Rechner zugelassen werden.

Zum Überprüfen der Konfiguration kann der Befehl:

     # ipchains -L -n
   

ausgeführt werden. Dieser zeigt alle konfigurierten Regeln an und sollte eine folgende Ausgabe erzeugen:

    Chain input (policy DENY):
    target     prot opt     source                destination           ports
    fire       all  ------  0.0.0.0/0            0.0.0.0/0             n/a
    Chain forward (policy DENY):
    target     prot opt     source                destination           ports
    ACCEPT     all  ------  141.45.184.128/25    141.45.184.0/25       n/a
    ACCEPT     all  ------  141.45.184.0/25      141.45.184.128/25     n/a
    ACCEPT     all  ------  141.45.185.0/24      141.45.184.128/25     n/a
    ACCEPT     all  ------  141.45.185.0/24      141.45.184.0/25       n/a
    ACCEPT     all  ------  141.45.184.128/25    141.45.185.0/24       n/a
    ACCEPT     all  ------  141.45.184.0/25      141.45.185.0/24       n/a
    MASQ       all  ------  141.45.184.0/25      0.0.0.0/0             n/a
    MASQ       all  ------  141.45.184.128/25    0.0.0.0/0             n/a
    MASQ       all  ------  141.45.185.0/24      0.0.0.0/0             n/a
    Chain output (policy ACCEPT):
    Chain fire (1 references):
    target     prot opt     source                destination           ports
    ACCEPT     udp  ------  141.45.184.0/25      141.45.1.1            * ->   53
    ACCEPT     udp  ------  141.45.1.1           141.45.183.15         53 ->   *
    ACCEPT     udp  ------  141.45.184.0/25      141.45.5.100          * ->   53
    ACCEPT     udp  ------  141.45.5.100         141.45.183.15         53 ->   *
    ACCEPT     udp  ------  141.45.184.128/25    141.45.1.1            * ->   53
    ACCEPT     udp  ------  141.45.1.1           141.45.183.15         53 ->   *
    ACCEPT     udp  ------  141.45.184.128/25    141.45.5.100          * ->   53
    ACCEPT     udp  ------  141.45.5.100         141.45.183.15         53 ->   *
    ACCEPT     udp  ------  141.45.185.0/24      141.45.1.1            * ->   53
    ACCEPT     udp  ------  141.45.1.1           141.45.183.15         53 ->   *
    ACCEPT     udp  ------  141.45.185.0/24      141.45.5.100          * ->   53
    ACCEPT     udp  ------  141.45.5.100         141.45.183.15         53 ->   *
    ACCEPT     tcp  ------  0.0.0.0/0            141.45.183.15         1024:65535 ->   110
    ACCEPT     tcp  ------  141.45.184.15        0.0.0.0/0             110 ->   1024:65535
    ACCEPT     tcp  ------  0.0.0.0/0            141.45.183.15         1024:65535 ->   80
    ACCEPT     tcp  ------  141.45.184.15        0.0.0.0/0             80 ->   1024:65535
    ACCEPT     tcp  ------  0.0.0.0/0            141.45.183.15         1024:65535 ->   25
    ACCEPT     tcp  ------  141.45.184.15        0.0.0.0/0             25 ->   1024:65535
    ACCEPT     tcp  ------  0.0.0.0/0            141.45.183.15         1024:65535 ->   21
    ACCEPT     tcp  ------  141.45.184.15        0.0.0.0/0             21 ->   1024:65535
    ACCEPT     tcp  ------  0.0.0.0/0            141.45.183.15         1024:65535 ->   20
    ACCEPT     tcp  ------  141.45.184.15        0.0.0.0/0             20 ->   1024:65535
    ACCEPT     tcp  ------  141.45.185.0/24      141.45.184.15         1024:65535 ->   3128
    ACCEPT     tcp  ------  141.45.184.15        141.45.185.0/24       3128 ->   1024:65535
    ACCEPT     tcp  ------  141.45.184.128/25    141.45.184.15         1024:65535 ->   3128
    ACCEPT     tcp  ------  141.45.184.15        141.45.184.128/25     3128 ->   1024:65535
    ACCEPT     tcp  ------  141.45.184.15        0.0.0.0/0             1024:65535 ->   80
    ACCEPT     tcp  ------  0.0.0.0/0            141.45.183.15         80 ->   1024:65535
    ACCEPT     tcp  ------  141.45.184.15        0.0.0.0/0             1024:65535 ->   21
    ACCEPT     tcp  ------  0.0.0.0/0            141.45.183.15         21 ->   1024:65535
    ACCEPT     tcp  ------  141.45.184.15        0.0.0.0/0             1024:65535 ->   20
    ACCEPT     tcp  ------  0.0.0.0/0            141.45.183.15         20 ->   1024:65535
    ACCEPT     tcp  ------  141.45.185.0/24      141.45.184.130        1024:65535 ->   139
    ACCEPT     tcp  ------  141.45.184.130       141.45.185.0/24       139 ->   1024:65535
    ACCEPT     tcp  ------  141.45.185.0/24      141.45.184.15         1024:65535 ->   25
    ACCEPT     tcp  ------  141.45.184.15        141.45.185.0/24       25 ->   1024:65535
    ACCEPT     tcp  ------  141.45.185.0/24      141.45.184.15         1024:65535 ->   110
    ACCEPT     tcp  ------  141.45.184.15        141.45.185.0/24       110 ->   1024:65535
    ACCEPT     icmp ------  0.0.0.0/0            0.0.0.0/0             8 ->   *
    ACCEPT     icmp ------  0.0.0.0/0            0.0.0.0/0             0 ->   *
       

Sollte festgestellt werden, daß eine Regel fehlerhaft ist, kann diese entfernt werden, indem in dem Kommando welches die Regel erstellt hat die Option -A durch die Option -D ersetzt wird.

Systemtest

Nach der Konfiguration der Firewall kann mit Hilfe eines Portscanners die Erreichbarkeit von Diensten von jedem einzelnen Subnetz aus überprüft werden. Am geeignetsten bietet sich hier der Portscanner Nmap an, dessen Ausgaben im Folgenden für jedes Segment dargestellt werden:

• Zunächst wurde die Firewall vom Internet aus untersucht:

  # Nmap scan initiated Wed Jan 31 16:07:25 2001 as: nmap -O -sT -sR -n -o von_Internet.txt -g 20 
  # -vv firewall 
  Insufficient responses for TCP sequencing (0), OS detection will be MUCH less reliable
  Interesting ports on  (141.45.183.15):
  (Not showing ports in state: filtered)
  Port    State       Protocol  Service (RPC)
  20      unfiltered  tcp       ftp-data                
  21      open        tcp       ftp                     
  25      open        tcp       smtp                    
  80      open        tcp       http                    
  110     open        tcp       pop-3                   
  
  Remote OS guesses: AIX 4.0 - 4.1, AIX 4.02.0001.0000, AIX 4.1, AIX 4.2, Solaris 2.5, 
                     2.5.1, Solaris 2.6 - 2.7, Solaris 2.6 - 2.7 X86, Solaris 2.6 - 2.7 
                     with tcp_strong_iss=0, Solaris 2.6 - 2.7 with tcp_strong_iss=2
  OS Fingerprint:
  T1(Resp=N)
  T2(Resp=N)
  T3(Resp=N)
  T4(Resp=N)
  T5(Resp=N)
  T6(Resp=N)
  T7(Resp=N)
  PU(Resp=N)
       
  

  Hier fällt auf, daß eine Erkennung des Betriebssystems anhand der TCP-Sequenzen nicht sicher erfolgen kann und eine Vermutung auf das Betriebssystem fäll, welches die meisten Anfragen beantwortet, in diesem Fall ist es durch das Portforwarding der öffentliche Server, welcher unter Solaris 7 läuft.

• Als nächstes wurde die Firewall vom Clientnetz aus gescannt:

  # Nmap scan initiated Wed Jan 31 17:01:25 2001 as: nmap -O -sT -sR -n -o Firewall_von_Clientnetz.txt 
  # -g 20 -vv 141.45.185.1 
  Warning:  No tcp ports found open on this machine, OS detection will be MUCH less reliable
  Warning:  No tcp ports found open on this machine, OS detection will be MUCH less reliable
  Warning:  No tcp ports found open on this machine, OS detection will be MUCH less reliable
  Interesting ports on  (141.45.185.1):
  (Not showing ports in state: filtered)
  Port    State       Protocol  Service (RPC)
  
  Too many fingerprints match this host for me to give an accurate OS guess
  TCP/IP fingerprint:
  T5(Resp=N)
  T6(Resp=N)
  T7(Resp=N)
  PU(Resp=N)
  

  Hier ist sehr deutlich zu sehen, daß die Firewall als Rechner selbst nicht erreichbar ist.

• Ein Scan des öffentlichen Servers vom Clientnetzwerk aus zeigt, daß lediglich die explizit freigegeben Dienste von den Clients erreichbar sind.

  # Nmap scan initiated Wed Jan 31 17:15:24 2001 as: nmap -O -sT -sR -n -o 
  # Publicserver_von_Clientnetz.txt -g 20 -vv 141.45.184.15 
  Insufficient responses for TCP sequencing (0), OS detection will be MUCH less reliable
  Interesting ports on  (141.45.184.15):
  (Not showing ports in state: filtered)
  Port    State       Protocol  Service (RPC)
  25      open        tcp       smtp                    
  110     open        tcp       pop-3                   
  3128    open        tcp       squid-http              
  
  Remote OS guesses: AIX 4.0 - 4.1, AIX 4.02.0001.0000, AIX 4.1, AIX 4.2, Solaris 2.5, 
                     2.5.1, Solaris 2.6 - 2.7, Solaris 2.6 - 2.7 X86, Solaris 2.6 - 2.7 
                     with tcp_strong_iss=0, Solaris 2.6 - 2.7 with tcp_strong_iss=2
  OS Fingerprint:
  T1(Resp=N)
  T2(Resp=N)
  T3(Resp=N)
  T4(Resp=N)
  T5(Resp=N)
  T6(Resp=N)
  T7(Resp=N)
  PU(Resp=N)
       
  
  

Quellen:

• Nmap Portscanner