08-25-2009 08:51 PM
Hi, we have IDP blades in TAP mode in a ISG cluster. Everything works like a charm except that we loose the private addresses in the IDS alerts.
Anybody know if there's some ISG setting to make address translation to work so that the private addresses appear instead of the NAT address in the event logs?
08-26-2009 06:35 AM
the IDP doesn't have option to choose the IP address before or after NAT, as per design sees the packets as they're forwarded by the FW.
What NAT type are you using? Maybe you can change from VIP to MIP and see the difference?
08-27-2009 02:39 AM
if the attack is detected over a session established by the NATted client, then the original IP address should be in the logs...
Can you give us more details?
09-01-2009 06:57 PM
On the trust side, there are a couple of private subnets (RFC1918) which are hidden behind DIP pools. Tests show that in 90 percent of the cases the IDP logging shows Src IP and Xlate Src both contain the IP-address out of the DIP group. But sometimes the log view correctly shows the private Src IP in addition to the DIP address! So in 10 percent of the cases private addresses do show up in the event log. Makes any sence?
09-06-2009 05:26 AM
I think this depends on the flow wing where the attack is detected.
If it's cient2server or server2client can make a difference on the IPs logged.
Can you check the logs and see if the IPs are depending on the direction of the flow where the attack is detected?
To make it more clear, I'm not talking about the direction of the session, but the direction of the flow where the attack has been detected...
Host A --------------------------------------------------
188.8.131.52 port 1025
We'll have 1 session with 2 flows:
184.108.40.206:1025 -> 220.127.116.11:80
18.104.22.168:80 -> 22.214.171.124:1025
In this case we can have an attack detected on the traffic sent by the client (client2server) or detected on the traffic sent by the server (server2client).
Take some log events and inspect them.
You can open the attack defnition and looking at the signature definition you should be able to see the direction inspected.
Let me know!
09-27-2009 05:27 AM
Thanks for the update. Our first findings suggest that address translation works fine on client2server sigs (server2client uknown) but fails on protocol anomalies. I'll have the results from more extensive tests in the next days.