Understanding IPTABLES - asus ROG ax6000

[francisport]

Hi there!


I want to reinforce the router security (asus rog ax6000) running with asuswrt-merlin and entware installed.

I have some questions for most of them... specially state NEW and bootps/bootpc:

homeadmin@homerouter:/tmp/home/root# iptables -L INPUT | grep ACCEPT
Chain INPUT (policy ACCEPT)
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state NEW
ACCEPT all -- anywhere anywhere state NEW
ACCEPT udp -- anywhere anywhere udp spt:bootps dpt:bootpc
ACCEPT tcp -- anywhere homerouter. ctstate DNAT tcp dpt:8443
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT gre -- anywhere anywhere
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT udp -- anywhere anywhere udp dpt:bootpc
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT udp -- anywhere anywhere udp dpt:bootpc


My questions:
Does someone know why they are there?
Does state NEW be needed to allow accepting ssh/https ones?
Why bootps/bootpc entries are there?

In case of tunning, do I have to create a script to run at boot?


I have more doubts for the complex iptables I found, but I want to start with the INPUT table first.


MAY THE FORTH BE WITH YOU

 

[dave14305]

If you re-run your command as iptables -S INPUT | grep ACCEPT you will get some additional output for each of those rules, including the interface they apply to.

 

[francisport]

If you re-run your command as iptables -S INPUT | grep ACCEPT you will get some additional output for each of those rules, including the interface they apply to.

Thanks, really useful to understand why some entries are there, but maybe i'm still wondering for others

 

[eibgrad]

Understanding iptables output is a LOT more useful and meaningful if seen in its FULL context, particularly the order of execution.

iptables -vnL INPUT --line-numbers

Now you can see that context and point to specific rules (by number) which you feel need further explanation.

admin@lab-merlin1:/tmp/home/root# iptables -vnL INPUT --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination    
1    15709  943K ACCEPT     all  --  eth0   *       192.168.61.0/24      0.0.0.0/0            state NEW
2    1226K  135M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
3       37  1888 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
4     517K  110M PTCSRVWAN  all  --  !br0   *       0.0.0.0/0            0.0.0.0/0      
5    50660 4492K PTCSRVLAN  all  --  br0    *       0.0.0.0/0            0.0.0.0/0      
6    50660 4492K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0            state NEW
7       47  7081 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0            state NEW
8        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68
9        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.1          ctstate DNAT tcp dpt:8443
10      15   900 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
11       1    84 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0      
12    517K  110M OVPNSI     all  --  *      *       0.0.0.0/0            0.0.0.0/0      
13    517K  110M OVPNCI     all  --  *      *       0.0.0.0/0            0.0.0.0/0      
14    517K  110M DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Notice you can now see what rules are even being hit, and how often (if at all).

 

[francisport]

Understanding iptables output is a LOT more useful and meaningful if seen in its FULL context, particular the order of execution.

iptables -vnL INPUT --line-numbers

Now you see that context and point to specific rules (by number) which you feel need further explanation.

admin@lab-merlin1:/tmp/home/root# iptables -vnL INPUT --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination   
1    15709  943K ACCEPT     all  --  eth0   *       192.168.61.0/24      0.0.0.0/0            state NEW
2    1226K  135M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
3       37  1888 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
4     517K  110M PTCSRVWAN  all  --  !br0   *       0.0.0.0/0            0.0.0.0/0     
5    50660 4492K PTCSRVLAN  all  --  br0    *       0.0.0.0/0            0.0.0.0/0     
6    50660 4492K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0            state NEW
7       47  7081 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0            state NEW
8        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68
9        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.1          ctstate DNAT tcp dpt:8443
10      15   900 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
11       1    84 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0     
12    517K  110M OVPNSI     all  --  *      *       0.0.0.0/0            0.0.0.0/0     
13    517K  110M OVPNCI     all  --  *      *       0.0.0.0/0            0.0.0.0/0     
14    517K  110M DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Notice you can now see what rules are even being hit, and how often (if at all).

wonderful command, this might reduce the learning curve to understand what I'm doing

But I;ve installed a webdav service (alaya) running on port 3443

