Bitte um Audit einer Router-Konfiguration

[Tobias]

Hallo,

ich möchte bei einem Cisco 1712 die Router-Konfiguration (v.a. ACLs, IPS) hinsichtlich Sicherheitsaspekten verbessern und habe deshalb einige Änderungen an der aktuellen Konfiguration vorgenommen, welche mir in diverser Literatur empfohlen wurde.

Nun bin ich kein großer Cisco-Experte und würde mich daher freuen, wenn erfahrene Anwender sich durch meine Konfiguration lesen und mir Tips für Verbesserungen geben könnten... was ist gut gelöst worden, was überflüssig, was fehlt, was ist vielleicht sogar gefährlich oder verursacht später Probleme.

Die Netzwerk-Topologie sieht wie folgt aus: Cisco 1712 an sDSL (statische IPs). Hinter dem Cisco befindet sich ein WLAN (eine statische IP) sowie zwei Server (je Server eine statische IP). Auf den Servern laufen die folgenden Dienste: Web (http, https), E-Mail (POP3, SMTP, IMAP), FTP, DNS (primärer/sekundärer DNS mit freigegebenem Zonen-Transfer zu einer festgelegten IP außerhalb (Backup-DNS)). Die Server liefern Websites und verwalten E-Mail-Accounts, auf welche von außerhalb des LANs zugegriffen wird (also die Anwender greifen über das Internet auf die E-Mail-Accounts und auf FTP zu). Ich kann also nicht einfach sämtlichen von außen (Internet) initiierten Datenverkehr blockieren.

So... hier die aktuelle Konfiguration:

Building configuration...

Current configuration : 7667 bytes
!
! Last configuration change at 20:56:50 Berlin Sun Nov 4 2007 by *****
! NVRAM config last updated at 00:07:59 Berlin Sat Nov 3 2007 by *****
!
version 12.3
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service sequence-numbers
!
hostname router1
!
boot-start-marker
boot-end-marker
!
security authentication failure rate 3 log
security passwords min-length 6
logging buffered 131072 debugging
enable secret 5 *****
!
clock timezone Berlin 1
clock summer-time Berlin date Mar 30 2003 2:00 Oct 26 2003 3:00
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
aaa new-model
!
!
aaa authentication login local_authen local
aaa authorization exec local_author local
aaa session-id common
ip subnet-zero
no ip source-route
!
!
!
!
ip tcp synwait-time 10
ip cef
ip domain name *****
no ip bootp server
ip inspect audit-trail
ip inspect tcp max-incomplete host 50 block-time 30
ip inspect name mypolicy esmtp
ip inspect name mypolicy http
ip inspect name mypolicy cuseeme
ip inspect name mypolicy netshow
ip inspect name mypolicy realaudio
ip inspect name mypolicy rtsp
ip inspect name mypolicy streamworks
ip inspect name mypolicy vdolive
ip inspect name mypolicy h323
ip inspect name mypolicy skinny
ip inspect name mypolicy sip
ip inspect name mypolicy sqlnet
ip inspect name mypolicy ftp
ip inspect name mypolicy tftp
ip inspect name mypolicy rcmd
ip inspect name mypolicy icmp
ip inspect name mypolicy fragment maximum 256 timeout 1
ip inspect name mypolicy tcp
ip inspect name mypolicy udp
ip ips sdf location flash://attack-drop.sdf
ip ips fail closed
ip ips notify SDEE
ip ips po max-events 100
ip ips name sdm_ips_rule
vpdn enable
!
vpdn-group 1
 request-dialin
  protocol pppoe
!
no ftp-server write-enable
!
isdn switch-type basic-net3
!
!
username ***** privilege 15 view root password 7 *****
!
!
no crypto isakmp ccm
!
!
!
interface Null0
 no ip unreachables
!
interface BRI0
 description Alternatives ISDN-Interface
 no ip address
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip ips sdm_ips_rule in
 ip ips sdm_ips_rule out
 ip virtual-reassembly
 ip route-cache flow
 shutdown
 isdn switch-type basic-net3
 no cdp enable
!
interface FastEthernet0
 description Anschluß des DSL-Modems$ETH-WAN$
 no ip address
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip route-cache flow
 speed auto
 half-duplex
 pppoe enable
 pppoe-client dial-pool-number 1
 no cdp enable
!
interface FastEthernet1
 no cdp enable
!
interface FastEthernet2
 no cdp enable
!
interface FastEthernet3
 no cdp enable
!
interface FastEthernet4
 no cdp enable
!
interface Vlan1
 description LAN$FW_INSIDE$
 ip address 149.88.100.89 255.255.255.248
 ip access-group sdm_vlan1_in in
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip ips sdm_ips_rule in
 ip ips sdm_ips_rule out
 ip virtual-reassembly
 ip route-cache flow
