[prev in list] [next in list] [prev in thread] [next in thread]
List: isn
Subject: [ISN] Using iptables chains to simplify kernel ACL management.
From: InfoSec News <isn () c4i ! org>
Date: 2003-07-23 7:08:49
[Download RAW message or body]
+------------------------------------------------------------------+
| Linux Security: Tips, Tricks, and Hackery |
| Published by Onsight, Inc. |
| |
| 22-July-2003 |
| http://www.hackinglinuxexposed.com/articles/20030722.html |
+------------------------------------------------------------------+
This issue sponsored by Hacking Linux Exposed, Second Edition.
Hacking Linux Exposed, Second Edition updates the best-selling first
edition, and includes almost 200 new pages of hacking and cracking
materials for Linux and Unix-like systems. HLEv2 shows you,
step-by-step, how to defend against the latest Linux attacks by
understanding the hacker's methods and sinister thought processes.
For reviews, sample chapters, or to order, go to http://
www.hackinglinuxexposed.com/books/
--------------------------------------------------------------------
Using iptables chains to simplify kernel ACL management.
By Brian Hatch
Summary: By creating new chains that are called by the INPUT chain,
you can easily tweak kernel ACLs without recreating the entire
ruleset each time.
When last we left our heroes...
Over the last two newsletters, we've created a simple firewall that
prevents any inbound access. We'd like to make it possible to easily
allow certain hosts to connect inbound with SSH, eventually making it
an automated/dynamic process. This will mean we'll be adding and
removing rules a lot, and this can be a pain when all your rules are
in one big INPUT chain.
What we'll do is add a new iptables chain called allow_in. In this
chain we'll add rules that allow all TCP packets for hosts that
should be allowed to connect. To create this chain, you use
# iptables --new-chain allow_in
We now add this chain to our INPUT chain processing before the SYN
packets would normally be dropped. In the firewall ruleset we
created, we only had ACCEPT rules with a default DROP at the end, so
we should add the following rule just before the end of the rules:
# iptables -A INPUT -j allow_in
This tells the INPUT chain to process the entries in the new allow_in
chain. When this chain in finished processing the rules in INPUT will
continue where they left off. Since we don't have any rules in this
chain right now, it's not doing much, so let's add a few:
# iptables -A allow_in -p tcp --source 192.168.1.10/32 --dport 22 -j ACCEPT
# iptables -A allow_in -p tcp --source 10.15.78.231/32 --dport 22 -j ACCEPT
Let's look at the full iptables rules
# iptables -nL
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x16/0x02
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:53
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:68
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 3
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 4
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 11
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 12
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 5
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 9
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 0
allow_in all -- 0.0.0.0/0 0.0.0.0/0
DROP all -- 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain allow_in (1 references)
target prot opt source destination
ACCEPT tcp -- 192.168.1.10 0.0.0.0/0 tcp dpt:22
ACCEPT tcp -- 10.15.78.231 0.0.0.0/0 tcp dpt:22
So inbound packet processing looks like this:
* Allow inbound TCP packets that are in response to outbound
connections.
* Allow inbound UDP DNS replies
* Allow useful ICMP packets.
* Process the allow_in chain which will
+ Allow SSH from 192.168.1.10
+ Allow SSH from 10.15.78.231
* Log any other packets
* Drop all packets
Now the nice thing about this setup is that we can manage the
allow_in chain separate from the others. The nicest feature is that
we can flush this chain without affecting the other rules:
# iptables -F allow_in
So, the trick now is how exactly do we manage this chain easily? We'd
like him to be able to sit down on any random machine that wasn't
already in the list and somehow let his computer know that it's him
and to allow the machine to SSH in.
Next week I'll show you a DNS sniffing hack that will let us manage
this allow_in chain dynamically. It'll be fun, trust me.
-------------
Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking
Linux Exposed and Building Linux VPNs. He always prefers to build a
firewall on his own than use a commercial product. He has this
expensive Cisco PIX lying around with six tempting Ethernet ports -
anyone know how to install Linux on it? Brian can be reached at
brian@hackinglinuxexposed.com.
--------------------------------------------------------------------
This newsletter is distributed by Onsight, Inc.
The list is managed with MailMan (http://www.list.org). You can
subscribe, unsubscribe, or change your password by visiting
http://lists.onsight.com/ or by sending email to
linux_security-request@lists.onsight.com.
Archives of this and previous newsletters are available at
http://www.hackinglinuxexposed.com/articles/
--------------------------------------------------------------------
Copyright 2003, Brian Hatch.
-
ISN is currently hosted by Attrition.org
To unsubscribe email majordomo@attrition.org with 'unsubscribe isn'
in the BODY of the mail.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic