Text 7697, 147 rader
Skriven 2006-10-23 17:51:00 av Paul Rogers (1:105/360.0)
     Kommentar till en text av Martin Atkins
Ärende: Latest firewall script
==============================
 MA> If the statefull side of your table is working then it might be better
 MA> to leave it alone. After all it's not ugly.

I thought you said it was.

 PR>>   LOOPBACK="127.0.0.0/8"
 MA> Yea but it adds to the complexity of the script. No offense meant
 MA> but KISS allows you to quickly read a table and identify any anomalies.

What's hard about a CIDR like that?  "127.anything", that's simple.

KISS isn't an issue.  Security is.  The way I try to make it
"easy" to identify anomalies is by using lots of obvious
patterns.

 MA> Your knowledge of networking far exceeds mine so be forgiving if

I don't ever give that a thought, because the attackers out there
far exceed me!  If I ever thought "I finally got it," I'd be
exposing myself to the next trick.

 MA> i seem nieve but:-
 MA> iptables -A INPUT  -p tcp --sport $EPHEM --dport $EPHEM -m state
 MA> --state ESTABLISHED,RELATED -j ACCEPT
 MA> iptables -A OUTPUT -p tcp --sport $EPHEM --dport $EPHEM -m state
 MA> --state ESTABLISHED,RELATED -j ACCEPT

 MA> Here you are accepting $EPHEM (1024:65535) under established rules so
 MA> these two definitions are not neccasary. Unless of course traceroute
 MA> doesn't comply with the above rules.

It doesn't allow a NEW connection, so I couldn't start a
traceroute.  I wouldn't even consider allowing a NEW connection
from any port to any port.  Sayonara, security!

These rules are required by FTP.  It's unfortunate, but FTP
doesn't play well with firewalls.  Seems strange the TCP/IP
protocols designed for the ARPANET didn't have better security,
but we'll have to wait for the changeover to IPv6, I guess.

 PR>>   TR_SRC_PORTS="32769:65535"
 PR>>   TR_DEST_PORTS="33434:33523"
 MA> You will need try and explian if you will why traceroute needs it's

That was from the original source.  It was something that didn't
seem to be broke, so I left it.

 MA> own rules. Also notice that if the output policy was ACCEPT then
 MA> the second line of the tcp rule is redundant.

We've got different goals.  I'm not trying to minimize the number
of rules.  Rather than fewer broad rules, I want narrow rules, as
many as I need.

I see firewalls that aren't concerned with what goes out.  But
that not only lets a malicious webpage set something up, but it
lets anything that did infect my workstation to attack any port
on any other computer on my LAN.  Lots of web sites use ports 81
or 8080 for certain benign services, but I can't be sure WHAT
might be going on with some side-channel like that, so I
explicitly drop those.  Maybe something benign won't work.  I
accept that.  But at the top of my script I warn it's "tight".
If you don't want a tight firewall, it isn't for you.

 PR>>   LOCAL_NET=$BASEIP.0/24
 MA>> This doesn't make sense to me. $BASEIP has not been defined in this
 MA>> script nor has $network_devices/ifconfig.eth0$network_devices
 MA>> /ifconfig.eth0
 PR> It is on my LFS systems.  It's there as part of my installation
 MA> Hmm I don't "think" it belongs in the firewall script. I'm at a

What belongs?  You think I should define LOCAL_NET in
ifconfig.eth0?  I suppose one could do it that way.  I think
just the network root, the first 3 octets, is more versatile.

 MA> disadvantage here as LFS is forign to me. Normaly these things
 MA> are done in /etc/rc.d/init.d or /etc/xinetd.d but even if i'm
 MA> wrong it looks to me an ugly iplimtation of what you are trying to
 MA> achieve.

init.d/firewall saves & restores--init isn't the place to have
any glitches.  I put the script posted here in /usr/local/sbin/firewall.

 MA> Nooo it's the wrong way of doing it and it is not just my opinion.
 MA> I subscribe to the netfilter list and time and time again those with
 MA> greater knowledge than i (just about everyone) say that filtering
 MA> on the output policy is seldom if ever needed.

They may not consider it necessary, I do.  The motto of LFS is:
"Your distro, your rules."  Obviously I think output filtering
IS necessary.  I've got an OUTPUT rule for virtually every INPUT
rule.  And it's not causing me problems.

 MA> By filtering on the input policy (DROP) you are affectivly dealing
 MA> with situations before they hit the rest of the chain. This saves

Not necessarily.  People can get tricked into inviting malware
in.  The packets they come in on can pass filtering.  They may
come in by other means.  Just filtering the INPUT chain isn't
enough, IMO.  I filter the OUTPUT chain so that it doesn't get
in MY way, but gets in the way of everything else.

 MA> Yes but do you think anyone can make an informed comment on you script
 MA> when they have to deal with externel definitions on your machine?

It isn't clear what $IP means?  Would $MY_IP_ADDR be better?
That means changing several other scripts, but I'll consider
it.  Maybe a comment here will help.

 MA> Your IP address is the etho card (or what ever) that links your machine
 MA> to the network. It is not the loopback address.

Hello?  You may not have run into it yet, but I had packets
being dropped because I also thought only 127.0.0.0/8 addresses
ever used the loopback interface.  Packets addressed with the IP
address will also appear on the loopback!  (I didn't make it a
point to remember which service did it after I found it and
fixed it.)

 MA> Ah yes. The old "if it ain't broke don't fix it" philosophy. I

Yeah, it's sorta like the KISS philosophy.  ;-)

 MA> well crafted script is a pleasure when achieved and a wonder for others

It's got to please me.  This is open-source--others can change
it to satisfy themselves, and will.

 MA> iptables -L -v
 MA> This is an after thought from my last message. If run from a terminal
 MA> it will give you a better output.

Not unless there is a network connection at the time.  If not
then -L hangs until it times out, and it still only reports the
numeric addresses.  -L -n doesn't delay.  I only have a network
connection when I need to use it.  It goes through another
computer that isn't always on.

Paul Rogers, paulgrogers@yahoo.com                       -o)
http://www.angelfire.com/or/paulrogers                   /\\
Rogers' Second Law: Everything you do communicates.     _\_V

...   Oh, give me a phone, with a modem on loan..  
___ MultiMail/MS-DOS v0.35

---
 * Origin: The Bare Bones BBS (1:105/360)