!
interface Dialer1
 description T-DSL dialer$FW_OUTSIDE$
 ip address negotiated
 ip access-group 102 in
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip mtu 1492
 ip inspect mypolicy in
 ip ips sdm_ips_rule in
 ip ips sdm_ips_rule out
 ip virtual-reassembly
 encapsulation ppp
 ip route-cache flow
 ip tcp adjust-mss 1452
 dialer pool 1
 dialer-group 1
 ppp chap refuse
 ppp pap sent-username ***** password 7 *****
!
ip classless
ip route 0.0.0.0 0.0.0.0 Dialer1
ip http server
ip http access-class 9
ip http authentication local
ip http secure-server
!
!
!
!
ip access-list extended sdm_vlan1_in
 remark SDM_ACL Category=1
 remark Allow own traffic to the Internet
 permit ip 149.88.100.88 0.0.0.7 any log
 remark Stop illegal outgoing traffic
 deny   ip any any
access-list 9 permit 149.88.100.88 0.0.0.7
access-list 100 remark VTY Access-class list
access-list 100 remark SDM_ACL Category=1
access-list 100 permit ip 149.88.100.88 0.0.0.7 any
access-list 100 deny   ip any any
access-list 101 permit ip any any
access-list 102 remark SDM_ACL Category=17
access-list 102 remark Auto generated by SDM for NTP (123) 17.72.133.42
access-list 102 permit udp host 17.72.133.42 eq ntp any eq ntp
access-list 102 remark Apple Remote Desktop
access-list 102 deny   udp any 149.88.100.88 0.0.0.7 eq 3283 log
access-list 102 remark Apple Remote Desktop
access-list 102 deny   tcp any 149.88.100.88 0.0.0.7 eq 3283 log
access-list 102 remark Apple Remote Desktop
access-list 102 deny   udp any 149.88.100.88 0.0.0.7 eq 5900 log
access-list 102 remark Apple Remote Desktop
access-list 102 deny   tcp any 149.88.100.88 0.0.0.7 eq 5900 log
access-list 102 remark Apple Remote Desktop
access-list 102 deny   tcp any 149.88.100.88 0.0.0.7 eq 5432 log
access-list 102 remark Apple Remote Desktop
access-list 102 deny   tcp any 149.88.100.88 0.0.0.7 eq 5988 log
access-list 102 remark Apple Remote Desktop
access-list 102 deny   tcp any 149.88.100.88 0.0.0.7 eq 5989 log
access-list 102 remark SSH
access-list 102 deny   tcp any 149.88.100.88 0.0.0.7 eq 22 log
access-list 102 remark SSH
access-list 102 deny   udp any 149.88.100.88 0.0.0.7 eq 22 log
access-list 102 remark Telnet
access-list 102 deny   udp any 149.88.100.88 0.0.0.7 eq 23 log
access-list 102 remark Telnet
access-list 102 deny   tcp any 149.88.100.88 0.0.0.7 eq telnet log
access-list 102 remark TFTP
access-list 102 deny   udp any 149.88.100.88 0.0.0.7 eq tftp log
access-list 102 remark SFTP
access-list 102 deny   tcp any 149.88.100.88 0.0.0.7 eq 115 log
access-list 102 remark Server Admin
access-list 102 deny   tcp any 149.88.100.88 0.0.0.7 eq 311 log
access-list 102 remark Entfernter Verzeichniszugriff
access-list 102 deny   tcp any 149.88.100.88 0.0.0.7 eq 625 log
access-list 102 remark Seriennummerunterst^Otzung
access-list 102 deny   udp any 149.88.100.88 0.0.0.7 eq 626 log
access-list 102 remark Prevent networks claiming to be me
access-list 102 deny   ip 149.88.100.88 0.0.0.7 149.88.100.88 0.0.0.7 log
access-list 102 remark Stop illegal traffic
access-list 102 deny   ip host 0.0.0.0 149.88.100.88 0.0.0.7 log
access-list 102 remark Stop illegal traffic
access-list 102 deny   ip 10.0.0.0 0.255.255.255 149.88.100.88 0.0.0.7 log
access-list 102 remark Stop illegal traffic
access-list 102 deny   ip 127.0.0.0 0.255.255.255 149.88.100.88 0.0.0.7 log
access-list 102 remark Stop illegal traffic
access-list 102 deny   ip 172.16.0.0 0.15.255.255 149.88.100.88 0.0.0.7 log
access-list 102 remark Stop illegal traffic
access-list 102 deny   ip 192.168.0.0 0.0.255.255 149.88.100.88 0.0.0.7 log
access-list 102 remark Stop illegal traffic
access-list 102 deny   ip 224.0.0.0 15.255.255.255 149.88.100.88 0.0.0.7 log
access-list 102 permit ip any any
dialer-list 1 protocol ip list 101
no cdp run
!
!
control-plane
!
banner login ^CWelcome to ***** !
This is a private system; access is prohibited.
Contact for inquiries: *****
-------------------------------------------
Willkommen bei ***** !
Dies ist ein privates System; Zugriff nicht gestattet.
Kontakt für Anfragen: *****^C
!
line con 0
 password 7 *****
 login authentication local_authen
 transport output telnet
