|
Home > Archive > Unix administration > January 2004 > Re: Iptables or misconfiguration?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Iptables or misconfiguration?
|
|
| James T. Dennis 2004-01-23, 4:27 pm |
| Diogo C. Pereira <diogocolla@yahoo.com> wrote:quote:
> I'm building up a router with IPTABLES. My wish is to isolate the
> internal network from the internet. I inserted two rules to it:
quote:
> /usr/sbin/iptables -t nat -P POSTROUTING DROP
> /usr/sbin/iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to
> my_address
quote:
> NAT works very well, but what I get is that the router doesn't
> communicates with the machines on the internal network, but the
> machines communicate with the router.
> When I try to ping some 192.168.0. from the router, it says:
quote:
> PING 192.168.0.3 (192.168.0.3): 56 data bytes
> ping: sendto: Operation not permitted
> ping: wrote 192.168.0.3 64 chars, ret=-1
quote:
> I need to ssh and other things to the internal network...
> where am I failing?
You're being a little too simplistic. In general you should bind your
rules to a particular interface.
It is quite reasonable to block all the RFC 1918 blocks (10.0.0.0/8,
172.16.0.0/12, and 192.168.0.0/16) as well as "martians" (127.0.0.0/8)
and a few other known reserved blocks (168.254.0.0) (see
ftp://ftp.rfc-editor.org/in-notes/rfc3330.txt for a list and some
discussion on that).
These addresses should never appear as sources on any packets you receive
from the Internet. So you can presume that they are spoofed. I recommend
DROP as your policy for these sorts of inbound packets; but I wouldn't
bother logging them. (It's just doorknob twisting and is a waste of your
time to count how often portscanners and other malware are sweeping the
'net).
A rule for outbound packets should simply require that they have a
one of your valid (ISP assigned) addresses. This prevents your site from
emitting any spoofed packets and is the crux of egress filtering. It
means that many sorts of DDoS worm would be prevented from using your site
to attack others. In addition a cracker who broke into your site would
find your network connections of limited use as a launch point for further
attacks (assuming he/she didn't manage to "own" your router, too).
I recommend these be REJECTed and logged. (You should be alerted to any
attempts by your users to spoof or abuse the 'net --- that you *can* and
should do something about).
Anyway, you could just put in an accept rule:
/usr/sbin/iptables -t filter -A OUTPUT -o eth0 -j ALLOW -s $MYIPADDR
... I think this should only apply to packets generated by local processes
(according the man page) and should pre-empt any other rules that would
otherwise effect the packet).
Do not remove (ellide) my signature from any E-MAIL replies.
--
Jim Dennis,
Starshine: Signed, Sealed, Delivered
| |
| James T. Dennis 2004-01-23, 4:38 pm |
| Diogo C. Pereira <diogocolla@yahoo.com> wrote:quote:
> I'm building up a router with IPTABLES. My wish is to isolate the
> internal network from the internet. I inserted two rules to it:
quote:
> /usr/sbin/iptables -t nat -P POSTROUTING DROP
> /usr/sbin/iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to
> my_address
quote:
> NAT works very well, but what I get is that the router doesn't
> communicates with the machines on the internal network, but the
> machines communicate with the router.
> When I try to ping some 192.168.0. from the router, it says:
quote:
> PING 192.168.0.3 (192.168.0.3): 56 data bytes
> ping: sendto: Operation not permitted
> ping: wrote 192.168.0.3 64 chars, ret=-1
quote:
> I need to ssh and other things to the internal network...
> where am I failing?
You're being a little too simplistic. In general you should bind your
rules to a particular interface.
It is quite reasonable to block all the RFC 1918 blocks (10.0.0.0/8,
172.16.0.0/12, and 192.168.0.0/16) as well as "martians" (127.0.0.0/8)
and a few other known reserved blocks (168.254.0.0) (see
ftp://ftp.rfc-editor.org/in-notes/rfc3330.txt for a list and some
discussion on that).
These addresses should never appear as sources on any packets you receive
from the Internet. So you can presume that they are spoofed. I recommend
DROP as your policy for these sorts of inbound packets; but I wouldn't
bother logging them. (It's just doorknob twisting and is a waste of your
time to count how often portscanners and other malware are sweeping the
'net).
A rule for outbound packets should simply require that they have a
one of your valid (ISP assigned) addresses. This prevents your site from
emitting any spoofed packets and is the crux of egress filtering. It
means that many sorts of DDoS worm would be prevented from using your site
to attack others. In addition a cracker who broke into your site would
find your network connections of limited use as a launch point for further
attacks (assuming he/she didn't manage to "own" your router, too).
I recommend these be REJECTed and logged. (You should be alerted to any
attempts by your users to spoof or abuse the 'net --- that you *can* and
should do something about).
Anyway, you could just put in an accept rule:
/usr/sbin/iptables -t filter -A OUTPUT -o eth0 -j ALLOW -s $MYIPADDR
... I think this should only apply to packets generated by local processes
(according the man page) and should pre-empt any other rules that would
otherwise effect the packet).
Do not remove (ellide) my signature from any E-MAIL replies.
--
Jim Dennis,
Starshine: Signed, Sealed, Delivered
| |
| James T. Dennis 2004-01-23, 4:54 pm |
| Diogo C. Pereira <diogocolla@yahoo.com> wrote:quote:
> I'm building up a router with IPTABLES. My wish is to isolate the
> internal network from the internet. I inserted two rules to it:
quote:
> /usr/sbin/iptables -t nat -P POSTROUTING DROP
> /usr/sbin/iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to
> my_address
quote:
> NAT works very well, but what I get is that the router doesn't
> communicates with the machines on the internal network, but the
> machines communicate with the router.
> When I try to ping some 192.168.0. from the router, it says:
quote:
> PING 192.168.0.3 (192.168.0.3): 56 data bytes
> ping: sendto: Operation not permitted
> ping: wrote 192.168.0.3 64 chars, ret=-1
quote:
> I need to ssh and other things to the internal network...
> where am I failing?
You're being a little too simplistic. In general you should bind your
rules to a particular interface.
It is quite reasonable to block all the RFC 1918 blocks (10.0.0.0/8,
172.16.0.0/12, and 192.168.0.0/16) as well as "martians" (127.0.0.0/8)
and a few other known reserved blocks (168.254.0.0) (see
ftp://ftp.rfc-editor.org/in-notes/rfc3330.txt for a list and some
discussion on that).
These addresses should never appear as sources on any packets you receive
from the Internet. So you can presume that they are spoofed. I recommend
DROP as your policy for these sorts of inbound packets; but I wouldn't
bother logging them. (It's just doorknob twisting and is a waste of your
time to count how often portscanners and other malware are sweeping the
'net).
A rule for outbound packets should simply require that they have a
one of your valid (ISP assigned) addresses. This prevents your site from
emitting any spoofed packets and is the crux of egress filtering. It
means that many sorts of DDoS worm would be prevented from using your site
to attack others. In addition a cracker who broke into your site would
find your network connections of limited use as a launch point for further
attacks (assuming he/she didn't manage to "own" your router, too).
I recommend these be REJECTed and logged. (You should be alerted to any
attempts by your users to spoof or abuse the 'net --- that you *can* and
should do something about).
Anyway, you could just put in an accept rule:
/usr/sbin/iptables -t filter -A OUTPUT -o eth0 -j ALLOW -s $MYIPADDR
... I think this should only apply to packets generated by local processes
(according the man page) and should pre-empt any other rules that would
otherwise effect the packet).
Do not remove (ellide) my signature from any E-MAIL replies.
--
Jim Dennis,
Starshine: Signed, Sealed, Delivered
|
|
|
|
|