A Question about FireWall logging

Have a question or want to start a discussion? Post it! No Registration Necessary.  Now with pictures!

Threaded View
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?


Re: A Question about FireWall logging

Quoted text here. Click to load it

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 :)



Re: A Question about FireWall logging

Quoted text here. Click to load it

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.



Re: A Question about FireWall logging
On Wed, 29 Mar 2006, in the Usenet newsgroup comp.security.firewalls, in article

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Re: A Question about FireWall logging
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?


Re: A Question about FireWall logging

Quoted text here. Click to load it

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



Re: A Question about FireWall logging
On 29 Mar 2006, in the Usenet newsgroup comp.security.firewalls, in article
wrote:

Quoted text here. Click to load it

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

Re: A Question about FireWall logging
Moe Trin wrote:

Quoted text here. Click to load it

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.

Re: A Question about FireWall logging


Moe Trin wrote:

Quoted text here. Click to load it

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

Re: A Question about FireWall logging
On Wed, 29 Mar 2006, in the Usenet newsgroup comp.security.firewalls, in article


Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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?

Quoted text here. Click to load it

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


Re: A Question about FireWall logging

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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*????????????

Quoted text here. Click to load it

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 :)




Re: A Question about FireWall logging
On Wed, 29 Mar 2006, in the Usenet newsgroup comp.security.firewalls, in article

Quoted text here. Click to load it

If you blocked it - why are you seeing it?

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

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


Quoted text here. Click to load it

Because the log viewer I am using shows the traffic, if that's not a problem
for you.
Quoted text here. Click to load it

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.
Quoted text here. Click to load it

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



Re: A Question about FireWall logging

Quoted text here. Click to load it

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



Re: A Question about FireWall logging

Moe Trin wrote:
Quoted text here. Click to load it

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.


Re: A Question about FireWall logging

Quoted text here. Click to load it

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

<snip>

whatever comments

<snip>

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 :)



Re: A Question about FireWall logging
On 31 Mar 2006, in the Usenet newsgroup comp.security.firewalls, in article

Quoted text here. Click to load it

[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]

Quoted text here. Click to load it

I interpreted the above as being a perimeter firewall.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Site Timeline