| View previous topic :: View next topic |
| Author |
Message |
wswartzendruber
Veteran
Joined: 23 Mar 2004
Posts: 1261
Location: Idaho, USA
|
 Posted: Mon Jun 02, 2008 11:06 pm Post subject: Obsessed With Security: Critique My IPTables Rules |
 |
|
Here is my IPTables script:
| Code: | IPTABLES='/sbin/iptables'
EXTIF='ppp0'
INTIF='eth1'
$IPTABLES -F
$IPTABLES -X
# Enable loopback.
$IPTABLES -A INPUT -i lo -j ACCEPT
# Setup strict forwarding rules.
$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
$IPTABLES -A FORWARD -j DROP
# Setup masquerading (NAT).
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE
# Setup strict input rules.
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -j DROP |
My goal is maximum security. These rules are designed to protect the router from both internal and external attack, while still allowing packets to pass through.
So what am I doing wrong here? What common attacks are these rules still vulnerable too?
_________________
Git has obsoleted SVN.
10mm Auto has obsoleted 45 ACP. |
|
| Back to top |
|
 |
Sadako
Advocate
Joined: 05 Aug 2004
Posts: 3792
Location: sleeping in the bathtub
|
| Posted: Mon Jun 02, 2008 11:50 pm Post subject: |
|
|
As I already suggested ( ), you should add "$IPTABLES -A INPUT -m state --state INVALID -j DROP" before "$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT" to drop any badly formed and possibly malicious packets.
"$IPTABLES -A INPUT -p tcp -m state --state NEW -m tcp ! --syn -j DROP" is one which catches a particular type of invalid packet which the INVALID state misses, although seeing as how you're not accepting any new connections it won't do anything on your current setup, but it's another one to keep in mind.
If you're using a grsec patched kernel (such as hardened-sources), there is a STEALTH module which would be worth enabling, and you can easily use hardened-sources on an otherwise non-hardened system without problems.
Finally, while it has nothing to do with security really, you'd be better of dropping the "$IPTABLES -A INPUT -j DROP" and adding "$IPTABLES -P INPUT DROP" after $IPTABLES -X.
_________________
"You have to invite me in" |
|
| Back to top |
|
|
wswartzendruber
Veteran
Joined: 23 Mar 2004
Posts: 1261
Location: Idaho, USA
|
| Posted: Tue Jun 03, 2008 1:15 am Post subject: |
|
|
Latest, greatest (learning) update:
| Code: | 1. IPTABLES='/sbin/iptables'
2. EXTIF='ppp0'
3. INTIF='eth1'
# Clear things out.
4. $IPTABLES -F
5. $IPTABLES -X
# Setup some anal defaults.
6. $IPTABLES -P FORWARD DROP
7. $IPTABLES -P INPUT DROP
# Enable loopback.
8. $IPTABLES -A INPUT -i lo -j ACCEPT
# Setup strict forwarding rules.
9. $IPTABLES -A FORWARD -m state --state INVALID -j DROP
10. $IPTABLES -A FORWARD -p tcp -m state --state NEW -m tcp ! --syn -j DROP
11. $IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT
12. $IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
# Setup masquerading (NAT).
13. $IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE
# Setup strict input rules.
14. $IPTABLES -A INPUT -m state --state INVALID -j DROP
15. $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT |
Explanation:
Lines 6 and 7: Default policies if no rules match.
Lines 9 and 14: Keep invalid packets from coming and going (whether forwarded or on established connections).
Line 10: Keep those sneakily invalid packets from being forwarded.
Now, how do these new rules look?
EDIT: Line 10 is to prevent users from exploiting whatever that is from inside my network. By the way, is there an article on what that does somewhere? Or maybe you could explain it?
EDIT: Am I still vulnerable to IP spoofing?
_________________
Git has obsoleted SVN.
10mm Auto has obsoleted 45 ACP. |
|
| Back to top |
|
|
wswartzendruber
Veteran
Joined: 23 Mar 2004
Posts: 1261
Location: Idaho, USA
|
| Posted: Tue Jun 03, 2008 2:38 am Post subject: |
|
|
Latest update:
| Code: | IPTABLES='/sbin/iptables'
EXTIF='ppp0'
INTIF='eth1'
# Clear things out.
$IPTABLES -F
$IPTABLES -X
# Setup some anal defaults.
$IPTABLES -P FORWARD DROP
$IPTABLES -P INPUT DROP
# Enable loopback.
$IPTABLES -A INPUT -i lo -j ACCEPT
# Setup strict forwarding rules.
$IPTABLES -A FORWARD -f -j DROP
$IPTABLES -A FORWARD -p tcp --tcp-flags ALL NONE -j DROP
$IPTABLES -A FORWARD -p tcp --tcp-flags ALL ALL -j DROP
$IPTABLES -A FORWARD -m state --state INVALID -j DROP
$IPTABLES -A FORWARD -p tcp -m state --state NEW -m tcp ! --syn -j DROP
$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
# Setup masquerading (NAT).
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE
# Setup strict input rules.
$IPTABLES -A INPUT -f -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
$IPTABLES -A INPUT -m state --state INVALID -j DROP
$IPTABLES -A INPUT -i $INTIF -p tcp --dport 22 -j ACCEPT
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT |
Is it safe to say that for a given block, your DROPs need to come before your ACCEPTs?
EDIT: SSHD is temporary.
_________________
Git has obsoleted SVN.
10mm Auto has obsoleted 45 ACP. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Tue Jun 03, 2008 3:21 am Post subject: |
|
|
Rules are processed in order until a match is found. Thus, you should order your DROP targets to occur before your ACCEPT targets if you want a packet which matches both to be dropped.
With regard to IP spoofing: these rules do not make you any more or less vulnerable to IP address spoofing. Plain IP is not an authenticated protocol, so an attacker can spoof packets. TCP has some inherent safety against spoofing since it is difficult for an attacker to get the control values correct if he or she cannot observe the packets generated by your system. |
|
| Back to top |
|
|
think4urs11
Bodhisattva
Joined: 25 Jun 2003
Posts: 6659
Location: above the cloud
|
| Posted: Tue Jun 03, 2008 6:48 am Post subject: |
|
|
as already suggested in the other thread in OTW you should add some anti-spoofing rules.
Depending on your network setup it might be neccessary to add some more networks besides $your-internal-net.
The same rule may also be applied to INPUT chain and OUTPUT chain if neccessary - you're one of the good boys, arent't you? 
Additionally it might be needed to restrict your FORWARD chain a bit more, e.g. to not allow anything through but only udp/tcp/icmp.
To be a good boy (i.e. RFC compliant and make error tracking a bit easier) you shall also allow your box to respond to some icmp types. (echo-request/reply, time-exceeded, fragmentation-needed and maybe source-quench, destination-unreachable, parameter-problem)
As we're paranoid here you should add an OUTPUT chain too, with only the very minimum needed allowed to go out of your box (or nothing at all, depending on your needs).
_________________
Nothing is secure / Security is always a trade-off with usability / Do not assume anything / Trust no-one, nothing / Paranoia is your friend / Think for yourself |
|
| Back to top |
|
|
|
Networking & Security
