Kurt Mahan wrote:
> I'm looking for some advice/suggestions/pointers.
> 
> Currently I'm running m0n0wall 1.23 on a WRAP 3 port board.  It works great!

Good combination. I use m0n0 on 3-port WRAPS and have ZERO issues with
any of them.

> The DMZ is configured according to the faq article.  All my external facing
> services live in there.  No need to talk to the LAN.

Excellent.  But remember, machines on the LAN also have no need to pass
any packets to the servers on the DMZ - except for packets destined to
the specific servers and ports where a service is provided and allowed
for the LAN clients to use. eg: LAN clients might be allowed access to
TCP port 25 (SMTP) on the email server on the DMZ, but not UDP port 53
(DNS) or any others for that matter. :)

> The default LAN setting is working but it allows everything to exit the
> firewall.

I do not agree with this one aspect of m0n0wall. I believe that
everything must be denied by default and the firewall admin must build
from there.

> Several articles I've read suggest restricting outgoing packets
> from the LAN to prevent viruses and such from contacting their mothership.  
> My LAN has a mix of Linux and Windows boxen.  Any suggestions/examples of
> LAN rulesets?  Any popular ports used by viruses to close?
> 
> I didn't see a FAQ article covering this.
> 
> Thanks!
> 
> Kurt

Hi Kurt. I think Chris said this already, but your firewall policy
should always be to deny that which is not explicitly allowed. This
includes traffic from your internal LAN.

In other words, when setting up a m0n0wall I first delete the "allow all
from the LAN to anywhere on all ports rule". In my opinion, someone
(Chris maybe?? :) should suggest to Manual that this should be the new
default to consider.

After all, "deny everything" is the default rule on the WAN and any
other OPT interfaces that get created, and the LAN should be treated no
differently - perhaps even MORE suspiciously. [IMHO]

Next, set up the logging on m0n0wall (Diagnostics -> Logs -> Settings)
and enable the "Log packets handled by the default rule" option.

I log to a remote syslog host whenever possible. For this, you will need
a syslog server configured to accept packets from remote machines. This
way you can tail a live log of blocked packets. Otherwise you can just
click the "Firewall" tab on the logs page of m0n0wall each time you need
to get an update. (enabling the "Show entries in reverse order will help
in the latter case)

Now watch for a little while and you will be amazed at the sheer amount
of machines and packets from these machines that are now blocked which
would normally just be passed.

As you are watching, open a new tab in your browser and add rules to
your LAN interface to explicitly allow only what you decide should be
allowed. This will depend on your specific system, network and security
needs - and only you can make the right decision for each.

For instance, I see someone posted some sample rules in this thread
which include allowing all DNS, NTP, SMTP and ICMP requests out from the
LAN. In my configurations, DNS requests are only allowed outbound from
an internal DNS server which all the internal clients must use. NTP
requests are allowed from the internal NTP timeserver(s) which all the
clients and/or servers are configured to use. SMTP outbound is only
allowed from my mail server(s) - usually on a DMZ network - which all
internal clients must sent their email through. And ICMP outbound is
generally allowed from a management workstation and possibly a server or
two since client machines don't require that to function.

[IMHO] Even port 80 and 443 are best allowed out ONLY from a proxy
server like a Dans Guardian/Squid combination with authentication
enabled. Since port 80 is practically always wide open by default, it
can almost always be exploited as a back-channel from infected machines
and an authenticating proxy can help mitigate some security issues.

Wanna test? With all outbound traffic denied (you will need dns allowed
and working first though), start up your AIM client and watch what it
does... after failing to connect on port 5190, and 5109 and a few others
guess what it tries next?  yup... you guessed it - port 80.


Why so parinoid? Well, I think Chris said it pretty well: "If you permit
anything, you're not secure. Or potentially not secure."


For example (true story): Just yesterday I set up a new AXIS 207 IP
camera for testing. This thing is set up default to get its NTP time
from SomeTimeHost.axis.com, and to set up dynamic dns at
SomeDynDnsServer.axis.com.

In my opinion this is ROGUE traffic and is not allowed. I see no need
to help a company track me and their products, they already have my
money, that should be enough. Some may call me silly - but I still am
not going to allow this camera to phone home. BTW, It's on its own
"Camera" VLAN now with only the default deny rule. :)

On a more serious, less tinfoil-hat-paranoid note, the first thing an
infected Windows machine will do in many cases is call out to an IRC
channel to link up to the person/people/botnet that now _OWNS_ your
machine to ask for its instructions. If your firewall is set to allow
all outbound traffic then your firewall is now useless. You have an
intruder on the INSIDE of your network that would not have gotten there
if all outbound traffic were not allowed by default.


Now, after watching all the denied packets and researching which ports
are typically used for what services, surely your interest will be
piqued and you will want to know things like:

"Gee, why is my printer asking the DNS servers for the IP address of HP.com"

or

"Gee why is my wireless access point asking netgear.com for the time?"

or (and I just saw this at a new client's site whose network needed
fumigation)

"Why is my Microsoft SQL server sending SYN packets to random addresses
all over the Internet?"

and last but not least "should I be allowing these things".

At which point you'll soon be grabbing a hub and a laptop running
wireshark and plugging them into the firewall to see "...what the heck
is in these packets that my firewall is blocking?"

Congratulations. You've taken the first steps towards
paranoi^H^H^H^H^H^H^Network Security. :)


Remember "Security is a journey not a destination."


Enjoy!

:)


--
Bill Arlofski
Reverse Polarity
waa dash m0n0 at revpol dot com