A Question about FireWall logging

I would think the ability to get a total picture of all traffic hitting the FW that's being rejected. I particularly like to keep track or keep an eye on remote IP(s) the same IP coming at the FW numerous times and run analysis reporting on how many times the same IP is coming at the FW by day, week and month. I have not done it that often maybe 3 or 4 times that I have set a rule on my Watchguard that I denied specific IP(s) that were coming just a little to hard, even if the unsolicited traffic was being rejected by the FW. It's just me, but I don't like flying half blind and want to see all aspects of what's happening from time to time.

Duane :)

I'm in basic agreement although the volume of incoming denied traffic at some places makes it impractical to do for very long (ie, a gigabyte of log data every two or three hours). To some degree it doesn't matter because if it's dropped it's out of your hair but there are indeed useful bits of info to be gleaned from it. I like to log it, analyse it, then dump the raw data and keep the reports, when that infrastructure exists.

However sometimes dropped data that is *outbound* is very, very useful. In other words, what are your PC's doing that they shouldn't be? I find this data is almost always relavent, in places with a positive permit / default deny outbound model, which is my preferance.

-Russ.

It's useful when trying to debug a problem. User Jones says they can't connect to service $FOO on site $BAR, but they can connect to $FOO on $BAZ, or service $QUX on $BAR. Looking at 'deny/reject' logs may tell you what is wrong, and give a hint of how to fix it.

If you can actually do something productive with the data, this might be valid.

Your description is a little unclear, but the concept makes no sense. If the traffic is being blocked at the perimeter, who gives a flying what-ever. If it's _not_ being blocked at the perimeter, then "why not"?

Blocking a specific IP address??? Duane, as of the 15th, there were

2,257,589,720 _active_ IPv4 addresses in 72091 networks with 30853 routings. If you're aware of IPv6, there are another 1429 networks there. Even blocking individual networks is insane. "You're wearing blue shoes, brown pants, a green shirt and a red hat, so you can't come in". You _allow_ specific addresses/networks to specific service, and block, deny, reject the rest BY DEFAULT. Are you aware that there are 137 _other_ protocols besides TCP, UDP, and ICMP? I really doubt your firewall has a clue about IPComp (protocol 108 or 0x6c - per RFC2393) and rejects it by default - or did you put in a specific rule for that protocol?

Your firewall is blocking it - there are no Internet Police - and the packets are not causing you problems. Besides giving you something else to worry about - which might keep you from gaining weight, why else would you even care? Or do you really have that much extra time on your hands and are bored?

Old guy

A question is - why is it getting so far as to be logged? Why isn't it dropped at the perimeter?

Agreed, but that's a whole different bucket of tar. Much of the blocks are bi-directional. We (for example) don't allow connections to residential addresses, and a number of blocks that have been determined to be bad Internet neighbors. But as we are dealing with a relatively savvy set of users (who are not using windoze), we don't have that much in the way of problems. Our employees are aware of the policies and know that mis-use of the computers/networks/etc. will get frowny marks on their employment records.

Old guy

Dear Moe Trin, to make it clear, you think "In general, there is no need to enable full logging, most of the time accepted packet logging is enough". Am i right?

What you see as being of use and what I see as being of use is like night and day or day and night, whatever.

You want to drive my car for me too????????

Yeah, that's what I did. And what's any of this above have to do with anything if I see the same IP coming at a port or port(s) and I want to do it?

If I decide to block it I am going to set rule to do just that. If I want to block IP 999.999.999.999 I am going to do it. Don't be getting into all the protocol stuff with me as I know all about it. If I want to set a rule to block an IP even if it's being blocked by DEFAULT, that's my business.

What concern of it is it to *you*????????????

Look Old guy, I don't need you going off the deep end with your boxers in a bind about this. :)

You're out of line here chief.

Duane :)

Yes, that's all that's being said. Why Moe Trin needs to make some kind of Federal case out of it is questionalable???

Duane :).

Yup - the less work spent blocking, the better off you are. "The bad guy" isn't getting in - that particular battle is over. There is no Internet Police, and nothing else you can (or need to) do.

