Text 7720, 278 rader
Skriven 2006-10-27 20:06:02 av Paul Rogers (1:105/360.0)
Kommentar till en text av Martin Atkins
Ärende: Latest firewall script
==============================
PR>> issue, e.g. the Morris worm,
MA> Stinking Maurice. ;-\
Robert T.
PR>> A firewall will never catch them.
MA> Exactly. So why mention if it is not a firewall issue?
But it is! I can make it harder for them to phone home with the
firewall.
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?
OK, here's a scenario for you.
I visit a website's port 80. No problem getting out through the
firewall, or getting the HTML responses back in over the
ESTABLISHED link. Unbeknownst to me it's been hacked and
hijacked. There's a Java script on the page I get that tries to
establish a NEW connection to a malware server on some ephemeral
port. That would work if all OUTPUT ports are open. If it gets
that, then it intends to download a bunch of malware. My
firewall stops that. Unbeknownst to $BAD_BOY, it might have
worked if he'd used one of the well known ports, until I catch
on and blacklist his IP address.
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
I'll check into that. Of course, if the ports don't EXIST,
they're blocked. ;-)
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
Sure it does. An output packet to some server's port 81 doesn't
traverse the INPUT chain. Without my rules, a webpage/Java
script could communicate to any server's port 81 or 8080,
whatever that does. I don't allow that. Your rule only works
for a packet coming in to port 81 on my machine, where, since
this isn't a server with Apache listening on port 81, there's
nothing to receive it anyhow. In any event, since I don't have
an INPUT rule to ACCEPT packets coming to ports 81 or 8080,
those get dropped at the end.
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.
Mine affects the OUTPUT chain traversal. Yours affects the
INPUT chain traversal. They are NOT the same.
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.
Because the default policy is DROP. ACCEPT is the exception. I
don't have a rule to ACCEPT an OUTPUT to ports 81 or 8080, so
they wouldn't get out anyway, I just make it explicit.
MA> Sub-channels? You need more than a firewall you
MA> need a bomb shelter.
See scenario above.
MA> Give me an example of one valid situation where it is imperative
MA> for you to filter on the output chain.
See above.
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?
I see you're having a lot of difficulty. Tell me what CIDR
you'd write to cover a range of addresses except one that's
neither the beginning or end?
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.
I wasn't inviting comment, but offering it for others to use.
Thought Wayne might be interested.
MA> Lets have a look at the gist of what you have done with $LOCAL_NET
MA> throughout your script. For brevity i have omitted the statefull
MA> side of things and used port numbers but have the service commented.
MA> iptables -A INPUT -p udp --dport 137 -s $LOCAL_NET -j ACCEPT
MA> #netbios-ns iptables -A INPUT -p udp --dport 138 -s $LOCAL_NET -j
MA> ACCEPT #netbios-dgm iptables -A INPUT -p udp -s $LOCAL_NET --sport 53
MA> -j ACCEPT #domain iptables -A OUTPUT -p udp -d $LOCAL_NET --dport 53
MA> -j ACCEPT #domain iptables -A INPUT -p udp -s $LOCAL_NET --sport 113
MA> -j ACCEPT #auth iptables -A INPUT -p tcp --dport 139 -s $LOCAL_NET -j
MA> ACCEPT #netbios-ssn iptables -A OUTPUT -p tcp --sport 139 -d $LOCAL_NET
MA> -j ACCEPT #netbios-ssn iptables -A INPUT -p tcp --dport 139 -s
MA> $LOCAL_NET -j ACCEPT #netbios-ssn iptables -A OUTPUT -p tcp --dport 137
MA> -s $LOCAL_NET -j ACCEPT #netbios-ns iptables -A OUTPUT -p tcp --dport
MA> 138 -s $LOCAL_NET -j ACCEPT #netbios-dgm iptables -A OUTPUT -p tcp
MA> --dport 139 -s $LOCAL_NET -j ACCEPT #netbios-ssn iptables -A INPUT -p
MA> tcp -s $LOCAL_NET --sport 113 -j ACCEPT #auth
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
$man iptables
DROP discards the packet without informing the sender. REJECT
returns an error to the sender. I play nice with my own
machines. If they try something I don't allow, rather than
hanging until the operation times out, I have the firewall
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.
Certainly could, but I think that would be harder to understand.
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.
No, I got it fine. You must be reading it wrong. See:
http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-6.html
Here is a text rendition:
+++++++++++
6. How Packets Traverse The Filters
The kernel starts with three lists of rules in the `filter' table; these
lists are called *firewall chains* or just *chains*. The three chains
are called *INPUT*, *OUTPUT* and *FORWARD*.
For ASCII-art fans, the chains are arranged like so: *(Note: this is a
very different arrangement from the 2.0 and 2.2 kernels!)*
_____
Incoming / \ Outgoing
-->[Routing ]--->|FORWARD|------->
[Decision] \_____/ ^
| |
v ____
___ / \
/ \ |OUTPUT|
|INPUT| \____/
\___/ ^
| |
----> Local Process -----
The three circles represent the three chains mentioned above. When a
packet reaches a circle in the diagram, that chain is examined to decide
the fate of the packet. If the chain says to DROP the packet, it is
killed there, but if the chain says to ACCEPT the packet, it continues
traversing the diagram.
A chain is a checklist of *rules*. Each rule says `if the packet header
looks like this, then here's what to do with the packet'. If the rule
doesn't match the packet, then the next rule in the chain is consulted.
Finally, if there are no more rules to consult, then the kernel looks at
the chain *policy* to decide what to do. In a security-conscious system,
this policy usually tells the kernel to DROP the packet.
1. When a packet comes in (say, through the Ethernet card) the kernel
first looks at the destination of the packet: this is called
`routing'.
2. If it's destined for this box, the packet passes downwards in the
diagram, to the INPUT chain. If it passes this, any processes
waiting for that packet will receive it.
3. Otherwise, if the kernel does not have forwarding enabled, or it
doesn't know how to forward the packet, the packet is dropped. If
forwarding is enabled, and the packet is destined for another
network interface (if you have another one), then the packet goes
rightwards on our diagram to the FORWARD chain. If it is ACCEPTed,
it will be sent out.
4. Finally, a program running on the box can send network packets.
These packets pass through the OUTPUT chain immediately: if it
says ACCEPT, then the packet continues out to whatever interface
it is destined for.
++++++++++++
OUTPUT packets from some client of mine, e.g. browser, ftp,
etc., goes to the OUTPUT chain, not the INPUT chain. See #4
above.
MA> Where pray tell me? After having defined $CLASS_C it's never
MA> mentioned again except where you have commented it out.
All 192.168.x.y INPUT packets traverse the INPUT chain. They
aren't explicitly dropped like the Class-[A,B] addresses are.
If they are from $LOCAL_NET for ports I allow they find an
ACCEPT rule and are passed. If they're NOT from $LOCAL_NET,
e.g. 192.168.0.y, 192.168.[2-255].y, etc., OR they're $LOCAL_NET
to a prohibited port, they NEVER find an ACCEPTing rule. They
traverse the entire chain to the bottom where they get shunted
to log-it, where they're logged & dropped.
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?
Yes. My perimeter firewall/router machine is 192.168.1.254 on
my LAN. I'm not running a DMZ setup.
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.
It's in iptables-1.2.11.
$man iptables-save
$man iptables-restore
MA> So you like sending youself error messages? Did i say you shouldn't
MA> log it? Why not just log and drop it?
Yes. I don't like sitting there while a failing operation times
out. If it isn't going to work, I'd like to know about it
immediately by returning an error code.
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?
You mean set-up the blacklisting on the perimeter firewall?
That's a lot harder.
PR>> Ummm, paranoia?
MA> Then don't let it in in the first place.
I don't. Net-filter is a kernel facility. They never make
it through.
MA> Are you telling me that $IP is a variable? You must have the distro
MA> from hell.
It is defined in /etc/sysconfig/network_devices/ifconfig.eth0,
and sourced in several scripts: here in firewall, &
/etc/rc.d/init.d/network. RedHat does it similarly.
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.
As it says, someone else wrote a firewall script which I took
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.
It does, when you have a connection to a DNS server. It hangs
unless you specify -n and you need a DNS lookup. My way, I can
update my workstation when the network is down and it doesn't
hang for DNS lookups.
---
* Origin: The Bare Bones BBS (1:105/360)
|