Tracking NAT'd users activity on the PIX firewall

[mitchen]

Our company use a product called Scansafe for web scanning. Every now and then we are sent a report from scansafe along the lines of:

"The ScanSafe service discovered a possible virus or malicious code in a Web page or download accessed from within your organisation.

Access to the Web page/download was blocked.

Report:

Browsing ip: xxx.xxx.xxx.xxx

Reason: virus : Exploit.HTML.CodeBaseExec

URL: http://whatever

User Name: xxx.xxx.xxx.xxx

Group Name: default

No further action is required."

Now, the xxx.xxx.xxx.xxx address (I have removed the actual IP address!) is the public address of our PIX 515E firewall, running 6.3(3).

What we would like to be able to do is actually identify which particular user was trying to access the dodgy webpage.

Is there anything I can do on the PIX itself which would provide this information?

I've had a look through the Pix logs to see if I could find anyone accessing the URL specified but no success from that (I guess because the ScanSafe blocked it from being accessed in the first place?)

Any suggestions as to how we could identify users accessing malicious content?

The ScanSafe reports are useful in telling us that a threat was blocked but not so much use in identifying who was responsible.

[jackko]

to start with, you need to match the public ip of that particular url as pix doesn't work with url but ip.

after obtaining the ip, you can either do a "capture" or "sh conn".

to configure "capture",

access-list url permit tcp any host eq 80

capture url access-list url interface inside

no config for "sh conn".

e.g

pix#sh conn

TCP out 202.58.56.1:80 in 192.168.1.151:1555 idle 0:00:03 Bytes 7189 flags UIO

TCP out 202.58.56.1:80 in 192.168.1.151:1556 idle 0:00:03 Bytes 1793 flags UIO

TCP out 202.58.56.1:80 in 192.168.1.151:1546 idle 0:00:01 Bytes 65401 flags UIO

TCP out 202.58.56.1:80 in 192.168.1.151:1547 idle 0:00:01 Bytes 69058 flags UIO

pix(config)# sh capture url

105 packets captured

22:04:07.703073 192.168.1.151:1581 > 202.58.56.1.80: P 2726115435:2726115629(194) ack 1253828938 win 17640

22:04:08.152396 192.168.1.151:1581 > 202.58.56.1.80: . ack 1253830010 win 16568

22:04:08.485463 192.168.1.151:1581 > 202.58.56.1.80: . ack 1253831082 win 17640

22:04:08.662914 192.168.1.151:1581 > 202.58.56.1.80: . ack 1253831618 win 17104

22:04:08.936566 192.168.1.151:1581 > 202.58.56.1.80: . ack 1253832690 win 17640

22:04:08.950008 192.168.1.151:1582 > 202.58.56.1.80: S 1781971934:1781971934(0) win 16384

[mitchen]

Hi Jackko,

thanks for the info - I should have mentioned, I also checked the PIX logs for the public IP address of the web server from the URL but there was no sign of it either.

If I understand the information you have supplied correctly, then this will show me how to capture any traffic hitting that web server in future.

However, what I really want to know is - if this has happened in the past, is there anything I can do on the PIX to find out who it was?

The reason being - its Scansafe who alert us if anyone accesses a URL they have deemed dangerous. (i.e. we don't hold a list of banned sites ourselves) So we don't actually know about it until after it has happened.

Again, if I understand correctly (I'm a PIX novice so bare with me!), the "sh conn" command will show me current connections, but what I really want to find out is information on a connection that happened in the past.

However, thanks for the info - that's useful to know all the same!

Any suggestions on how I can look at this kind of info historically? And if ScanSafe has prevented access to a particular site, should I expect to see anything related to this in the PIX logs, in any case?

Thanks,

Neil

[Patrick Iseli]

Might be a good idea to log all messages to a syslog server. Like that you can grep (search) the logs for that specific IP and can figure out which source and destination address in your network had generated that alert.

Syslog server could be:

Kiwi Syslog:

http://www.kiwisyslog.com/

30COM Deamon

http://www.ncat.co.uk/Download/

Commercial products could be:

FireGen http://www.eventid.net/firegen/

EIQ Networks Network Security Analyzer eiqnetworks.com

config example:

logging buffered warning

logging trap info

logging queue 4096

logging host inside x.x.x.x

Logging levels:

0 emergency

System unusable.

1 alert

Immediate action needed.

2 critical

Critical condition.

3 error

Error condition.

4 warning

Warning condition.

5 notification

Normal but significant condition.

6 informational

Informational message only.

7 debugging

Appears during debugging only.

sincerely

Patrick

[mitchen]

Hi Patrick,

thanks for the info, yes we are already logging to a syslog server, using the Kiwi Syslog which seems pretty good.

(The main issue I have is that the logs do get pretty big)

I searched the logs for the particular IP/URL mentioned in the last ScanSafe report we had but could not find any mention of it.

I don't know if this is because a) I'm not logging everything I should be or b) it wasn't logged because ScanSafe had blocked it in the first place.

If either of these are the case though, how do I track what user has caused Scansafe to block their action?

Any suggestions?

This is what we have currently configured on our Pix for logging purposes:

logging on

logging timestamp

logging console critical

logging monitor debugging

logging buffered debugging

logging trap informational

logging history informational

logging host inside x.x.x.x

no logging message 106011

Thanks,

Neil

[Patrick Iseli]

It depends where the ScanSafe is located if it is behind the PIX then the session should be logged in the PIX syslog.

Logging trap informational is ok and give a lot of output.

Is it deployed like this ?

Internet --- PIX --- ScanSafe ---- Internal Users

sincerely

Patrick

[mitchen]

Hi Patrick,

no, it's not behind the PIX so I guess that may be why nothing is logged on the PIX but it means we can't really tell a lot from our ScanSafe reports, unfortunately!

It is:

Internet --- ScanSafe --- PIX --- Internal Users

Thanks,

Neil

[Patrick Iseli]

Yes difficult, but still if you get the IP of the destination, if it is not a fake one, you still should see some packets.

Another way might be to add an access-list on the inside interface and add logging to " ip any any " which would be logged to the syslog server. But this might cause a lot of traffic for the syslog server.

On the other hand there are a lot of trojans and other malicious code in html pages and probably it was not the intention to the user to get that junck.

It is more important that the malicious code get blocked as to track the user.

sincerely

Patrick