line aux 0
 login authentication local_authen
 transport output telnet
line vty 0 4
 access-class 100 in
 exec-timeout 30 0
 password 7 *****
 authorization exec local_author
 login authentication local_authen
 transport input ssh
!
scheduler allocate 4000 1000
scheduler interval 500
ntp clock-period 17179935
ntp server 17.72.133.42
end

Nun freue ich mich auf Ihre Resonanz
Eine Bitte allerdings noch: Da ich die Konfiguration mit SDM erstellt habe und keine tiefgehenden Kenntnisse zu IOS und dem Arbeiten auf Kommandozeilen-Ebene besitze, bitte Verbesserungsvorschläge etwas ausführlicher erklären

[Zwerg#7]

Hallo Tobias,

willkommen im Board! 

Die ganze Konfig bin ich noch nicht durch gegangen, vorallem für die ACL müsste ich mir noch ein bisschen mehr Zeit nehmen.
Was mir aber auf die Schnelle auffällt:

1) Deaktiviere den HTTP Server und verwende nur HTTPS
2) username tobias privilege 15 view root password 7 ***** -> ersetze "password" durch "secret"
3) In einem Login-Banner sollten keine verwertbaren Infos wie Firmen- oder Geräte-Namen zu finden sein, auch eine Kontaktinfo gibt schon einiges preis!
4) Konfiguriere noch "no service udp-small-servers" und "no service tcp-small-servers", die brauchst du IMHO nicht (sind vielleicht sogar schon defaultmäßig deaktiviert)
5) Kann nichts bezgl. SNMP aus deiner Config herauslesen, vielleicht hab ichs aber auch nur überlesen. SNMP solltest du jedenfalls deaktiviren wenn du es nicht brauchst bzw. die Community ändern und auch mit einer ACL versehen.

Soviel mal fürs erste, die ACL muss ich mir noch mal in Ruhe durchsehen 
Deine Config sieht aber im großen und ganzen sehr gut aus!

[Tobias]

> Die ganze Konfig bin ich noch nicht durch gegangen, vorallem für die ACL müsste ich mir noch ein bisschen mehr Zeit nehmen.

Das wäre nett, die ACLs haben mir nämlich am meisten Kopfzerbrechen bereitet (vor allem, die etwas gewöhnungsbedürftige Zuordnung des Datenstroms "inbound" und "outbound" bei den Interfaces).

> 1) Deaktiviere den HTTP Server und verwende nur HTTPS
> 2) username tobias privilege 15 view root password 7 ***** -> ersetze "password" durch "secret"

Wie kann ich diese beiden Einstellungen über SDM vornehmen ?

Den Router (via SDM) kann man nur von innerhalb des IP-Blocks aufrufen. Ist das nicht bereits sicher genug ? SSH/Telnet sollte überhaupt keine erfolgreiche Verbindung von außerhalb zustande bringen. Ich dachte, das wäre für den Zugriffsschutz ausreichend.

> 3) In einem Login-Banner sollten keine verwertbaren Infos wie Firmen- oder Geräte-Namen zu finden sein, auch eine Kontaktinfo gibt schon einiges
> preis!

Okay, guter Tip. Aber was kann man mit den Firmeninfos anfangen ? Mache ich ein whois auf die IP, erscheint der Firmenname ja ebenso.

Der Router-Name ist nach außen hin auch nicht bekannt. Zumindest gehe ich davon aus, da ich unter http://www.qualys.com/forms/trials/freemap/matrix/?lsid=6965 eine "Landkarte" der Netzwerktopologie aufgebaut habe, allerdings völlig inkorrekt (der Cisco erschien gar nicht, dafür wurden zwei Router eingezeichnet, die einfach - zumindest im hiesigen Netzwerk - nicht existent sind. Ich nehme an, es handelt sich um Router des ISPs.).

> 4) Konfiguriere noch "no service udp-small-servers" und "no service tcp-small-servers", die brauchst du IMHO nicht (sind vielleicht sogar schon
> defaultmäßig deaktiviert)

Wieder mein Problem mit SDM, nirgends gefunden... dann also doch via Kommandozeile. Wie war das nochmal: Log in via SSH, dann "conf -t" und wie sichere ich die Einstellungen ?

> 5) Kann nichts bezgl. SNMP aus deiner Config herauslesen, vielleicht hab ichs aber auch nur überlesen. SNMP solltest du jedenfalls deaktiviren wenn
> du es nicht brauchst bzw. die Community ändern und auch mit einer ACL versehen.

Endlich mal ein Punkt, den ich abarbeiten kann SNMP ist deaktiviert (SDM: "Configure", "Additional tasks", "Router access/Mgt. access" -> keine Einträge vorgenommen).

> Soviel mal fürs erste, die ACL muss ich mir noch mal in Ruhe durchsehen 

Das wäre nett

Ach, ich darf gleich noch ein paar Fragen anhängen, die ich gestern vergessen hatte:

(1) IPS: Der Router verfügt über 96 MB Speicher und 32 MB Flash, ich kann also nur attack-drop.sdf verwenden. Ist das ausreichend ? Ich habe irgendwo gelesen, daß die größte Signaturdatei über 500 Signaturen enthält - verglichen mit 81 ist das doch ein Unterschied.

Um eine größere Datei einzuspielen, führt wahrscheinlich nichts an einer Speichererweiterung vorbei, oder ? Wie teuer sind die, kann man auch alternative verwenden (technische Spezifikationen, oder verwendet Cisco eine Eigenentwicklung) ?

Können sich die Signaturen von selbst aktualisieren oder müssen neue Versionen gekauft werden ? Ich hatte mich bei Cisco mal für eine "Update notification" (oder ähnlich) Mailingliste angemeldet, aber seitdem keine einzige Mail bekommen.

(2) Seit ein paar Tagen (als ich mit den Änderungen anfing) habe ich bei den ACLs die Logging-Funktion aktiviert. Allerdings scheint es, als ob mein Firewall-Log sich von Zeit zu Zeit selbst löscht. Gestern hatte ich einmal über 70 Einträge, dann 6 und heute morgen 0. Ich habe den Logging-Buffer auf 1048576 Byte gesetzt.

So, das soll's jetzt erst einmal gewesen sein. Ich möchte Ihre Geduld nicht überstrapazieren Nochmals danke für die Tips.

