Chris,

Yeah, as far as the blocking, that's what I was getting at...like an
implicit rule not listed in the gui.  As far as the blocking rules, I
was hoping that implementing those would help.

Also, for the infected users, that is exactly what I do.  Except I know
where they live, so I have an RA run the tool up to them!

Thanks for the input.  I'll try the blocking rules and see if that
helps.  Those are good ports to block anyway.  I block them on every
other firewall; I don't know why I haven't here other than sheer
laziness.


-Bryan

-----Original Message-----
From: Chris Bagnall [mailto:m0n0wall at minotaur dot cc]
Sent: Wednesday, September 01, 2004 3:40 AM
To: m0n0wall at lists dot m0n0 dot ch
Subject: RE: [m0n0wall] m0n0 stops accepting new connections

> Curiously, before the virus-laden ports were shut down, the
> firewall showed several blocked packets originating from the
> LAN and outgoing to the internet on TCP port 445.  I have NOT
> blocked that port outgoing.  Is it blocked by the default
> rule perhaps?  I wish I had kept the logs, because now those
> blocks aren't showing.

To the best of my knowledge it isn't blocked by default. Perhaps m0n0
blocks
NetBIOS to itself by default since it knows it doesn't use it for
anything
personally?

Your problem sounds very much like the NAT table is filling up with
these
brief connection attempts that don't close themselves properly. What I
tend
to do is to define 3 rules on all my interfaces to block netbios
silently.
The ports to block are 135, 137-139 and 445. I've gone with TCP/UDP, but
I
think it's only 139 that actually uses UDP, the rest are TCP.

That'll prevent m0n0 from wasting CPU cycles logging the damn things and
will also prevent m0n0 from creating NAT entries for them.  Hopefully
that'll solve your problem. The only downside here is if you have 2 LAN
interfaces (perhaps a wireless?) and you want to allow netbios between
them.
In that circumstance, you'd want to use the "not" option in the
destination.

In all honesty the best approach would be to disconnect the offending
users
at the switch and wait for them to complain. When they do, inform them
of
the deplorable state of affairs and give 'em a CD with a removal tool.
They're freely available online for most common viruses. That'd do both
you
and the offending users a favour (since at the moment they run the risk
of
infecting others on the LAN interface).

Regards,

Chris
--
C.M. Bagnall, Partner, Minotaur
Tel: (07010) 710715   Mobile: (07811) 332969
ICQ: 13350579   AIM: MinotaurUK   MSN: minotauruk at hotmail dot com   Y!:
Minotaur_Chris
This email is made from 100% recycled electrons


---------------------------------------------------------------------
To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch






________________________________

avast! Antivirus <http://www.avast.com> : Outbound message clean. 

Virus Database (VPS): 0436-0, 08/31/2004
Tested on: 9/1/2004 7:11:01 AM
avast! - copyright (c) 2000-2004 ALWIL Software.