/tmp/home/root# lsof -i :3443
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
alaya 3858 nroot 10u IPv4 13773 0t0 TCP *:3443 (LISTEN)

But it seems the iptable I set need something else:

# iptables -I INPUT 13 -p tcp -m tcp --dport 3443 -j ACCEPT


# iptables -L INPUT --line-numbers
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 INPUT_PING icmp -- anywhere anywhere icmp echo-request
2 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
3 logdrop all -- anywhere anywhere state INVALID
4 PTCSRVWAN all -- anywhere anywhere
5 PTCSRVLAN all -- anywhere anywhere
6 logdrop tcp -- anywhere anywhere tcp dpt:5152
7 ACCEPT all -- anywhere anywhere state NEW
8 ACCEPT all -- anywhere anywhere state NEW
9 ACCEPT udp -- anywhere anywhere udp spt:bootps dpt:bootpc
10 ACCEPT tcp -- anywhere homerouter. ctstate DNAT tcp dpt:8443
11 ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
12 ACCEPT tcp -- anywhere anywhere tcp dpt:https
13 ACCEPT tcp -- anywhere anywhere tcp dpt:3443 <------ added right here
14 INPUT_ICMP icmp -- anywhere anywhere
15 ACCEPT gre -- anywhere anywhere
16 ACCEPT udp -- anywhere anywhere udp dpt:domain
17 ACCEPT udp -- anywhere anywhere udp dpt:bootps
18 ACCEPT udp -- anywhere anywhere udp dpt:bootpc
19 DROP all -- anywhere anywhere
20 ACCEPT udp -- anywhere anywhere udp dpt:domain
21 ACCEPT udp -- anywhere anywhere udp dpt:bootps
22 ACCEPT udp -- anywhere anywhere udp dpt:bootpc
23 DROP all -- anywhere anywhere
24 WGSI all -- anywhere anywhere
25 WGCI all -- anywhere anywhere
26 OVPNSI all -- anywhere anywhere
27 OVPNCI all -- anywhere anywhere
28 logdrop all -- anywhere anywhere


So:
do I have to set something else somewhere?
where to find the NAT or DNAT table?



MIGHT THE FORCE BE WITH YOU!

 

[ColinTaylor]

@francisport Please remove the Entware prefix from your thread title as your question has nothing to do with Entware. Thanks.

 

[eibgrad]

In general, it's a bad idea to try and insert a rule in a specific/absolute location (13 in your case). The firewall can change significantly over time as subsystems come and go and add/remove their own rules. You're usually better off to simply insert them at the top (no number), and ideally after any other subsystems have completed their own changes. Doesn't always work, but the chances are much greater it will then trying to use absolute positioning.

 

[francisport]

In general, it's a bad idea to try and insert a rule in a specific/absolute location (13 in your case). The firewall can change significantly over time as subsystems come and go and add/remove their own rules. You're usually better off to simply insert them at the top (no number), and ideally after any other subsystems have completed their own changes. Doesn't always work, but the chances are much greater it will then trying to use absolute positioning.

thanks for the advice, i just want to know if adding into an specific position works

 

[eibgrad]

thanks for the advice, i just want to know if adding into an specific position works

Well you didn't use the command exactly as I suggested. Instead of using ...

iptables -vnL INPUT --line-numbers

... you specified ...

iptables -L INPUT --line-numbers

... which left out details, in this case, whether the rule is getting any hits (pkts)! That alone will answer if it's working.

But there's always the possibility that rules that execute before it may jump to other chains that will DROP/REJECT a packet before it ever gets to your rule. But if there's at least one hit, we know it can be reached at least *sometimes*.

That's why you sometimes need even more context, such as dumping the filter table entirely.

iptables -vnL --line-numbers

Or at least other chains that are reachable from the INPUT chain and precede your rule(s).

iptables -vnL PTCSRVWAN --line-numbers
iptables -vnL PTCSRVLAN --line-numbers

Context is king here!

 

[francisport]

It partially works now, I thought the service was configured with SSL but not yet...


anyway, below the output to know the context:

