Printable View
I’m new to iptables and much of the tutorials I find are not quite clear. What series of iptables commands would I use to do the following?
By default deny all traffic not from localhost.
Accept all traffic from the local network (let’s say 123.123.*.* for example) to TCP ports 139,445,110
Accept all traffic from anywhere to ports 25, 80, 22.
Thanks
Oh, I should give a little more information. This is not a gateway firewall, it's just a single home box that I want to set up a host based firewall on.
Ok, I think the following more or less does it:
Any other suggestions? Think this will cause any problems?Code:#!/bin/bash
iptables -F FORWARD
iptables -F INPUT
iptables -F OUTPUT
iptables -P INPUT DROP
iptables -P OUTPUT DROP
#Let DNS traffic pass
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -p udp --sport 53 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -m multiport -p tcp -s 123.123.0.0/16 --dports 139,445,110 -j ACCEPT
iptables -A OUTPUT -m multiport -p tcp -s 123.123.0.0/16 --sports 139,445,110 -j ACCEPT
iptables -A INPUT -m multiport -p tcp --dports 25,80,22 -j ACCEPT
iptables -A OUTPUT -m multiport -p tcp --sports 25,80,22 -j ACCEPT
I know you said that you haven't found any really useful IPtable tutorials, Irongeek...but I thought this one might suit the bill nicely anyways...
http://iptables-tutorial.frozentux.n...-tutorial.html
Iptables Tutorial 1.1.19
if it does the trick great...if not, just ignore.
Eg ;)
okQuote:
Code:#!/bin/bash
iptables -F FORWARD
iptables -F INPUT
iptables -F OUTPUT
added FORWARD chain just in case you activate routing by mistake :)Quote:
Code:iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
this allow anything to go in/ou thru loopback interface. So,Quote:
Code:#Let DNS traffic pass
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
DNS can use TCP queries too. :)Quote:
Code:iptables -A INPUT -p udp --sport 53 -j ACCEPT
iptables -A INPUT -p tcp --sport 53 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
--sports and --dports are subparameters of -m multiport and must follow it.Quote:
Code:iptables -A INPUT -m multiport --dports 139,445,110 -p tcp -s 123.123.0.0/16 -j ACCEPT
iptables -A OUTPUT -m multiport --sports 139,445,110 -p tcp -s 123.123.0.0/16 -j ACCEPT
same.Quote:
Code:iptables -A INPUT -m multiport --dports 25,80,22 -p tcp -j ACCEPT
iptables -A OUTPUT -m multiport --sports 25,80,22 -p tcp -j ACCEPT
I dont like that approach. Try to use instead statefull inspection - take a look at -state tags.
Take a look at the tutorial from Oskar Andreasson that EG posted. Its nice. I use to use it on my iptables classes.
Oops, looks like I put my DNS comment in the wron place, I ment for it to be about 3 lines down. even putting dports or sports latter in the command seems to work (where I have them), is there a reason to change them? Thanks for the advice.
Irongeek,
I've been doing the input drop, output drop, input accept, etc., stuff for awhile now and granted it works great but you might want to take a look at this to see if it speeds up the build:
Firewall Builder
I haven't used this yet, but think I might see what it will do myself. Anyone else use this yet?
cheers
Yeah, phishphreek80 pointed that out to me but I found it non-intuitive. Besides, I want to learn more about Iptables. Thanks.
And if you haven't got enough yet.... :)
Quote:
This article had been published http://networking.earthweb.com/
Building Firewalls with iptables, Part 2
June 10, 2003
By Carla Schroder
Last week in Part 1 we began uncovering some of the mysteries of tables and chains, and how to build iptables rules. This week we will dig more into writing rules for basic firewalling, sharing an Internet connection, and scripting.
Paying for Our SYNs
We can't close off all ports; that will shut us off completely. We also can't just specify that certain ports will remain open, since it's impossible to predict which ports non-service programs will grab. And simply allowing traffic destined for specific ports does nothing to prevent malicious bits from waltzing right on in. So what exactly can we do to set up an effective rule that allows the good guys to pass through while preventing the bad ones from accessing our network?
For starters, we can take advantage of the syn flag set to prevent unauthorized access. While iptables examines only headers, not payload, it still does a lot of useful packet analysis based on the headers. For example, when Web surfing, a request goes from your PC to a web server out there somewhere. The web server then responds and sends packets back to you, grabbing the first convenient ephemeral (temporary) port on your system. Other than responding to your request, the server has no reason whatsoever to be sending traffic your way. We can take advantage of this by setting up a rule that blocks all incoming TCP connections that are not initiated by your system:
# iptables -t filter -A INPUT -i eth0 -p tcp --syn -j DROP
-i names the network interface, -p names which protocol, and --syn means TCP packets with the syn flag set. This also illustrates the importance of understanding TCP/IP. SYN is used to initiate a TCP connection. If you're not running any servers on your end, there's no reason for anyone to be sending you SYN packets.
At this point, someone usually wails, "Why can't it be EASY?" Yes, there are easier ways to build firewalls. There are nice hardware widgets as well as software utilities for constructing rulesets (see Resources), but Grasshopper, you know as well as I do, the easy way is not always the best way. And if an old fossil like me can figure this stuff out, anyone can.
Stateful Packet Inspection
The previous example rule looks at each packet individually, rather than in context, and relies on the information in the header. If everyone were truthful and benevolent, this would be enough. (Heck, if everyone were truthful and benevolent, we wouldn't need firewalls in the first place, would we?) iptables inspects the source and destination IP addresses, the source and destination ports, the sequence numbers of incoming packets, the TCP sequencing information, and the status from the header flags (SYN, ACK, FIN, RST, etc.). In other words, it tracks entire connection sessions, making filtering decisions in context.
Sharing an Internet Connection
Network address translation/IP masquerading allows sharing a single Internet connection among several hosts -- a mixed LAN with Linux and Windows systems, for example. Assume a firewall box with two NICs and a static, routable IP address. eth0 is the "public" NIC, eth1 the "private." In other words, eth0 is assigned the static, routable IP, while eth1 is assigned a private, non-routable IP, and belongs to the LAN subnet. We need to add chains to the nat and filter tables:
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# iptables -t filter -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
# iptables -t filter -A FORWARD -i eth1 -o eth0 -j ACCEPT
This illustrates the great value of stateful packet inspection. Notice how only incoming packets that belong to an existing connection are allowed. All packets from the LAN headed outbound are allowed to pass. (Note: filter is the default table; it is not necessary to explicitly name it. Many iptables examples leave it out.) The first rule makes all outgoing traffic appear as though it comes only from the firewall machine, with no indication there is an entire LAN lurking behind it.
This example sets the default policies for the FORWARDand POSTROUTING chains. It is important to have a default POSTROUTING DROP policy when using masquerading; otherwise, it is possible for a malicious user to tunnel through your gateway and masquerade their own identity.
# iptables -t filter -P FORWARD DROP
# iptables -t filter -P POSTROUTING DROP
This example is for dialup connections, with dynamically-assigned IPs:
# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Running Servers
A popular way to pass time is to engage in arguments about whether it is better to put servers behind firewalls, or outside of them. If you choose to put them behind your firewall, iptables needs to know where to pass the packets:
# iptables -t nat -A PREROUTING -i eth0 -p tcp -dport 80 -j DNAT -to 192.168.0.10:80
# iptables -t nat -A PREROUTING -i eth0 -p tcp -dport 25 -j DNAT -to 192.168.0.11:25
Scripting
So far, all the examples have been run from the command line. This is a good way to test new rules. Once they are working to your satisfaction, preserve them in a script. This sample is not a complete script, though, as it only illustrates using variables and provides additional sample rules.
#!/bin/sh
#Assign variables
IPTABLES=/sbin/iptables
LAN_NET="192.168.1.0/24"
IFACE= "eth0"
LO_IFACE="lo"
LO_IP="127.0.0.1"
#Any kernel modules that need to be loaded go here
/sbin/modprobe ip_conntrack
/sbin/modprobe iptable_nat
#IP forwarding is usually disabled in the kernel, by default. To enable it:
echo "1" > /proc/sys/net/ipv4/ip_forward
#Sers with dynamically assigned IPs need this
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
###Every time this script is restarted, it is a good idea to flush all rules and start over
#Many tutorials recommend setting OUTPUT to DROP. This is very restrictive, so
#do what suits your needs
$IPTABLES -P INPUT DROP
$IPTABLES -F INPUT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -F OUTPUT
$IPTABLES -P FORWARD DROP
$IPTABLES -F FORWARD
$IPTABLES -F -t nat
###Random useful rule examples
#Allow ssh connections inside the LAN only
$IPTABLES -A INPUT -s LAN_NET -p tcp --destination-port ssh -j ACCEPT
#Must enable loopback!
$IPTABLES -A INPUT -i lo -p all -j ACCEPT
$IPTABLES -A OUTPUT -o lo -p all -j ACCEPT
###Foil source IP spoofing; drop incoming packets that claim to be from us,
#and drop outgoing packets that are not from us
$IPTABLES -A INPUT -i $IFACE -s $LAN_NET -j DROP
$IPTABLES -A OUTPUT -o $IFACE -s ! $LAN_NET -j DROP
###Some outgoing traffic must be restricted, to
#foil spyware and trojans from phoning home
$IPTABLES -A OUTPUT -o eth0 -p tcp -dport 31337 -j DROP
$IPTABLES -A OUTPUT -o eth0 -p tcp -sport 31337 -j DROP
###Other good ports to block include 31335, 27444, 27665, 20034 NetBus, 9704, 137-139 (smb)
#...etc.... it may be easier to OUTPUT DROP and then define what is allowed!
Big Fat Warning
We have used only tcp in our examples to this point, but don't forget there are UDP and ICMP packets to contend with as well. In other words, by no means is this a complete firewall tutorial! Hopefully, you now understand the basic concepts and terminology. If you are new to iptables, I recommend starting with some serious TCP/IP study, followed by a review of Oskar Andreasson's wonderful iptables tutorial.
Resources
iptables Tutorial 1.1.19 by Oskar Andreasson
Netfilter/iptables home page - includes downloads, documentation, and mail lists
LinuxGuruz - offers a mondo collection of iptables scripts
Building Secure Servers with Linux by Michael D. Bauer
Yup. I use it all the time. I only use it for iptables and the linksys/sveasoft firmware though.Quote:
Originally posted here by Relyt
Irongeek,
I've been doing the input drop, output drop, input accept, etc., stuff for awhile now and granted it works great but you might want to take a look at this to see if it speeds up the build:
Firewall Builder
I haven't used this yet, but think I might see what it will do myself. Anyone else use this yet?
cheers
Thanks, it looks interesting enough. I'm sure I can look at how it sets up IPTables and compare it with what I already have.Quote:
Yup. I use it all the time. I only use it for iptables and the linksys/sveasoft firmware though.
cheers
At first glance I was with cacosapo on this one. But after reviewing, your syntax seems correct. His is not.Quote:
even putting dports or sports latter in the command seems to work (where I have them), is there a reason to change them?
In defense of cacosapo the man pages are a bit misleading.
If you want to know if your rule works, after you load it try
“ iptables –list -n –line-numbers -v “ to test chain
I do agree, some “statefull” inspection may indeed be appropriate. ( You didn't by any chance “grow-up” on IPFWADM ? )
You said this is a workstation. Are you sharing files on this box with others on the LAN?
If not, why open those ports to everyone on the LAN? Why not just open them up outbound to the ( SAMBA ) server and use the “ -state” to maintain the connection? I assume there will be M$ boxes there, and if they get infected with a virus or worm that searches for those open ports:
1) if they are closed and logged, you will have evidence of an infection or misconfiguration on your LAN ( like my sons Win2k box that broadcasts to the LAN )
2) if they are open and these bastards write a virus that also spreads to *nix boxes through files sharing, etc., your F***.
I think you get my point.
To say the least, you may also want to include the following, as the last rules ( you already set the default policies in the begining )
# ---log all packets that hit the default policy ---- #
iptables -A INPUT -j LOG --log-level info --log-prefix "input_default_drop: "
iptables -A OUTPUT -j LOG --log-level info --log-prefix "output_default_drop: "
iptables -A FORWARD -j LOG --log-level info --log-prefix "forward_default_drop: "
Also, I find it useful when building a new firewall from scratch to log everything.
So, for example, your one rule rule would become two:
iptables -A INPUT -m multiport -p tcp -s 123.123.0.0/16 --dports 139,445,110 -j LOG --log-level info --log-prefix "MS-SMB-mail_in: "
iptables -A INPUT -m multiport -p tcp -s 123.123.0.0/16 --dports 139,445,110 -j ACCEPT
Once you see a rule is working and you no longer need it for debugging you can either comment out the log rule or delete it.
Hope this helped!
I Dont think so.Quote:
[B]At first glance I was with cacosapo on this one. But after reviewing, your syntax seems correct. His is not.
- tags are parameters and -- are subparameters.
Altough iptables command processor can recognize misplaces subtags, its advisable to keep them following the parameters. And this is more important on ---source-port, --destination-port and --port, because those sub-tags can be used on several places (e.g. they are subtags of -m multiport, -p tcp, etc)
In Irongeek's case, since he wrote subtags with commas, iptables command processor was able to detect that --dport is a -m multiport subtag and not a -p tcp subtag.
Sometimes that can be a mess.
Irongeek, i suggest also that you use service names instead ports. The usage of service names make the config more readable. iptables will lookup at /etc/services file to resolv name-to-port translation.
Thanks folks. I've never played with IPFWADM, is was a little before my time where Linux is concerned. The box in question also serves files to others so I needed the ports dealing with SMB open. I'll be continuing to play with iptables some more.
Yes cacosapo I agree, but ...
run the following,
what I get is:Quote:
#!/bin/sh
#
iptables -F
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables -X
iptables -t mangle -F
iptables -t nat -F
iptables -t mangle -X
iptables -t nat -X
# ------Set default policies for packets going through this firewall box-------- #
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
#--------------------------------------------------------------------------------------
iptables -A INPUT -m multiport --dports 139,445,110 -p tcp -s 123.123.0.0/16 -j ACCEPT
iptables -A OUTPUT -m multiport --sports 139,445,110 -p tcp -s 123.123.0.0/16 -j ACCEPT
#--------------------------------------------------------------------------------------
# ---log all packets that hit the default policy ---- #
iptables -A INPUT -j LOG --log-level info --log-prefix "input_default_drop: "
iptables -A OUTPUT -j LOG --log-level info --log-prefix "output_default_drop: "
iptables -A FORWARD -j LOG --log-level info --log-prefix "forward_default_drop: "
echo "1" > /proc/sys/net/ipv4/tcp_syncookies
echo tcp_syncookies
And listing the rules after running this gives only the default drops.Quote:
iptables v1.2.11: multiport needs `-p tcp' or `-p udp'
Try `iptables -h' or 'iptables --help' for more information.
iptables v1.2.11: multiport needs `-p tcp' or `-p udp'
Try `iptables -h' or 'iptables --help' for more information.
tcp_syncookies
I only tried this on this version, ( default for updated Fedora 3 ) , haven't tried it on newer versions. I also like using the “ ! “ to make things simpler, but the multiport module had some problems with that in certain versions ( 1.3.0.rc1 ? )