Quoting James Pifer <jep at obrien-pifer.com>: > Alright, I figured I would try a simple proof of concept with this. > Without setting any policies to drop, meaning all the chains are wide > open (all ACCEPT) I wanted to try and do VNC through the port forward. > > So I started with this: > #iptables -L > Chain INPUT (policy ACCEPT) > target prot opt source destination > > Chain FORWARD (policy ACCEPT) > target prot opt source destination > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > > Ran this: > iptables -A FORWARD -p tcp --dport 5900 -s 192.168.192.24 -d 10.10.60.4 > -j ACCEPT Well, James, you are missing quite a lot here. First of all, default policy is set to ACCEPT, so everything goes through as if there were no firewall rules at all. Secondly, the examples people sent you implied you already had some other firewall rules needed for them to work (most of them don't work on their own). I'll attach sample /etc/sysconfig/iptables file with some comments you can use to play with. It something I just typed for you, so might contain a type or two. It's good starting point for building your own firewall rules. The configuration style is total overkill for your simple problem, however if your configuration becomes complex with hundreds or thousands of rules, it'll pay off to do it this way from the beggining. You might want to deinstall system-config-securitylevel and system-config-securitylevel-tui since they will blindly rewrite this file. You might also want to remove any other GUI tool for managing firewall rules, since it will either overwrite this file, or it will use its own scripts to replace the rules with whatever that GUI tool thinks configuration should look like. Also, if you use "/etc/init.d/iptables save" (as some folks suggested), it will also overwrite this file with whatever are currently loaded rules (you'll loose all those nice comments I put in for you, and nice looking ordering of them too). To load the file, you might do "/etc/init.d/iptables start". Once the rules are up and running, and you change something in the file, don't use iptables script to reload new version. Use "iptables-restore /etc/sysconfig/iptables". Or your current sessions might hung ;-) OK, there's the file in attachment. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- ######################################################################## ######################################################################## # First, let define filter table. Use "iptables -nvxL" to see counters. ######################################################################## ######################################################################## *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] ######################################################################## # First, let define a nice small helper chain for logging things in # filter table. If you want to log something, just jump to it from # wherever. -N LOG_INP -N LOG_OUT -N LOG_FWD # Uncomment if you get too many broadcasts logged on some of your # interfaces. Change interface name as needed. Windows machines # would usually generate tons of these. Thanks Bill for wasting our # network bandwith. If you don't want to log anything else, just add # additional lines for that stuff and call RETURN target before you # hit the lines that call LOG target. # -A LOG_INP -i eth0 -m pkttype --pkt-type broadcast -j RETURN -A LOG_INP -j LOG --log-prefix "INPUT " -A LOG_OUT -j LOG --log-prefix "OUTPUT " -A LOG_FWD -j LOG --log-prefix "FORWARD " -A LOG_INP -j RETURN -A LOG_OUT -j RETURN -A LOG_FWD -j RETURN ######################################################################## # You want to have this as the very first rules in INPUT, OUTPUT and # FORWARD chains for performance reasons. They allow packets that # belong to already established connections to pass through. The wast # majority of packets going through the firewall will be matched # against those first three lines bellow. Some people blindly allow # all related connections too (by using only the first three lines and # changing "ESTABLISHED" to "ESTABLISHED,RELATED"), but I'd rather be # a bit more peaky about it. On firewall, you want to accept almost # all related ICMP messages. You can be a bit more restrictive here # and allow only ICMP types actually needed for networking to work # stable and fast. But even this setup is more restrictive than most # people use. It's your choice what you'll actually use here. -A INPUT -m state --state ESTABLISHED -j ACCEPT -A OUTPUT -m state --state ESTABLISHED -j ACCEPT -A FORWARD -m state --state ESTABLISHED -j ACCEPT -A INPUT -p icmp -m state --state RELATED -j ACCEPT -A OUTPUT -p icmp -m state --state RELATED -j ACCEPT -A FORWARD -p icmp -m state --state RELATED -j ACCEPT ######################################################################## # OK, now the rest is total overkill for this simple config (and will # burn more CPU cycles). However, as this file grows in size and # complexity, this will actually make things more managable and will # consume less CPU cycles since Netfilter's kernel modules don't need # to check packets against all your 10,000 rules. For each service # we'll define custom chain to do filtering in. In INPUT, OUTPUT and # FORWARD chains will insert only the rules to call custom chain for # each of the service that we want to accept. Make sure each custom # chain ends up with either RETURN or DROP targets. If you fall off # the end of custom chain, what happens is not usually what you # intended to happen. I find using the RETURN target to be more # flexible option, since it allows for a packet to be accepted by some # other custom chain (not used in this particular file). ######################################################################## # First let do SSH. We'll allow it from everywhere so you don't end # up locked out. Tighten it up. If you also wanted to allow your # firewall to forward SSH connections, you'd create new custom chain # SSH_FWD similar to SSH_INP. # Create new chain and insert the rule to call it -N SSH_INP -A INPUT -p tcp --syn --sport 1024: --dport 22 -m state --state NEW -j SSH_INP # Put your SSH rules here. You probably want to be more restrictive # than allowing access from anywhere. -A SSH_INP -j ACCEPT # And this should be last thing at the end of all your custom chains -A SSH_INP -j RETURN ######################################################################## # OK, now let do the HTTP stuff. Same as for SSH. Let say you also # want to allow HTTPS. # define it -N HTTP_INP -A INPUT -p tcp --syn --sport 1024: --dport 80 -m state --state NEW -j HTTP_INP -A INPUT -p tcp --syn --sport 1024: --dport 443 -m state --state NEW -j HTTP_INP # rules -A HTTP_INP -j ACCEPT # go back -A HTTP_INP -j RETURN ######################################################################## # VNC stuff # define it -N VNC_FWD -A FORWARD -p tcp --syn --sport 1024: --dport 5900 -m state --state NEW -j VNC_FWD # rules -A VNC_FWD -s 192.168.192.24 -d 10.10.60.4 -j ACCEPT # go back -A VNC_FWD -j RETURN ######################################################################## # And your 8000 port thingie. I'll put some dummy addresses here. # Change them to what you need. Here you see advantage of using # custom chains. If packet is destined for port 10000, you check it # only once (the FORWARD rule), instead of checking it four times # (once for each src-dst combo you allow). # define it -N P8000_FWD -A FORWARD -p tcp --syn --sport 1024: --dport 8000 -m state --state NEW -j P8000_FWD # rules -A P8000_FWD -s 1.2.3.4 -d 10.10.60.123 -j ACCEPT -A P8000_FWD -s 1.2.3.5 -d 10.10.60.123 -j ACCEPT -A P8000_FWD -s 1.2.3.6 -d 10.10.60.123 -j ACCEPT -A P8000_FWD -s 1.2.3.7 -d 10.10.60.123 -j ACCEPT # go back -A P8000_FWD -j RETURN ######################################################################## # OK, this stuff should be at the end of filter table. If you want to # log things that firewall blocked, just call our nice logging chains. -A INPUT -j LOG_INP -A OUTPUT -j LOG_OUT -A FORWARD -j LOG_FWD ######################################################################## # Commit line must be the last line in table definition. It commits # the above rules into the kernel. COMMIT ######################################################################## ######################################################################## # Next, we define the nat table. You'd implement stuff such as SNAT # or DNAT here. Use "iptables -t nat -nvxL" to see counters. ######################################################################## ######################################################################## *nat :PREROUTING ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] ######################################################################## # So, you said you want that fancy port forwarding of port 8000. I'll # put a dummy address here, change it to what you actually need. The # rules in filter's INPUT and FORWARD chains will see this IP address, # not the original destination address. You just do DNAT here, access # is controlled from the filter table (above). -A PREROUTING -p tcp --dport 8000 -j DNAT --to-destination 10.10.60.123 ######################################################################## # And again, COMMIT is the last thing in table's definition. COMMIT ######################################################################## ######################################################################## # Here comes the mangle table. Not used for anything in this # particular simplicit setup. We'll just define it and leave it # empty. Use "iptables -t mangle -nvxL" to see counters. ######################################################################## ######################################################################## *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT