CentOS 8 Default iptables rules Question

Support for security such as Firewalls and securing linux
Post Reply
User avatar
Fern.3.P.O
Posts: 6
Joined: 2016/09/21 16:26:48

CentOS 8 Default iptables rules Question

Post by Fern.3.P.O » 2020/09/13 01:16:28

Hello All, Im new to Linux, CentOS, At this time im working on getting familiar with iptables. Based on my online findings I've come up with the rules below, can anyone help confirm if I'm on the right track. Have I locked down my test workstation properly? Am I missing any other rule? The test workstation only needs to be able to ping it's loopback interface and access to the internet and not anything else.

Any and all help is very much appreciated.

F3rn

Rules on test workstation I entered and tested. Im able to ping my loopback interface and have access to the internet.

1 - Flushed all chain rules
2 - Added a rule to the INPUT chain to ACCEPT all loopback traffic
3 - Added a rule to the OUTPUT chain to accept all loopback traffic
3 - Changed the INPUT, OUTPUT and FORWARD chains to DROP all traffic
4 - Added a rule to the INPUT chain to ACCEPT all ESTABLISHED and RELATED traffic
5 - Added a rule to the OUTPUT chain to ACCEPT all NEW, ESTABLISHED and RELATED traffic
6 - Added a rule to drop all else incoming INPUT chain traffic

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: CentOS 8 Default iptables rules Question

Post by TrevorH » 2020/09/13 03:25:35

If you're using CentOS 8 then by default your firewall is firewalld.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

User avatar
jlehtone
Posts: 4523
Joined: 2007/12/11 08:17:33
Location: Finland

Re: CentOS 8 Default iptables rules Question

Post by jlehtone » 2020/09/13 09:55:36

Fern.3.P.O wrote:
2020/09/13 01:16:28
Hello All, Im new to Linux, CentOS, At this time im working on getting familiar with iptables. Based on my online findings ...
You have missed an important detail:
* The 'iptables' command is a tool to modify the firewall rules that are in the kernel's 'netfilter'
* The kernel in CentOS 8 (and all kernels from version 3.13 -- released Jan 2014) has 'nftables' that supersedes netfilter
* Rules in netfilter are modified with 'nft' tool
* The 'iptables' in CentOS 8 is a wrapper to 'nft' that merely converts your iptables-syntax to nftables-syntax

As such, learning the iptables syntax now (even though it can still be used) is a bit late. It seems that learning nft could be more useful.
Whether or not, learning iptables with distro that does not actually use netfilter is <trying to pick an adjective>.

While CentOS 8 has iptables.service, Red Hat writes in https://access.redhat.com/documentation ... networking
The iptables utility is deprecated in Red Hat Enterprise Linux 8. Use instead nftables.
The iptables.service is a service that uses command iptables to load rules to kernel during system startup.
The default service is firewalld.service. If it is running, then your manual commands battle with firewalld and result can be anything.

You can see the actual rules that are in the kernel with:

Code: Select all

sudo nft list ruleset

That said,
Fern.3.P.O wrote:
2020/09/13 01:16:28
1 - Flushed all chain rules
2 - Added a rule to the INPUT chain to ACCEPT all loopback traffic
3 - Added a rule to the OUTPUT chain to accept all loopback traffic
3 - Changed the INPUT, OUTPUT and FORWARD chains to DROP all traffic
4 - Added a rule to the INPUT chain to ACCEPT all ESTABLISHED and RELATED traffic
5 - Added a rule to the OUTPUT chain to ACCEPT all NEW, ESTABLISHED and RELATED traffic
6 - Added a rule to drop all else incoming INPUT chain traffic
Lets look at your INPUT. By your description it has:

Code: Select all

ACCEPT loopback
ACCEPT ESTABLISHED and RELATED
DROP
DROP (chain default)
Firewalld's 'block' zone has effectively in INPUT:

Code: Select all

		type filter hook input priority filter + 10; policy accept;
		ct state { established, related } accept
		iifname "lo" accept
		reject with icmpx type admin-prohibited
The difference between drop and reject is that reject tells everyone: "I'm not talking to you", while drop does not reply at all, pretending to not exists.

The chain's default is "accept", but we never reach that due to the catch all reject.

