Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I am experimenting further with IPTABLES and wonder if this behavior is normal.
I have a PC setup running Fedora Core 2 as a server. The only thing I will be using the PC for is a firewall. I have eth0 connected to my cable modem. I have eth1 connected to my LAN switch. If I start the server up without IPTABLES running, it can browse the internet. Obviously the other PCs on the LAN can't browse, but I am not concerned with that just yet. The PCs can SSH and telnet to the server with no problem. So I know both NICs are functioning properly.
If I start IPTABLES, the server can no longer browse the internet. However, the PCs are still able to telnet to the server.
Here is the script I am using. What do I need to add so the server (not LAN PCs) can browse the internet again?
# Drop all to start with
iptables --policy INPUT DROP
iptables --policy OUTPUT DROP
iptables --policy FORWARD DROP
#block outside packets that pretend to be from the firewall server
iptables -A INPUT -p all -s 172.16.1.1 -i eth0 -j DROP
# Loopback interface should accept all traffic
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Allow all bi-directional traffic from the firewall to the LAN
iptables -A INPUT -j ACCEPT -p all -s 172.16.1.0/24 -i eth1
iptables -A OUTPUT -j ACCEPT -p all -d 172.16.1.0/24 -o eth1
iptables -A FORWARD -t filter -i eth1 -m state --state / NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -t filter -i eth0 -m state --state / ESTABLISHED,RELATED -j ACCEPT
# Enable forwarding of NAT packets to internet
echo 1 > /proc/sys/net/ipv4/ip_forward
# Allow DNS queries in and out of the firewall Port 53 is DNS
iptables -A OUTPUT -p udp -o eth0 --dport 53 --sport 1024:65535 -j ACCEPT
iptables -A INPUT -p udp -i eth0 --sport 53 --dport 1024:65535 -j ACCEPT
Any suggestions would be appreciated. It is kind of strange that the firewall itself is being blocked from browsing.
You don't have any rules allowing the firewall to communicate with the internet. Your default OUTPUT rule is DROP, so you'll need to specify all the types of traffic to allow outbound, including http and dhcp. Something like:
iptables -A OUTPUT -o eth0 -p tcp --dport 80 --sport 1024:65535 -j ACCEPT
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
I'm also not sure of what your masquerading rule is designed to do. It's only masquerading traffic from the interface of the firewall itself (not any internal LAN traffic), but if the server needs to communicate with the internet, it will just use the external interface in the first place. If you want to allow the LAN PCs to communicate out with the internet, then just remove the ip address so that it looks like this:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Also, don't forget to add a rule to allow outbound DHCP as well.
Capt_Caveman, the MASQUERADE rule is used to msaquerade all outgoing traffic, all traffic leaving the network be it from the server or the LAN leaves through the eth0 interface.
Capt_Caveman, thanks for your comments. That solved the problem of the server not being able to get out.
Ugge, I removed the masquerade statement and that stopped the LAN clients from getting out. However, the server can still get out. So Capt_Caveman is correct in his comments about masquerade not being needed for the server.
Now, I have 2 problems left. I cannot make a SSH connection from outside of the LAN and I cannot ping from outside of the lan.
If you look at the SSH rules, I have 2 of them commented out. I have tried various combinations of the 3 rules including each rule by itself. However, SSH still refuses to respond from outside of the LAN.
I know my ISP does not block ports 22 and ports 7 because if I remove the Linux firewall and replace it with my Linksys firewall I am able to get into the Linux box if I turn IPTABLES off.
Here are my new rules that are in place now.
# Drop all to start with
iptables --policy INPUT DROP
iptables --policy OUTPUT DROP
iptables --policy FORWARD DROP
#block outside packets that pretend to be from the firewall server
iptables -A INPUT -p all -s 172.16.1.1 -i eth0 -j DROP
# Loopback interface should accept all traffic
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Allow all bi-directional traffic from the firewall to the LAN
iptables -A INPUT -j ACCEPT -p all -s 172.16.1.0/24 -i eth1
iptables -A OUTPUT -j ACCEPT -p all -d 172.16.1.0/24 -o eth1
# Allow outbound internet traffic for server
iptables -A OUTPUT -o eth0 -p tcp -m multiport --dport 7,22,80,443 -j ACCEPT
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow outboud connections for LAN clients - for now, all protocols
iptables -A FORWARD -d 172.16.1.0/24 -i eth1 -j ACCEPT
iptables -A FORWARD -s 172.16.1.0/24 -i eth1 -j ACCEPT
iptables -A FORWARD -t filter -i eth1 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -t filter -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow ping in and out
iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
# Enable forwarding of NAT packets to internet
echo 1 > /proc/sys/net/ipv4/ip_forward
# Allow DNS queries in and out of the firewall Port 53 is DNS
iptables -A OUTPUT -p udp -o eth0 --dport 53 --sport 1024:65535 -j ACCEPT
iptables -A INPUT -p udp -i eth0 --sport 53 --dport 1024:65535 -j ACCEPT
# Allow SSH connections in from internet
#iptables -A FORWARD -p tcp -i eth0 -o eth1 -d 172.16.1.1 --dport 22 -m state --state NEW -j ACCEPT
#iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 22 -j DNAT --to-destination 172.16.1.1
iptables -A INPUT -i eth0 -s 0/0 -d 172.16.1.1 -p tcp --dport 22 -j ACCEPT
# Allow external connections to the ATC Webserver
iptables -t nat -A PREROUTING -d 68.xxx.xx.xxx -i eth0 -p tcp -m tcp --dport 2010 -j DNAT --to-destination 172.16.1.125
iptables -A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 2010 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
No 2buck56, you have just proven him wrong as the LAN stations was stopped from surfing when you took that MASQUERADE away. It's right that the server it self doesn't need masquerade, this is because the server already sits on a public IP address, which the LAN stations doesn't.
Masquerade is a kind of NAT (Network Address Translation) secifically designed for cases where you have a dynamic IP address, which normally is the case with dial-up connections.
Originally posted by ugge Capt_Caveman, the MASQUERADE rule is used to msaquerade all outgoing traffic, all traffic leaving the network be it from the server or the LAN leaves through the eth0 interface.
What this rule says: Masquerade any packet going out the external interface (eth0) that has a source address of 172.16.1.1 (this is the IP address of the internal interface only, not the LAN!) and is destined for any IP address. It will not masquerade any packets originating from inside the LAN (say from host 172.16.1.5) since the packet will have a source address of 172.16.1.5, not 172.16.1.1. The only packets this rule will masquerade would originate from the internal interface (eth1) of the firewall machine, but since the firewall will never send packets from eth1 that would be routed to the internet (it will just use eth0 in the first place), this rule will never match any packets.
However. The masquerading rule from his first post is not the same as the one posted in his second post:
Post 1: iptables -t nat -A POSTROUTING -o eth0 -s 172.16.1.1 -d 0/0 -j MASQUERADE
Post 2: #iptables -t nat -A POSTROUTING -o eth0 -s 172.16.1.0/24 -d 0/0 -j MASQUERADE
Note that in the second rule, the source address has a mask of 24 which will maquerade all the LAN hosts properly (the first rule has an implicit mask of /32). Whether that was a typo in the first post I don't know, but the first rule will not work properly, try it. I did and you get unmasqueraded LAN packets spewed out from the firewall.
Quote:
Originally posted by ugge No 2buck56, you have just proven him wrong as the LAN stations was stopped from surfing when you took that MASQUERADE away.
If the first rule was indeed a typo and his firewall actually used the second (and correct) rule, then that would explain the results.
I stand corrected. Missed on the source address due to that I'm used to use SNAT for this which alters the source IP prior to reaching the POSTROUTING chain.
Iptables calls for another cup of coffe before designing
Originally posted by 2buck56 Ugge, I removed the masquerade statement and that stopped the LAN clients from getting out. However, the server can still get out. So Capt_Caveman is correct in his comments about masquerade not being needed for the server.
No, Ugge is correct here. You will absolutely need a masquerading rule for the internal hosts to connect out. If you re-read my first post, I was trying to get you to remove the problematic source address in the rule not remove the rule entirely, but you will definitely need to masquerade or SNAT rule of some sort. The second rule that you posted will work just fine. Uncomment it again and it should work as expected and shouldn't affect the firewall from browsing the Internet.
Quote:
Originally posted by 2buck56 Now, I have 2 problems left. I cannot make a SSH connection from outside of the LAN and I cannot ping from outside of the lan.
If you look at the SSH rules, I have 2 of them commented out. I have tried various combinations of the 3 rules including each rule by itself. However, SSH still refuses to respond from outside of the LAN.
<SNIP>
iptables -A INPUT -i eth0 -s 0/0 -d 172.16.1.1 -p tcp --dport 22 -j ACCEPT
Here this rule has a problem similar to the first masquerading rule. The destination address is the IP address of the internal interface. If you want to allow incoming sshd connections from the internet, then you'll need to change the destination address to your external IP address. Hosts inside the LAN are already allowed to communicate with the firewall box and shouldn't need another rule. Also remember that since you're using a default policy of DROP for the OUTPUT chain, you'll need to add rules to allow the firewall to communicate out. So remove the ssh rule you had above and add these:
If SSHd is running on an internal box and you are simply trying to forward traffic to that LAN system, then you'll need to do DNAT and add a forwarding rule.
If you want to be able to ping the firewall from outside the LAN, then you'll need to add the reverse of what you have. Currently your rules should allow the firewall to ping remote hosts, but they shouldn't be able to ping you. To allow that:
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-reply -j ACCEPT
Capt_Caveman and ugge, I think maybe there was a little confusion on my part. Both of you are actually correct.
Post 1: iptables -t nat -A POSTROUTING -o eth0 -s 172.16.1.1 -d 0/0 -j MASQUERADE
This was not a typo. What I was trying to do was make the server browse the internet. The server's IP address is 172.16.1.1 and I thought that would work. However, it didn't work because the OUTPUT and INPUT statements were not there as Capt_Caveman said in his first post. I was not interested in making the workstations work at that point.
Post 2: #iptables -t nat -A POSTROUTING -o eth0 -s 172.16.1.0/24 -d 0/0 -j MASQUERADE
I changed the MASQUERAD statement when I wanted to bring the workstations up. This is what egge said had to be done, which was correct.
Capt_Caveman, your rules for PING and SSH corrected the last 2 problems I had. The only change I made was in the INPUT rule. I added a -s 68.xx.xxx.xx so that SSH only worked from a specific IP address that I will be using.
After this discussion I am starting to see the light on how IPTABLES and the firewall works. This is more or less how I understand it to work:
Any desktop on the LAN communicating with the server does it through INPUT and OUTPUT rules on eth1. If a desktop on the LAN side needs the outside world it does it with FORWARD/POSTROUTING rules.
The server has direct access to the outside world through eth0 and INPUT and OUTPUT rules. Therefore the server/firewall itself does not use forwarding rules.
Anything from the outside coming in does it through FORWARD/PREROUTING rules on eth0.
I appreciate the posts from both of you. I don't think I would have been able to make everything work without your help. Thanks and a hats off to you guys. :-)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.