L4TM ignores additional Suspected Malware Addresses?

[johanssen]

Hi,

my WSA ignores additional suspected malware addresses when I connect via http to the website. Connections on Port 23 (telnet) to the host ARE detected.

In detail:
I recently activated L4TM. In the L4 Traffic Monitor overview I can see several ports and sites being monitored (or if I want also blocked) when recognized as malware.

L4TM is set to "monitor all ports".

For testing purpose I defined a normal website as an "additional Suspected Malware Address" in the Websecurity Manager under "Edit L4 Traffic Monitor" settings. I expected this website beeing monitored or blocked, when I try to access the site via http from a browser. But this DOES NOT happen. On the other hand, when I try a telnet connection to the same host, the WSA firewall correctly detects the IP as a malware address and notes or blocks the connection, this also shows up in traffic monitor log.

I tried both, entering the IP address or hostname, but the WSA ignores it when connecting via http.

Can somebody confirm this (wrong?) behaviour or is my understanding of L4 monitoring wrong?

[jowolfer]

Johanssen,

Your best bet is to file a support ticket to have this looked at deeper. There are a few things that could be going on.

Are you able to see in the trafmon logs, whether or not this HTTP traffic is noted or blocked?

If you are monitoring all ports (per your post) and you are not seeing any entries in the trafmon logs, I recommend verifying the location of the span port. Perhaps you're using WCCP or other policy based routing that uses an different patch to get out. This may be bypass your port monitor for HTTP traffic only.

[johanssen]

ok, I'll open a ticket.

BTW: if I set to monitor instead of block, I can see activity in the trafmon log file, like "Address 78.46.220.99 discovered for images2.mopo.de (images2.mopo.de) added to firewall blacklist. This is ok since I defined mopo.de as additional malware site. On the other hand I CANT see anything like "Firewall noted TCP data from 10.3.x.y.:1458 to 212.201.100.133(cdn1.eyewonder.com):80" These kind of entries I can see for other sites beeing automaticaly recognized and therefor logged. I would expect a similar entry for my additionaly defined malware site.
I do see entries in the normal aclog file when I connect to the mopo site. I do not use WCCP or any policy based routing. The L4TM is connected with a network tap, so no span/mirror port setting can cause the malfunction...

[jowolfer]

Johanssen,

The 'Discovered' messages are where we're we're seeing DNS responses and learning domains / IPs. This sounds like you might be sending only return traffic via your port monitor.

You need to make sure the you're sending bidirectional, since the L4TM is works off of the client's SYN and DNS responses.

[johanssen]

Hi Josh,

just to follow up:
I solved the problem, reason was my proxy port P1 being in the DMZ segment of my network whereas the monitoring port listened in another internal network segment (routed by a Cisco Pix).

The support line worked hard on the issue and they said, L4TM should also work in this case. But it simply does not.

Solution: proxy port P1 and T1/T2 MUST reside in the same subnet (if L4TM blocking mode is wanted. I know, RTFM... :-( The manual is misleading, because it says L4TM is independant from proxy and in explicit forward mode can be placed anywhere in the network.

The effects of this are really confusing and if someone runs into the same problems these are the symptoms:
1) additional malware sites are ignored from blocking (support said because the L4 TM does not dig into the packets. The destination address will always be the proxy interface and not the malicious site. The proxy afterwards opens the connection to the malicious site and on this connection the L4 TM does NOT listen...)

2) if there are clients that are configured to not use the proxy, the L4 TM can detect malicious connections. What is more confusing, the ironport reports successfull blocking (if configured like that), in fact this reporting is wrong. The firewall CANNOT block these connections (when traffic monitor and proxy are in different subnets) although it says it would do so...

I wonder if it is all because of NAT/PAT I'm using? Is it that unusual to place the proxy in the DMZ??

regards
Peter

[jowolfer]

johanssen,

Thank you for the details followup.

Yeah, the NAT is what messes things up. Since the T1 interface will pick up traffic on one side of the NAT and the P1 interface is on a segment on the other side of the NAT.

I've seen many different deployments. It is somewhat unusual to place the WSA in the DMZ, but not unheard of.

Typically web proxy devices are placed on the ingress side of the border firewall (pre DMZ).