Why is this iptables file line failing in CentOS 6

Question

Hi could could anyone help me understand why line 15 is failing supposedly in my iptables file. I'm using CentOS 6.

When I try to restart iptables service, get the following:

[root@dbserver ~]# service iptables restart
iptables: Flushing firewall rules:                         [  OK  ]
iptables: Setting chains to policy ACCEPT: filter          [  OK  ]
iptables: Unloading modules:                               [  OK  ]
iptables: Applying firewall rules: iptables-restore: line 15 failed
                                                           [FAILED]

My iptables file looks like:

# 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
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
#-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -m udp -p tcp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 25 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.1/254 -m state --state NEW -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 21 -j ACCEPT

I'm only really trying to allow access to the machine from the local network presently.

Any help would be much appreciated. Thanks.

EDIT:

As per first answer, have moved COMMIT to end of file, however still receiving errors...

# 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
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -m udp -p tcp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 25 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/255 -m state --state NEW -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 21 -j ACCEPT
COMMIT

Error:

[root@dbserver ~]# service iptables restart
iptables: Flushing firewall rules:                         [  OK  ]
iptables: Setting chains to policy ACCEPT: filter          [  OK  ]
iptables: Unloading modules:                               [  OK  ]
iptables: Applying firewall rules: iptables-restore: line 13 failed
                                                           [FAILED]

Solution 1

Simple -- you need to move your COMMIT down to the end of the file.

COMMIT tells iptables that you've finished your declaration and want to send your configuration to the kernel. It ends your declaration. You're telling iptables to COMMIT, and then you're giving new rules without a new declaration, hence your error.

Edit to include contents of comment downwind:

Here's an updated and working (not necessarily optimal) version of your config: http://gist.github.com/3818123. I'll summarize some of the issues:

1. Your input chain, RH-Firewall-1-INPUT, doesn't exist. Are you copying and pasting from somewhere else?
2. Some of your rules fell after your default-reject rules. Even if the syntax took, the rules wouldn't work.
3. 192.168.1.1/254 isn't even close to valid CIDR addressing. Did you mean 192.168.1.0/24?
4. You have -A RH-Firewall-1-INPUT -m udp -p tcp, which doesn't make any sense -- I'm assuming you mean -A INPUT -m udp -p udp.

Solution 2

In addition to the COMMIT problem, as mentioned by jgoldschrafe, you're trying to add lines to a rule that doesn't exist (RH-Firewall-1-INPUT).

You will need to add a line

:RH-Firewall-1-INPUT - [0:0]

immediately below

:OUTPUT ACCEPT [0:0]

which will declare the chain, thus allowing you to add rules to it. But the chain will still have no effect, as there's nothing magic about the name, and nothing in the three main chains (INPUT,OUTPUT, and FORWARD) sends any packets to it. Certainly you can add a rule to the INPUT chain to send traffic to your new chain, but - and please don't take this the wrong way - I do note that it says at the top of that file

Manual customization of this file is not recommended.

That's there for a reason. By all means do ignore that, and edit it, but you may make some pretty big holes in your system's security or availability while you're learning to get it right.

Edit: I suspect the problem with line 19 is the address range specified as 192.168.1.0/255, which is not valid. If you want to indicate all addresses between 192.168.1.0 and 192.168.1.255, you need 192.168.1.0/24.

I do beg your pardon, but you're really not coming across as someone who knows a lot about firewalling and networks, and - assuming that this is a server you're maintaining professionally - it may not be the best place to learn this stuff.

Solution 3

In general it pays to add rules via iptables and then dump them to a file with iptables-save in case you want to use to load them again via iptables-restore for example when your system restarts because quite simply iptables-save knows its own prerequisites better than you.

Comments

[Admin]

192.168.1.1/254 looks wrong

[Larry B]

Thanks, i've move commit to the end but still receive error: [root@dbserver ~]# service iptables restart iptables: Flushing firewall rules: [ OK ] iptables: Setting chains to policy ACCEPT: filter [ OK ] iptables: Unloading modules: [ OK ] iptables: Applying firewall rules: iptables-restore: line 13 failed [FAILED] Any thoughts? cheers

[jgoldschrafe]

Hoo boy, looking this over more carefully, you've got probably half a dozen mistakes on here. I'll post an updated version to Gist in a second, but does system-config-securitylevel-tui do what you need it to do? It's a lot simpler than mucking with rules directly.

[Larry B]

Thanks for this, this still produces an error unfortuantely. iptables: Applying firewall rules: iptables-restore v1.4.7: invalid mask 254' specified Error occurred at line: 19 Try iptables-restore -h' or 'iptables-restore --help' for more information. [FAILED] Any thoughts? cheers

[jgoldschrafe]

I've updated the answer to address some of the other issues with the configuration.

[Larry B]

Thanks for all your input, just about to test. These believe it or not were from authoritative looking article

[Larry B]

Success! Much appreciated!

[Larry B]

Should mention these rules actually came from a respectable blog post, I couldn't even begin to write iptable rules. How big a risk to security do you believe these errors to be out of interest?

[Larry B]

Thank you, the "/" denoting a range did throw me a little. It's simply a database server for use on our local network and not one holding the location of the Queens private reserve of Toblerones or anything as sensitive, so just an opportunity to learn really. cheers.

[MadHatter]

Mmmmmm, National Toblerone Reserve; my kind of Swiss banking! And the slash doesn't denote a range, it denotes a mask, aka netmask.

[Larry B]

Ah! Nice one ;)

[Michael Hampton]

Welcome to Server Fault. This is not a forum; any answers should actually answer the question. See our About page and FAQ to learn how we are different from other sites.

[MadHatter]

Sorry, how does this relate to the OP's question?