Matching log aan ruleset in Pix-firewall

[Verwijderd]

Ik heb al gezocht op de CISCO TAC site maar geen relevante informatie gevonden.

Het probleem is alsvolgt:
We hebben een CISCO PIX firewall, voorzien van diverse rules (SrcHost - DestHost en Port). De PIXen loggen naar een SYSLOG server. Nu willen we graag zien door welke rule een sessie wordt 'gehit'

Bijvoorbeeld (logische ruleset):
RULE1 host a - host b prot 1 ACCEPT
RULE2 host c - host d prot 2 ACCEPT
RULE3 subn a - subn b prot 3 ACCEPT
RULE4 subn a - subn b ANY DROP
RULE5 ANY - ANY ANY DROP

Van elk pakket dat in de log wordt weggeschreven willen we zien welke rule wordt gefired.

De Checkpoint -firewalls ondersteunen dit, IPtabels firewalls ondersteunen dit. De PIX firewalls echter niet.

Heeft iemand een oplossing? Of hebben we iets over het hoofd gezien?
Dit is (volgens mij althans) toch een basis functionaliteit van een firewall.....

[kell.nl]

Ik weet niet wat voor een versie je hebt van de PDM, maar daar is het heel gemakkelijk in te stellen.
In de rule advanced options aanklikken, en aangeven dat ie moet loggen.
In cli kun je het op deze manier doen:

code:

access-list inside_access_in line 1 permit icmp any any  log 4 interval 300

Bovenstaande rule logt dus elk ICMP pakketje als level 4 (warning), waarbij die om de 300 secs een nieuwe entry logt voor dezelfde flow.

[Verwijderd]

kell.nl schreef op 30 juli 2004 @ 15:49:
Ik weet niet wat voor een versie je hebt van de PDM, maar daar is het heel gemakkelijk in te stellen.
In de rule advanced options aanklikken, en aangeven dat ie moet loggen.
In cli kun je het op deze manier doen:

code:

access-list inside_access_in line 1 permit icmp any any  log 4 interval 300

Bovenstaande rule logt dus elk ICMP pakketje als level 4 (warning), waarbij die om de 300 secs een nieuwe entry logt voor dezelfde flow.

Welke versie van PDM weet ik niet. Het is een dienst die we van een dienstenleverancier afnemen.
Ziet bovenstaande log-regel eruit?
Per logregel wil ik ook de rule zien waarop deze 'fired'

Bijvoorbeeld zoals IPTABLES dit ook weergeeft (in eenvoudige vorm weergegeven)
RULE 1: 1.2.3.4 4.5.6.7 ICMP ACCEPT

[kell.nl]

Nou.. Ik heb even zo'n regel aangemaakt om mijn PIX, en de logging aangezet voor die regel.
(ICMP loggen interesseert me normaal niet zo )
Ik heb gepinged naar 195.121.1.35 en mijn intern ip is 10.0.0.2.
De Pix is 10.0.0.254
Hij geeft de volgende output:

code:

2004-07-30 21:22:27 Local4.Warning  10.0.0.254  Jul 30 2004 21:22:28 pixsis : %PIX-4-106100: access-list inside_access_in permitted icmp inside/10.0.0.2(0) -> outside/195.121.1.35(8) hit-cnt 21 (300-second interval)

[Verwijderd]

kell.nl schreef op 30 juli 2004 @ 21:26:
Nou.. Ik heb even zo'n regel aangemaakt om mijn PIX, en de logging aangezet voor die regel.
(ICMP loggen interesseert me normaal niet zo )
Ik heb gepinged naar 195.121.1.35 en mijn intern ip is 10.0.0.2.
De Pix is 10.0.0.254
Hij geeft de volgende output:

code:

2004-07-30 21:22:27 Local4.Warning  10.0.0.254  Jul 30 2004 21:22:28 pixsis : %PIX-4-106100: access-list inside_access_in permitted icmp inside/10.0.0.2(0) -> outside/195.121.1.35(8) hit-cnt 21 (300-second interval)

oke....
Het nummer -1- in dit geval, wijst dat naar het volgnummer in de log of is dit een verwijziging naar de -1- in de ruleset? Dat het laatste het geval is dan is mijn probleem opgelost

[kell.nl]

Dan moet ik je helaas teleurstellen.
Die 1 staat erbij omdat ik code tags heb gebruikt.
Maar je ziet in de logging toch gewoon waarom ie gelogd wordt? Dan kan je zelf terugleiden naar welke regel.

[Bor]

kell.nl -> Als ik het goed begrijp wil ts zien welke rule een willekeurige deny veroorzaakt. De pix geeft alleen aan dat het verkeerd gedropped is, niet op basis van welke rule. Door zelf bij een rule op te geven dat ie dit verkeer moet loggen krijg je niet hetzelfde resultaat.

[chromeeh]

Bor_de_Wollef schreef op 01 augustus 2004 @ 12:09:
kell.nl -> Als ik het goed begrijp wil ts zien welke rule een willekeurige deny veroorzaakt. De pix geeft alleen aan dat het verkeerd gedropped is, niet op basis van welke rule. Door zelf bij een rule op te geven dat ie dit verkeer moet loggen krijg je niet hetzelfde resultaat.

Maar je kunt toch ook gewoon aan geven als in het voorbeeld echter met op drop
En anders moet je eens kijken of je wat met een Cisco Confg maker kunt, want daar staan ook altijd goede voorbeelden bij / in

[Verwijderd]

Bor_de_Wollef schreef op 01 augustus 2004 @ 12:09:
kell.nl -> Als ik het goed begrijp wil ts zien welke rule een willekeurige deny veroorzaakt. De pix geeft alleen aan dat het verkeerd gedropped is, niet op basis van welke rule. Door zelf bij een rule op te geven dat ie dit verkeer moet loggen krijg je niet hetzelfde resultaat.

Dit begrijp je goed....
Zowel door CheckPoint als door IPTabels kun je direct aangegeven op welke rule een entry is gefired.
Is dit nu een beperking van de Cisco's? Het lijkt mij toch een basisfunctionaliteit voor een firewall. Zeker bij een firewall met enige omvang van ruleset moet het aantoonbaar zijn (audit) waarom sessies worden dorogelaten. Ook bij forensic analyses is dit zeer gewenst.

Ik vind dit persoonlijk een zeer zwak punt van de Pix.