Some people think it's great to have two or more firewalls blocking an intrusion attempt "in case the first one fails". I fail to see any reason to do so, as a proper firewall should not fail, and in the unlikly event that it does, it should fail in the 'block' mode. If it doesn't fail in that mode, it should never be installed in the first place..

Old guy

If you blocked it - why are you seeing it?

No Duane, I don't think you do know.

True - but don't expect everyone to have to block a /8 and a /9 within that, and a /10 within that, on up to a /32. If the range is blocked, it's blocked and adding the same block over and over is an example of not understanding what is going on. Or, you're using a toy that doesn't do the job..

Old guy

After all a firewall is a security concept and host/client security configuration is an essential part of it. So, your concept should involve that even if the firewall fails, in terms of permitting traffic flow, you system shouldn't be in danger.

----- Original Message ----- From: "Moe Trin" Newsgroups: comp.security.firewalls Sent: Wednesday, March 29, 2006 8:59 PM Subject: Re: A Question about FireWall logging

Because the log viewer I am using shows the traffic, if that's not a problem for you.

Oh, like some kind of protocols needs some kind of rocket scientist like you to figure it. Hell, I have been the IT field since 1971 -- Operations, Network, Tech Support, Computer Programmer etc, etc.

Do you actually think that you're the only one that can interpret or understand something?

You need to get out of my face with this Old One.

Look Old man, who did anything over and over?

I should *dog* you about this but I won't

The only reason that's stopping me is that I got a minuscule amount of respect for you.

Duane

One other thing here old man, I am using a FW appliance that can set protocol numbers in the rules, if I choose to do then I can do it. Again, it doesn't take a rocket scientist to figure things out.

And you need to get off your high horse, as I will take you off that horse.

Duane

Logging blocks at the perimeter can be useful for research purposes - for example a spike in probes to a specific port may indicate a zero-day exploit is being developed.

In general I agree one is best served by minimising resources expended to attenuate Internet noise - however the OP did not stipulate that his question pertained to a perimeter firewall. Internal "bad guys" need to be tracked down and dealt with, so logging configuration of internal firewalls is an entirely different matter.

Triffid

Moe was originaly responding to the OP. IIRC, the original question was whether or not to log rejects as well as accepts on a firewall.

Moe:

The OP never stated that this was not a perimeter firewall BTW

In any case, from a standpoint of protecting 'my' perimeter Moe is right, if it is blocked, it will not cause me any headaches so I probably do not need to log it. However, it may be useful to log some forms of rejects just to keep track of what is out there. DSHIELD works by having people send them their firewall logs so events can be correlated across multiple organizations to determine active attack patterns. It is also useful to log rejects to see for ourselves what is going on out there.

There are certain classes of logs that you do not need to log, such as Microsoft netbios traffic and inbound SQL. This type of traffic is so massive that it can affect FW performance to log it.

Then he should have done the right thing and inticated it was coming from somewhere else in a thread

whatever comments

And not inline which is what he did with no indication that it was coming from somewhere else in the thread.

I am not into reading someone's mind or reading every post in a thread.

Duane :)

[quote]

In our company, we enable only the ACCEPTED packet logging (cisco firewall) ? I wonder the advantage of deny or rejected pakets logging also i.e. (full logging). Any idea ? What type of analysis can be done at that time?

[\\quote]

I interpreted the above as being a perimeter firewall.

As mentioned in the response to Russ, we to monitor the _outbound_ stuff, just to make sure policy isn't being violated. Inbound rejects are ignored unless there is a reported problem.

Prohibited by company policies. At home, I rarely bother wasting CPU cycles or RAM logging stuff - it's only a clapped out 386SX, and doesn't have all at much attention anyway because I offer _no_ network services to the public.

Hit the nail on the head there. I don't run windoze, so crap that is targeting windoze is absolutely of no interest to me. I see enough of the skript kiddiez and zombies knocking on the SSH port that I had to move my server to a less commonly probed port, and finally to switch over to a port-knocking scheme.

Old guy