Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

"Acceptable" number of firewall drops

Status
Not open for further replies.

garion42

IS-IT--Management
Jun 15, 2005
29
DE
Hi All!

Can someone give me some guide´lines as to what is an "acceptable" number/percentage of firewall drops? For example, we have one firewall with over 2 million packets a day. On a bad day we see less than 50 drops, spread across serveral machines. Sometimes there are several drops between maschine with given destination port. Usually, there are just single drops between machines.

My boss insists that we should get the drops down to zero. Every drop has a cause and we just need to find the cause. Although I agree that there is a cause and theoretically one could be able to find it. However, there are any number of things that could cause a drop. It could be something as mundane as a cable that wiggle each time someone walks past the server and one time in ten causes a drop between random machines. To me tracking down something like that is ludicrous.

Any input appreciated.


 
First off that is a very general question and is really only one that you can answer. here are some questions that you need to answer yourself.

* Do you log all rules? or only rules that should be accepted or encrypted.
* Are the dropped packets should be dropped or are the dropped packets ones that should be accepted/encrypted. By this I mean, if a device from a public IP is attempting to access your public webserver using SSH/telnet and it should't be I wouldn't open it up to pls what the Boss say.

I agree with his statement "Every drop has a cause and we just need to find the cause" however it could be someone scanning your network, virus/worms talking to whoever will listen. You want these dropped, but you can explain them. Also if you are running Windows device and you need you XP PC to talk to your W2003 IIS server using only HTTP(S) then you'll see drops on a lot of NBT(netbios) traffic, this too is acceptable.

What I would say to you is Understand your rulebase, and the traffic that passes through it. The job of a FW is to drop everything except what you want to let through. With that being said, if all rules are logging then you should have a lot of drops, but with no applications/services being broken by it.

good luck
 
one more example I meant to add, you should have a stealth rule(blocks traffic from access the FW directly) if this rule is being logged you should see tons of drops. You dont want the average user or Jonny Hacker being able to Http(s), telnet or in anymeans talk to your FW directly. The only thing you want talking to your FW is devices you've specifed on ports you've specified.

good luck
 
We are logging all of the packets and reporting only the drops. All of the drops being reported are to/from machines other than the firewall. As I said, even on a bad day there are less than 50 drops.

Admittedly, I did not consider that aspect about packets "that should be accepted/encrypted". Obviously, if they "should" be accepted and aren't, the packet might be corrupt, an ACK to a packet that was lost or something similar. Those we can ignore.

Telnet attempts to a webserver are obviously something that should not be occuring at all. From what I can tell, there are no drops along those lines. For the most part, the services in question are defined objects in the firewall so they have "real" names and not just the post number. However, I will check to make sure that the communication to/from is the same is supposed to happen.

Your comment "if all rules are logging then you should have a lot of drops" doesn't seem quite logical to me, at least not in our environment. On public networks, there is likely to be a lot of script kiddies trying all sorts of things. In this case, we are ignoring the drops on the external systems for the most part. The < 50 drops I said we are seeing are all within our internal net segments.
 
You know your environment, I do not. In my environment, If a PC only needs HTTP(s) access to a webserver in the DMZ that's all it gets. Since we have a prodominantly windows network at the PC/Server level. I see alot of drops, however it's expected behavior.

I guess what I'm saying is no one can say to you that you should only get 1 or 1000000 drops per day. It depends on a variety of factors, size of the network, number of firewalls, strictness of security policies etc. I think what you need to do is look at why there being dropped. Is the deny all rule at the bottem of your rulebase? Is it going out the correct rule but there's an error message ie out of state? In valid SA's or Incorrect NATing. My personal opion is that if your seeing alot of drops, but based on your policy they should be and there's no business or technical reason for those devices to talk on that TCP/UDP port, then there is nothing to correct. Hoever, if the drops should not be occuring ie. an application port should allowed but not, invalid SAs, incorrect NATing etc these are the issues that need to be investigated.

In my environment, it's normal to see a few 'out of state' error messages for example 1 every 5 or 10 minutes. It could be someone logged into a application walked away from their PC came back 10 minutes later filled out the form and state was lost. However, if I see alot/constant stream of these error messages then I know there's an issue.

good luck
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top