Text 7686, 205 rader
Skriven 2006-10-24 00:24:00 av MARTIN ATKINS (1:123/140)
     Kommentar till en text av PAUL ROGERS
Ärende: Latest firewall script
==============================
-=> PAUL ROGERS wrote to MARTIN ATKINS <=-

 PR>   NAMESERVER_2=209.102.124.15  # change as necessary
 MA> Fair enough if your local net is routing you to the outside world.

 PR> Actually, I guess I could change that to the router's address.
 PR> Bering provides a DNS relay with its firewall/router.  But it
 PR> goes to those same addresses.  I don't use a local DNS, all
 PR> static in /etc/hosts.

If the statefull side of your table is working then it might be better
to leave it alone. After all it's not ugly.

 MA> Nameservers are not my strong point as i only have a small home network
 MA> and the other machines routed to the outside world yet.

 PR> Those are DNS servers provided by my ISP.

Ok that reinforces my above view.

 PR>   LOOPBACK="127.0.0.0/8"
 MA> Why define loopback this way? Loopback is for testing your own machine

 PR> That was how the original parts I borrowed from James Stephens
 PR> defined it--didn't see any overwhelming reason to change it.

 MA> and normally will only be 127.0.0.0. Iptables accepts "lo" and so
 MA> _normally_ does not require defining.

 PR> Right.  "Normally".  But IIANM all of 127 is defined as
 PR> loopback, and IIRC I've seen 127.0.0.1 used also.  This gets the
 PR> whole range.

Yea but it adds to the complexity of the script. No offense meant
but KISS allows you to quickly read a table and identify any anomalies. 

$IPTABLES -A INPUT -i lo -j ACCEPT

This should do what you want and do away with three lines of script
and one definition. Nice. ;)

 PR>   CLASS_A="10.0.0.0/8"
 PR>   CLASS_B="172.16.0.0/12"
 PR>   CLASS_C="192.168.0.0/16"
 PR>   CLASS_D_MULTICAST="224.0.0.0/4"
 PR>   CLASS_E_RESERVED_NET="240.0.0.0/5"

 MA> None of these are necessary. Since INPUT policy is DROP they never
 MA> get through.

 PR> They do.  I get probes from Class-C addresses coming from other
 PR> users on the ISP's routers frequently--some of the other
 PR> customers aren't clean.  (And they may not even know.)
 PR> Depending on how the ISP configures itself, I suppose I could
 PR> get any of the RFC1419 addresses.  I'd rather have the check
 PR> than not.

Doh' Silly me. Yes of course you are filtering on the ports and
not Ip's.

 PR>   EPHEM="1024:65535"   # ephemeral ports
 MA> If as /proc/sys/net/ipv4/ip_local_port_range or what is appropriate
 MA> for your distro.

 PR> I have some checks in it that might not be necessary, e.g.
 PR> fragments, depending on how the kernel parameters are set.  I
 PR> know some set those as part of the firewall setup.  I chose to
 PR> keep the two separate and dedicate this script to just the
 PR> iptables setup.  I'd rather waste a small amount of time having
 PR> the firewall check, in case kernel checking gets turned off.

Waaay over my head. ;)

 PR>   TR_SRC_PORTS="32769:65535"
 PR>   TR_DEST_PORTS="33434:33523"
 MA> This is a worry. $EPHEM is now defined so these ports are as far as i
 MA> know safe. There may be some reason for defining these ports but it is
 MA> not  obvious from this script

 PR> They're used later on to allow traceroutes.

Your knowledge of networking far exceeds mine so be forgiving if
i seem nieve but:-

iptables -A INPUT  -p tcp --sport $EPHEM --dport $EPHEM -m state --state
ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp --sport $EPHEM --dport $EPHEM -m state --state
ESTABLISHED,RELATED -j ACCEPT 

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

 PR>   TR_SRC_PORTS="32769:65535"
 PR>   TR_DEST_PORTS="33434:33523"

You will need try and explian if you will why traceroute needs it's
own rules. Also notice that if the output policy was ACCEPT then
the second line of the tcp rule is redundant.

 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
 PR> process.  It asks once for a base-IP, then just the LAN node
 PR> numbers for the workstation, the server, the router.  Saves
 PR> typing, or more properly mistyping.

Hmm I don't "think" it belongs in the firewall script. I'm at a 
disadvantage here as LFS is forign to me. Normaly these things
are done in /etc/rc.d/init.d or /etc/xinetd.d but even if i'm
wrong it looks to me an ugly iplimtation of what you are trying to 
achieve.  

 PR>   iptables -P FORWARD DROP
 PR>   iptables -P OUTPUT DROP
 MA> Unless you are intending to block yourself or a terminal on your

 PR> Making the default policy DROP makes sure nothing gets through
 PR> while I'm allowing things.  It's the right way to do it, even
 PR> since I start the firewall before I bring up eth0.  But some
 PR> distros aren't that careful, RHL[6,7] IIANM.

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

MA> network from the communicating with the outside world then:-
MA> iptables -P OUTPUT ACCEPT
MA> Even if you do intend to restrict output from certain terminals there
MA> are better ways of doing it.

 PR> Better in what sense?

By filtering on the input policy (DROP) you are affectivly dealing
with situations before they hit the rest of the chain. This saves
a lot of uneccassary scripting as i have shown you on two accasions.

 PR>   iptables -A INPUT  -i lo -s $IP -j ACCEPT
 PR>   iptables -A OUTPUT -o lo -d $IP -j ACCEPT
 MA> As far as i can see $IP has not been defined in this script. Even if

 PR> Remember those sourced files?  If yours isn't defined there you
 PR> could define it anywhere you like.

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

 MA> it was $IP cannot under normal circumstances request "lo" on a remote
 MA> machine.

 PR> I didn't think so either.  Then I found packets being dropped on
 PR> the loopback interface with my IP address rather than 127.0.0.0,
 PR> so I had to allow both.

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

 PR> #### PGR: BLACKLIST CHECKING
 MA> Why not cover all this with the input policy?

 PR> It works and it's the way I chose to do it.

Ah yes. The old "if it ain't broke don't fix it" philosophy. I subscribe
to this tenet when it comes to old automobiles but we ain't talking
about automobiles we are talking scripting and firewalls. A well crafted
script is a pleasure when achieved and a wonder for others to behold. :)

########################################################################  

 PR> function off {
 PR>   # stop firewall
 PR>   echo "Firewall: disabling filtering (allowing all access)"
 PR>   echo "Are you sure?  Really sure?"
 PR>   read ans
 PR>   if [ $ans = "y" -o $ans = "Y" ]; then
 PR>     iptables -P INPUT ACCEPT
 PR>     iptables -P OUTPUT ACCEPT
 PR>     iptables -P FORWARD ACCEPT
 PR>     iptables -F
 PR>     iptables -X
 PR>     echo "The gates to the citadel are wide open!"
 PR>     echo "Welcome, sailor!"
 PR>   else
 PR>     echo "Good idea!  Firewall stop, cancelled."
 PR>   fi
 PR> }

# flush.sh

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -F
iptables -X
iptables -L -v

This is an after thought from my last message. If run from a terminal
it will give you a better output.

--- MultiMail/Linux v0.47
 * Origin: Try Our Web Based QWK: DOCSPLACE.ORG (1:123/140)