Address translation in TAP mode

[soc46]

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?

Many thanks,
/Ola

[Daniele]

Hi Ola

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?

Ciao

Daniele

[soc46]

Hi Daniele

DIP is used to hide traffic behind a pool of addresses (in combination with PAT). We need the source IP-address in the IDP blade.

Thanks!

/Ola

[Daniele]

Ola,

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?

Ciao

Daniele

[soc46]

Hi Daniele,

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? 

Regards,

/Ola

[Daniele]

Hi Ola,

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...

Example:

Host A ------------------------------------------------------- Web Server

1.1.1.1 port 1025                                                     2.2.2.2 port 80

We'll have 1 session with 2 flows:

1.1.1.1:1025 -> 2.2.2.2:80

2.2.2.2:80 -> 1.1.1.1: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!

Ciao

Daniele

[soc46]

Hi Daniele,

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.

Regards,

/Ola