CentOS 7, iptables, and rules not taking effect

cwbuege · 06-02-2016, 03:43 PM

All -

Here's what I'm working with here. I've got a CentOS 7 server with two NICs on it. It's a virtual server so the interfaces aren't physical, but the system doesn't care.

Additionally, after trying to get it to work, I've gone back to iptables instead of firewalld. I'm reading many posts that recommend more and more strongly that firewalld is good for workstations, but not a good fit for servers. Anyone who comments in that regards, I'll listen, so feel free to chime in on that subject. That isn't my real question though.

Here's the real crux of my problem. I've just installed iptabes, iptables-services, and enabled it. I can stop and start iptables with systemctl no problem. What I am running into is this specific scenario. As mentioned previously, I've got two NICs on it and they are ens160 for private/internal network and ens192 for external traffic/access. Iptables works fine when I first start up the machine - I have the port 22/ssh rule defined to only work on interface ens160 (I added '-i ens160' to the end of the rule).

Full rule: -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -i ens160

I'd also only like to permit ping from the inside as well. I did the same thing adding '-i ens160'.

Full rule: -A INPUT -p icmp -j ACCEPT -i ens160

If I remove the '-i ens160' from the ssh rule and restart iptables, I can then access ssh from the outside world via ens192. Ok - that's normal. I put '-i ens160' back onto the port 22 rule, restart iptables, and *poof* I can't ssh in from ens192. Again, perfectly normal. Done this TONS of times before to make sure my security was right in CentOS 6.

I start a continuous ping against my external IP address (the one assigned to ens192) and it doesn't work. Normal behavior. If I remove the '-i ens160' from the icmp line, restart iptables, and then the ping starts going through. Again, this is normal. Here's where it gets weird. I put the '-i ens160' back onto the icmp rule, restart iptables, and my ping keeps going. I keep getting a response from it. After restarting the server, the rule 'takes effect' and the ping stops (I've had the ping running all of this time).

So, for some reason, upon the restart of iptables the '-i' parameter on the icmp rule is being ignored.

Anyone have any suggestions as to what I may be doing wrong? I'll share whatever I can as far as my config files, etc., but I'm utterly confused here.

Thank you in advance,
Charles

v4r3l0v · 06-02-2016, 09:06 PM

Charles,
Adopting firewalld and dumping iptables isn't just a cosmetic feature. Firewalld is much more closely integrated with NetFilter than iptables ever were. There's much more you could do with firewalld beside opening ports and adding services, namely rich rules.

lazydog · 06-03-2016, 12:38 PM

Quote:

Originally Posted by cwbuege

Here's where it gets weird. I put the '-i ens160' back onto the icmp rule, restart iptables, and my ping keeps going. I keep getting a response from it. After restarting the server, the rule 'takes effect' and the ping stops (I've had the ping running all of this time).

So, for some reason, upon the restart of iptables the '-i' parameter on the icmp rule is being ignored.

Anyone have any suggestions as to what I may be doing wrong? I'll share whatever I can as far as my config files, etc., but I'm utterly confused here.

Thank you in advance,
Charles

Your ICMP connection is considered ESTABLISHED and that is why the pings continue to work. Once you reboot the server all contentions are reset thus ping no longer works. If you stop the pings and allow time for the connection to timeout you will see the pings will be dropped after that.

If you would like to see what the kernel has for connection you could install conntrack-tools and have a look at them with

Code:

conntrack -L

Here is a sample of what you can see:

Code:

# conntrack -L
udp      17 22 src=10.5.35.18 dst=255.255.255.255 sport=49154 dport=8585 [UNREPLIED] src=255.255.255.255 dst=10.5.35.18 sport=8585 dport=49154 mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1
udp      17 23 src=10.5.33.237 dst=10.5.63.255 sport=137 dport=137 [UNREPLIED] src=10.5.63.255 dst=10.5.33.237 sport=137 dport=137 mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1
tcp      6 299 ESTABLISHED src=10.5.33.30 dst=10.5.32.50 sport=19829 dport=22 src=10.5.32.50 dst=10.5.33.30 sport=22 dport=19829 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1
udp      17 26 src=10.5.33.61 dst=10.5.63.255 sport=137 dport=137 [UNREPLIED] src=10.5.63.255 dst=10.5.33.61 sport=137 dport=137 mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1
icmp     1 29 src=10.5.33.30 dst=10.5.32.50 type=8 code=0 id=1 src=10.5.32.50 dst=10.5.33.30 type=0 code=0 id=1 mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1
conntrack v1.4.2 (conntrack-tools): 5 flow entries have been shown.

You will notice that I have an icmp line. That is my ping to the device from my laptop.

Quote:

Originally Posted by v4r3l0v

Charles,
Adopting firewalld and dumping iptables isn't just a cosmetic feature. Firewalld is much more closely integrated with NetFilter than iptables ever were. There's much more you could do with firewalld beside opening ports and adding services, namely rich rules.

Not sure where you get the idea from. Firewalld is no better then iptables.
They both do the same thing and iptables can do anything that firewalld can.

Turbocapitalist · 06-04-2016, 01:40 AM

Quote:

Originally Posted by v4r3l0v

Firewalld is much more closely integrated with NetFilter than iptables ever were. There's much more you could do with firewalld beside opening ports and adding services, namely rich rules.

Would you have a good reference to cite which backs up that claim? The source code seems to contradict it.

