Wondering if anyone is willing to give me a little assistance with some firewall rules. I think what I'm looking for is fairly simple, and I've been trying to use webmin's firewall module without success.
I have a web server that I'd like to open up port 80 and forward a specific port for a select number of allowed ips. That's it. Everything else is dropped.
allow: port 80 allow: forward port 8000 for x.x.x.x to y.y.y.y
Anyone willing to assist with the rules? And lastly, how would I apply it in a way that it will always be in affect? If the machine reboots for example.
Any help is appreciated. James
On 28/09/05, James Pifer jep@obrien-pifer.com wrote:
Wondering if anyone is willing to give me a little assistance with some firewall rules. I think what I'm looking for is fairly simple, and I've been trying to use webmin's firewall module without success.
I have a web server that I'd like to open up port 80 and forward a specific port for a select number of allowed ips. That's it. Everything else is dropped.
allow: port 80 allow: forward port 8000 for x.x.x.x to y.y.y.y
Anyone willing to assist with the rules? And lastly, how would I apply it in a way that it will always be in affect? If the machine reboots for example.
Have a look at the bastion firewall setup examples from the O'Reilly Linux Server Security book at http://examples.oreilly.com/linuxss2/
They should point you in the right direction. As for starting across reboots, I'd place the script either in root's home or somewhere else normal users can't get to and run it from /etc/rc.d/rc.local
Will.
Quoting James Pifer jep@obrien-pifer.com:
Wondering if anyone is willing to give me a little assistance with some firewall rules. I think what I'm looking for is fairly simple, and I've been trying to use webmin's firewall module without success.
The problem is, you either use GUI tools and live with the limitations of the tool, or you do it all by hand. Most GUI tools are not going to allow you to mix and match. If you make some changes manually, next time you use GUI tools it'll discard them.
Said that, default config file with firewall rules for iptables on CentOS is /etc/sysconfig/iptables. There's also /etc/sysconfig/iptables.conf with some settings you might need to alter in specific situations (for example, NAT helper modules to be loaded are specified there). The former (the one with rules) might get overwritten, or its rules overriden by GUI various interfaces. As I said, you either use GUI and live with limitations, or do it all by hand and are able to implement whatever you need.
I have a web server that I'd like to open up port 80 and forward a specific port for a select number of allowed ips. That's it. Everything else is dropped.
allow: port 80 allow: forward port 8000 for x.x.x.x to y.y.y.y
When you say forward port 8000, what exactly do you have in mind? Simple packet forwarding (if we see packet from xxx to yyy we allow it to be forwarded)? Or do you mean NAT (if we see packet comming in for us on 8000 from xxx, we forward it to yyy optinally chaning port number)?
Standard disclaimer. These rules are not going to work on their own, and they are *unsafe*. They are here only to give you a pointer how to solve specific problem, but they are not complete nor secure solution. Before manually applying any firewall rules, make sure you know exactly what you are doing. I personally don't use them as presented here, and would not recommend anybody else to use them as is. This is just simplification of actuall configuration to show how the problem could be solved.
Anyhow, in general case, you would do something like this on command line:
To allow incomming connections to port 80 is fairly simple (but see disclaimer):
# iptables -A INPUT -p tcp --dport 80 -j ACCEPT
Now, if you want to allow simple packet forwarding:
# iptables -A FORWARD -p tcp --dport 8000 -s x.x.x.x -d y.y.y.y.y -j ACCEPT
Now, if you wanted to do NATing, it goes something like this.
# iptables -A FORWARD -p tcp ---dport 8000 -s z.z.z.z -d y.y.y.y.y -j ACCEPT # iptables -t nat -A PREROUTING -p tcp --dport 8000 -d x.x.x.x \ -j DNAT --to-destination y.y.y.y
If you wanted to change port 8000 to 80, you'd do it something like:
# iptables -A FORWARD -p tcp --dport 80 -s z.z.z.z -d y.y.y.y -j ACCEPT # iptables -t nat -A PREROUTING -p tcp --dport 8000 -d x.x.x.x \ -j DNAT --to-destination y.y.y.y:80
Note that chains in filter table will see NATed address, because we used DNAT (rewriting of destination address) target in PREROUTING chain. In short, flow of packets through chains looks something like this.
(if from local) local --> OUTPUT -+ +-----------------+ | | | +-> routing --> FORWARD -+-> POSTROUTING --> net | | net --> PREROUTING -+ +-> INPUT --------------------------> local
Each chain will see changes made by previous chain. Note that almos all chains are also parts of one of three tables of chains (filter, nat, and mangle), so you actually have two PREROUTING chains (in nat and mangle tables), three OUTPUT chains, and so on... Each with distinct set of rules, and each with distinct set of allowed targets (as documented in manual page for iptables).
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Wed, 28 Sep 2005 09:47:47 -0500 Aleksandar Milivojevic alex@milivojevic.org wrote:
The problem is, you either use GUI tools and live with the limitations of the tool, or you do it all by hand. Most GUI tools are not going to allow you to mix and match. If you make some changes manually, next time you use GUI tools it'll discard them.
These tools are advanced, and can do almost everything iptables can: Shorewall (CLI) http://www.shorewall.net Firewall Builder (GUI) http://www.fwbuilder.org/ Kmyfirewall (GUI) http://kmyfirewall.sourceforge.net/
I recommend shorewall for every day use. Its obscenely powerful.
On Wed, 2005-09-28 at 08:54 -0400, James Pifer wrote:
Wondering if anyone is willing to give me a little assistance with some firewall rules. I think what I'm looking for is fairly simple, and I've been trying to use webmin's firewall module without success.
I have a web server that I'd like to open up port 80 and forward a specific port for a select number of allowed ips. That's it. Everything else is dropped.
allow: port 80 allow: forward port 8000 for x.x.x.x to y.y.y.y
Anyone willing to assist with the rules? And lastly, how would I apply it in a way that it will always be in affect? If the machine reboots for example.
James, I've found that "man iptables" is actually a fairly good introduction to iptables.
For your setup, you probably need something along the lines of # iptables -I INPUT -p tcp --dport 80 -j ACCEPT to allow global access to the web server, and similar lines for your more limited access to port 8000.
As for making your changes permanent, "service iptables save" will store your current iptables rules in /etc/sysconfig/iptables; this is the file that "service iptables start" uses at boot time. MAKE BACKUP COPIES OF /etc/sysconfig/iptables EVERY TIME BEFORE YOU RUN service iptables save JUST IN CASE YOU DON'T LIKE THE CHANGES.
You should check to make sure that the iptables service is set start at boot time. You can do this by running "chkconfig --list iptables"; you will get something like this: iptables 0:off 1:off 2:off 3:on 4:on 5:on 6:off
This example means "iptables will be started when entering runlevels 3, 4, or 5, and stopped when entering runlevels 0, 1, 2, or 6."
Your server is most likely running at runlevel 3, unless you have a GUI interface running on it. The GUI is only necessary if your server is also someone's desktop. You can find out which runlevel your server is set to use by running "grep ^id /etc/inittab"; you will get a line like this: id:3:initdefault:
Look for the number after the first colon.
hth
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Sep 28, 2005 at 08:54:56AM -0400, James Pifer wrote:
Wondering if anyone is willing to give me a little assistance with some firewall rules. I think what I'm looking for is fairly simple, and I've been trying to use webmin's firewall module without success.
I have a web server that I'd like to open up port 80 and forward a specific port for a select number of allowed ips. That's it. Everything else is dropped.
allow: port 80 allow: forward port 8000 for x.x.x.x to y.y.y.y
Anyone willing to assist with the rules? And lastly, how would I apply it in a way that it will always be in affect? If the machine reboots for example.
Any help is appreciated. James
Forward port 8000 to several hosts might be difficult using only iptables. You might want to take a look at LVS (Linux Virtual Server) for that, on http://www.linuxvirtualserver.org/
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Wed, 2005-09-28 at 12:11 -0300, Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Sep 28, 2005 at 08:54:56AM -0400, James Pifer wrote:
Wondering if anyone is willing to give me a little assistance with some firewall rules. I think what I'm looking for is fairly simple, and I've been trying to use webmin's firewall module without success.
I have a web server that I'd like to open up port 80 and forward a specific port for a select number of allowed ips. That's it. Everything else is dropped.
allow: port 80 allow: forward port 8000 for x.x.x.x to y.y.y.y
Anyone willing to assist with the rules? And lastly, how would I apply it in a way that it will always be in affect? If the machine reboots for example.
Any help is appreciated. James
Forward port 8000 to several hosts might be difficult using only iptables. You might want to take a look at LVS (Linux Virtual Server) for that, on http://www.linuxvirtualserver.org/
[]s
No, I need to forward several machines through a specific port to a single machine. Not "forward 8000 to several hosts".
Still looking over the other responses.
Thanks for the responses. James
James Pifer wrote:
No, I need to forward several machines through a specific port to a single machine. Not "forward 8000 to several hosts".
James, you don't say if you need to forward one port or all ports to that single machine. There is no way to forward from a single port on the firewall to *all* ports on the target host. You can, however, forward individual ports: say from port 8000 on the firewall to port 80 on the target host.
I did this successfully providing external SSH access to a collection of hosts on a private network. However for this to work, the hosts on the private net also need to be doing SNAT back out through the firewall.
Kirk Bocek
Quoting Kirk Bocek t004@kbocek.com:
I did this successfully providing external SSH access to a collection of hosts on a private network. However for this to work, the hosts on the private net also need to be doing SNAT back out through the firewall.
Unless you are doing something funky, SNAT is not needed. All he needs is DNAT. Netfilter should take care of returning packets automagically (unless, as I said, you are doing something funky and confusing Netfilter with it).
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Aleksandar Milivojevic wrote:
Unless you are doing something funky, SNAT is not needed. All he needs is DNAT.
Hmmm, I may be unclear on this. When doing DNAT, is the source IP address of the traffic coming from firewall and going to the internal host set to the internal address of the firewall? Or does it remain the address of the outside host that initiated the traffic in the first place.
I always *assumed* (a bad thing) that it was the latter. Thus my statement regarding the need for SNAT on the outbound traffic.
Kirk
Quoting Kirk Bocek t004@kbocek.com:
Hmmm, I may be unclear on this. When doing DNAT, is the source IP address of the traffic coming from firewall and going to the internal host set to the internal address of the firewall? Or does it remain the address of the outside host that initiated the traffic in the first place.
I always *assumed* (a bad thing) that it was the latter. Thus my statement regarding the need for SNAT on the outbound traffic.
You assumed right. However, Netfilter is smart enough to change source address on returning packet without explicit SNAT rule(s). As long as incomming and outgoing packets are going through same firewall (or unless you are doing something else funky within your firewall rules). You need explicit SNAT rules only if you want to make outgoing connections from the hosts on local network.
Of course, if you want your internal hosts to see all connections as comming from the firewall, you can do SNAT too. For example, if they don't have default route set or something like that...
On an example, it looks like this:
External interface of firewall receives:
SRC: 1.2.3.4 DST: 4.3.2.1
DNAT 4.3.2.1 -> 192.168.1.123
Internal interface of firewall transmits and destination host receives:
SRC: 1.2.3.4 DST: 192.168.1.123
Destination host transmits and internal interface of firewall receives:
SRC: 192.168.1.123 DST: 1.2.3.4
Firewall knows it was doing DNAT on this specific connection, and automatically rewrites source address. You do not need explicit SNAT rule for this:
Automatic rewriting, no rules needed 192.168.1.123 -> 4.3.2.1
Firewall transmits on its external interface:
SRC: 4.3.2.1 DST: 1.2.3.4
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Aleksandar Milivojevic wrote:
You assumed right. However, Netfilter is smart enough to change source address on returning packet without explicit SNAT rule(s). As long as incomming and outgoing packets are going through same firewall
Ah ha! I *was* right. :) If you have more than one router on the network, you need to make sure the internal host uses the same router doing the DNAT for it's outbound traffic.
On our network we have more than one router doing SNAT for the internal network which provides redundancy and load sharing. When I setup the inbound DNAT for SSH, I realized that both inbound and outbound streams from the target host had to go through the same router. What I didn't know is that you don't *need* the SNAT. My network just *happens* to be doing it.
Thanks, Kirk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Sep 28, 2005 at 11:46:50AM -0500, Aleksandar Milivojevic wrote:
Quoting Kirk Bocek t004@kbocek.com:
I did this successfully providing external SSH access to a collection of hosts on a private network. However for this to work, the hosts on the private net also need to be doing SNAT back out through the firewall.
Unless you are doing something funky, SNAT is not needed. All he needs is DNAT. Netfilter should take care of returning packets automagically (unless, as I said, you are doing something funky and confusing Netfilter with it).
If you have a RELATED,ESTABLISHED matching rule only.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Quoting Rodrigo Barbosa rodrigob@suespammers.org:
On Wed, Sep 28, 2005 at 11:46:50AM -0500, Aleksandar Milivojevic wrote:
Quoting Kirk Bocek t004@kbocek.com:
I did this successfully providing external SSH access to a collection of hosts on a private network. However for this to work, the hosts on the private net also need to be doing SNAT back out through the firewall.
Unless you are doing something funky, SNAT is not needed. All he needs is DNAT. Netfilter should take care of returning packets automagically (unless, as I said, you are doing something funky and confusing Netfilter with it).
If you have a RELATED,ESTABLISHED matching rule only.
Somebody will probably correct me if I'm wrong, but I think restriction is as long as you have connection tracking module loaded. And you will have it as soon as you call any of NAT targets (iptable_nat module depends on ip_conntrack module). So you don't have to have any state related rules at all.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, Sep 29, 2005 at 09:21:40AM -0500, Aleksandar Milivojevic wrote:
I did this successfully providing external SSH access to a collection of hosts on a private network. However for this to work, the hosts on the private net also need to be doing SNAT back out through the firewall.
Unless you are doing something funky, SNAT is not needed. All he needs is DNAT. Netfilter should take care of returning packets automagically (unless, as I said, you are doing something funky and confusing Netfilter with it).
If you have a RELATED,ESTABLISHED matching rule only.
Somebody will probably correct me if I'm wrong, but I think restriction is as long as you have connection tracking module loaded. And you will have it as soon as you call any of NAT targets (iptable_nat module depends on ip_conntrack module). So you don't have to have any state related rules at all.
If your default rule for the related chain is DROP, then you do need the state rules.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Quoting Rodrigo Barbosa rodrigob@suespammers.org:
On Thu, Sep 29, 2005 at 09:21:40AM -0500, Aleksandar Milivojevic wrote:
I did this successfully providing external SSH access to a collection of hosts on a private network. However for this to work, the hosts on the private net also need to be doing SNAT back out through the firewall.
Unless you are doing something funky, SNAT is not needed. All he needs is DNAT. Netfilter should take care of returning packets automagically (unless, as I said, you are doing something funky and confusing Netfilter with it).
If you have a RELATED,ESTABLISHED matching rule only.
Somebody will probably correct me if I'm wrong, but I think restriction is as long as you have connection tracking module loaded. And you will have it as soon as you call any of NAT targets (iptable_nat module depends on ip_conntrack module). So you don't have to have any state related rules at all.
If your default rule for the related chain is DROP, then you do need the state rules.
But, the returning packet will be in ESTABLISHED state, not the RELATED state. RELATED is simmilar to NEW, it matches only the first packet (that firewall saw) of a new connection that is somehow related to an already established connection (and all subsequent packets in that related connection will be in ESTABLISHED state if you accepted the RELATED packet).
I've just tested it on a spare box I have. Single DNAT rule in nat table, no rules at all in filter table, checked with tcpdump, everything worked as I described.
The rule was:
# iptables -A PREROUTING -p tcp --dport 2200 -i eth0 \ -j DNAT --to-destination host2:22
Showing the first incomming (syn) and first outgoing (syn ack) packet here (edited to remove non-relevant clutter):
# tcpdump 'tcp[tcpflags] & tcp-syn != 0' IP host1.49506 > fw.2200: S IP host1.49506 > host2.ssh: S IP host2.ssh > host1.49506: S ack IP fw.2200 > host1.49506: S ack
You can see how firewall rewrote destination address and destination port on the incomming packet (first two lines), and then it rewrote source address and srouce port number on returning packet (last two lines).
Then I added some logging rules into filter table to detect in what state will be the returning packet, and it was in ESTABLISHED state as expected.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Wed, 2005-09-28 at 08:49 -0700, Kirk Bocek wrote:
James Pifer wrote:
No, I need to forward several machines through a specific port to a single machine. Not "forward 8000 to several hosts".
James, you don't say if you need to forward one port or all ports to that single machine. There is no way to forward from a single port on the firewall to *all* ports on the target host. You can, however, forward individual ports: say from port 8000 on the firewall to port 80 on the target host.
I did this successfully providing external SSH access to a collection of hosts on a private network. However for this to work, the hosts on the private net also need to be doing SNAT back out through the firewall.
Just to clarify. Single port. For example:
x.x.x.x:8000 to y.y.y.y:8000 z.z.z.z:8000 to y.y.y.y:8000
Thanks, James
James Pifer wrote:
Just to clarify. Single port. For example:
x.x.x.x:8000 to y.y.y.y:8000 z.z.z.z:8000 to y.y.y.y:8000
Then Rodrigo's "-t nat" lines would be all you need. The five "-A FORWARD" lines would be an option depending on if you wanted to limit connection to *only* a certain group of hosts.
Don't forget to set the default policy for each chain with "iptables -P".
Kirk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Sep 28, 2005 at 11:37:41AM -0400, James Pifer wrote:
On Wed, 2005-09-28 at 12:11 -0300, Rodrigo Barbosa wrote:
allow: port 80 allow: forward port 8000 for x.x.x.x to y.y.y.y
Forward port 8000 to several hosts might be difficult using only iptables. You might want to take a look at LVS (Linux Virtual Server) for that, on http://www.linuxvirtualserver.org/
No, I need to forward several machines through a specific port to a single machine. Not "forward 8000 to several hosts".
Still looking over the other responses.
Humm, that should be relatively simple:
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j ACCEPT iptables -t nat -A PREROUTING -p tcp --destination-port 8000 -j DNAT --to-destination ${DESTINATION_SERVER}
iptables -A FORWARD -p tcp --destination-port 8000 -d ${DESTINATION_SERVER} -s ${SOURCE1} -j ACCEPT iptables -A FORWARD -p tcp --destination-port 8000 -d ${DESTINATION_SERVER} -s ${SOURCE2} -j ACCEPT iptables -A FORWARD -p tcp --destination-port 8000 -d ${DESTINATION_SERVER} -s ${SOURCE3} -j ACCEPT iptables -A FORWARD -p tcp --destination-port 8000 -d ${DESTINATION_SERVER} -s ${SOURCE4} -j ACCEPT iptables -A FORWARD -p tcp --destination-port 8000 -d ${DESTINATION_SERVER} -j REJECT --reject-with tcp-reset
SOURCEX can be either a single IP address, or a network/netmask pair.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
Humm, that should be relatively simple:
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j ACCEPT iptables -t nat -A PREROUTING -p tcp --destination-port 8000 -j DNAT --to-destination ${DESTINATION_SERVER}
iptables -A FORWARD -p tcp --destination-port 8000 -d ${DESTINATION_SERVER} -s ${SOURCE1} -j ACCEPT iptables -A FORWARD -p tcp --destination-port 8000 -d ${DESTINATION_SERVER} -s ${SOURCE2} -j ACCEPT iptables -A FORWARD -p tcp --destination-port 8000 -d ${DESTINATION_SERVER} -s ${SOURCE3} -j ACCEPT iptables -A FORWARD -p tcp --destination-port 8000 -d ${DESTINATION_SERVER} -s ${SOURCE4} -j ACCEPT iptables -A FORWARD -p tcp --destination-port 8000 -d ${DESTINATION_SERVER} -j REJECT --reject-with tcp-reset
Rodrigo, wouldn't the port filtering take place in the INPUT chain?
iptables -P INPUT DROP iptables -A INPUT -p tcp --destination-port 80 -j ACCEPT
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Sep 28, 2005 at 09:09:27AM -0700, Kirk Bocek wrote:
Rodrigo Barbosa wrote:
Humm, that should be relatively simple:
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j ACCEPT iptables -t nat -A PREROUTING -p tcp --destination-port 8000 -j DNAT --to-destination ${DESTINATION_SERVER}
iptables -A FORWARD -p tcp --destination-port 8000 -d ${DESTINATION_SERVER} -s ${SOURCE1} -j ACCEPT iptables -A FORWARD -p tcp --destination-port 8000 -d ${DESTINATION_SERVER} -s ${SOURCE2} -j ACCEPT iptables -A FORWARD -p tcp --destination-port 8000 -d ${DESTINATION_SERVER} -s ${SOURCE3} -j ACCEPT iptables -A FORWARD -p tcp --destination-port 8000 -d ${DESTINATION_SERVER} -s ${SOURCE4} -j ACCEPT iptables -A FORWARD -p tcp --destination-port 8000 -d ${DESTINATION_SERVER} -j REJECT --reject-with tcp-reset
Rodrigo, wouldn't the port filtering take place in the INPUT chain?
iptables -P INPUT DROP iptables -A INPUT -p tcp --destination-port 80 -j ACCEPT
My bad. I started writing thinking it would have to redirect port 80 too, then noticed my mistake. After that, I forgot to move it to the INPUT chain.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Quoting Rodrigo Barbosa rodrigob@suespammers.org:
Humm, that should be relatively simple:
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j ACCEPT
You probably want to use INPUT chain of filter table for this:
iptables -A INPUT -p tcp --destination-port 80 -j ACCEPT
If INPUT chain of filter table has default policy set to DROP, putting an ACCEPT target into PREROUTING chain of nat table isn't going to let the packet go through the firewall.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Wed, 2005-09-28 at 11:56 -0500, Aleksandar Milivojevic wrote:
Quoting Rodrigo Barbosa rodrigob@suespammers.org:
Humm, that should be relatively simple:
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j ACCEPT
You probably want to use INPUT chain of filter table for this:
iptables -A INPUT -p tcp --destination-port 80 -j ACCEPT
If INPUT chain of filter table has default policy set to DROP, putting an ACCEPT target into PREROUTING chain of nat table isn't going to let the packet go through the firewall.
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
Ended up with this: iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT tcp -- anywhere anywhere tcp dpt:http
Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT tcp -- 192.168.192.24 10.10.60.4 tcp dpt:5900
Chain OUTPUT (policy ACCEPT) target prot opt source destination
Now shouldn't I be able to run the VNC client from my machine 192.168.192.24, connecting to this server (10.10.60.3) and shouldn't it forward the VNC request to 10.10.60.4?
Yes, communication does work between 192.168.192 and 10.10.60 subnets.
Thanks, James
This need to happen in the nat table:
iptables -t nat -A PREROUTING -p tcp -d 10.10.60.3 --dport 5900 -j DNAT --to-destination 10.10.60.4:5900
Make sure 10.10.60.4 is using 10.10.60.3 as it's router for this traffic.
Kirk
James Pifer wrote:
On Wed, 2005-09-28 at 11:56 -0500, Aleksandar Milivojevic wrote:
Quoting Rodrigo Barbosa rodrigob@suespammers.org:
Humm, that should be relatively simple:
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j ACCEPT
You probably want to use INPUT chain of filter table for this:
iptables -A INPUT -p tcp --destination-port 80 -j ACCEPT
If INPUT chain of filter table has default policy set to DROP, putting an ACCEPT target into PREROUTING chain of nat table isn't going to let the packet go through the firewall.
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
Ended up with this: iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT tcp -- anywhere anywhere tcp dpt:http
Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT tcp -- 192.168.192.24 10.10.60.4 tcp dpt:5900
Chain OUTPUT (policy ACCEPT) target prot opt source destination
Now shouldn't I be able to run the VNC client from my machine 192.168.192.24, connecting to this server (10.10.60.3) and shouldn't it forward the VNC request to 10.10.60.4?
Yes, communication does work between 192.168.192 and 10.10.60 subnets.
Thanks, James
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Wed, 2005-09-28 at 10:46 -0700, Kirk Bocek wrote:
This need to happen in the nat table:
iptables -t nat -A PREROUTING -p tcp -d 10.10.60.3 --dport 5900 -j DNAT --to-destination 10.10.60.4:5900
Make sure 10.10.60.4 is using 10.10.60.3 as it's router for this traffic.
Kirk
I can't make 10.10.60.3 use 10.10.60.4 as the router.
If I loaded a port forwarding application on 10.10.60.3 and had it forward ports to .4 for port 5900 I would not have this requirement.
Can't iptables to the same thing somehow?
I have a java application that would do the port forwarding I need, EXCEPT, that application will not let me restrict by ip address. BUT, now that I think about it, I could run this java application to forward the ports and just use iptables to make that port only available to certain IPs. It would be accomplishing the same thing I suppose.
Would still rather do it with iptables since that would be one less point of failure.
Thanks, James
James Pifer wrote:
I can't make 10.10.60.3 use 10.10.60.4 as the router.
I might be wrong about needing to use 10.10.60.3 for the return traffic. The DNAT function on 10.10.60.3 won't change the source IP address. As long a 10.10.60.4 has a route to the first network, this should still work.
If I loaded a port forwarding application on 10.10.60.3 and had it forward ports to .4 for port 5900 I would not have this requirement.
Can't iptables to the same thing somehow?
You lost me here. Iptables *is* our 'port forwarding application' on 10.10.60.3. The rule I wrote would accept traffic going to 10.10.60.3:5900 and send it back out to 10.10.60.4:5900.
On Wed, 2005-09-28 at 11:20 -0700, Kirk Bocek wrote:
James Pifer wrote:
I can't make 10.10.60.3 use 10.10.60.4 as the router.
I might be wrong about needing to use 10.10.60.3 for the return traffic. The DNAT function on 10.10.60.3 won't change the source IP address. As long a 10.10.60.4 has a route to the first network, this should still work.
If I loaded a port forwarding application on 10.10.60.3 and had it forward ports to .4 for port 5900 I would not have this requirement.
Can't iptables to the same thing somehow?
You lost me here. Iptables *is* our 'port forwarding application' on 10.10.60.3. The rule I wrote would accept traffic going to 10.10.60.3:5900 and send it back out to 10.10.60.4:5900.
Okay, doesn't seem to be doing it. I must be doing something wrong. I'll play with it more this evening.
Thanks, James
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Sep 28, 2005 at 02:35:39PM -0400, James Pifer wrote:
On Wed, 2005-09-28 at 11:20 -0700, Kirk Bocek wrote:
James Pifer wrote:
I can't make 10.10.60.3 use 10.10.60.4 as the router.
I might be wrong about needing to use 10.10.60.3 for the return traffic. The DNAT function on 10.10.60.3 won't change the source IP address. As long a 10.10.60.4 has a route to the first network, this should still work.
If I loaded a port forwarding application on 10.10.60.3 and had it forward ports to .4 for port 5900 I would not have this requirement.
Can't iptables to the same thing somehow?
You lost me here. Iptables *is* our 'port forwarding application' on 10.10.60.3. The rule I wrote would accept traffic going to 10.10.60.3:5900 and send it back out to 10.10.60.4:5900.
Okay, doesn't seem to be doing it. I must be doing something wrong. I'll play with it more this evening.
Hummm, it will be really complicated to do this, since you will need 2 terminating rules to be applied. So, you will need to use 2 tables for it.
iptables -t nat -A PREROUTING -p tcp -s ! 10.0.0.0/8 --destination-port 5900 -j DNAT --to-destination 10.10.60.4 iptables -t nat -A POSTROUTING -p tcp -d 10.10.60.4 --destination-port 5900 -j MASQUERADE
Of course, you can use -j SNAT --to-source 10.10.60.3 to get the same effect of -j MASQUERADE. I'm just lazy.
Bu port forwarding application, I think he means a SOCKS{4,5} Proxy. Which is NOT a port forward application.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Wed, 2005-09-28 at 13:09, James Pifer wrote:
This need to happen in the nat table:
iptables -t nat -A PREROUTING -p tcp -d 10.10.60.3 --dport 5900 -j DNAT --to-destination 10.10.60.4:5900
Make sure 10.10.60.4 is using 10.10.60.3 as it's router for this traffic.
Kirk
I can't make 10.10.60.3 use 10.10.60.4 as the router.
Other way around - the actual destination must route back through the one that did the DNAT.
The packet has to come back through the same machine so the reverse nat is applied to the returning packets on the connection. Otherwise the originating client will see packets coming back from 10.10.60.4 and not associate it with the connection it is trying to make to 10.10.60.3.
If I loaded a port forwarding application on 10.10.60.3 and had it forward ports to .4 for port 5900 I would not have this requirement.
Can't iptables to the same thing somehow?
You have to source nat as well if the packets wouldn't otherwise route back through the host doing DNAT.
I have a java application that would do the port forwarding I need, EXCEPT, that application will not let me restrict by ip address. BUT, now that I think about it, I could run this java application to forward the ports and just use iptables to make that port only available to certain IPs. It would be accomplishing the same thing I suppose.
Would still rather do it with iptables since that would be one less point of failure.
Note that xinetd can also proxy any tcp connection with it's 'redirect' option, and the destination server will see the xinetd host as the source and thus return packets without concerns about routing to the client.
Quoting James Pifer jep@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.
On Wed, 2005-09-28 at 15:14 -0500, Aleksandar Milivojevic wrote:
Quoting James Pifer jep@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.
---- nice job
Aleksandar's custom iptables/firewall rulesets is now open for business... $ 2.00 US per custom rule set ($3.00 for really complicated ones). You could make a small fortune.
;-)
Craig
Quoting Craig White craigwhite@azapple.com:
nice job
Aleksandar's custom iptables/firewall rulesets is now open for business... $ 2.00 US per custom rule set ($3.00 for really complicated ones). You could make a small fortune.
Me and fortune in the same sentence somehow doesn't go well together....
But yeah, anybody using this experiment of mine that I've put together for James in their actuall firewall configs, feel free to donate to my Paypal account if you like the rules ;-)
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
--- Aleksandar Milivojevic alex@milivojevic.org wrote:
Quoting Craig White craigwhite@azapple.com:
nice job
Aleksandar's custom iptables/firewall rulesets is
now open for
business... $ 2.00 US per custom rule set ($3.00
for really complicated
ones). You could make a small fortune.
Me and fortune in the same sentence somehow doesn't go well together....
But yeah, anybody using this experiment of mine that I've put together for James in their actuall firewall configs, feel free to donate to my Paypal account if you like the rules ;-)
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
i was wondering where i can information such as this, is there a good howto on the web or can someone recommend a good book for this stuff. it would be nice to know this stuff since i am trying to get a degree in telecommunications which does include some of this.
thanks
Steven
"On the side of the software box, in the 'System Requirements' section, it said 'Requires Windows or better'. So I installed Linux."
Quoting Steven Vishoot sir_funzone@yahoo.com:
i was wondering where i can information such as this, is there a good howto on the web or can someone recommend a good book for this stuff. it would be nice to know this stuff since i am trying to get a degree in telecommunications which does include some of this.
The manual page for iptables is good read. The Netfilter web site (www.netfilter.org) has good documentation. You might want to follow Netfilter mailing list. Visit Linux Advanced Routing and Traffic Control page at lartc.org for how to use firewall marks for making routing decisions (and there's tons of other advanced stuff covered there).
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
--- Aleksandar Milivojevic alex@milivojevic.org wrote:
Quoting Steven Vishoot sir_funzone@yahoo.com:
i was wondering where i can information such as
this,
is there a good howto on the web or can someone recommend a good book for this stuff. it would be
nice
to know this stuff since i am trying to get a
degree
in telecommunications which does include some of
this.
The manual page for iptables is good read. The Netfilter web site (www.netfilter.org) has good documentation. You might want to follow Netfilter mailing list. Visit Linux Advanced Routing and Traffic Control page at lartc.org for how to use firewall marks for making routing decisions (and there's tons of other advanced stuff covered there).
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
thanks for all the information, i will take a gander at these sites.
Steven
"On the side of the software box, in the 'System Requirements' section, it said 'Requires Windows or better'. So I installed Linux."
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.
Aleksandar,
Wow, this is excellent. I read through it all and commented out the 8000 stuff for the moment. I totally agree with doing it right from the start.
That being said it loaded fine. I can still ssh and hit http. The only problem is that the VNC forward stuff still doesn't work. Here's what it looks like applied.
#iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere state ESTABLISHED ACCEPT icmp -- anywhere anywhere state RELATED SSH_INP tcp -- anywhere anywhere tcp spts:1024:65535 dpt:ssh flags:SYN,RST,ACK/SYN state NEW HTTP_INP tcp -- anywhere anywhere tcp spts:1024:65535 dpt:http flags:SYN,RST,ACK/SYN state NEW LOG_INP all -- anywhere anywhere
Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere state ESTABLISHED ACCEPT icmp -- anywhere anywhere state RELATED VNC_FWD tcp -- anywhere anywhere tcp spts:1024:65535 dpt:5900 flags:SYN,RST,ACK/SYN state NEW LOG_FWD all -- anywhere anywhere
Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere state ESTABLISHED ACCEPT icmp -- anywhere anywhere state RELATED LOG_OUT all -- anywhere anywhere
Chain HTTP_INP (1 references) target prot opt source destination ACCEPT all -- anywhere anywhere RETURN all -- anywhere anywhere
Chain LOG_FWD (1 references) target prot opt source destination LOG all -- anywhere anywhere LOG level warning prefix `FORWARD ' RETURN all -- anywhere anywhere
Chain LOG_INP (1 references) target prot opt source destination LOG all -- anywhere anywhere LOG level warning prefix `INPUT ' RETURN all -- anywhere anywhere
Chain LOG_OUT (1 references) target prot opt source destination LOG all -- anywhere anywhere LOG level warning prefix `OUTPUT ' RETURN all -- anywhere anywhere
Chain SSH_INP (1 references) target prot opt source destination ACCEPT all -- anywhere anywhere RETURN all -- anywhere anywhere
Chain VNC_FWD (1 references) target prot opt source destination ACCEPT all -- 192.168.192.24 10.10.60.4 RETURN all -- anywhere anywhere
If I do an nmap scan all it returns is port 22 and port 80. Since it's port forwarded, should port 5900 show up as well? I'm doing the scan from 192.168.192.24.
I don't really understand the logging part. Is there a way I can turn on some logging to see the VNC requests coming in and see what it's doing with them?
Thanks for everything! James
Quoting James Pifer jep@obrien-pifer.com:
That being said it loaded fine. I can still ssh and hit http. The only problem is that the VNC forward stuff still doesn't work. Here's what it looks like applied.
#iptables -L
Actually, to debug things, you would need output of "iptables -nvxL" and "iptables -t nat -nvxL". The former would list rules in filter table, and later would list rules in nat table. Both with counters, so you can see how many packets (if any) were matched by those rules. They would also show you how many packets in each chain were matched by default policy for that chain (wich is DROP for INPUT, OUPUT and FORWARD chains of filter table).
The "-L" option accepts optional argument, so you can also do things like "iptables -nvxL FORWARD" or "iptables -nvxL VNC_FWD" to list only particular chain and its counters.
If I do an nmap scan all it returns is port 22 and port 80. Since it's port forwarded, should port 5900 show up as well? I'm doing the scan from 192.168.192.24.
You might find tcpdump to be a better friend in debugging firewall rules then nmap. Run it on the firewall machine. It will show you what is going on the ethernet wire. Try running it in two terminals in parallel, in one terminal you would run something like "tcpdump -i eth0 host xxx and port 5900". In the other window you would run "tcpdump -i eth1 host xxx and port 5900", where xxx is the address of the source host. The "host xxx and port 5900" is to filter out the clutter, change it as needed. If you see packets on eth0 but not on eth1, then your firewall is "eating" them. You shuold also see change in destination address by comparing the output in those two terminal windows.
I don't really understand the logging part. Is there a way I can turn on some logging to see the VNC requests coming in and see what it's doing with them?
The rules, as I sent them to you, will log all dropped packets to /var/log/messages. You'll see relatively long line saying it was logged by the kernel, then from what chain (INPUT, OUTPUT or FORWARD), and than a (long) summary of the dropped packet (type of packet, source, destination, ports (if applicable), flags, and so on). If your firewall is dropping anything, you should see it in the logs.
If you want to see incomming VNC requests in log files, try putting this as first rule in VNC_FWD chain:
-A -j LOG_FWD
Note that this will log only the SYN packet (the first packet initiaing the connection), so you don't have to worry about your logs getting too large. This is becasue you are jumping into VNC_FWD chain only when you see SYN packet (the --syn option that expands to flags:SYN,RST,ACK/SYN in iptables -L output).
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Quoting James Pifer jep@obrien-pifer.com:
Wondering if anyone is willing to give me a little assistance with some firewall rules. I think what I'm looking for is fairly simple, and I've been trying to use webmin's firewall module without success.
I have a web server that I'd like to open up port 80 and forward a specific port for a select number of allowed ips. That's it. Everything else is dropped.
allow: port 80 allow: forward port 8000 for x.x.x.x to y.y.y.y
Anyone willing to assist with the rules? And lastly, how would I apply it in a way that it will always be in affect? If the machine reboots for example.
There is a solution where you can use a firewall script at http://projectfiles.com/firewall
-
Aleksandar Milivojevic -
Craig White -
David Johnston -
James Pifer -
Kirk Bocek -
Les Mikesell -
MAHAYUDIN MOHD HASHIM -
Rodrigo Barbosa -
Ryan -
Steven Vishoot -
Will McDonald