Da der IPS4210-Sensor nur zwei Interfaces (einmal Command und Control, einmal Monitoring) hat, habe ich diesen Sensor nach dem Update auf die IPS-Software 5.0 schon abgeschrieben, da er mit nur einem Monitoring-Interface nicht den doch recht interessanten Inline-Mode beherrschte.In der Software-Version 5.1 ist jetzt aber die Möglichkeit dazu gekommen, auch mit einem Interface mit Hilfe von VLAN-Pairs den Inline-Mode zu konfigurieren. Für dieses Beispiel wird folgender physikalischer Aufbau verwendet:
In den älteren Software-Versionen war hier der 4210 nur im Promiscuous-Mode zu verwenden, indem mit Hilfe eines SPAN-Ports der Server-Traffic zum Sensor gespiegelt wird.
Life of an ICMP-Packet – Wie funktioniert der Inline-VLAN-Pair-Betrieb
Obwohl sich die zwei kommunizierenden PCs in einem gemeinsamen IP-Subnetz befinden, müssen sie denoch in zwei unterschiedliche VLANs konfiguriert werden. Der Sensor wird mit einem Trunk angeschlossen.
1) Der ICMP Echo-Request kommt im VLAN101 am Switch an und wird über den Trunk mit einer VLAN-ID von 101 zum Sensor gesendet.
2) Der Sensor empfängt das Paket, untersucht es, und schickt es über den Trunk zurück sofern es nicht aufgrund einer Inline-Deny-Aktion verworfen wird. Dabei schreibt der Sensor den 802.1q-Header um und ersetzt die VLAN-ID 101 mit der 102 (die VLANs sind natürlich konfiguriert). Damit verlässt der Echo-Request den Sensor über den selben Trunk und wird dem Ziel-PC zugesendet.
3) Der Ziel-PC antwortet mit einem Echo-Reply der auf dem Trunk zum Sensor mit einer VLAN-ID von 102 zu sehen ist.
4) Der Sensor schreibt den Header wieder um und sendet das Paket mit einer VLAN-ID von 101 über den Trunk zurück.
Vorgehensweise und Konfiguration
1) Sensor auf Version 5.1 updaten
Der Sensor muß natürlich die Version 5.1 ausführen, weil erst in dieser Version die VLAN-Paare dazugekommen sind.
2) Interfaces auf dem Switch konfigurieren
Im Promiscous-Betrieb war der PC auf dem Interface Fa0/1 und der Server auf Fa0/2 in einem VLAN da sie sich direkt erreichen müssen. Der Port Fa0/3 war der Zielport einer SPAN-Sitzung.
Die Switch-Konfiguration für den Inline-Betrieb ist recht übersichtlich. Der PC und der Server müssen in unterschiedliche VLANs konfiguriert werden, da der Traffic jetzt nicht mehr direkt fließen darf, sondern immer den Umweg über den Sensor nehmen muss. Auf dem Trunk ist es nicht absolut nötig die “allowed VLANs” zu konfigurieren, ich halte dies aber für eine “Standard-Konfig” auf einem Trunk.
vlan 101-102
!
interface FastEthernet0/1
switchport access vlan 101
switchport mode access
!
interface FastEthernet0/2
switchport access vlan 102
switchport mode access
!
interface FastEthernet0/3
switchport trunk allowed vlan 101,102
switchport mode trunkDamit dieser Inline-Mode funktioniert muss der Switch mehrere CAM-Tabellen unterstützt, das macht z.B. der Cisco Catalyst 3750 mit einer neueren IOS-Version.
3) Interfaces und VLANs auf dem Sensor konfigurieren
Die Konfiguration des Sonsors geschieht an zwei Stellen: Zum einen muß unter “Interface Configuration” das Monitoring-Interface für den Inline-Mode konfiguriert werden, zum anderen die “Analysis Engine” angepaßt werden.
3.1) Unter “Interface Configuration -> Summary” ist zu sehen, daß das Monitoring-Interface noch keinem virtuellem Sensor zugeordnet wurde.
3.2) Es ist noch kein VLAN-Pair vorhanden,
3.3) über “Add” wird ein neues angelegt. In diesem Fall werden über das Subinterface 100 die VLANs 101 und 102 im Inline-Mode verbunden.
3.4) Stanardmäßig ist dieses keinem virtuellen Sensor zugeordnet.
3.5) Über “Edit” wird die Zuordnung vorgenommen
3.6) Weiterhin muß das Interface eingeschaltet werden
Zusätzlich wurde für eine FTP-Signatur eine Inline-Deny-Aktion konfiguriert. Aufgrund der doch sehr trägen Oberfläche auf dem 4210 habe ich das auf dem CLI gemacht wobei folgende Konfig rausgekommen ist:
signatures 6250 0
engine string-tcp
event-action deny-attacker-inline
exit
Überprüfung
Ein “Angriff” wird gestartet:
C:Documents and SettingsAdministrator>ftp 172.26.26.50
Connected to 172.26.26.50.
220 ca Microsoft FTP Service (Version 5.0).
User (172.26.26.50:(none)): sdfdsa
331 Password required for sdfdsa.
Password:
530 User sdfdsa cannot log in.
Login failed.
ftp> user dfdsf
331 Password required for dfdsf.
Password:
530 User dfdsf cannot log in.
Login failed.
ftp> user dfdsf
331 Password required for dfdsf.
Password:
530 User dfdsf cannot log in.
Login failed.
ftp>“show events” zeigt, daß die konfigurierte Inline-Aktion ausgeführt wird:
evStatus: eventId=1150240014237161088 vendor=Cisco
originator:
hostId: sensor
appName: sensorApp
appInstanceId: 328
time: 2006/06/16 15:14:12 2006/06/16 15:14:12 UTC
denyAttackerStarted:
description: denyAttackerStarted for address: 172.26.26.170
address: 172.26.26.170Der Angreifer ist als “denied” im Sensor eingetragen:
sensor# sh statistics denied-attackers
Denied Attackers and hit count for each.
172.26.26.170 = 18
Statistics for Virtual Sensor vs0
Denied Attackers with percent denied and hit count for each.
Attacker Address Victim Address Port Protocol Requested Percentage
172.26.26.170 100
Actual Percentage Hit Count
100 18
sensor#Weitere Konfigurationen
Erst nachdem das Monitoring-Interface auf 10MBit/s und Fullduplex konfiguriert wurde hat der Betrieb problemlos funktioniert. Wenn das Interface auf 100MBit/s steht wird der 4210-Sensor anscheinend so schnell überlastet, daß selbst im Testbetrieb etliche Sessions abgebrochen sind, die normal hätten durchlaufen sollen.