Just a quick skim of the scripts, it's in python and shell, suggests that it is more similar to UFW and both are front-ends for iptables. It also looks like it has some ability to interact with ebtables as well for bridging. In other words, it looks like just another UI and the rules produced by firewalld are going to be the exact same ones (though maybe more convoluted) than ones that you would make with iptables directly.

fred2014 · 06-06-2016, 03:25 AM

I've been using shorewall for about 5 years now(http://www.shorewall.net/) and have found it
highly flexible and totally reliable for my use. One reason I like it is once installed
it is very easy to maintain and adjust. To enable changes without restarting the server
just use a reload command. It is far more capable than my needs warrant but I've found
I can just ignore the rest I don't use and leave it on defaults and everything runs fine.
It may be worth a look if you are unhappy with what you have.

cwbuege · 06-06-2016, 11:06 AM

Quote:

Originally Posted by lazydog

Your ICMP connection is considered ESTABLISHED and that is why the pings continue to work. Once you reboot the server all contentions are reset thus ping no longer works. If you stop the pings and allow time for the connection to timeout you will see the pings will be dropped after that.

lazydog -

I understand what you're saying, but here's my question: If I do the exact same thing with CentOS 6, when I put the '-i eth1' (since its eth and not ens for CentOS 6) and restart iptables, the ping stops immediately. Any idea why that might be? And you're right - if I stopped the continuous ping and gave it about 30 seconds, the next time I tried to ping the external address it did fail.

I guess, in the end, I want to understand what's happening with CentOS 6 (which I'm more used to) and isn't happening with CentOS 7 to make the difference as to why the ping doesn't stop immediately.

Thanks,
Charles

lazydog · 06-06-2016, 12:31 PM

How different are the rules between 6 and 7? are the same files being used? I would expect the same to happen on 6 as it does on 7.
Can you post the file /etc/sysconfig/iptables from both 6 and 7?

cwbuege · 06-06-2016, 12:45 PM

Quote:

Originally Posted by lazydog

How different are the rules between 6 and 7? are the same files being used? I would expect the same to happen on 6 as it does on 7.
Can you post the file /etc/sysconfig/iptables from both 6 and 7?

Sure - I should have just done that to begin with.

Here's the CentOS 6 one:
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT -i eth0
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -i eth0
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

Here's the CentOS 7 one:
# sample configuration for iptables service
# you can edit this manually or use system-config-firewall
# please do not ask us to add additional ports/services to this default configu$
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
### -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT -i ens160
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -i ens160
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

The only change I made to this file was that the CentOS 7 was originally set for 'RELATED,ESTABLISHED' on the first line, so I commented it out and tried swapping it to 'ESTABLISHED,RELATED' like the CentOS 6 one, but that made no difference.

And just to be thorough, here's more info - I've changed the IP address info for the last three octets of the external interfaces to protect the (probably) n00b! *laughs*

CentOS 6 - ifcfg-eth0

DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=none
HWADDR=00:0C:29

4:2C:4A
IPADDR=10.105.43.2
PREFIX=16
DNS1=10.105.0.21
DNS2=10.105.0.22
DOMAIN=mydomain.com
DEFROUTE=no
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth0"

CentOS 6 - route-eth0 -

10.0.0.0/8 via 10.105.0.254 dev eth0

CentOS 6 - ifcfg-eth1 - And yes, the IP address and Gateway are correct values and are not the same

DEVICE=eth1
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=none
HWADDR=00:0C:29

4:2C:54
IPADDR=12.X.Y.X
PREFIX=25
GATEWAY=12.X.Y.X
DNS1=12.127.16.67
DNS2=12.127.17.71
DOMAIN=mydomain.com
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth1"

CentOS 6 - network -

NETWORKING=yes
HOSTNAME=centos6hostname
GATEWAY=12.X.Y.Z
GATEWAYDEV=eth1

CentOS 7 - ifcfg-ens160 -

TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=no
IPV4_FAILURE_FATAL=no
IPV6INIT=no
NAME=ens160
DEVICE=ens160
ONBOOT=yes
DNS1=10.105.0.21
DNS2=10.105.0.22
DOMAIN=temeda.com
IPADDR=10.105.43.1
PREFIX=16
GATEWAY=10.105.0.254
ZONE=work

CentOS 7 - route-ens160 -

10.0.0.0/8 via 10.105.0.254 via dev ens160

CentOS 7 - ifcfg-ens192 - And yes, the IP address and Gateway are correct values and are not the same

TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=no
NAME=ens192
DEVICE=ens192
ONBOOT=yes
DNS1=12.127.16.67
DNS2=12.127.17.71
DOMAIN=temeda.com
IPADDR=12.X.Y.Z
PREFIX=25
GATEWAY=12.X.Y.Z
ZONE=external

Let me know if you need me to share any additional information.

Charles

lazydog · 06-07-2016, 08:11 AM

I don't have a Centos 6 box setup at the moment to look into this deeper.

cwbuege · 06-08-2016, 08:50 AM

Quote:

Originally Posted by lazydog

I don't have a Centos 6 box setup at the moment to look into this deeper.

lazydog -

No problem, man. Thanks for looking into what you have so far. Maybe someone else will stumble across this and be able to help out. I do everything like this off of a VMware ESXi box so I can build and destroy machines at will. Man, I sound like an Evil Overlord saying it like that - Lol!!

Charles