Text 7712, 347 rader
Skriven 2006-10-28 05:00: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>> 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.
PR> Yes, we can.
Nup.
PR> A firewall will only stop packet attacks. While those are an
PR> issue, e.g. the Morris worm,
Stinking Maurice. ;-\
PR> attacks also happen on a higher
PR> level. Today attacks happen through email attachments, web
PR> pages' Java scripts, even MSIE "browser helpers", etc. (OK,
PR> this is Linux, call it a malicious Firefox extension then.)
PR> A firewall will never catch them.
Exactly. So why mention if it is not a firewall issue?
PR> But if one of them comes in
PR> through a user error, by limiting the ability to get out,
PR> "preventing ET from phoning home", I lower the threats coming
PR> back--which could be using well formed packets my firewall
PR> passes.
If something traverses the INPUT rules and you didn't see it
coming, by what magic are you going have an OUTPUT rule to
deal with it going? If you did have something in the OUTPUT rule
to deal with it, why wasn't it stopped at the INPUT part of the
table?
PR> I guess we'll just have to agree to disagree about the necessity
PR> of filtering output chains.
I'll agree to continually disagree with you about filter on the output
chain.
MA> I think I'm marginally safer by
PR> limiting NEW connections to just the well known ports. Yes, I
PR> can imagine attack methods that won't catch. Still, I do what I
PR> can.
I have no problem with that, indeed you could tighten it up more
by defining $EPHEM according to the amount of ram you have.
The value on my system is in /proc/sys/net/ipv4/ip_local_port_range.
I'm not sure if it's the same with LFS but as i have 384meg ram
the value on my machine is 32768:61000
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
PR> No, it doesn't! This firewall is for a workstation, there is no
PR> web server.
Yes it does. It doesn't matter whether it's on a workstation or
a server. What do you think iptables knows the difference? The two top
lines are taken from your firewall and the two at the bottom would do
_exactly_the_same_thing.
PR> Since I don't have the rules you suggest, such
PR> packets fail every INPUT rule I have until they get down to what
PR> I call the "fall-through" section, AT which point THEN they get
PR> logged & dropped. So I already do as you suggest, just not
PR> quite as explicitly. Your suggestion doesn't do what I do.
Fall through? If you write a rule in the output chain that stops
an undesirable event then why did you not stop such an event in
the input chain.
PR> What I do is actively prevent any such webpage from ever sending
PR> a packet home over these sub-channels.
Sub-channels? What are you being attacked by things falling through
the roof and submarines by sea? You need more than a firewall you
need a bomb shelter.
PR> I get the webpage the
PR> server sends out from the WWW port, but it never gets the
PR> request the webpage is supposed to send back on 81 or 8080.
PR> Perhaps that's a pop-up, but maybe it's worse. I don't want
PR> either.
Sigh. Then stop them in the INPUT rules.
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.
PR> I did that. But the OUTPUT rule I have isn't superfluous.
Give me an example of one valid situation where it is imperative
for you to filter on the output chain.
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.
PR> In my case LOCAL_NET is 192.168.1.x, (though now I wish I'd made
PR> it something like 192.168.137.x, 0 & 1 are too easy to guess).
Then why later in this message do you say in your script:-
# iptables -A INPUT -s $CLASS_C -j DROP
# PGR Can't do that, our LAN is a Class C private network
Earlier in the script you define.
CLASS_C="192.168.0.0/16"
So you are making things up as you go along. How is anyone supposed
to follow your script?
PR> Look more carefully.
LOCAL_NET=$BASEIP.0/24
As i said, if you invite comment on your iptables chain you need
to define things in the script correctly and not use outside references
unless you have to.
PR> Since I don't have any INPUT rules to
PR> accept 192.168.0.x or 192.168.[2-254].x, they get logged &
PR> dropped at the end, accomplishing what I commented out for Class
PR> C addresses--except for my LOCAL_NET. No, I don't drop ALL
PR> Class C addresses, but later on I only allow the LOCAL_NET
PR> packets in, all others "fall-through" to get logged & dropped.
PR> Even in-coming packets from LOCAL_NET must come to ports I
PR> specifically allow, or they're logged & dropped. I don't know
PR> how to accomplish that with a simple rule as the Class A/B/D/E
PR> network rules.
Lets have a look at the gist of what you have done with $LOCAL_NET
throughout your script. For brevity i have omitted the statefull
side of things and used port numbers but have the service commented.
iptables -A INPUT -p udp --dport 137 -s $LOCAL_NET -j ACCEPT #netbios-ns
iptables -A INPUT -p udp --dport 138 -s $LOCAL_NET -j ACCEPT #netbios-dgm
iptables -A INPUT -p udp -s $LOCAL_NET --sport 53 -j ACCEPT #domain
iptables -A OUTPUT -p udp -d $LOCAL_NET --dport 53 -j ACCEPT #domain
iptables -A INPUT -p udp -s $LOCAL_NET --sport 113 -j ACCEPT #auth
iptables -A INPUT -p tcp --dport 139 -s $LOCAL_NET -j ACCEPT #netbios-ssn
iptables -A OUTPUT -p tcp --sport 139 -d $LOCAL_NET -j ACCEPT #netbios-ssn
iptables -A INPUT -p tcp --dport 139 -s $LOCAL_NET -j ACCEPT #netbios-ssn
iptables -A OUTPUT -p tcp --dport 137 -s $LOCAL_NET -j ACCEPT #netbios-ns
iptables -A OUTPUT -p tcp --dport 138 -s $LOCAL_NET -j ACCEPT #netbios-dgm
iptables -A OUTPUT -p tcp --dport 139 -s $LOCAL_NET -j ACCEPT #netbios-ssn
iptables -A INPUT -p tcp -s $LOCAL_NET --sport 113 -j ACCEPT #auth
God only knows why you have these last lines.
iptables -A INPUT -s $LOCAL_NET -j REJECT
iptables -A OUTPUT -d $LOCAL_NET -j REJECT
By having your OUTPUT as ACCEPT then you can replace the whole lot
with:-
iptables -A INPUT -p tcp -s $LOCAL_NET -m multiport --port 53,113,137,138,139
-j ACCEPT
iptables -A INPUT -p udp -s $LOCAL_NET -m multiport --port 53,113,137,138,139
-j ACCEPT
Without the line wrap of course.
PR> In effect, yeah, I'm making an assumption my own machines are
PR> cleaner and safer to allow in, and in part that's because I
PR> don't allow them priveleges to send out anything they want
PR> either.
You just don't get it do you. What ever goes in or out of your network
including your local machine has to go through the INPUT chain.
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
PR> Yeah, it does. It just happens later.
Where pray tell me? After having defined $CLASS_C it's never
mentioned again except where you have commented it out.
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.
PR> I have a pizza-box Compaq acting as a perimeter firewall. It is
PR> my primary filter using LEAF/Bering & SHORWALL. My workstation
PR> firewall is primarily to protect my LAN, though it also has the
PR> blacklisting.
It's a simple question i asked you. Does your local net and the inet hook
up to _your_ machine through one etho?
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.
PR> Mine does. By saving the tables at shutdown, and restoring them
PR> at boot, I'm using already processed tables. No glitches.
Well if it works for your distro so be it.
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
PR> The log-it user chain logs and drops packets! The OUTPUT REJECT
PR> tells whatever local client process tried to send the packet an
PR> error code. If it was me at a browser I get an error message
PR> from the browser. My most recent mod was to log all the
PR> blacklisted packets with a different prefix which makes them
PR> easier to identify.
So you like sending youself error messages? Did i say you shouldn't
log it? Why not just log and drop it?
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...
PR> NO! Not what I want to do. That would send an ICMP packet back
PR> to $BAD_BOY. It tells him I don't exist, but that's more than I
PR> want him to know. As it is, he sends packets which "disappear".
Why let it into the firewall in the first place?
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?
PR> Ummm, paranoia?
Then don't let it in in the first place.
MA> Suppose you where SNAT/DNATing or
MA> FORWARDING. You let the damn thing in the front door. It could go
MA> anywere.
PR> "If wishes were horses, beggars would ride." I'm not doing any
PR> NAT or FORWARD. FORWARD's policy is DROP, and it has no rules.
PR> If I were, indeed, I wouldn't be using THIS firewall.
Just because you are not forwarding or s/dnating it doesn't excuse
sloppy practice.
MA> If $IP was defined in the script it would be self explanatory.
PR> But it could disagree with what was set in
PR> /etc/sysconfig/network_devices/. Better to source the same
PR> file.
Are you telling me that $IP is a variable? You must have the distro
from hell.
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.
PR> Well, yes. But it wasn't my code and I wasn't prepared to take
PR> responsibility for my own idiosyncratic branch. I think it may
PR> have been part of the OpenSSH package, which I figured was
PR> trustworthy.
I asked at the very beginning if it was your script or if someone else
had written it. If it's an adaptation then of course it will be messy.
IMO you should keep that script but start building your own. You need
clearly defined goals for your setup and make it efficient.
MA> Huh? If "iptables -L -v" hangs then so would "iptables -L -n" and
PR> 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.
PR> With -n, iptables just leaves numeric addresses and doesn't try
PR> to run a DNS lookup, which hangs if there is no effective DNS
PR> server online.
MA> iptables -L -v
<CUT>
MA> anywhere icmp echo-request 0 0 ACCEPT icmp -- eth1 any anywhere
MA> anywhere icmp echo-reply limit: avg 2/min burst 5
PR> OK, now put a numeric in/out IP address in your example, pull
PR> the plug and rerun it. It'll hang until it times out.
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
80 5024 ACCEPT all -- lo any localhost anywhere
50 4200 ACCEPT all -- any any 192.168.0.0/24 anywhere
0 0 ACCEPT all -- any any anywhere 192.168.0.0/24
0 0 ACCEPT tcp -- eth1 any anywhere anywhere tcp dpts:32768:61000
4 588 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 134 packets, 9504 bytes)
pkts bytes target prot opt in out source destination
I ran iptables -L -v while pinging a remote and then had the remote ping
me. Next i instigated a NFS connection and for icing on the cake i got
hackerwacker.com to probe my ports. I flushed the firewall and bought
it up again and on each occasion iptables -L -v worked flawlessly.
--- MultiMail/Linux v0.47
* Origin: Try Our Web Based QWK: DOCSPLACE.ORG (1:123/140)
|