Text 7704, 271 rader
Skriven 2006-10-26 09:32:00 av MARTIN ATKINS (1:123/140)
Kommentar till en text av PAUL ROGERS
Ärende: Latest firewall script
==============================
-=> PAUL ROGERS wrote to MARTIN ATKINS <=-
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.
PR> I thought you said it was.
No. I said it was ok if those addresses connect you to the outside
world.
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.
PR> What's hard about a CIDR like that? "127.anything", that's simple.
It's not needed. The way i suggested does away with three lines of
script and why open up more addresses than you need?
PR> KISS isn't an issue. Security is. The way I try to make it
PR> "easy" to identify anomalies is by using lots of obvious
PR> patterns.
MA> Your knowledge of networking far exceeds mine so be forgiving if
PR> I don't ever give that a thought, because the attackers out there
PR> far exceed me! If I ever thought "I finally got it," I'd be
PR> exposing myself to the next trick.
Fair enough. Complacancy can bite you on the bum. :-}
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.
PR> It doesn't allow a NEW connection, so I couldn't start a
PR> traceroute. I wouldn't even consider allowing a NEW connection
PR> from any port to any port. Sayonara, security!
Ok. I will have to study traceroute one day.
PR> These rules are required by FTP. It's unfortunate, but FTP
PR> doesn't play well with firewalls. Seems strange the TCP/IP
PR> protocols designed for the ARPANET didn't have better security,
PR> 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
PR> That was from the original source. It was something that didn't
PR> seem to be broke, so I left it.
Why not just comment them out and see if traceroute still works the way
you want?
MA> own rules. Also notice that if the output policy was ACCEPT then
MA> the second line of the tcp rule is redundant.
PR> We've got different goals. I'm not trying to minimize the number
PR> of rules. Rather than fewer broad rules, I want narrow rules, as
PR> many as I need.
I don't think we have different goals, just different attitudes. I'm
driven to perfection even if i can never achieve it.
PR> I see firewalls that aren't concerned with what goes out. But
PR> that not only lets a malicious webpage set something up, but it
PR> lets anything that did infect my workstation to attack any port
PR> on any other computer on my LAN.
If you didn't stop something malicious coming in then you won't stop
it going out.
PR> Lots of web sites use ports 81
PR> or 8080 for certain benign services, but I can't be sure WHAT
PR> might be going on with some side-channel like that, so I
PR> explicitly drop those. Maybe something benign won't work. I
PR> accept that. But at the top of my script I warn it's "tight".
PR> If you don't want a tight firewall, it isn't for you.
Ok fine. If those two ports make you nervious then IMO there is
nothing wrong with you writing a rule for them, but why use the
OUTPUT table? I note you are loging those ports for any activity
with:-
iptables -A OUTPUT -p tcp --dport 81 -j log-it
iptables -A OUTPUT -p tcp --dport 8080 -j log-it
This does exactly the same.
iptables -A INPUT -p tcp --dport 81 -j log-it
iptables -A INPUT -p tcp --dport 8080 -j log-it
It may not matter to you but to me it does because throughout the
script, by dealing with things at the front door, i may be able to
do away with superfluous rules.
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
PR> What belongs? You think I should define LOCAL_NET in
PR> ifconfig.eth0? I suppose one could do it that way. I think
PR> just the network root, the first 3 octets, is more versatile.
Are we talking $IP or LOCAL_NET?
IP="192.168.0.1" # Or what's appropriate.
LOCAL_NET="192.168.0.0/16" # Ditto.
Actually you have it defined in your script as $CLASS_C and have
it commented out in one of the rules.
# Refuse packets claiming to be from a Class C private network.
# iptables -A INPUT -s $CLASS_C -j DROP
# PGR Can't do that, our LAN is a Class C private network
It was never gonna work. :) I think though you where on the right
track. Does your local net and the inet hook up to your machine
through one etho? We may be able to do something with this.
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.
PR> init.d/firewall saves & restores--init isn't the place to have
PR> any glitches. I put the script posted here in
PR> /usr/local/sbin/firewall.
Yea well i like my firewall to come up on boot.
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.
PR> They may not consider it necessary, I do. The motto of LFS is:
PR> "Your distro, your rules." Obviously I think output filtering
PR> IS necessary.
Obviously i don't think output filtering IS necessary. :-}
PR> I've got an OUTPUT rule for virtually every INPUT
PR> rule. And it's not causing me problems.
Yes it is. And here is an example from your script:-
# Input packets are logged & forgotten
iptables -A INPUT -s $BAD_BOY -j log-it
# Output packets from internal processes receive an error code,
# but they still don't go through.
iptables -A OUTPUT -d $BAD_BOY -j REJECT --reject-with icmp-host-unreachable
What you appear to be trying achieve is to block known bad IP's from
your system be it local or the internet. If so then it is not doing
what you think it is doing. In fact worse still $BAD_BOY is logged but
still gets into your system. What it actually does is block you and
anything going through your firewall (local net) from communicating
with $BAD_BOY. What you will and your terminals will get is
icmp-host-unreachable. Now this may be desirable but not what i
think you where after.
# Input packets are logged
iptables -A INPUT -s $BAD_BOY -j log-it
# We've seen you sonofabitch now die.
iptables -A INPUT -s $BAD_BOY -j REJECT --reject-with icmp-host-unreachable
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
PR> Not necessarily. People can get tricked into inviting malware
PR> in. The packets they come in on can pass filtering. They may
PR> come in by other means. Just filtering the INPUT chain isn't
PR> enough, IMO.
Yes it is. If it doesn't get past the input chain it is dead in the
water.
PR> I filter the OUTPUT chain so that it doesn't get
PR> in MY way, but gets in the way of everything else.
What kind of attutude is that? Suppose you where SNAT/DNATing or
FORWARDING. You let the damn thing in the front door. It could go
anywere.
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?
PR> It isn't clear what $IP means? Would $MY_IP_ADDR be better?
PR> That means changing several other scripts, but I'll consider
PR> it. Maybe a comment here will help.
If $IP was defined in the script it would be self explanatory.
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.
PR> Hello? You may not have run into it yet, but I had packets
PR> being dropped because I also thought only 127.0.0.0/8 addresses
PR> ever used the loopback interface. Packets addressed with the IP
PR> address will also appear on the loopback! (I didn't make it a
PR> point to remember which service did it after I found it and
PR> fixed it.)
I would be highly suspicious of anything attempting to use something
outside 127.0.0.1 for loopback or local machine. It runs counter
to your philosophy of running a tight firewall.
MA> Ah yes. The old "if it ain't broke don't fix it" philosophy. I
PR> Yeah, it's sorta like the KISS philosophy. ;-)
MA> well crafted script is a pleasure when achieved and a wonder for others
PR> It's got to please me. This is open-source--others can change
PR> 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.
PR> Not unless there is a network connection at the time. If not
PR> then -L hangs until it times out, and it still only reports the
PR> numeric addresses. -L -n doesn't delay. I only have a network
PR> connection when I need to use it. It goes through another
PR> computer that isn't always on.
Huh? If "iptables -L -v" hangs then so would "iptables -L -n" and
it doesn't only report numerical output it does as the -v option
suggests and reports verbose. The -n option is as it suggests
numerical.
iptables -L -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo any anywhere anywhere
0 0 ACCEPT all -- eth0 any anywhere anywhere
0 0 ACCEPT tcp -- eth1 any anywhere anywhere tcp dpts:32768:61000
0 0 ACCEPT udp -- eth1 any anywhere anywhere udp dpts:32768:61000
0 0 ACCEPT icmp -- eth1 any anywhere anywhere icmp echo-request
0 0 ACCEPT icmp -- eth1 any anywhere anywhere icmp echo-reply limit:
avg 2/min burst 5
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
--- MultiMail/Linux v0.47
* Origin: Try Our Web Based QWK: DOCSPLACE.ORG (1:123/140)
|