homeadmin@homerouter:/tmp/home/root#
homeadmin@homerouter:/tmp/home/root# iptables -vnL INPUT --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 1740 144K INPUT_PING icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
2 102K 18M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
3 441 45120 logdrop all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
4 217K 35M PTCSRVWAN all -- !br0 * 0.0.0.0/0 0.0.0.0/0
5 11257 3816K PTCSRVLAN all -- br0 * 0.0.0.0/0 0.0.0.0/0
6 0 0 logdrop tcp -- !lo * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5152
7 11257 3816K ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0 state NEW
8 208K 33M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 state NEW
9 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
10 2043 107K ACCEPT tcp -- * * 0.0.0.0/0 192.168.50.1 ctstate DNAT tcp dpt:8443
11 46 2280 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
12 55 2916 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
13 5 260 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3443
....

# iptables -vnL PTCSRVWAN --line-numbers
Chain PTCSRVWAN (1 references)
num pkts bytes target prot opt in out source destination
#

# iptables -vnL PTCSRVLAN --line-numbers
Chain PTCSRVLAN (1 references)
num pkts bytes target prot opt in out source destination
#


Now I need to understand how alaya manage the authentication and the way to secure by SSL.

 

[fearz]

Hi there!


I want to reinforce the router security (asus tuf ax6000) running with asuswrt-merlin and entware installed.

I have some questions for most of them... specially state NEW and bootps/bootpc:

homeadmin@homerouter:/tmp/home/root# iptables -L INPUT | grep ACCEPT
Chain INPUT (policy ACCEPT)
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state NEW
ACCEPT all -- anywhere anywhere state NEW
ACCEPT udp -- anywhere anywhere udp spt:bootps dpt:bootpc
ACCEPT tcp -- anywhere homerouter. ctstate DNAT tcp dpt:8443
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT gre -- anywhere anywhere
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT udp -- anywhere anywhere udp dpt:bootpc
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT udp -- anywhere anywhere udp dpt:bootpc


My questions:
Does someone know why they are there?
Does state NEW be needed to allow accepting ssh/https ones?
Why bootps/bootpc entries are there?

In case of tunning, do I have to create a script to run at boot?


I have more doubts for the complex iptables I found, but I want to start with the INPUT table first.


MAY THE FORTH BE WITH YOU

How did you install Merlin on that router? its not supported.

 

[francisport]

How did you install Merlin on that router? its not supported.

it seems it´s supported but I don´t know since.

I just went through asuswrt-merlin and got it.

 

[fearz]

it seems it´s supported but I don´t know since.

I just went through asuswrt-merlin and got it.

Can you please share the link?

are you sure its for the TUF AX6000?

 

[francisport]

Can you please share the link?

are you sure its for the TUF AX6000?

really sorry it's ROG one instead TUF

Asuswrt-Merlin - Browse /GT-AX6000 at SourceForge.net

Alternative firmware for Asus wireless routers

sourceforge.net

 

[fearz]

really sorry it's ROG one instead TUF

Asuswrt-Merlin - Browse /GT-AX6000 at SourceForge.net

Alternative firmware for Asus wireless routers

sourceforge.net

And its working fine on your TUF? Or you have a GT?

 

[francisport]

And its working fine on your TUF? Or you have a GT?

Really sorry replying so late, but it´s ASUS GT-AX6000

 

[lgkahn]

BACK to the original questions... bootp etc is used for network device config. to get an ip address during boot up.. it is a different protocol than the more widely used dhcp.. so my guess would be those rules are to allow bootp to work on you network behind any firewall on your router.

 

[ColinTaylor]

BACK to the original questions... bootp etc is used for network device config. to get an ip address during boot up.. it is a different protocol than the more widely used dhcp.. so my guess would be those rules are to allow bootp to work on you network behind any firewall on your router.

The "bootp" references are just human-friendly names for specific ports and protocols as defined in /etc/services. In itself it doesn't actually define what that port is going to be used for. This is clearer in post #4 where we can see the iptables rule is for UDP source port 67 and destination port 68. So what this rule does is tell the firewall to allow replies from an upstream DHCP server (e.g. when your router's WAN interface is configured as a DHCP client).