iptables and general tcp/ip

dividingbyzero · 05-22-2008, 11:25 PM

Hello,

Can someone show me a simple iptables script that would work with
DHCP. I basically have a box connected by cable to the web and want a firewall, no FORWARD chain, etc.

i got this so far ...

Code:

iptables -F
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

iptables -N tcp_packets

iptables -A tcp_packets -p TCP -s 0/0 --dport 80 -j allowed

iptables -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j ACCEPT

I basically just wanna surf the web and allow through DHCP which I don't know how to do. Should I just allow everything out on the OUTPUT chain?

I know the script still needs ALOT of work, however it's just a beginning.
Any help for a simple basic script that I can just surf the web would be appreciated.

Also, should I allow in ICMP echo requests, etc? And what about port 113?

Thanks .

dkm999 · 05-23-2008, 12:11 AM

Well, you have a start with the script you posted. From your (sketchy) description, I assume that you have only one machine, and it is attached to something like a cable modem that is providing DHCP to your machine. In that case (and not for any situation where there is more than one computer sharing the Internet connection), we can improve your script just a little and get you started.

Code:

iptables -F
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

iptables -A INPUT -p tcp -j tcp_packets
iptables -A INPUT -p udp -j udp_packets
iptables -A INPUT -p icmp -j icmp_packets

iptables -N tcp_packets
iptables -N udp_packets
iptables -N icmp_packets

iptables -A tcp_packets -p tcp -m state --state ESTABLISHED -j ACCEPT
iptables -A tcp_packets -p tcp --sport 80 -j ACCEPT

iptables -A udp_packets -p udp -m state --state ESTABLISHED -j ACCEPT
iptables -A udp_packets -p udp --dport 67:68 -j ACCEPT

iptables -A icmp_packets -p ICMP --icmp-type 8 -j ACCEPT

The first 4 lines establish the base policies: accept nothing, allow this computer to send anything, and do not forward.

Then the next 3 rules form the INPUT chain. Their job is to classify a packet and send it off for qualification. If a packet gets to the bottom of this chain, the policy kicks in (and the packet is dropped).

After we create the protocol-specific chains, we can fill them with rules. For TCP, we accept incoming packets for established connections, and we also accept packets from web servers (port 80). Everything else will get dropped. For UDP, we accept packets for established connections, and for DHCP (destined for a DHCP requestor, from anywhere). Finally, for ICMP, we accept PING packets from the outside.

In all cases, this computer can initiate any sort of communication, because the OUTPUT policy is to let stuff through.

Good luck.

win32sux · 05-23-2008, 02:30 AM

