05-25-2008 08:56 AM
Here is row syslog msg example:
"<164>May 25 2008 18:30:29: %PIX-4-106023: Deny udp src RET-inside:RETSEAP002V/137 dst RETREBRAND-AD:pobdc005/137 by access-group "RETREBRAND-AD_access_out" [0x0, 0x0]"
I want to track such connections: for example, in case when a customer need an access to some resource from inside to DMZ or...whatever. I can query on demand or just create a rule which will "make" incidents. Also, I have CSM plugged with MARS. But MARS tracks such events (syslog entries) as unresolved. Here what I mean: the SourceIP and DestinationIP showed as 0.0.0.0. Policy Table Lookup process becomes impossible - the CSM icon "Policy Query" (looks like crazy planet:) ) is not showed.
Is it possible to resolve this issue in next realises? During device discovery (analyzing config file) MARS can resolve such objects into real IP addresses (or at least resolveble domain naims) and tracks it correctly.
05-26-2008 09:58 PM
You post is a little cryptic, but I am assuming you are talking about the 'name' command in PIX/ASA/FWSM?
We faced the same issues on our network, MARS was unabled to understand the name command referenced in our ACLs and it would show 0.0.0.0 instead of properly resolving the name to IP (from the firewall configuration). It also has similar issues with Netscreen Addresses (when defined as names).
I hope this is on the feature roadmap.
Regards
Farrukh
05-27-2008 04:53 AM
>You post is a little cryptic, but I am assuming you are talking about the 'name' command in PIX/ASA/FWSM?
Yeap:)...exectly - you've got the msg. Hope this will be resolved next update))) Wouldn't it?
The reason why should it be fixed - becouse using CSM/ASDM/SDM you can easy manage (reuse) your named objects (like CheckPoint do). I also hate any GUI tools...but in enterprise environment it brings some benefits.
07-30-2008 09:43 AM
I'm digging up an older post here, but this thread helped me resolve a problem I was having in MARS. I was starting to see the same messages with the 0.0.0.0 src and 0.0.0.0 dst events when they all used to read the correct IP addresses. Turned out that another admin had just 'named' all of the devices we had. I don't have the Topology/Monitored Device Update Scheduler configured to automatically update and was therefore not getting the current configuration of the ASA into MARS. Once I 'discovered' the ASAs again, the resolution worked properly and I had my IP addresses again. So, this can be remedied by 'discovering' the ASA again when a change is made to the names. It will also be applied during a scheduled Topology/Managed Device update.
Thanks again,
Jeff
07-30-2008 03:23 PM
Jeff, for us we never changed our name entries since months (since MARS was installed), yet it seems it cannot gather the entries properly from the FWSM.
Regards
Farrukh
07-30-2008 03:47 PM
Hello. What versions of MARS and FWSM are you running? I can try to test it later to see if it's working against an FWSM I have access to.
Thanks,
Jeff
07-30-2008 03:57 PM
MARS 4.3.4
FWSM 3.1(4) (will check and update later, don't remember exactly)
Thanks
Farrukh
07-30-2008 07:51 PM
i was wondering if this is related to name command in PIX/ASA/FWSM, then why am i getting the same as i have just added 2 4500 cat switches to MARS...I get this..
Session ID: S:272258477
Src: 0.0.0.0/0
Dest: 10.3.109.249/0
Event Types:
Inactive CS-MARS reporting device
Pardon if this is ir-relavant to ongoing discussion.
07-30-2008 11:25 PM
Dear Mohsin, it is not just the name command.
There are many other events that cause the 'zero' thing. For example summary events generated from IPS signatures also have no IPs. Similaly some PIX/ASA syslogs have port as 0. On this particular MARS, it was the name command (this can easily be veriifed by looking at the 'raw event' which is present in each inident).
Regards
Farrukh
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: