Re: Request for comments: iptables script for use on laptops.
Hi,
On Wed, May 24, 2006 at 06:52:59AM +0200, Mike Dornberger wrote:
> So what can happen? {SYN,ICMP} floods, TCP RST attacks, but the last one is
> then just guesswork (assuming the attacker can't see the real traffic at
> 192.168.0.0/24 else you already have a big problem). Am I missing something?
Unfortunately, it's very common for an attacker to be able to watch
local traffic if you're on a hostile network with your laptop, for
example...
> I have a rule for spoofed localhost addresses, I took from someone else some
> time ago at top of my INPUT chain:
>
> iptables -A INPUT -d 127.0.0.0/8 -i ! lo -j DROP
Nice. There are probably more (similar) things you can do. I need to
read a bit more about how rp_filter and friends work. Isn't the above
already covered by rp_filter or some similar config option?
> Hm, I often see people first cleaning/flushing/deleting the rules and then
> setting the default policy. If the policy was for some reason set to ACCEPT,
> you have a small time window when packets will be accepted, that got dropped
> or rejected before by the rules you just deleted. Why not first set the
> policy to DROP and then deleting rules?
Good point. But is the default policy deleted or reset after a
clean/flush/delete? If not, this is probably a good idea.
> Something different I saw at various iptables scripts, that I don't quite
> understand: Why do people put so much rules into the OUTPUT chain?
Easy - for increased security. With this approach I know exactly which
traffic will go out of my computer (on which ports).
Anything running on my computer trying to use some other port is logged.
I can then decide whether I just missed a rule (i.e. it's valid traffic)
and adapt the script accordingly, or if it's some nasty application,
trojan, rootkit, spyware, whatever which tries to "phone home"...
For example, I remember having heard of a version of Adobe Acrobat
Reader (for Linux) secretly connecting to some obscure Adobe server and
sending some information (don't know whether it was a fake or not)...
This kind of stuff can (sometimes) be prevented by filtering OUTPUT.
Another example: I don't want to _ever_ use unencrypted POP3 to fetch
emails, so I block that port. Now I simply cannot do that mistake, not
even by accident.
> For
> single user workstation/notebooks it hinders yourself a lot. E. g. you allow
> access to some services like HTTP or SSH on other hosts. But what if you
> want to connect to host that has that service running on an unusual port?
> You then need to tweak you iptables script as root...
Exactly :)
> Is it because you don't trust the software that is running?
That's one of the reasons, yes. Trust noone ;)
> Especially since
> this is a Debian mailing list here: You have the sources. If a service can't
> bind to only 127.0.0.1, change it!
True. Still, sometimes you (or your local users) might run software you
don't know, didn't check, or which is simply closed-source. Again, a
firewall might help here in certain situations.
> Or is it because you don't trust the other users there?
That can be another reason. Trust noone ;)
> Why do they have an
> account then or a computer that is connected to the internet (assuming you
> don't want them to surf or run some file exchange/p2p service)?
Sometimes they want/need an account. If you don't (fully) trust them, you can
limit the amount of damage they can do somewhat. One method for doing so
is a firewall.
> Once you
> allow a user to just connect to a single port "out there", he might start to
> tunnel stuff if he really wants to do something else...
True.
> (ssh over HTTP someone?)
Or ssh over DNS.
> Maybe blocking something in OUTPUT is reasonable for servers as a stumbling
> block if a service got taken over but then it probably won't be long until
> the intruder got root access there and removes the rules anyway.
True. Of course, it's not a complete "now we're 100% safe" method,
but it helps prevent _some_ problems.
Cheers, Uwe.
--
Uwe Hermann
http://www.hermann-uwe.de
http://www.it-services-uh.de | http://www.crazy-hacks.org
http://www.holsham-traders.de | http://www.unmaintained-free-software.org
signature.asc
Description: Digital signature
Re: Request for comments: iptables script for use on laptops.
Hi, On Tue, May 23, 2006 at 07:29:44PM +0400, Konstantin Khomoutov wrote: > On Tue, May 23, 2006 at 04:36:31PM +0200, Uwe Hermann wrote: > > >>> useless. Did I miss anything? > >> Kernel shoots any packet it considers as being "martian" -- e.g. packets > >> from 127.0.0.0/8 cannot appear on any interface except lo. > >> The same applies to the reverse case: no packet coming from "external" > >> interface but claiming to be destined to 127.0.0.0/8 woun't be passed > >> further by the kernel. > >> > >> net/ipv4/conf/ethN/log_martians=1 > > Are you sure? log_martians does just that, it _logs_ such > > packets/attempts, but it does not prevent them (at least the kernel > > docs don't say so). > Yes, this option just logs them. > But they get logged when they are killed. > > This behaviour, BTW, even forbids manual FORWARDing rules in iptables > that redirect packets from "external" interfaces to lo. While the > Netfilter framework will happily accept such rules, kernel will shoot > packets forwarded this way since it sees a packet that came from external > iface but is destined to localhost (which cannot occur). > > This behaviour costed me several days to figure out while I tried to set > up IPSec (openswan) + L2TP (l2tpd) server. The idea of this setup is > that 1) IPSec virtual ifaces are coupled with real Inet ifaces; 2) After > openswan did it's work, kernel sees "just IP" packes as if they were > coming from the real Inet iface. We then should forward these packets to > L2TP daemon, and the straightforward solution -- to bind l2tpd to the > localhost -- simply doesn't work since l2tpd sees no packets: they are > all killed by the kernel (as going from external interface and destined > to localhost). The working solution is to put l2tpd to a LAN iface > (another external one) and deny direct connections to in from that iface > (only forwarded packets must reach). > > I think you may be misguided (as I was) by the fact that packets to > localhost are "destined to us" and must be accepted. But think of it: > when some *other* host wants to send us a packet, it sends it to one of > our "external" IP addresses, not to 127.0.0.1! And we get this packet as > destined to that "external" IP. Packets destined to localhost can really > be generated only by localhost. That's why it's called loopback, after > all. ;-) > > >> I think the best way to secure the box is the simplest: allow incoming > >> packets with states ESTABLISHED and RELATED, deny all others (except for > >> OpenVPN or whatever remote access is needed). > > I fully agree. That's what I'm trying to do with my script. The only > > other thing I let in is some types of ICMP packets... > >> All special ICMP packets needed for proper functioning of TCP/IP (PMTU > >> discovery for example) fall to the RELATED domain and are passed to the > >> stack. > > I currently have the below lines to handle ICMP. So are you saying I > > could safely remove the last three lines, as they're already handled by > > ESTABLISHED and RELATED? > I'm not *surely* confident about this, but they must be counted as > RELATED. My setups are based on this and it seems to work. > > ESTABLISHED is only useful for TCP, it's not about ICMP. > > P.S. > Our conversation should better occur on the debian-security > mailing list, I think. ;-) Indeed :) Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org signature.asc Description: Digital signature
Re: Request for comments: iptables script for use on laptops.
Hi, On Tue, May 23, 2006 at 10:01:46AM +0200, Rolf Kutz wrote: > > > iptables -A INPUT -j ACCEPT -s 127.0.0.1 # local host > > > iptables -A OUTPUT -j ACCEPT -d 127.0.0.1 > > > > Correct me if I'm wrong, but I think this would also allow incoming > > traffic from 127.0.0.1 to the eth0 interface. So somebody spoofing > > his IP address to appear to be 127.0.0.1 could send _any_ traffic > > to you and you would ACCEPT it, basically rendering the firewall > > useless. Did I miss anything? > > Maybe this: > > | echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter Um, no. The line is from my own script, but the one from George Hein (which I was referring to) does not have that line. Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org signature.asc Description: Digital signature
Re: Request for comments: iptables script for use on laptops.
Hi, On Tue, May 23, 2006 at 10:02:33PM -0400, Michael Stone wrote: > (E.g., want to be able to test > without the complexity of an encryption layer, don't want overhead of > encrypting both sides of a local connection, etc.) Aside from that, > yeah, ip addresses shouldn't be used for authentication on untrusted > networks. (Though they are useful as one layer of security, to mitigate > the risk of vulnerabilities in the encryption routines.) Full ACK. It's one additional layer of security, but should never be relied upon alone. Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org signature.asc Description: Digital signature
Re: Request for comments: iptables script for use on laptops.
Mike Dornberger <[EMAIL PROTECTED]> wrote: >> > If I set up my firewall to accept only my local network (eg. >> > -s 192.168.0.0/255.255.255.0) connecting to a port (eg. smtp), then >> > anyone can spoof that too. So what's the point of creating rules? :) > > even if one can spoof the IP, he (= the attacker) can't do very much more > (assuming, he can't read local traffic), at least with TCP connection. And he needs to get around the ingress spoof filter. You of course dont accept ip packets with the internal addresses on the external interface. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for comments: iptables script for use on laptops.
Hi,
On Tue, May 23, 2006 at 03:40:58PM +0200, Michel Messerschmidt wrote:
> LeVA said:
> > If I set up my firewall to accept only my local network (eg.
> > -s 192.168.0.0/255.255.255.0) connecting to a port (eg. smtp), then
> > anyone can spoof that too. So what's the point of creating rules? :)
even if one can spoof the IP, he (= the attacker) can't do very much more
(assuming, he can't read local traffic), at least with TCP connection.
First, he has to guess the initial sequence number the server (e. g. SMTP)
would send for that connection. If the TCP stack is patched properly (maybe
this is already added to Linux mainline), then this guess is 1 out of 2**32.
(If it isn't patched, with a bit of investigating the traffic of that server
-- valid connections from your computer are probably enough -- the ISN is
much easier to guess.)
After that, the attacker must exactly know how many bytes the servers sends
within each TCP packet (the attacker usually won't see the packets sent by
the server), so he can send the the right ACK number.
Also, if the attacker uses an IP address that is active, the SYN+ACK from
the server to that IP will trigger a TCP RESET AFAIUI from that station and
the connection won't be opened. (In case of UDP that station might send a
ICMP "destination unreachable" and the server won't "open" that connection,
also.)
So what can happen? {SYN,ICMP} floods, TCP RST attacks, but the last one is
then just guesswork (assuming the attacker can't see the real traffic at
192.168.0.0/24 else you already have a big problem). Am I missing something?
> This is ok. You simply need some more "anti-spoofing" rules.
> You can allow packets from 127.0.0.1 only if they come from the loopback
> interface. And you may want to discard packets coming from the internal
> network card, if they don't have an appropriate IP address.
I have a rule for spoofed localhost addresses, I took from someone else some
time ago at top of my INPUT chain:
iptables -A INPUT -d 127.0.0.0/8 -i ! lo -j DROP
Thinking about it, I wonder, whether I should add the same rule for source =
127.0.0.0/8. What can happen, if someone sends me a packet with
src=127.x.x.x and dst=x.x.x.x (!=127.x.x.x) over iface!=lo?
If dst!=one of my_ip_addresses it won't go into INPUT. FORWARD has DROP
policy and it's not (on my router) from a local network address (192.*) nor
state related/established -> drop.
But what if dst==one of my_ip_addresses? Assuming kernel generates some
package with src and dst exchanged. I think it can't interfere with
processes running locally and communicating over some IP based protocol,
since there is no valid 127.x.x.x<->129.168.x.x (or other private subnets)
or 127.x.x.x<->3.3.3.3 (<- some valid, official assigned IP address)
connection.
Something bad could happen, if kernel builds the new package with
dst=old_source and src=127.y.y.y. Does someone know what the kernel will do
in such a case when I get a packet with src=127.x.x.x and dst=x.x.x.x?
> Here is an example: http://www.sns.ias.edu/~jns/files/iptables_ruleset
Hm, I often see people first cleaning/flushing/deleting the rules and then
setting the default policy. If the policy was for some reason set to ACCEPT,
you have a small time window when packets will be accepted, that got dropped
or rejected before by the rules you just deleted. Why not first set the
policy to DROP and then deleting rules?
# set policy to drop, flush the tables' chains and delete user chains
#
for CHAIN in INPUT OUTPUT FORWARD; do
#true
iptables -P $CHAIN DROP
done
for TABLE in filter nat mangle; do #filter is default (if -t is omitted)
iptables -t $TABLE -F
iptables -t $TABLE -X
done
(From reading iptables' man page and/or experimenting you need to
flush/delete the chains in different tables manually. I hadn't found a
"general reset" option back then.)
For TCP, if a packet got dropped in that time window, it will be resent
eventually. For UDP your application is required to deal with dropped
packages gracefully (it could have been dropped elsewhere) and I think ICMP
is not so much important (and could be dropped elsewhere, too). If you run
other protocols on top of IP (maybe BGP or something), you probably shut
down that service beforehand (if it can't deal with some few packages being
dropped).
Something different I saw at various iptables scripts, that I don't quite
understand: Why do people put so much rules into the OUTPUT chain? For
single user workstation/notebooks it hinders yourself a lot. E. g. you allow
access to some services like HTTP or SSH on other hosts. But what if you
want to connect to host that has that service running on an unusual port?
You then need to tweak you iptables script as root...
Is it because you don't trust the software that is running? Especially since
this is a Debian mailing list here: You have the sources. If a service can't
bind to only 127.0.0.1, chan
Re: Request for comments: iptables script for use on laptops.
On Tue, May 23, 2006 at 02:10:19PM +0200, marco.celeri wrote: yes, i think this allow incoming spoofed traffic to eth0 (or it is "martian?") but the response must follow what found in routing table -> lo interfaces... am i wong? Yes, but that doesn't necessarily help in the case of a single-packet exploit, for example. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for comments: iptables script for use on laptops.
On Tue, May 23, 2006 at 04:20:58PM +0200, Uwe Hermann wrote: On Tue, May 23, 2006 at 09:53:05AM +0200, LeVA wrote: But if one can spoof 127.0.0.1, then one can spoof anything else, so creating any rule with an ip address matching is useless. Correct. IP-based authentication is inherently flawed. If you want something like that, use strong cryptography to verify the sender/receiver (think certificates, SSL, etc.). No, it's not inherently flawed for loopback addresses on the loopback interface. There are valid reasons to want a different set of rules on the local host than on the network. (E.g., want to be able to test without the complexity of an encryption layer, don't want overhead of encrypting both sides of a local connection, etc.) Aside from that, yeah, ip addresses shouldn't be used for authentication on untrusted networks. (Though they are useful as one layer of security, to mitigate the risk of vulnerabilities in the encryption routines.) Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for comments: iptables script for use on laptops.
Hi, On Tue, May 23, 2006 at 09:53:05AM +0200, LeVA wrote: > But if one can spoof 127.0.0.1, then one can spoof anything else, so creating > any rule with an ip address matching is useless. Correct. IP-based authentication is inherently flawed. If you want something like that, use strong cryptography to verify the sender/receiver (think certificates, SSL, etc.). > If I set up my firewall > to accept only my local network (eg. -s 192.168.0.0/255.255.255.0) connecting > to a port (eg. smtp), then anyone can spoof that too. So what's the point of > creating rules? :) Well, there are still some benefits in using a firewall. For example, if you don't allow access to any port per default, but only open a few ones you really need (in case you're running servers which must be reachable from the net). If you accidentally/unknowingly install/start a daemon which should _not_ be reachable from outside, the firewall will block any traffic to it, and hence any exploit attempts. There are many other valid examples. It's not the concept of a firewall that is flawed, it's relying on IP addresses for authentication which is a bad idea. Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org signature.asc Description: Digital signature
Re: Request for comments: iptables script for use on laptops.
2006. május 23. 10:06, Rolf Kutz <[EMAIL PROTECTED]> -> debian-security@lists.debian.org,: > * Quoting LeVA ([EMAIL PROTECTED]): > > > iptables -A INPUT -i lo -j ACCEPT > > > iptables -A OUTPUT -o lo -j ACCEPT > > > > But if one can spoof 127.0.0.1, then one can spoof anything else, so > > creating any rule with an ip address matching is useless. No? If I set up > > my firewall to accept only my local network (eg. -s > > 192.168.0.0/255.255.255.0) connecting to a port (eg. smtp), then anyone > > can spoof that too. So what's the point of creating rules? :) > > The script under scrutiny was intended for a > laptop. A router or firewall setup is something > different and should not route traffic with > spoofed addresses. rp_filter should catch this > easily, if you can use it. If not, an IP-based > rule is ok, IMHO. So sticking with the smtp example, if I have enabled rp_filter, then does it matter whether I'm using this: iptables -A INPUT -p tcp -i lo --dport 25 -j ACCEPT or this: iptables -A INPUT -p tcp -s 127.0.0.1 --dport 25 -j ACCEPT Daniel -- LeVA
Re: Request for comments: iptables script for use on laptops.
LeVA said: > But if one can spoof 127.0.0.1, then one can spoof anything else, so > creating any rule with an ip address matching is useless. No? It's not totally useless but gives only a minor level of protection, i.e. it helps against attacks without spoofing :) > If I set up my firewall to accept only my local network (eg. > -s 192.168.0.0/255.255.255.0) connecting to a port (eg. smtp), then > anyone can spoof that too. So what's the point of creating rules? :) This is ok. You simply need some more "anti-spoofing" rules. You can allow packets from 127.0.0.1 only if they come from the loopback interface. And you may want to discard packets coming from the internal network card, if they don't have an approriate IP address. Here is an example: http://www.sns.ias.edu/~jns/files/iptables_ruleset -- Michel Messerschmidt, [EMAIL PROTECTED] $ rpm -q --whatrequires linux no package requires linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for comments: iptables script for use on laptops.
On Tue, May 23, 2006 at 02:04:13AM +0200, Uwe Hermann wrote: [...] >> iptables -A INPUT -j ACCEPT -s 127.0.0.1 # local host >> iptables -A OUTPUT -j ACCEPT -d 127.0.0.1 > Correct me if I'm wrong, but I think this would also allow incoming > traffic from 127.0.0.1 to the eth0 interface. So somebody spoofing > his IP address to appear to be 127.0.0.1 could send _any_ traffic > to you and you would ACCEPT it, basically rendering the firewall > useless. Did I miss anything? Kernel shoots any packet it considers as being "martian" -- e.g. packets from 127.0.0.0/8 cannot appear on any interface except lo. The same applies to the reverse case: no packet coming from "external" interface but claiming to be destined to 127.0.0.0/8 woun't be passed further by the kernel. See RFC 1812 for explanations. One can switch logging records about killed martian packets with net/ipv4/conf/ethN/log_martians=1 in /etc/sysctl.conf [...] I agree to your other comments. P.S. I think the best way to secure the box is the simplest: allow incoming packets with states ESTABLISHED and RELATED, deny all others (except for OpenVPN or whatever remote access is needed). May be it's also worth accepting ICMP Ping packets. All special ICMP packets needed for proper functioning of TCP/IP (PMTU discovery for example) fall to the RELATED domain and are passed to the stack. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for comments: iptables script for use on laptops.
On Tue, May 23, 2006 at 10:06:45AM +0200, Rolf Kutz wrote: The script under scrutiny was intended for a laptop. A router or firewall setup is something different and should not route traffic with spoofed addresses. rp_filter should catch this easily, if you can use it. If not, an IP-based rule is ok, IMHO. No, if you mean to accept loopback traffic then you should accept -i lo. If nothing else, all of 127.0.0.0/8 is loopback addresses, not just 127.0.0.1, and I have seen software that makes use of that. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for comments: iptables script for use on laptops.
Hi, > > iptables -A INPUT -j ACCEPT -s 127.0.0.1 # local host > > iptables -A OUTPUT -j ACCEPT -d 127.0.0.1 > > Correct me if I'm wrong, but I think this would also allow incoming > traffic from 127.0.0.1 to the eth0 interface. So somebody spoofing > his IP address to appear to be 127.0.0.1 could send _any_ traffic > to you and you would ACCEPT it, basically rendering the firewall > useless. Did I miss anything? > yes, i think this allow incoming spoofed traffic to eth0 (or it is "martian?") but the response must follow what found in routing table -> lo interfaces... am i wong? bye
Re: Request for comments: iptables script for use on laptops.
* Quoting Michael Stone ([EMAIL PROTECTED]): > On Tue, May 23, 2006 at 10:06:45AM +0200, Rolf Kutz wrote: > >The script under scrutiny was intended for a > >laptop. A router or firewall setup is something > >different and should not route traffic with > >spoofed addresses. rp_filter should catch this > >easily, if you can use it. If not, an IP-based > >rule is ok, IMHO. > > No, if you mean to accept loopback traffic then you should accept -i lo. > If nothing else, all of 127.0.0.0/8 is loopback addresses, not just > 127.0.0.1, and I have seen software that makes use of that. Locally, yes, but on a firewall or router? _And I was referring to 192.168.x.x addresses. - Rolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for comments: iptables script for use on laptops.
* Quoting LeVA ([EMAIL PROTECTED]): > > iptables -A INPUT -i lo -j ACCEPT > > iptables -A OUTPUT -o lo -j ACCEPT > > > But if one can spoof 127.0.0.1, then one can spoof anything else, so creating > any rule with an ip address matching is useless. No? If I set up my firewall > to accept only my local network (eg. -s 192.168.0.0/255.255.255.0) connecting > to a port (eg. smtp), then anyone can spoof that too. So what's the point of > creating rules? :) The script under scrutiny was intended for a laptop. A router or firewall setup is something different and should not route traffic with spoofed addresses. rp_filter should catch this easily, if you can use it. If not, an IP-based rule is ok, IMHO. - Rolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for comments: iptables script for use on laptops.
* Quoting Uwe Hermann ([EMAIL PROTECTED]): > > iptables -A INPUT -j ACCEPT -s 127.0.0.1 # local host > > iptables -A OUTPUT -j ACCEPT -d 127.0.0.1 > > Correct me if I'm wrong, but I think this would also allow incoming > traffic from 127.0.0.1 to the eth0 interface. So somebody spoofing > his IP address to appear to be 127.0.0.1 could send _any_ traffic > to you and you would ACCEPT it, basically rendering the firewall > useless. Did I miss anything? Maybe this: | echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter - Rolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for comments: iptables script for use on laptops.
2006. május 23. 02:04, Uwe Hermann <[EMAIL PROTECTED]> -> George Hein <[EMAIL PROTECTED]>,debian-laptop@lists.debian.org, debian-security@lists.debian.org: > > iptables -A INPUT -j ACCEPT -s 127.0.0.1 # local host > > iptables -A OUTPUT -j ACCEPT -d 127.0.0.1 > > Correct me if I'm wrong, but I think this would also allow incoming > traffic from 127.0.0.1 to the eth0 interface. So somebody spoofing > his IP address to appear to be 127.0.0.1 could send _any_ traffic > to you and you would ACCEPT it, basically rendering the firewall > useless. Did I miss anything? > > The following should be better, as it only allows traffic to/from the > loopback interface (but not eth0 or what have you)... > > iptables -A INPUT -i lo -j ACCEPT > iptables -A OUTPUT -o lo -j ACCEPT > But if one can spoof 127.0.0.1, then one can spoof anything else, so creating any rule with an ip address matching is useless. No? If I set up my firewall to accept only my local network (eg. -s 192.168.0.0/255.255.255.0) connecting to a port (eg. smtp), then anyone can spoof that too. So what's the point of creating rules? :) Daniel -- LeVA
Re: Request for comments: iptables script for use on laptops.
Hi, On Mon, May 22, 2006 at 07:57:59AM -0400, George Hein wrote: > Your iptables scares me a bit, do we really have to do all that stuff > like "echo to /proc/sys/...". I was a TP professional many years ago > but since the internet I have become a novice, thus running scared. You don't really _need_ those lines, but they're mostly useful in that they add some more levels of security (or mitigate some attacks), in addition to just closing TCP/UDP ports. > iptables -A INPUT -j ACCEPT -s 127.0.0.1 # local host > iptables -A OUTPUT -j ACCEPT -d 127.0.0.1 Correct me if I'm wrong, but I think this would also allow incoming traffic from 127.0.0.1 to the eth0 interface. So somebody spoofing his IP address to appear to be 127.0.0.1 could send _any_ traffic to you and you would ACCEPT it, basically rendering the firewall useless. Did I miss anything? The following should be better, as it only allows traffic to/from the loopback interface (but not eth0 or what have you)... iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT > iptables -A INPUT -j ACCEPT -s 192.168.0.0/28 # allow x.x.x.1-7 > iptables -A OUTPUT -j ACCEPT -d 192.168.0.0/28 IP-based blocking of traffic is almost always not a good idea. Same reason as above - IPs are easily faked, so any intruder could pretend to be 192.168.0.2 and would bypass the firewall. > # iptables -A INPUT -j ACCEPT -p icmp -m icmp --icmp-type 3 > # iptables -A OUTPUT -j ACCEPT -p icmp -m icmp --icmp-type 3 > iptables -A INPUT -j ACCEPT -p tcp -m multiport --port > 20,21,25,37,80,110,111,119,443 > iptables -A INPUT -j ACCEPT -p udp -m multiport --port > 53,67,68,111,520,631 Are you sure you want to allow the whole Internet access to all those ports? Especially portmap, FTP, CUPS etc? Are you running a server which needs to be reachable from the Internet? Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org signature.asc Description: Digital signature
Re: Request for comments: iptables script for use on laptops.
Hi, On Mon, May 22, 2006 at 03:16:04PM -0700, Vineet Kumar wrote: > > echo 1 > /proc/sys/net/ipv4/ip_forward > > echo 0 > /proc/sys/net/ipv4/ip_forward > > While I haven't yet gone through the actual content of the script, a > note of style preference: > > Personally, I prefer using sysctl -w instead of echo > /proc/sys. I > prefer /etc/sysctl.conf further still. Ok, this is a matter of taste, I guess. I would argue that echo is available pretty much everywhere, but on the other hand sysctl should also be available everywhere where you have iptables... Is there any _real_ reason why sysctl might be better in certain situations? For me /etc/sysctl.conf is not so nice, as I want to be able to download my own script from my website when I'm at other machines which I want to secure. Thus, I'd like to have everything in one single script (vs. multiple files). Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org signature.asc Description: Digital signature
Re: Request for comments: iptables script for use on laptops.
Hi, You have FORWARD policy set to DROP (not by default but by rule) -> you don't need "echo ... /ip_forward" I don't like to log all what it drop, it can make full a partition and it is not good :) bye > Your iptables scares me a bit, do we really have to do all that stuff > like "echo to /proc/sys/...". I was a TP professional many years ago > but since the internet I have become a novice, thus running scared. > > My script is simple, and perhaps too simple for some 6 PC's. > I even have FTP/20+21 turned off most of the time, and I question some > of the others (put them on due to err-log messages). > > > > #!/bin/sh > # /opt/sbin/ziptables > # /etc/init.d/local > # >iptables -t mangle -F # flush all: mangle,nat,filter >iptables -t nat-F # flush all: mangle,nat,filter >iptables -t filter -F # flush all: mangle,nat,filter >iptables -A INPUT -j ACCEPT -s 127.0.0.1 # local host >iptables -A OUTPUT -j ACCEPT -d 127.0.0.1 >iptables -A INPUT -j ACCEPT -s 192.168.0.0/28 # allow x.x.x.1-7 >iptables -A OUTPUT -j ACCEPT -d 192.168.0.0/28 >iptables -A FORWARD -j DROP > # > # PASS ICMP TYPE 3 PACKETS (avoid ping, allow nfs) > # iptables -A INPUT -j ACCEPT -p icmp -m icmp --icmp-type 3 > # iptables -A OUTPUT -j ACCEPT -p icmp -m icmp --icmp-type 3 > # > # [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL > PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED] > # [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED] > # [EMAIL PROTECTED],[EMAIL PROTECTED] > # [EMAIL PROTECTED],MOUNTD@(add "MOUNTD_PORT=3" to /etc/sysconfig/nfs) > # [EMAIL PROTECTED] > >iptables -A INPUT -j ACCEPT -p tcp -m multiport --port > 20,21,25,37,80,110,111,119,443 > >iptables -A OUTPUT -j ACCEPT -p tcp -m multiport --port > 25,37,80,110,111,119,443 > >iptables -A INPUT -j ACCEPT -p udp -m multiport --port > 53,67,68,111,520,631 > >iptables -A OUTPUT -j ACCEPT -p udp -m multiport --port > 53,67,68,111,520,631,5353 > # > # LOG DROP THROUGHS FOR DIAGNOSTICS, WRITTEN TO /var/log/messages >iptables -A INPUT -j LOG --log-prefix ZZI- >iptables -A OUTPUT -j LOG --log-prefix ZZO- >iptables -A INPUT -j DROP >iptables -A OUTPUT -j DROP >iptables -L > # >
Re: Request for comments: iptables script for use on laptops.
* Uwe Hermann ([EMAIL PROTECTED]) [060521 11:18]: > echo 1 > /proc/sys/net/ipv4/ip_forward > echo 0 > /proc/sys/net/ipv4/ip_forward While I haven't yet gone through the actual content of the script, a note of style preference: Personally, I prefer using sysctl -w instead of echo > /proc/sys. I prefer /etc/sysctl.conf further still. Vineet -- http://www.doorstop.net/ -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." --Benjamin Franklin signature.asc Description: Digital signature
Request for comments: iptables script for use on laptops.
Hi everyone, this is crossposted to debian-laptop and debian-security, as I believe it is relevant to both. Today, I have heavily updated my (GPL'd) iptables script which I have been using for quite a while now to secure my laptop (and various workstations). The script is available from http://www.hermann-uwe.de/files/fw_laptop and is also attached to this email. The goal is to have a very paranoid/secure firewall ruleset (don't allow any incoming traffic, only allow minimal outgoing traffic) which makes sense for laptops. One major change is that EGRESS traffic is now blocked by default, too (INGRESS traffic was already blocked previously), and some more sysctl settings... I'd like to hear your opinions, comments, suggestions on the approach and the script. Did I miss some important issues? Did I mess up somewhere? Are there any serious flaws? Thanks in advance, Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org #!/bin/sh #-- # File: fw_laptop # Author: Uwe Hermann <[EMAIL PROTECTED]> # URL: http://www.hermann-uwe.de/files/fw_laptop # License: GNU GPL (version 2, or any later version). # $Id: fw_laptop 515 2006-05-21 17:13:43Z uh1763 $ #-- # A firewall script intended to be used on workstations / laptops. It basically # blocks all incoming traffic and only allows minimal outgoing traffic. # Note: This is work in progress! Any comments and suggestions are welcome! # Thanks for comments and suggestions: # * Jean Christophe André <[EMAIL PROTECTED]> # * Ryan Giobbi <[EMAIL PROTECTED]> #-- # Configuration. #-- # For debugging. # IPTABLES="/sbin/iptables -v" IPTABLES="/sbin/iptables" MODPROBE="/sbin/modprobe" # Logging options. # Note: We use --log-level debug, so that the messages are not output # to all virtual consoles (which would be quite annoying). # Alternative: Start klogd with -c 4 (e.g. by setting KLOGD="-c 4" in the # /etc/init.d/klogd startup-script. LOG="LOG --log-level debug --log-tcp-sequence --log-tcp-options" LOG="$LOG --log-ip-options" # Load required kernel modules (if automatic module loading is disabled). $MODPROBE ip_conntrack_ftp #-- # Kernel configuration. # For details see: # * http://www.securityfocus.com/infocus/1711 # * http://www.linuxgazette.com/issue77/lechnyr.html # * /usr/src/linux/Documentation/filesystems/proc.txt # * /usr/src/linux/Documentation/networking/ip-sysctl.txt #-- # Disable IP forwarding. # Note: Turning this on and off should reset all settings to their defaults. echo 1 > /proc/sys/net/ipv4/ip_forward echo 0 > /proc/sys/net/ipv4/ip_forward # Enable IP spoofing protection (i.e. source address verification). echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter # Protect against SYN flood attacks (see http://cr.yp.to/syncookies.html). echo 1 > /proc/sys/net/ipv4/tcp_syncookies # Ignore all (incoming + outgoing) ICMP ECHO requests (i.e. disable PING). # Usually not a good idea, as some protocols and users need/want this. # echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_all # Ignore ICMP ECHO requests to broadcast/multicast addresses. We do not # want to participate in smurf (and similar) DoS attacks. echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # Log packets with impossible addresses. echo 1 > /proc/sys/net/ipv4/conf/all/log_martians # Don't log invalid responses to broadcast frames, they just clutter the logs. echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses # Don't accept or send ICMP redirects. echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects # Don't accept source routed packets. echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route # Disable multicast routing. Should not be needed, usually. # TODO: This throws an "Operation not permitted" error. Why? # echo 0 > /proc/sys/net/ipv4/conf/all/mc_forwarding # Disable proxy_arp. Should not be needed, usually. echo 0 > /proc/sys/net/ipv4/conf/all/proxy_arp # Enable secure redirects, i.e. only accept ICMP redirects for gateways # listed in the default gateway list. Helps against MITM attacks. echo 1 > /proc/sys/net/ipv4/conf/all/secure_redirects # Disable bootp_relay. Should not be needed, usually. echo 0 > /proc/sys/net/ipv4/conf/all/bootp_relay # TODO: These may mitigate ARP poisoning attacks? # /proc/sys/net/ipv4/neigh/*/locktime # /proc/sys/net/ipv4/neigh/*/gc_stale_time #