A couple of observations. IMHO making protocol-specific chains for scripts like this is pointless and just adds clutter. Also, you're missing a rule for the loopback interface, as well as for packets in states RELATED or ESTABLISHED. You don't need to allow ICMP echo nor ident unless you have specific requirements for those (most people don't). I'd suggest this as a better starting point:

Code:

iptables -F
iptables -X

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

If you really want your firewall to only allow traffic to Web ports (which seems likely to me after re-reading your post), you'll just need to change the OUTPUT policy to DROP and add rules for DNS queries, HTTP, and HTTPS, like:

Code:

iptables -F
iptables -X

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

iptables -A OUTPUT -p UDP --dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p TCP --dport 80 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p TCP --dport 443 -m state --state NEW -j ACCEPT

dkm999 · 05-24-2008, 01:10 AM

With all due respect to win32sux (whose screen name I agree with), there IS a point to the protocol specific chains: they make the classification of packets more efficient, and reduce the length of the chains that must be traversed by any particular packet. In these days of blazing clock speeds, perhaps that is not a big consideration, but CPU cycles are still not in abundance.

While it is not obvious, the ruleset proposed by win32sux will not permit browsing (and lots of other kinds of connections) initiated by processes on the firewall machine. This occurs because the state ESTABLISHED really means that traffic has been seen in both directions. A connection initiated by the firewall will cause one outbound packet, but the INPUT chain does not allow for any return packet to pass. The RELATED keyword also does not help; it is only useful for FTP connections.

My apologies to dividingbyzero; the ruleset I proposed is missing the loopback rule, and will not work without it. It should probably be first in the INPUT chain.

win32sux · 05-24-2008, 12:40 PM

Quote:

Originally Posted by dkm999

With all due respect to win32sux (whose screen name I agree with), there IS a point to the protocol specific chains: they make the classification of packets more efficient, and reduce the length of the chains that must be traversed by any particular packet. In these days of blazing clock speeds, perhaps that is not a big consideration, but CPU cycles are still not in abundance.

Clearly, having more specific chains can be a good idea with larger more complex scripts, but IMHO it's counter-productive when it comes to small desktop scripts such as this, as they end up adding a lot of clutter for no gain at all. While your CPU cycle observation is true, it is almost irrelevant at this scale.

Quote:

While it is not obvious, the ruleset proposed by win32sux will not permit browsing (and lots of other kinds of connections) initiated by processes on the firewall machine. This occurs because the state ESTABLISHED really means that traffic has been seen in both directions.

I would suggest you read-up on connection tracking, as you are quite mistaken. You're actually not the first person I see here with this weird idea of the ESTABLISHED state, so I assume there's good reasons for the misconception. But no, traffic does NOT need to be "seen in both directions" before packets will match the ESTABLISHED state. It would be completely insane for it to be that way, as you would end up needing giant holes in every set of firewall rules. For example, look at one of the giant holes in the script you posted:

Quote:

Originally Posted by dkm999

Code:

iptables -A tcp_packets -p tcp --sport 80 -j ACCEPT

With that rule you are allowing anyone access to TCP daemons on your box as long as they make their packets have source port 80. That kind of security nightmare hasn't been necessary since back in the ipchains days, which was many many many years ago.

As a side note (and as further evidence that you are mistaken), is the fact that if you were prevented from browsing the Web with the rules I posted then I wouldn't have been able to post those rules in the first place.

Quote:

A connection initiated by the firewall will cause one outbound packet, but the INPUT chain does not allow for any return packet to pass. The RELATED keyword also does not help; it is only useful for FTP connections.

Well, as explained above, you are confused about the ESTABLISHED state, and returning packets will indeed match perfectly. If you do a bit of reading-up (and experimenting) I'm quite confident you'll understand this.

As for the RELATED match, you are absolutely correct that the script I posted has no need for it. That said, I've been here long enough to know that most of the time people who ask for scripts that "only allow Web surfing" quickly start allowing a few additional things, with FTP being at the top of the list. So if the OP ever adds a port 21 rule to the OUTPUT chain, he'd have less work to do if the RELATED match is already there. It's also common for TCP and UDP connection failures to generate ICMP errors, and in those cases you'll need to be able to match ICMP packets in state RELATED if you want your box to utilize them.

EDIT: In any case, the RELATED match can be safely removed if it makes one happy. In fact, it might be better to remove it anyway in this case (from a security perspective), as removing it would prevent people from using FTP daemons which are listening on ports 80 or 443 - even if the FTP connection tracking module is loaded (or if FTP connection tracking was compiled into the kernel). In that case, my suggested Web-only script becomes:

Code:

iptables -F
iptables -X

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

iptables -A OUTPUT -p UDP --dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p TCP --dport 80 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p TCP --dport 443 -m state --state NEW -j ACCEPT

Of course, one should add rules for ICMP packets in state RELATED. I think it's much more convenient to simply leave the RELATED match and make sure the FTP connection tracking is disabled, though.

Anyhow, thanks for bringing that up!

dividingbyzero · 05-26-2008, 12:13 AM

Code:

echo  "Starting our little firewall :)"

iptables -F
iptables -X

iptables -P INPUT DROP
iptables -P OUTPUT DROP

iptables -A INPUT -p ALL -m state --state ESTABLISHED,RELATED -j LOG --log-prefix "ES_RE "
iptables -A INPUT -p ALL -m state --state ESTABLISHED,RELATED -j ACCEPT 


#DHCP
iptables -A INPUT -p udp -i eth0 --sport 67 --dport 68 -j LOG --log-prefix "DHCP_IN "
iptables -A INPUT -p udp -i eth0 --sport 67 --dport 68 -j ACCEPT

iptables -A OUTPUT -p udp --sport 68 --dport 67 -j LOG --log-prefix "DHCP_OUT "
iptables -A OUTPUT -p udp --sport 68 --dport 67 -j ACCEPT
 

#DNS
iptables -A OUTPUT -p udp --dport 53 -j LOG --log-prefix "DNS "
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT

#web browser
iptables -A OUTPUT -p tcp --dport 80 -j LOG --log-prefix "BROWSER_OUT "
iptables -A OUTPUT -p tcp --dport 443 -j LOG --log-prefix "BROWSER_OUT "
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT



iptables -A INPUT -p ALL -j LOG --log-prefix "BLOCKED_IN "
iptables -A INPUT -p ALL -j DROP

iptables -A OUTPUT -p ALL -j LOG --log-prefix "BLOCKED_OUT "
iptables -A OUTPUT -p ALL -j DROP

the only reason right now that i'm logging all connections is to
understand how the web works and stuff, eventually i'll just log
BLOCKED_IN and BLOCKED_OUT. I just wanted to see what ports DHCP and DNS
use etc. and the TCP 3-way handshake. Also, on Slackware, do I put all this in rc.firewall? And doesn't DHCP always come from port 67 to my comp on port 68? or should I also allow DHCP in on 67? Oh yeah, and i forgot loopback .. what's that used for? and allow it OUT and IN?

Thanks alot

dkm999 · 05-27-2008, 12:39 AM

It looks to me like you are getting the idea. And using the log target to see what happens is a good debugging strategy. But it will fill up your logfile pretty quickly if you leave the LOGGING rules in place.

According to the official definition (RFC 951), DHCP [an extension of BOOTP] operates this way:
1. A requestor broadcasts a DHCP request on port 67 [255.255.255.255:67]
2. A DHCP server listening on port 67 sees this, and returns a reply on port 68. Since the requestor does not know its IP address yet, the reply is also 255.255.255.255:68, with the requestor's Ethernet address in the outer envelope.
So, you only need to allow port 68 in, and port 67 out, if the DHCP server is elsewhere on your network. If that daemon is running on the firewall computer, this conversation will occur over the loopback interface.

The loopback address [127.0.0.1] is used by several systems on your computer to talk to other daemons that listen for IP traffic. This is how, for example, your browser talks to your DNS daemon (if you have one). It is also how your e-mail delivery hands stuff from the transport agent (sendmail daemon, or postfix) to the mail delivery agent (lots of choices). There are several other cases that you may or may not have running. Generally, unless you are especially paranoid, you can ACCEPT all traffic on this interface, without regard to the port number or protocol.

I must apologize regarding the Slackware-specific question. I do not use this distribution, and so might steer you wrong. I guess, though, that you will be able to find this out with a fairly quick Google search.

win32sux · 05-27-2008, 03:33 PM

Quote:

Originally Posted by dividingbyzero

I just wanted to see what ports DHCP and DNS
use etc. and the TCP 3-way handshake.

DHCP servers should listen on port 67, and DHCP clients should use source port 68 when sending packets to the server's port 67. As for TCP handshakes, they don't occur over any separate ports - they are done using the same ports as the completed connection will use. For example, an HTTP client would send a SYN packet from an ephemeral port to the HTTP server on port 80, then the server sends the client a SYN/ACK packet from port 80 to the ephemeral port, then the client sends an ACK packet from the ephemeral port to the server's port 80, and the handshake is completed. So by allowing all outgoing TCP packets to port 80 you are already allowing the handshake to happen for all TCP connections which use that port. If you wish to experiment with this you could filter certain packet types (SYN, SYN/ACK, ACK, etc.) in order to see how the handshake is broken.

Quote:

Also, on Slackware, do I put all this in rc.firewall?

That's correct. I would just add that it's considered more proper to specify the full path to the iptables binary (use a variable at the top to make it easy to modify), instead of just using the command name. In practice it shouldn't make a difference, though, as rc.firewall can use any command in $PATH (IIRC).

Quote:

And doesn't DHCP always come from port 67 to my comp on port 68? or should I also allow DHCP in on 67?

Yes, the de-facto standard is for clients to use port 68. So no, you wouldn't need to allow incoming UDP to your port 67. You can verify this by using netstat, like:

Code:

netstat -anu

Quote:

Oh yeah, and i forgot loopback .. what's that used for? and allow it OUT and IN?

Wikipedia has a pretty concise explanation. And yes, it's fine to allow all traffic to and from the loopback interface (generally speaking). Sometimes the situation might require a more restrictive approach, though, specially on multi-user boxes. It really depends on your level of paranoia and there is no one-size-fits-all solution to loopback firewall rules. For example, say you have a Squid proxy server listening on localhost, port 3128, and you only want local user foo to be able to connect to it. You might use a set of rules like this to make sure no other local users can connect to the Squid daemon:

Code:

iptables -A OUTPUT -p TCP -o lo --dport 3128 \
-m owner --uid-owner foo -j ACCEPT

iptables -A OUTPUT -p TCP -o lo --dport 3128 -j REJECT

Regarding the incoming DHCP rules, you definitely want to make sure you specify that it is to match against broadcast packets, as if not then you could be leaving yourself open to packets coming from upstream (depending on your gateway's configuration). Example:

Code:

iptables -A INPUT -p UDP --dport 68 --sport 67 \
-d 255.255.255.255 -j ACCEPT

dividingbyzero · 05-28-2008, 06:48 AM

Can anyone help me make this firewall better? or is it ok like it is?
It basically is a box that gets DHCP and i wanna surf the web. Right now
I'm logging inbound and outbound just to learn internet traffic, eventually i'll just log BLOCKED.

Also, my logs are showing me that DHCP is only coming IN and not going out. Do I have to have the rule that lets udp out from dport 68 back
to sport 67, or is this unnecessary?

thanks

Code:

echo "Starting our little firewall :)"

iptables -F
iptables -X

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

iptables -A INPUT -p ALL -j LOG --log-prefix "INBND "

iptables -A INPUT -p ALL -m state --state ESTABLISHED,RELATED -j ACCEPT 

#DHCP
iptables -A INPUT -p udp -i eth0  --sport 67 --dport 68 -j ACCEPT


iptables -A INPUT -i lo -j ACCEPT 


iptables -A INPUT -p ALL -j LOG --log-prefix "BLOCKED_IN "
iptables -A INPUT -p ALL -j DROP

#DNS
iptables -A OUTPUT -p ALL -j LOG --log-prefix "OUTBND "
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT 

#web browser 
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT 

#dhcp out
iptables -A OUTPUT -p udp --sport 68 --dport 67 -j ACCEPT 

#localhost
iptables -A OUTPUT -p ALL -o lo -j ACCEPT


iptables -A OUTPUT -p ALL -j LOG --log-prefix "BLOCKED_OUT "
iptables -A OUTPUT -p ALL -j DROP

win32sux · 05-28-2008, 12:43 PM

Quote:

Originally Posted by dividingbyzero

Can anyone help me make this firewall better? or is it ok like it is?
It basically is a box that gets DHCP and i wanna surf the web. Right now
I'm logging inbound and outbound just to learn internet traffic, eventually i'll just log BLOCKED.

I've merged this new thread of yours back into here, as there is no reason to make a separate discussion. As for suggestions, I would say that you should always specify the state in your rules whenever possible. By not doing so, you are implying that you want to allow packets in INVALID states to be sent from your box, and I'm not sure why you would want that.

dkm999 · 05-29-2008, 12:10 AM

It is not so easy to construct this DHCP experiment. It might be that the outbound DHCP packet is getting sent before your iptables rules are in place, or before syslog is ready to receive the log message. That packet is almost certainly being sent out, or you would not be getting a reply.

To check this, immediately after bootup, look at the results of the command

Code:

iptables -nvL

On the left side of the listing are two columns that show the number of packets and the number of bytes that matched each rule. You should see 1 packet counted by the OUTPUT rule for UDP sport 68, dport 67, and one packet counted by the INPUT rule for UDP sport 67, dport 68. If this is so, then the syslog message is getting discarded somehow. If the OUTPUT packet is not being counted, then dhcpd is starting before your iptables rules get set up; this is probably wrong, as it offers a narrow window during bootup when your machine is not protected.

win32sux · 05-29-2008, 02:26 PM

It's possible, but very unlikely that this is a timing issue - especially if you are using rc.firewall. I would instead suggest that if you are using ISC's DHCP client, you should maybe try with some other non-ISC client to see if you get different results. The ISC DHCP server bypasses the Linux IP stack (notice how local iptables rules don't affect an ISC DHCP 3.x server), and I'm thinking perhaps something similar might be happening here with your client.

sundialsvcs · 05-29-2008, 09:14 PM

Keep it simple...

Buy an off-the-shelf router and stick it in-between your cable modem and the rest of your home network.

Then, surf the manual for this router (which just might be on a CD-ROM to save printing costs).

The router will have a very nice built-in firewall. This firewall will, in fact, be all that you need. (And, it's in the right place: in-between the Outside World and You.)

Isn't it sweet when an apparently-thorny problem devolves into something that ... has already been completely solved? ("Maybe not," but, "probably so.")