[#9370]

schau dir mal den Befehl "autosecure" an. Das kümmert sich um die notwendigsten Dinge.
http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a0080455ba7.html

(1) IPS: Der Router verfügt über 96 MB Speicher und 32 MB Flash, ich kann also nur attack-drop.sdf verwenden. Ist das ausreichend ? Ich habe irgendwo gelesen, daß die größte Signaturdatei über 500 Signaturen enthält - verglichen mit 81 ist das doch ein Unterschied.

Beim IOS IPS muss dir bewusst sein, dass du Abstriche machen musst. Eine IPS Appliance hat um ein vielfaches mehr an Signaturen. Der Router kann "nur" die häufigsten Attacken erkennen. Bei den Speichererweiterungen ist es immer die Frage. Es müssten non-Cisco RAMs auch funktionieren, nur würde ich die originalen reingeben, da man auf der sicheren Seite ist.

Können sich die Signaturen von selbst aktualisieren oder müssen neue Versionen gekauft werden ? Ich hatte mich bei Cisco mal für eine "Update notification" (oder ähnlich) Mailingliste angemeldet, aber seitdem keine einzige Mail bekommen.

Man muss die Upgrades kaufen, ähnlich wie bei AV Programmen.

(2) Seit ein paar Tagen (als ich mit den Änderungen anfing) habe ich bei den ACLs die Logging-Funktion aktiviert. Allerdings scheint es, als ob mein Firewall-Log sich von Zeit zu Zeit selbst löscht. Gestern hatte ich einmal über 70 Einträge, dann 6 und heute morgen 0. Ich habe den Logging-Buffer auf 1048576 Byte gesetzt.

Es wäre besser, die Logs auf einen Syslog Server zu schicken. Dann hast du immer alle Logs. Bsp.: Kiwi Syslog Server (Freeware)
Gelöscht sollten sie aber nie werden, außer bei log-relevanten Configänderungen oder mit "clear logg"

/#9370

[Tobias]

> schau dir mal den Befehl "autosecure" an. Das kümmert sich um die notwendigsten Dinge.
> http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a0080455ba7.html

Ich habe das kurz überflogen, ist das vergleichbar mit dem Security Audit, welches SDM anbietet ? Falls ja, das habe ich schon laufen lassen und auch die Empfehlungen übernommen.

Allerdings lese ich mir den Artikel nochmal detaillierter durch und mal schauen, ob ich am Wochenende mich da mal ran wage (unter der Woche ist mir das zu gefährlich, da die Server ja nicht vom Internet abgeschnitten werden sollten

> Beim IOS IPS muss dir bewusst sein, dass du Abstriche machen musst. Eine IPS Appliance hat um ein vielfaches mehr an Signaturen. Der Router kann "nur" die häufigsten
> Attacken erkennen. Bei den Speichererweiterungen ist es immer die Frage. Es müssten non-Cisco RAMs auch funktionieren, nur würde ich die originalen reingeben, da man auf
> der sicheren Seite ist.

Okay, ich werde dann mal über eine Speichererweiterung nachdenken. Aber für wie sinnvoll halten Sie das generell Ihrer Erfahrung nach ? Ist das aktuelle attack-drop.sdf ausreichend an Signaturen ? Wir betreiben ja keine Server des Pentagon oder des BND, allerdings will ich schon sicher gehen, daß man so wenig Angriffsfläche wie möglich bietet

> (2) Seit ein paar Tagen (als ich mit den Änderungen anfing) habe ich bei den ACLs die Logging-Funktion aktiviert. Allerdings scheint es, als ob mein Firewall-Log sich von Zeit zu
> Zeit selbst löscht. Gestern hatte ich einmal über 70 Einträge, dann 6 und heute morgen 0. Ich habe den Logging-Buffer auf 1048576 Byte gesetzt.
>
> > Es wäre besser, die Logs auf einen Syslog Server zu schicken. Dann hast du immer alle Logs. Bsp.: Kiwi Syslog Server (Freeware)
> > Gelöscht sollten sie aber nie werden, außer bei log-relevanten Configänderungen oder mit "clear logg"

Da hatte ich auch daran gedacht, daß beispielsweise nach jeder Änderung an den ACLs die Firewall-Logs zurückgesetzt werden. Aber ich hatte gestern wieder das gleiche: SDM gestartet und über "Monitor" das Firewall-Log angesehen. 8 Einträge. Nach einer halben Stunde nochmal nachgesehen (neue SDM-Sitzung): 0 Einträge.

Sonderbar. Mir ist auch aufgefallen, daß SDM bei "Home" (also der ersten Ansicht nach dem Start) anzeigt, daß die Firewall deaktiviert ist. Obwohl dann bei den Einstellungen in der Sektion "Firewall" die ACLs erscheinen und offenbar die ACLs auch korrekt arbeiten (soweit ich das nachvollziehen konnte, wie von einem anderen ISP aus versuchen, via SSH auf einen Server zuzugreifen).

[#9370]

Ich habe das kurz überflogen, ist das vergleichbar mit dem Security Audit, welches SDM anbietet ? Falls ja, das habe ich schon laufen lassen und auch die Empfehlungen übernommen.

Das kann ich jetzt nicht sagen, wird aber wahrscheinlich das selbe sein (mit dem SDM tue ich eigentlich nie etwas). Das Doc ist ganz gut, da auch erklärt wird, warum manche Dinge abgeschaltet gehören.

Okay, ich werde dann mal über eine Speichererweiterung nachdenken. Aber für wie sinnvoll halten Sie das generell Ihrer Erfahrung nach ? Ist das aktuelle attack-drop.sdf ausreichend an Signaturen ? Wir betreiben ja keine Server des Pentagon oder des BND, allerdings will ich schon sicher gehen, daß man so wenig Angriffsfläche wie möglich bietet wink

Einen Grundschutz bietet es allemal.

Da hatte ich auch daran gedacht, daß beispielsweise nach jeder Änderung an den ACLs die Firewall-Logs zurückgesetzt werden. Aber ich hatte gestern wieder das gleiche: SDM gestartet und über "Monitor" das Firewall-Log angesehen. 8 Einträge. Nach einer halben Stunde nochmal nachgesehen (neue SDM-Sitzung): 0 Einträge.

verbinde dich mal mit Telnet/SSH auf den Router und mache ein "show logg". Höchstwahrscheinlich zeigt der SDM nur eine Momentaufnahme und nicht den logging buffer.

/#9370

[Tobias]

> verbinde dich mal mit Telnet/SSH auf den Router und mache ein "show logg". Höchstwahrscheinlich zeigt der SDM nur eine Momentaufnahme und
> nicht den logging buffer.

Da sind in der Tat mehr Einträge, über 6800+, allerdings die, welche im SDM unter "Logging" erscheinen.

Von meiner access list 102 (die sonst immer in den Firewall-Logs aufgetaucht ist) konnte ich auch nach einigen tausend Zeilen durchsuchen nichts finden. Ich hoffe, ich habe da nichts falsch gemacht...

Könnte es sein, daß die Regeln, die ich in der ACL 102 aufgestellt habe nur für die Dienste angewendet werden, welche in der Inspection rule "mypolicy" festgelegt wurden ? Ich muß gestehen, daß ich die Application Security ohne langes Nachdenken aktiviert habe, da ich mir davon lediglich einen zusätzlichen Sicherheitsgewinn versprochen hatte.

Andererseits wenn ich Dienste wie SSH versuche aufzurufen, die in der ACL 102 gesperrt wurden, gelingt mir das nur von innerhalb der IP-Range 149.88.100.89-...95, nicht jedoch von außerhalb (also wenn ich mich mit einem Dial-up-Account eines ISPs einwähle). Und "SSH" ist in den "Application Security" Einstellungen nicht zu finden.

Also ist das Verhalten doch so wie es sein sollte. Von daher sollte es also funktionieren... oder ?

Einmal explizit gefragt: In welchem Verhältnis steht die Inspection Rule zu der jeweiligen ACL ? Limitiert sie die ACL-Regeln auf die in der Inspection Rule ausgewählten Applikationen ?

[#9370]

Da sind in der Tat mehr Einträge, über 6800+, allerdings die, welche im SDM unter "Logging" erscheinen.

das ist klar, nur zeigt der SDM keine Logs vor dem Start.

Von meiner access list 102 (die sonst immer in den Firewall-Logs aufgetaucht ist) konnte ich auch nach einigen tausend Zeilen durchsuchen nichts finden. Ich hoffe, ich habe da nichts falsch gemacht...

das permit ip any any am Schluss ist fragwürdig. Im Normallfall sollte die ACL so ausschauen, dass gewollte Dinge erlaubt werden und dann zum Schluss alles andere verboten wird.

Einmal explizit gefragt: In welchem Verhältnis steht die Inspection Rule zu der jeweiligen ACL ? Limitiert sie die ACL-Regeln auf die in der Inspection Rule ausgewählten Applikationen ?

Die Config sollte so aussehen:

Code:

am Inside Interface: "ip inspect name in"
am Outside Interface: "ip access-group 102 in"

Mit dieser Config wird für ausgehende Sessions gesorgt, dass der Antwortverkehr erlaubt wird. Wenn du keinen Server hinter dem Router hast, dann kann die ACL 102 so aussehen:

Code:

access-list 102 deny ip any any

/#9370

[Tobias]

> > Da sind in der Tat mehr Einträge, über 6800+, allerdings die, welche im SDM unter "Logging" erscheinen.
> das ist klar, nur zeigt der SDM keine Logs vor dem Start.

Das tut er schon. Ich habe jetzt folgendes versucht:

1. SDM aufgerufen -> Firewall-Log ist leer. SDM beendet.
2. Zwei SSH-Verbindungen von einem Dial-up-Account aus gestartet; wurden beide abgelehnt.
3. SDM erneut aufgerufen -> Eben diese beiden Versuche stehen im Log.

Daraufhin habe ich den SDM beendet und wieder gestartet. Immer noch zwei Logeinträge. Mal sehen, wie lange die dort drin stehen bleiben

Das ist schon sonderbar, besonders weil ich mir nicht erklären kann, warum im Firewall-Log nichts steht, dafür das "normale" Logging alles aufzeichnet. In der Dokumentation die ich zu SDM gefunden habe, ist kein Log-Rotating oder ähnliches erklärt.

> das permit ip any any am Schluss ist fragwürdig. Im Normallfall sollte die ACL so ausschauen, dass gewollte Dinge erlaubt werden und dann zum
> Schluss alles andere verboten wird.

Das wurde mir von dem ISP so eingerichtet (Grundkonfiguration). Da hinter dem Router ja neben dem LAN auch noch zwei Server stehen, sei das die einfachere Möglichkeit. So wurde mir das zumindest damals erklärt.

Aber so ganz habe ich deren Konfiguration auch nicht verstanden: Wenn laut ACL 102 Datenverkehr auf Port 22 von any nach 149.88.77.88/0.0.0.7 verboten ist, weshalb kann ich dann von sagen wir 149.88.77.93 doch eine SSH-Session initiieren ? Es muß also noch eine höhere ACL vorhanden sein oder eine andere Einstellung dies ermöglichen. Aber wie gesagt, das soll ja so sein (die Server sollen von innerhalb der IP-Range gemanagt werden können, nicht jedoch von einer anderen IP aus).

> > Einmal explizit gefragt: In welchem Verhältnis steht die Inspection Rule zu der jeweiligen ACL ? Limitiert sie die ACL-Regeln auf die in der
> > Inspection Rule ausgewählten Applikationen ?
> Die Config sollte so aussehen:
> ...

Die Application Policy ist momentan gebunden an Dialer1(FastEthernet0) inbound (siehe Konfiguration in meiner ersten Post). Meinem Verständnis nach ist das aber das Outside-Interface, oder ?

Siehe Screenshot (warum erscheint die Firewall hier als "Inactive" ?):

Nochmal gefragt für ganz Dumme wie mich : Wie beeinflusst eine ACL eine Application-Policy ? Haben die beiden etwas miteinander zu tun oder beeinflussen sie sich nicht ? Also würde bei aktivierter Application-Policy die ACL nachwievor ihren ursprünglichen Job tun und umgekehrt ?

> Mit dieser Config wird für ausgehende Sessions gesorgt, dass der Antwortverkehr erlaubt wird. Wenn du keinen Server hinter dem Router hast,
> dann kann die ACL 102 so aussehen:

Wie gesagt, da sind zwei Server dahinter. Die liefern zwar nur die eingangs erwähnten Standardservices (web, ftp, mail, dns, etc.), aber ich glaube es wäre mehr Aufwand Dienste explizit zu erlauben als die "gefährlichen" zu verbieten. Außerdem besitzt jeder Server seine eigene Firewall, dort habe ich alle nicht benötigten Dienste deaktiviert.

Also beispielsweise MySQL auf Port 3306 ist in der Server-Firewall ausgeschaltet. SSH hingegen ist aktiviert, da ich ja von innerhalb des Netzes darauf zugreifen möchte. Dafür habe ich dann den Port 22 im Router via der ACL 102 blockiert, sodaß kein Zugang von "außerhalb" möglich ist.

Dazu gesagt werden sollte, daß sich die Server und das LAN zwar hinter dem Router befinden, jedoch nicht intern zugänglich sind. Also möchte ich vom LAN aus einen der Server erreichen, muß ich das über dessen WAN-IP tun.

Ich hoffe, das ergibt für Sie Sinn

[#9370]

Zusammenhang ACL - Inspect:
Die ACL ist statisch -> man muss sich um die Antworten kümmern, was oft schwierig ist. Mit dem Inspect wird sie dynamisch -> Wenn eine Session aufgebaut wird, dann wird ein dynamischer Eintrag für die Antwort erstellt.

Die ACL schaut dann so aus:
access-list 102 permit tcp any host host1 eq ftp
access-list 102 permit tcp any host host1 eq http
...
access-list 102 deny ip any any log

Diese ACL wird dann inbound dem Outside Interface (Interface, das in deinem Fall zum Internet schaut) zugewiesen.

Am Inside Interface (LAN) wird dann das Inspect inbound definiert.

d.h.:
die ACL am Outside Interface lässt nur die Abfragen an den Server zu. Das Inspect am Inside kümmert sich darum, dass dynamische Einträge am Outside für den Antwortverkehr erstellt werden.

/#9370

[Tobias]

> Die ACL ist statisch -> man muss sich um die Antworten kümmern, was oft schwierig ist. Mit dem Inspect wird sie dynamisch -> Wenn eine Session aufgebaut wird, dann wird
> ein dynamischer Eintrag für die Antwort erstellt.

Okay. Dann kann ich also zumindest sicher gehen, daß die Inspect Policies die ACL nicht "aufweichen", in der Hinsicht, daß sie Traffic gestatten würden, der eigentlich verboten sein sollte.

> Diese ACL wird dann inbound dem Outside Interface (Interface, das in deinem Fall zum Internet schaut) zugewiesen.
>
> Am Inside Interface (LAN) wird dann das Inspect inbound definiert.
>
> d.h.:
> die ACL am Outside Interface lässt nur die Abfragen an den Server zu. Das Inspect am Inside kümmert sich darum, dass dynamische Einträge am Outside für den
> Antwortverkehr erstellt werden.

Aber ist dann meine Anbindung der Inspect Rules korrekt ? Inbound an Dialer1{FastEthernet0} scheint ja richtig zu sein. Ich müsste sie dann aber noch "outbound" an VLAN1 anbinden, oder ?

Ich hoffe das mit diesen Interfaces stimmt, so wie ich es mir zurecht gelegt habe: "Vlan" klingt nach Inside Interface und Dialer1 nach Outside... ja, ich weiß eine sehr professionelle Vorgehensweise

[Zwerg#7]

Hab dich lange warten lassen aber jetzt hab ich mir doch mal deine Config ausgedruckt und in Ruhe noch mal durchgelesen 

Erstmal zu deiner Frage

Aber so ganz habe ich deren Konfiguration auch nicht verstanden: Wenn laut ACL 102 Datenverkehr auf Port 22 von any nach 149.88.77.88/0.0.0.7 verboten ist, weshalb kann ich dann von sagen wir 149.88.77.93 doch eine SSH-Session initiieren ? Es muß also noch eine höhere ACL vorhanden sein oder eine andere Einstellung dies ermöglichen. Aber wie gesagt, das soll ja so sein (die Server sollen von innerhalb der IP-Range gemanagt werden können, nicht jedoch von einer anderen IP aus).

ACL102 mag zwar SSH verbieten aber diese ACL zieht in diesem Fall nicht. In deiner Config findest du ziemlich am Ende den Punkt "line vty 0 4" (=Management Login -> Telnet/SSH). Dort ist die ACL 100 konfiguriert "access-class 100 in"
Und die ACL 100 beasgt "permit 149...."
Steht zwar bei dir in der Konfig überall noch mal dabei aber auch wenn man bei einer ACL sonst nichts angibt, steht am Ende automatisch ein "deny all"


Die ACL 102 regelt somit nur den incoming Traffic am Dialer Interface.
Was ich an dieser ACL sehr merkwürdig finde, ist, wie auch #9370 schon geschrieben hat, dass sie mit deny's arbeitet und mit einem generellen permit am Ende den Rest erlaubt (und der Rest ist immer noch viel)

Ich persönlich finde das sehr unübersichtlich und außerdem unsicher. Es gibt ca. 65000 mögliche Ports (je für TCP und UDP), deine ACL102 verbietet ja nur eine handvoll davon (wenn auch sehr geläufige)
Eine ACL die erlaubt was man will und den Rest verbietet ist viel übersichtlicher und sicherer. Man geht her und bestimmt welche der 65000 Ports aufgemacht werden, der Rest ist defaultmäßig zu


In deinem Fall also in etwa so (nur mal schematisch):

access-list 102 permit tcp any 149.88.100.88 0.0.0.7 eq http
access-list 102 permit tcp any 149.88.100.88 0.0.0.7 eq https
access-list 102 permit tcp any 149.88.100.88 0.0.0.7 eq POP3
access-list 102 permit tcp any 149.88.100.88 0.0.0.7 eq SMTP
access-list 102 permit tcp any 149.88.100.88 0.0.0.7 eq IMAP
access-list 102 permit tcp any 149.88.100.88 0.0.0.7 eq FTP
access-list 102 permit udp any 149.88.100.88 0.0.0.7 eq DNS
access-list 102 deny ip any any (diese Zeile kann man sich theoretisch sparen weil diese automatisch am Ende jeder ACL steht, auch wenn sie nicht angezeigt wird)

Noch eine Spur sicherer wäre natürlich die beiden Server direkt anzugeben. Also statt "149.88.100.88 0.0.0.7" dann jeweils "host 149.88.100.8x"

[Zwerg#7]

Oh... zwei neue Antworten... ich sollte wohl besser nicht eine Stunde lang an einer Antwort hängenbleiben.
Andererseits war ja nicht damit zu rechnen, dass ihr auch noch wach seid

Also entschuldigt, dass es da vielleicht ein paar Überschneidungen mit der Antwort von #9370 gibt 

[Zwerg#7]

Inbound an Dialer1{FastEthernet0} scheint ja richtig zu sein. Ich müsste sie dann aber noch "outbound" an VLAN1 anbinden, oder ?

Nein, musst du nicht. Der Traffic wurde ja am Outside überprüft und dann ins LAN geroutet (natürlich nur Matches).
Wenn du die selbe ACL dann auch noch ans Inside Interface bindest, wird der Traffic noch mal überprüft -> das brauchts ja nicht mehr.

Also lass das Inside einfach so, wenn keine ACL ans Interface gebunden wird, dann wird dort auch nichts mehr überprüft sondern einfach nur durchgeroutet.

[Tobias]

> Hab dich lange warten lassen aber jetzt hab ich mir doch mal deine Config ausgedruckt und in Ruhe noch mal durchgelesen 

Kein Problem So schnelle Hilfe wie hier habe ich von den "NetPros" im Cisco-Forum noch nie bekommen... wirklich ein erstklassiges Forum, schade, daß ich es erst so spät gefunden habe

> ACL102 mag zwar SSH verbieten aber diese ACL zieht in diesem Fall nicht. In deiner Config findest du ziemlich am Ende den Punkt "line vty 0
> 4" (=Management Login -> Telnet/SSH). Dort ist die ACL 100 konfiguriert "access-class 100 in"
> ...

Ja stimmt. Die ACL 100 ist mir gar nicht aufgefallen (erscheint im SDM aus unbekannten Gründen nicht).

> Die ACL 102 regelt somit nur den incoming Traffic am Dialer Interface.
> Was ich an dieser ACL sehr merkwürdig finde, ist, wie auch #9370 schon geschrieben hat, dass sie mit deny's arbeitet und mit einem generellen
> permit am Ende den Rest erlaubt (und der Rest ist immer noch viel)

So war die Konfiguration, die mir der ISP geliefert hat. Ich denke mal, die wollten sich ständiges Nachfragen meinerseits ersparen, da es natürlich so weniger Probleme gibt (da generell die Ports offen sind).

Okay... also diverse Port-Scans haben keine offenen Ports gezeigt und jeder Server hat ja noch seine eigene Firewall, die nur die benötigten Dienste geöffnet hat und alles andere ablehnt. So gesehen könnte man es auch so lassen...

Aber Sie haben natürlich recht, warum nicht schon beim Router "gefährlichen" Datenverkehr abfangen und dadurch die Server entlasten...

Also, spielen wir das doch mal durch: Ich gehe jetzt einmal von der Server-Firewall aus, ich würde dann in der ACL 102 alle Ports freigeben, die auch die Server-Firewall freigegeben hat. Bis auf eben jene die ich jetzt in den "deny"-Anweisungen stehen habe (die sind in der Server-Firewall ja freigegeben, sollen aber nicht vom Internet aus zugänglich sein).

Wie sieht es aber dann mit folgenden Firewall-Einträgen des Servers aus:


...


Was muß ich in der ACL 102 angeben, um diesen Datenverkehr zu ermöglichen ? Das "deny ip any any" in der ACL 102 blockiert ja alles nicht explizit freigegebene.

Und wie verhält es sich dann mit dem Router, der ja über 149.88.100.89 erreichbar ist, sowie mit der Netz-IP und der Broadcast-IP ? Muß ich dafür in der ACL 102 auch etwas freigeben ?

Benutzt der SDM einen speziellen Port, den ich ebenfalls berücksichtigen muß ?

> Noch eine Spur sicherer wäre natürlich die beiden Server direkt anzugeben. Also statt "149.88.100.88 0.0.0.7" dann jeweils "host 149.88.100.8x"

Aber ist es nicht sicherer, wenn sich die ACL auf das ganze Netzwerk auswirkt anstatt nur auf eine IP, oder übersehe ich da etwas ?