+------------------------------------------------------------------+ | 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 brianat_private -------------------------------------------------------------------- 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-requestat_private 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 majordomoat_private with 'unsubscribe isn' in the BODY of the mail.
This archive was generated by hypermail 2b30 : Wed Jul 23 2003 - 02:46:37 PDT