This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

UTM 9 version 9.411-3, HTTP/S DROPPED packets are never dropped but are logged as DROPS.

EDITED: BLUF, Rulz #2 you will see that the UTM "services" such as Web Proxy, WAF, DNS, DHCP, etc all take precedence over the Network Firewall rules. If you need to restrict devices from using those ports and protocols, you must do 100% of that configuration in that specific section and not in the firewall rule base. The only thing I can think regarding the fact I was seeing firewall DROPS logged was that when the config was touched it may have invalidated the stateful inspection tables causing unknown established sessions to be rejected and causing a logged dropped packet.

 

I recently saw a host on my local network that seemed to be getting past the firewall rules and I was puzzled.

I have some rules that are setup as DROP rules and others as REJECT rules.

The drop rule was logging as "DROPPED" in RED, but I was pulling HTTP pages, pinging, traceroute, etc which should NOT be happening. With NEVER any issue getting past this rule which should be stopping all traffic! The rule is simple, SOURCE->(any protocol)->ANY, DROP, LOG.  It is like nothing is actually blocked.

So I moved the rule to the very top of the rule base (it was at #5 position before and all the rules above were switched off anyway). Same result. I also made sure I was seeing all the rules and not looking at a subset. I don't have any IP ANY ANY ALLOWs above this rule. (or anywhere else for that matter)

I changed the rule from a DROP to a REJECT. and BANG, now the rule is doing something different. It seems to be intermittently rejecting, and other times passing traffic.

I changed the IP address of the network object in the rule from the windows VM that was the original system I detected this activity on and switched it to another VM that is an Ubuntu server, statically configured, etc. I then did some WGET's for a domain that I have which is parked at GoDaddy and 50% of the time I would get:
2017-03-28 22:58:44 ERROR 503: Service Unavailable.
The other 50% of the time, I would get:
HTTP request sent, awaiting response... 200 OK
And the index.html file would be served up.

Same rule!, set to always fire with no time settings.
I have no load balancing settings. A simple inside interface and outside interface.

At this point, I don't trust this firewall to be dropping packets at all. I am concerned that perhaps the firewall has been compromised in some fashion.

Has anyone else seen this were a simple rule to DROP traffic shows in the LIVE LOG as "DROPPED" but the traffic is in fact passed?



This thread was automatically locked due to age.
  • Thanks, I just went in and set the options to SKIP TRANSPARENT mode for the test VM's.

    I set it to not allow HTTP/S for those listed (because this seemingly puts in an invisible PERMIT rule), and then went back to the firewall rule base.

    I removed the useless installation wizard entries at the bottom, and made sure no HTTP/S permits exist.

     

    Test VM is now seeing reject or drops as expected.

  • Great and glad it's working for you. You ain't the first and won't be the last on this one. Got the tee shirt myself.

    The UTM is a superb piece of kit when used correctly but it can fool some on the initial install due to the way it works compared to a bog standard firewall.

    We came from clustered Cisco 5510's to clustered SG310's and we are very happy with the outcome, albeit some slightly confusing bits at the start as you have found too.

    You'll probably find yourself in the web proxy part more than anything but as mentioned, it's worth devoting some time to it.

    If you have any forward facing web servers, I'd also advise on spending some time with the web application firewall (WAF) as that is very good too and offers very granular access compared to a traditional DNAT.