5

Hi I Have a online server which i use like gateway and iptables is acting weird

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j BLOCK_CHAIN
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j BLOCK_CHAIN
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i tun+ -j ACCEPT
-A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun+ -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i eth0 -o tun+ -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i eth0 -o tun+ -p tcp -m tcp --dport 443 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A BLOCK_CHAIN -s 173.230.154.149/32 -j REJECT --reject-with icmp-host-prohibited
-A BLOCK_CHAIN -m state --state NEW -j ACCEPT

but 173.230.154.149 still can get to the apache server in 80 or 443 it shouldn't be blocked by

-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j BLOCK_CHAIN
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j BLOCK_CHAIN

and

-A BLOCK_CHAIN -s 173.230.154.149/32 -j REJECT --reject-with icmp-host-prohibited

Yes It's a online server which route all the web services to an personal bigger server over a vpn whit openvpn

every thing work as expected just i cant block incoming connection from certain ip witch obviously are attacking the server

the typolgy of he network is

External Ip XX.XX.X.XX Vpn 10.0.0.0/24

-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.100
-A PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.0.0.100
5
  • By "gateway", do you mean that your web server is not running on the online server? Because your rule is intended to block access to a local web server, not a routed web server. Also if the tunnel is involved somehow, you should describe your network setup (ie: addresses, routes etc.). Btw, it will block new connections, not those already here.
    – A.B
    Jul 5, 2023 at 21:33
  • Yes I know any New Connection it should be rejected right i did reboot the server so every connection it should be marked as knew and i will update the question thank for your advise
    – denn0n
    Jul 5, 2023 at 22:16
  • 1
    As a general point in case it's useful, monitoring the rule counters (-L option) is a useful diagnostic tool. However it obviously doesn't help much with packets which haven't been matched by anything, unless one is absolutely paranoid about ensuring that every possible path has at least one dummy rule. Jul 6, 2023 at 12:34
  • @MarkMorganLloyd and to follow your idea: iptables-save -c gives the best of both things: shows rules counters, while also giving a reproducible ruleset.
    – A.B
    Jul 6, 2023 at 12:42
  • 1
    @A.B Good point. I'd add that in the past, with a particularly cussed system where rules were being created/deleted to track dynamic interfaces, I added specific logging rules... but for the moment at least I can't remember how I was extracting the data. /Something/ is badly needed, otherwise one has problems like OP. Jul 6, 2023 at 14:04

1 Answer 1

9

A packet being routed rather than received by a local process traverses the filter/FORWARD chain and not the filter/INPUT chain, even if this is caused by the use of NAT. So the current blocking rules in filter/INPUT have no effect. These rules:

-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j BLOCK_CHAIN
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j BLOCK_CHAIN

should simply be replaced by:

-A FORWARD -i eth0 -p tcp -m tcp --dport 443 -j BLOCK_CHAIN
-A FORWARD -i eth0 -p tcp -m tcp --dport 80 -j BLOCK_CHAIN

Obviously, they should be added before the rules allowing access to the web server so they can have any effect. So add them at least before these:

-A FORWARD -i eth0 -o tun+ -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i eth0 -o tun+ -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i eth0 -o tun+ -p tcp -m tcp --dport 443 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT

Because once the initial connection is accepted, all further packets will be short-circuited by this rule:

-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

So they must be blocked the first time they are seen.


Additional remarks:

  • redundant rules

    -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    -A FORWARD -i tun+ -j ACCEPT
    -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
    

    The 1st rule above, and also the 2nd rule, each of them separately, make the 3rd rule redundant.

    Likewise:

    -A FORWARD -i eth0 -o tun+ -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
    -A FORWARD -i eth0 -o tun+ -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
    -A FORWARD -i eth0 -o tun+ -p tcp -m tcp --dport 443 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
    

    The first rule makes the two following redundant.

    But all this might have been for testing the current issue.

  • unless running a very recent kernel (where the issue is fixed), any REJECT rule should not be allowed to reject a packet in INVALID state. Such packet should "only" be DROP-ed, or rare random connection failures of legitimate traffic can happen.

    This is now documented in iptables-extensions(8):

    Warning: You should not indiscriminately apply the REJECT target to packets whose connection state is classified as INVALID; instead, you should only DROP these.

    (The man page then provides further rationale.)

    So typically,

    -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    

    should be followed by:

    -A FORWARD -m conntrack --ctstate INVALID -j DROP
    

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .