Text 7706, 221 rader
Skriven 2006-10-25 21:33:00 av Paul Rogers (1:105/360.0)
Kommentar till en text av Martin Atkins
Ärende: Latest firewall script
==============================
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!
MA> Ok. I will have to study traceroute one day.
Well, in the first place traceroute uses UDP protocol, and the
any-port rule you quoted was using TCP protocol. But suppose
both were TCP, because the point would be relevant for some
other service. So if "traceroute" used TCP:
To run a traceroute we have to allow a NEW connection out. To
run passive-mode FTP we have to allow connections to/from any
ephemeral port--but they will be ESTABLISHED or RELATED to a
connection already setup through a NEW connection allowed to
the remote server's FTP control port. So I allow NEW out only
on the emphemeral ports traceroute will use.
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.
MA> If you didn't stop something malicious coming in then you won't stop
MA> it going out.
Yes, we can.
A firewall will only stop packet attacks. While those are an
issue, e.g. the Morris worm, attacks also happen on a higher
level. Today attacks happen through email attachments, web
pages' Java scripts, even MSIE "browser helpers", etc. (OK,
this is Linux, call it a malicious Firefox extension then.)
A firewall will never catch them. But if one of them comes in
through a user error, by limiting the ability to get out,
"preventing ET from phoning home", I lower the threats coming
back--which could be using well formed packets my firewall
passes.
I guess we'll just have to agree to disagree about the necessity
of filtering output chains. I think I'm marginally safer by
limiting NEW connections to just the well known ports. Yes, I
can imagine attack methods that won't catch. Still, I do what I
can.
MA> Ok fine. If those two ports make you nervious then IMO there is
MA> nothing wrong with you writing a rule for them, but why use the
MA> OUTPUT table? I note you are loging those ports for any activity
MA> with:-
MA> iptables -A OUTPUT -p tcp --dport 81 -j log-it
MA> iptables -A OUTPUT -p tcp --dport 8080 -j log-it
MA> This does exactly the same.
MA> iptables -A INPUT -p tcp --dport 81 -j log-it
MA> iptables -A INPUT -p tcp --dport 8080 -j log-it
No, it doesn't! This firewall is for a workstation, there is no
web server. Since I don't have the rules you suggest, such
packets fail every INPUT rule I have until they get down to what
I call the "fall-through" section, AT which point THEN they get
logged & dropped. So I already do as you suggest, just not
quite as explicitly. Your suggestion doesn't do what I do.
What I do is actively prevent any such webpage from ever sending
a packet home over these sub-channels. I get the webpage the
server sends out from the WWW port, but it never gets the
request the webpage is supposed to send back on 81 or 8080.
Perhaps that's a pop-up, but maybe it's worse. I don't want
either.
MA> It may not matter to you but to me it does because throughout the
MA> script, by dealing with things at the front door, i may be able to
MA> do away with superfluous rules.
I did that. But the OUTPUT rule I have isn't superfluous.
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.
MA> Are we talking $IP or LOCAL_NET?
MA> IP="192.168.0.1" # Or what's appropriate.
MA> LOCAL_NET="192.168.0.0/16" # Ditto.
MA> Actually you have it defined in your script as $CLASS_C and have
MA> it commented out in one of the rules.
In my case LOCAL_NET is 192.168.1.x, (though now I wish I'd made
it something like 192.168.137.x, 0 & 1 are too easy to guess).
Look more carefully. Since I don't have any INPUT rules to
accept 192.168.0.x or 192.168.[2-254].x, they get logged &
dropped at the end, accomplishing what I commented out for Class
C addresses--except for my LOCAL_NET. No, I don't drop ALL
Class C addresses, but later on I only allow the LOCAL_NET
packets in, all others "fall-through" to get logged & dropped.
Even in-coming packets from LOCAL_NET must come to ports I
specifically allow, or they're logged & dropped. I don't know
how to accomplish that with a simple rule as the Class A/B/D/E
network rules.
In effect, yeah, I'm making an assumption my own machines are
cleaner and safer to allow in, and in part that's because I
don't allow them priveleges to send out anything they want
either.
MA> # iptables -A INPUT -s $CLASS_C -j DROP
MA> # PGR Can't do that, our LAN is a Class C private network
MA> It was never gonna work. :) I think though you where on the right
Yeah, it does. It just happens later.
MA> track. Does your local net and the inet hook up to your machine
MA> through one etho? We may be able to do something with this.
I have a pizza-box Compaq acting as a perimeter firewall. It is
my primary filter using LEAF/Bering & SHORWALL. My workstation
firewall is primarily to protect my LAN, though it also has the
blacklisting.
PR>> init.d/firewall saves & restores--init isn't the place to have
MA> Yea well i like my firewall to come up on boot.
Mine does. By saving the tables at shutdown, and restoring them
at boot, I'm using already processed tables. No glitches.
PR>> I've got an OUTPUT rule for virtually every INPUT
PR>> rule. And it's not causing me problems.
MA> Yes it is. And here is an example from your script:-
MA> # Input packets are logged & forgotten
MA> iptables -A INPUT -s $BAD_BOY -j log-it
MA> # Output packets from internal processes receive an error code,
MA> # but they still don't go through.
MA> iptables -A OUTPUT -d $BAD_BOY -j REJECT --reject-with icmp-host-unr...
MA> What you appear to be trying achieve is to block known bad IP's from
MA> your system be it local or the internet. If so then it is not doing
MA> what you think it is doing. In fact worse still $BAD_BOY is logged but
MA> still gets into your system. What it actually does is block you and
The log-it user chain logs and drops packets! The OUTPUT REJECT
tells whatever local client process tried to send the packet an
error code. If it was me at a browser I get an error message
from the browser. My most recent mod was to log all the
blacklisted packets with a different prefix which makes them
easier to identify.
MA> anything going through your firewall (local net) from communicating
MA> with $BAD_BOY. What you will and your terminals will get is
MA> icmp-host-unreachable. Now this may be desirable but not what i
MA> think you where after.
MA> # Input packets are logged
MA> iptables -A INPUT -s $BAD_BOY -j log-it
MA> # We've seen you sonofabitch now die.
MA> iptables -A INPUT -s $BAD_BOY -j REJECT --reject-with icmp-host-unr...
NO! Not what I want to do. That would send an ICMP packet back
to $BAD_BOY. It tells him I don't exist, but that's more than I
want him to know. As it is, he sends packets which "disappear".
PR>> I filter the OUTPUT chain so that it doesn't get
PR>> in MY way, but gets in the way of everything else.
MA> What kind of attutude is that?
Ummm, paranoia?
MA> Suppose you where SNAT/DNATing or
MA> FORWARDING. You let the damn thing in the front door. It could go
MA> anywere.
"If wishes were horses, beggars would ride." I'm not doing any
NAT or FORWARD. FORWARD's policy is DROP, and it has no rules.
If I were, indeed, I wouldn't be using THIS firewall.
MA> If $IP was defined in the script it would be self explanatory.
But it could disagree with what was set in
/etc/sysconfig/network_devices/. Better to source the same
file.
MA> I would be highly suspicious of anything attempting to use something
MA> outside 127.0.0.1 for loopback or local machine. It runs counter
MA> to your philosophy of running a tight firewall.
Well, yes. But it wasn't my code and I wasn't prepared to take
responsibility for my own idiosyncratic branch. I think it may
have been part of the OpenSSH package, which I figured was
trustworthy.
MA> Huh? If "iptables -L -v" hangs then so would "iptables -L -n" and
Nope. It doesn't. I use it that way. Don't tell me it hangs!
MA> it doesn't only report numerical output it does as the -v option
MA> suggests and reports verbose. The -n option is as it suggests
MA> numerical.
With -n, iptables just leaves numeric addresses and doesn't try
to run a DNS lookup, which hangs if there is no effective DNS
server online.
MA> iptables -L -v
MA> Chain INPUT (policy DROP 0 packets, 0 bytes)
MA> pkts bytes target prot opt in out source destination
MA> 0 0 ACCEPT all -- lo any anywhere anywhere
MA> 0 0 ACCEPT all -- eth0 any anywhere anywhere
MA> 0 0 ACCEPT tcp -- eth1 any anywhere anywhere tcp
MA> dpts:32768:61000 0 0 ACCEPT udp -- eth1 any anywhere anywhere
MA> udp dpts:32768:61000 0 0 ACCEPT icmp -- eth1 any anywhere
MA> anywhere icmp echo-request 0 0 ACCEPT icmp -- eth1 any anywhere
MA> anywhere icmp echo-reply limit: avg 2/min burst 5
OK, now put a numeric in/out IP address in your example, pull
the plug and rerun it. It'll hang until it times out.
Paul Rogers, paulgrogers@yahoo.com -o)
http://www.angelfire.com/or/paulrogers /\\
Rogers' Second Law: Everything you do communicates. _\_V
... is OS/2 only half an operating system?
___ MultiMail/MS-DOS v0.35
---
* Origin: The Bare Bones BBS (1:105/360)
|