Re: iptables configuration

From: Natman (natmanz@home.com)
Date: 12/11/01


From: "Natman" <natmanz@home.com>
Date: Tue, 11 Dec 2001 16:41:57 GMT


"Ian Jones" <ian@dsl081-056-052.sfo1.dsl.speakeasy.net> wrote in message
news:m31yi27dey.fsf@mobile.lan...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> "Natman" <natmanz@home.com> writes:
>
> > I have a few questions to Ian...
> [...]
>
> I am honored. But just because I am loud do not assume that I am also
> knowledgeable :)

True enough, but the more input someone gets, the better decisions they can
make. (and that someone = me)

[cut]
> >
> > I do this too. What other options are there? My clients on the LAN run
> > everything from basic web/email to mIRC, Morpheus, and some games. I
know
> > that if a 'virus/trojan' initiated a connection to the net, the firewall
> > would not protect the LAN. Is there some better way to make sure that
only
> > 'authorized' connections are allowed?
>
> Well, to answer that you need to be specific about what exactly
constitutes
> "authorized" traffic on _your_ network. If this is work, management
> may have an opinion on what is acceptable. If you use a proxy do you
> want to allow direct ->tcp/80 connections also? Is mail collected
> off-site? Are protected hosts using NAT?

The LAN is NATed with private IPs to one public IP. I don't proxy http,
ftp, mail traffic (except running SOCKS for those really nasty programs like
ICQ). Since I only have one computer available to run as a 'server' for
everything I use, the one computer has to be both a firewall and provides
services both to the LAN and to the inet. The firewall runs services for
the inet such as (I took the names from my services file): imaps, pop3s,
www, auth (a self-made script), domain (dns), ftp, ssh, smtp (NOT sendmail),
https. There are a few others that are for the LAN only, and have been
blocked off VIA iptables (or sometimes by proper bindings). I know that
this is generally not a good idea, in case one of the services gets
exploited, but I have little choice (other than just giving up the ability
to run these things). One way of improving security might be to just limit
the ports that are used by services running on linux. Is it possible to
just reduce this window to something like 1000 ports allowed in and 1000
ports allowed out? I have also heard about the ability to match packets
based on what process they came from. Have you (or anyone else) tried this?

>
> My point earlier was that you should at least know if you are not
> filtering anything. If that is what you want, no problem.
>