Note how established connections are handled before loopback. Thus the loopback rule sees only new connections.
The nftables rules in pseudo format:

Code: Select all

ACCEPT ESTABLISHED and RELATED
ACCEPT loopback
REJECT
ACCEPT (chain default)

On OUTPUT:

Code: Select all

type filter hook output priority filter + 10; policy accept;
oifname "lo" accept
ip6 daddr { ::/96, ::ffff:0.0.0.0/96, 2002::/24, 2002:a00::/24, 2002:7f00::/24, 2002:a9fe::/32, 2002:ac10::/28, 2002:c0a8::/32, 2002:e000::/19 } reject with icmpv6 type addr-unreachable
That is "accept all", except special IPv6 targets.

You have:

Code: Select all

ACCEPT loopback
ACCEPT all NEW, ESTABLISHED and RELATED traffic
DROP (chain default)
Does your machine send out anything but new, established, or related packets? If that is all, then nothing is dropped.

The default in CentOS 7 (which has netfilter) is:

Code: Select all

ACCEPT loopback
ACCEPT (chain default)

User avatar
Fern.3.P.O
Posts: 6
Joined: 2016/09/21 16:26:48

Re: CentOS 8 Default iptables rules Question

Post by Fern.3.P.O » 2020/09/13 23:24:21

Thank you @jletone, for having taking time to reply to my question. Ive been in and out of the Linux world for sometime, I plan on changing that. I'll look into leaning nftables, woud you mind if I were to reach out to you with questions if and when they come accross?

Two questions to your reply sir,

Reply 1 You Wrote : "The difference between drop and reject is that reject tells everyone: "I'm not talking to you", while drop does not reply at all, pretending to not exists"

Question : if im running a pen test box that I dont want it detected on the network, wouldnt I want for any probing taffic coming my way to be DROP, with no response? Or does it not work this way?


Reply 2 You Wrote : Does your machine send out anything but new, established, or related packets? If that is all, then nothing is dropped.

Question : if TCP\UDP port scan packets sent my way by another box, using the rules Ive set up on this test box, will these packets not get droped? Would my rule set ACCEPT all incoming traffic regardless? Am I missing this type of rule? Or is it where Ive place the rule that allows no traffic to get dropped?

Again, thank you for taking the time to answer my questions, I appreciate it very much.

F3rn
F3rn

User avatar
jlehtone
Posts: 4523
Joined: 2007/12/11 08:17:33
Location: Finland

Re: CentOS 8 Default iptables rules Question

Post by jlehtone » 2020/09/14 07:19:36

Fern.3.P.O wrote:
2020/09/13 23:24:21
Question : if im running a pen test box that I dont want it detected on the network, wouldnt I want for any probing taffic coming my way to be DROP, with no response?
Yes. There was a period, when the default/recommendation was to drop. At some point the default did change to reject.
Perhaps revealing existence became acceptable risk or some regular setups did benefit from it.

I can tell you that it is not convenient to diagnose problems when only one port is open for you and nothing else replies, not even to ping.
I used to connect a mail server. I had drop rule. The server did send a TCP ident query; not part of connection. It did not actually
care of the query result (it was fine with admin_prohibited), but since I did drop, it had to wait to TCP timeout before my connection did proceed.
Fern.3.P.O wrote:
2020/09/13 23:24:21
Question : if TCP\UDP port scan packets sent my way by another box, using the rules Ive set up on this test box, will these packets not get droped? Would my rule set ACCEPT all incoming traffic regardless? Am I missing this type of rule? Or is it where Ive place the rule that allows no traffic to get dropped?
Someone on the outside probing this machine will hit the DROP in INPUT and process in your machine
cannot possibly reply to something that it did never receive.
We are talking OUTPUT here. What your machine sends out. You have:

Code: Select all

#1 ACCEPT loopback
#2 ACCEPT all NEW, ESTABLISHED and RELATED traffic
#3 DROP (chain default)
My question was: Will you ever send out something that does not match the #2?
If you do, then why do you want to fail?
If everything that you ever send will match #1 or #2, then how is your ruleset "better" than:

Code: Select all

#1 ACCEPT loopback
#2 ACCEPT (chain default)

Post Reply