Text 7738, 368 rader
Skriven 2006-10-30 10:02: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>> A firewall will never catch them.
MA> Exactly. So why mention if it is not a firewall issue?
PR> But it is! I can make it harder for them to phone home with the
PR> firewall.
Now you are contradicting yourself. First you say a firewall won't
catch them and in the next breath you say it will.
MA> If something traverses the INPUT rules and you didn't see it
MA> coming, by what magic are you going have an OUTPUT rule to
MA> deal with it going? If you did have something in the OUTPUT rule
MA> to deal with it, why wasn't it stopped at the INPUT part of the
MA> table?
PR> OK, here's a scenario for you.
PR> I visit a website's port 80. No problem getting out through the
PR> firewall, or getting the HTML responses back in over the
PR> ESTABLISHED link. Unbeknownst to me it's been hacked and
PR> hijacked. There's a Java script on the page I get that tries to
PR> establish a NEW connection to a malware server on some ephemeral
PR> port.
You shouldn't have a server on the ephemeral ports. You have your servers
on what you have defined as KNOWN="0:1024". If you mean the remote is
using a different port other than 80 then so what? It isn't going
anywhere. Why would they bother to do something like that? They
would be better of using port 80.
PR> That would work if all OUTPUT ports are open.
The $EPHEM ports don't provide a service and as far as i know ports
in the $EPHEM range are allocated as needed. So you can't define
OUTPUT ports.
PR> If it gets that, then it intends to download a bunch of malware.
If that was a real scenario there would be millions of win 9x users
downloading files without them knowing. It does happen of course but
that has nothing to do with what port the remote is using.
PR> My firewall stops that. Unbeknownst to $BAD_BOY, it might have
PR> worked if he'd used one of the well known ports, until I catch
PR> on and blacklist his IP address.
$BAD_BOY gets squashed because of his IP not because of the port.
MA> I have no problem with that, indeed you could tighten it up more
MA> by defining $EPHEM according to the amount of ram you have.
MA> The value on my system is in /proc/sys/net/ipv4/ip_local_port_range.
MA> I'm not sure if it's the same with LFS but as i have 384meg ram
MA> the value on my machine is 32768:61000
PR> I'll check into that. Of course, if the ports don't EXIST,
PR> they're blocked. ;-)
They lower ports do exist but they are not in the $EPHEM range.
They would be in what you have defined as $KNOWN but you have
IMO wisely not used it in your script. Of course $KNOWN could
be expanded but you don't want to give blanket permission to
any ports that provide a service.
PR>>> iptables -A OUTPUT -p tcp --dport 81 -j log-it
PR>>> 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
MA> Yes it does. It doesn't matter whether it's on a workstation or
PR> Sure it does. An output packet to some server's port 81 doesn't
PR> traverse the INPUT chain.
Unless you allow port 81 on the input chain then it is dropped as per
the policy. So unless you need that port for something you don't
need a rule.
PR> Without my rules, a webpage/Java
PR> script could communicate to any server's port 81 or 8080,
PR> whatever that does.
No it can't get to port but 81 but as you have $EPHEM defined as
1024:65535 then it can get to 8080 and NFS 2049 so deal with them
early in the input chain.
iptables -A INPUT -p tcp -m multiport --port 8080,2049 j DROP
iptables -A INPUT -p udp -m multiport --port 8080,2049 j DROP
PR> I don't allow that. Your rule only works
PR> for a packet coming in to port 81 on my machine, where, since
PR> this isn't a server with Apache listening on port 81, there's
PR> nothing to receive it anyhow. In any event, since I don't have
PR> an INPUT rule to ACCEPT packets coming to ports 81 or 8080,
PR> those get dropped at the end.
Not 81 but 8080 you do. This from your script:-
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 appear to allow a remote to connect to your machine using
any port of his above 1024. Exactly the situation you said you didn't
want.
MA> a server. What do you think iptables knows the difference? The two top
MA> lines are taken from your firewall and the two at the bottom would do
MA> _exactly_the_same_thing.
PR> Mine affects the OUTPUT chain traversal. Yours affects the
PR> INPUT chain traversal. They are NOT the same.
No they are not the same INPUT deals with things coming into
the table OUTPUT deals with things going out of the table.
It must traverse the INPUT rules before it hits the OUTPUT
rules.
MA> Fall through? If you write a rule in the output chain that stops
MA> an undesirable event then why did you not stop such an event in
MA> the input chain.
PR> Because the default policy is DROP. ACCEPT is the exception. I
PR> don't have a rule to ACCEPT an OUTPUT to ports 81 or 8080, so
PR> they wouldn't get out anyway, I just make it explicit.
See what i have said about this earlier. Both 8080 and 2049 are wide
open.
MA> Sub-channels? You need more than a firewall you
MA> need a bomb shelter.
PR> See scenario above.
See the fairies at the bottom of your garden. It aint gonna happen any
time soon.
MA> Give me an example of one valid situation where it is imperative
MA> for you to filter on the output chain.
PR> See above.
Ditto
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).
MA> Then why later in this message do you say in your script:-
MA> # iptables -A INPUT -s $CLASS_C -j DROP
MA> # PGR Can't do that, our LAN is a Class C private network
MA> Earlier in the script you define.
MA> CLASS_C="192.168.0.0/16"
MA> So you are making things up as you go along. How is anyone supposed
MA> to follow your script?
PR> I see you're having a lot of difficulty.
Of course i'm having difficulty because you have never defined
your local net range.
PR> Tell me what CIDR
PR> you'd write to cover a range of addresses except one that's
PR> neither the beginning or end?
Then define what want with 192.168.1.0/255.255.255.0 notation.
How do i know if you need to do this if you have never given me
the value of $LOCAL_NET or $IP.
MA> As i said, if you invite comment on your iptables chain you need
MA> to define things in the script correctly and not use outside references
MA> unless you have to.
PR> I wasn't inviting comment, but offering it for others to use.
PR> Thought Wayne might be interested.
If you post in a public forum you are inviting comment. Wayne has
dial-up IP with dynamic DNS so your firewall is totally inappropriate
for him. Having said that i applaud you for sticking you neck out
and sharing your thoughts with us. I wish more people would have a
go as you have. I'm sure Wayne is watching our exchange and learning
that firewalls can be a complex issue.
<CUT>
MA> God only knows why you have these last lines.
MA> iptables -A INPUT -s $LOCAL_NET -j REJECT
MA> iptables -A OUTPUT -d $LOCAL_NET -j REJECT
PR> $man iptables
Hmmm! God only knows why you have those last lines.
PR> DROP discards the packet without informing the sender. REJECT
PR> returns an error to the sender. I play nice with my own
PR> machines. If they try something I don't allow, rather than
PR> hanging until the operation times out, I have the firewall
PR> return an error so they/I know immediately the operation failed.
MA> By having your OUTPUT as ACCEPT then you can replace the whole lot
MA> with:-
MA> iptables -A INPUT -p tcp -s $LOCAL_NET -m multiport --port
MA> 53,113,137,138,139 -j ACCEP
MA> iptables -A INPUT -p udp -s $LOCAL_NET -m multiport --port
MA> 53,113,137,138,139 -j ACCEP
MA> Without the line wrap of course.
PR> Certainly could, but I think that would be harder to understand.
Two lines are harder to understand than twelve? You make a
comment in the script naming the ports and what they do.
MA> You just don't get it do you. What ever goes in or out of your network
MA> including your local machine has to go through the INPUT chain.
PR> No, I got it fine. You must be reading it wrong. See:
PR> http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-6.ht
PR> ml
PR> Here is a text rendition:
PR> +++++++++++
PR> 6. How Packets Traverse The Filters
PR> The kernel starts with three lists of rules in the `filter' table;
PR> these lists are called *firewall chains* or just *chains*. The three
PR> chains are called *INPUT*, *OUTPUT* and *FORWARD*.
PR> For ASCII-art fans, the chains are arranged like so: *(Note: this is a
PR> very different arrangement from the 2.0 and 2.2 kernels!)*
PR> _____
PR> Incoming / \ Outgoing
PR> -->[Routing ]--->|FORWARD|------->
PR> [Decision] \_____/ ^
PR> | |
PR> v ____
PR> ___ / \
PR> / \ |OUTPUT|
PR> |INPUT| \____/
PR> \___/ ^
PR> | |
PR> ----> Local Process -----
PR> OUTPUT packets from some client of mine, e.g. browser, ftp,
PR> etc., goes to the OUTPUT chain, not the INPUT chain. See #4
PR> above.
Read the diagram. You see the input table has to be traversed
before it reaches the output table. "Local Process" refers to
user defined tables and not the local network.
MA> Where pray tell me? After having defined $CLASS_C it's never
MA> mentioned again except where you have commented it out.
PR> All 192.168.x.y INPUT packets traverse the INPUT chain. They
PR> aren't explicitly dropped like the Class-[A,B] addresses are.
$LOCAL_NET as far as i can see has only access to specific ports.
It is therefore not necessary to to drop it. If it were to try
to access other services it is dropped as per the input policy.
PR> If they are from $LOCAL_NET for ports I allow they find an
PR> ACCEPT rule and are passed. If they're NOT from $LOCAL_NET,
PR> e.g. 192.168.0.y, 192.168.[2-255].y, etc., OR they're $LOCAL_NET
PR> to a prohibited port, they NEVER find an ACCEPTing rule. They
PR> traverse the entire chain to the bottom where they get shunted
PR> to log-it, where they're logged & dropped.
They do not traverse the entire in/outchain. If they don't meet the
the rules set out in the input table they are dropped. That
is the whole point of having the INPUT policy as DROP. At best
they can only use $EPHEM where they can do no harm if your
statefull side of thing are working correctly.
I was right at the begining of this thread when i said you don't
have to drop CLASS_[A,B] etc because they are not given permission
in the first place.
MA> It's a simple question i asked you. Does your local net and the inet
MA> hook up to _your_ machine through one etho?
PR> Yes. My perimeter firewall/router machine is 192.168.1.254 on
PR> my LAN. I'm not running a DMZ setup.
Ahh that gives be a much better picture of things. Something like this?
Internet
|
V
router
Your machine ------- 192.168.1.254 -------- Local net
PR> Mine does. By saving the tables at shutdown, and restoring them
PR> at boot, I'm using already processed tables. No glitches.
MA> Well if it works for your distro so be it.
PR> It's in iptables-1.2.11.
PR> $man iptables-save
PR> $man iptables-restore
Yea i know. On my system i only need run the firewall script and then
do iptables-save > /etc/sysconfig/iptables and then it's bought up
on boot.
MA> So you like sending youself error messages? Did i say you shouldn't
MA> log it? Why not just log and drop it?
PR> Yes. I don't like sitting there while a failing operation times
PR> out. If it isn't going to work, I'd like to know about it
PR> immediately by returning an error code.
Fair enough but do it on in the input table and drop it as well.
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
MA> Why let it into the firewall in the first place?
PR> You mean set-up the blacklisting on the perimeter firewall?
PR> That's a lot harder.
No but deal with it in the input table.
PR>> Ummm, paranoia?
MA> Then don't let it in in the first place.
PR> I don't. Net-filter is a kernel facility. They never make
PR> it through.
MA> Are you telling me that $IP is a variable? You must have the distro
MA> from hell.
PR> It is defined in /etc/sysconfig/network_devices/ifconfig.eth0,
PR> and sourced in several scripts: here in firewall, &
PR> /etc/rc.d/init.d/network. RedHat does it similarly.
Yes but your ip is not a vairible is it? So why not just define it
from within the script.
MA> I asked at the very beginning if it was your script or if someone else
MA> had written it. If it's an adaptation then of course it will be messy.
PR> As it says, someone else wrote a firewall script which I took
PR> and modified to suit myself.
MA> I ran iptables -L -v while pinging a remote and then had the remote
MA> ping me. Next i instigated a NFS connection and for icing on the cake i
MA> got hackerwacker.com to probe my ports. I flushed the firewall and
MA> bought it up again and on each occasion iptables -L -v worked
MA> flawlessly.
PR> It does, when you have a connection to a DNS server. It hangs
PR> unless you specify -n and you need a DNS lookup. My way, I can
PR> update my workstation when the network is down and it doesn't
PR> hang for DNS lookups.
It doesn't hang on my system. I've run every test possible and i can't
duplicate the problem you are reporting.
--- MultiMail/Linux v0.47
* Origin: Try Our Web Based QWK: DOCSPLACE.ORG (1:123/140)
|