Right, but that isn't necessarily what I want. Ideally, I want to be able
to allow stuff (web, mail, IRC, Morpheus, ICQ, games), and anything that
isn't within that list should be droped. One of my motivators for writing
this is that I've noticed lately that a windoze box sends out requests to M$
when the box is idle (a sniff of the traffic shows that it is HTTP traffic
which seems harmless, but it still shouldn't do that). Other possibilities
like Nimda come to mind. Even though I have virus scanners, doesn't mean
that a new virus will be caught in time. Anyways, the problem is that how
do you know what ports things will be running on? Like will web always have
a dst port of 80? Or is it possible that the port may change after the
initial syn is sent? If so, will NAT be able to see that the port has
changed and continue to allow the connection (because of the state match)?
When I started with my linux firewall (way back when RH6.2 was the latest),
I started out by leaving everything mostly open, and as my experience grew,
I started closing from there. Again, not the best idea, but at least it was
always 'better than nothing'. Now I feel that I'm to the point where I'm
secure from casual script kiddies, but if someone really, really wanted to
exploit the box, then they could. Plus, I'm always curious on how to step
up security a bit more, as it is a good learning experience.

> For example, here is a noisy NT 4.0 box (initial ttl 128) trying to
> browse it's /24 for PCAnywhere because the luser at the helm refuses
> to turn off this "feature":
>
[cut]

> This guy could use some egress filtering and if he was behind a
> forward-with-abandon firewall than anyone who cared to look could
> target the system using the appropriate exploits. Every time this
> joker reboots (which is often) he drops his pants and waggles like
> this.
>
> [...]
>
> > My OUTPUT chain contains accepts (basically) everything too. The only
> > exception is known bad IPs. What should I be blocking here? I run DNS,
> > HTTP, FTP, SSH, etc to the net, so I think I can't really block much...
any
> > specifics?
>
> Once again, without clearly defining what you would consider to be
> authorized, acceptable traffic it is impossible to answer. Personally,
> I see no need to accept *any* ICMP queries (those begging a response)
> and I see no reason to allow outgoing ICMP port unreachables or
> TCP-reset because this is just info-leakage that does not help you. In
> an ideal world, you will allow absolutely nothing on the OUTPUT chain
> of your firewall that is destined for the external interface. If your
> services are all run from DMZ or protected hosts there is no reason
> for the firewall/router to accept any external traffic in INPUT or
> OUTPUT of the filter table.

Before I fire up google and start searching, do you have any specifics (ie
what to put in my script) for blocking ICMP queries and TCP-reset? Any
sites that have info on this? I'm not fimiliar with all of the different
ICMP types and their consequences (although I do about 'ping'). I also
did't know that TCP-reset is a problem.

Ya, I also know about the ideal world... but now you know the limitations
that I metioned above because I [want / need] to run those services, so I
have to allow [something] to pass through the INPUT/OUTPUT tables.

>
> Start with DROP all from everywhere and work from there until you
> achieve acceptable connectivity. Every rule you insert above DROP
> should be as specific as possible in terms of port/protocol and
> especially interface. You may find that you really don't need all that
> you thought you did, and you can always set up methods of allowing
> things that you need only occasionally by using temporary changes to
> the rule set.

I think I may get brave and try that. When I have some spare time (which
will be soon), I should watch what typically happens (port-wise) for the
services which I run, and then start building an ACCEPT list... once I've
done that, then I can test my list by doing what you said.

>
> BTW, why are you wasting your time with certain IP addresses? I used
> to think there was some value in this too, but it is just not so. If
> you establish a trust relationship based on a source address then that
> can be exploited. Blocking from "bad guys" is just useless because
> there is no such thing as doubly dropped. If your "bad guy list" is
> dynamically created you are an easy DoS target.

Some IPs just annoy me :). One day I just got sick of seeing logs full of
'this IP tried to do this' (whether it be Nimda hits, or someone trying
logon to FTP with an invalid username), so I just build a deny list. Then I
got tired of doing it manually, so I wrote some scripts to add IPs
dynamically. It seems to work okay. Of course, I watch the list daily and
randomly check to see if an IP that has been blocked really did meet the
criteria. Since I'm not a major ISP or anything, I think that if someone
did use this to deny legit people, I think it would be okay, as long as I
keep checking the list daily. I set it up so that all of the 'bad list' is
acually a seperate table which is referenced in the INPUT table. This way I
can (and will, if needed) just flush the list, everything will be reset. I
honestly think that (for me) this is the best thing to do, short of just
denying all 24.x.x.x IPs -- which I read that someone else did on his/her
webpage quite a while ago. Also, ff they really do continually attempt to
attack me, then they deserve to be ex-communicated.

btw, thanks for the input.

Natman

[PGP sigs cut]



Relevant Pages

  • Re: How to stealth against ping/echo requests?
    ... I just started using the Online-Armor firewall. ... Some ports are even open. ... Are you behind a router? ... Every time it founds a new LAN, it asks if you want to trust it ...
    (comp.security.firewalls)
  • Re: block_ssh_guessers
    ... True but then, how fat is the pipe, compared to firewall device. ... the knocking host tries ports OTHER THAN the expected ones in the sequence ... checking the IPs being spoofed. ... We pay a bandwidth fee, ...
    (comp.os.linux.security)
  • Re: Problems with IP forwarding
    ... > firewall, and beyond to the web] and am having trouble with IP ... I'm not sure why you are running public IPs into/through your lan. ... you will need a router at the other end or hosts ...
    (comp.os.linux.networking)
  • Re: How do I use IPSEC to create a basic firewall.
    ... Ipsec is best used to manage/protect traffic for the lan. ... > secure domain controllers by IPSEC, thus providing a basic firewall ... > response ports opened by connections going to the WAN. ...
    (microsoft.public.win2000.security)
  • Re: Should a firewall ONLY allow access to an IP range - as well as blocking ports?
    ... >We do have a firewall but it is set up to let all IPs access the open ... >access on ports we use to administer the server to an IP range only? ... developed a firewall ruleset to block access to those. ...
    (comp.security.misc)