Firewall iprange rule issue

As above. Censys frequently access my website. They give me suggestion to block the scan. My firewall configuration as below:

config rule
	option src 'wan'
	option name 'CenSysBlock1'
	option proto 'all'
	option target 'REJECT'
	option extra '-m iprange --src-range 74.120.14.0-74.120.14.255'

config rule
	option src 'wan'
	option name 'CenSysBlock2'
	option proto 'all'
	option target 'REJECT'
	option extra '-m iprange --src-range 162.142.125.0-162.142.125.255'

config rule
	option src 'wan'
	option name 'CenSysBlock3'
	option proto 'all'
	option target 'REJECT'
	option extra '-m iprange --src-range 167.248.133.0-167.248.133.255'

config rule
	option src 'wan'
	option name 'CenSysBlock4'
	option proto 'all'
	option target 'REJECT'
	option extra '-m iprange --src-range 192.35.168.0-192.35.168.255'

config rule
	option src 'wan'
	option name 'CenSysBlock4-2'
	option proto 'all'
	option target 'REJECT'
	option extra '-m iprange --src-range 192.35.169.0-192.35.169.255'

when reload the rule. It says:

   * Rule 'CenSysBlock1'
Warning: fw3_ipt_rule_append(): Can't find match 'iprange'
   * Rule 'CenSysBlock2'
Warning: fw3_ipt_rule_append(): Can't find match 'iprange'
   * Rule 'CenSysBlock3'
Warning: fw3_ipt_rule_append(): Can't find match 'iprange'
   * Rule 'CenSysBlock4'
Warning: fw3_ipt_rule_append(): Can't find match 'iprange'
   * Rule 'CenSysBlock4-2'
Warning: fw3_ipt_rule_append(): Can't find match 'iprange'

And I'm sure:

iptables-mod-iprange 1.8.3-1
kmod-ipt-iprange 4.14.180-1

are all installed.

after reload or reboot. the rules are not effective. How should I soluve it?

You don't need those rules as input and forward from WAN are disabled by default.

3 Likes

He has a server running on the port.

I'm lost at what this means...

The proper notation for this subnet would be: 192.35.168.0/24. You can place that in the normal SRC IP section of the rule configs.

3 Likes

OK, Let's me clarify that I use the uhttp as a web server and deployed a website on my 3rd level router through port forwarding. I want to use the rules on my 2nd level router to filter Censys scan.

I have try the configuration as your suggestion:

config rule
	option src 'wan'
	option name 'CenSysBlock1'
	option proto 'all'
	option target 'REJECT'
	option extra '-m iprange --src-range 74.120.14.0/24'

config rule
	option src 'wan'
	option name 'CenSysBlock2'
	option proto 'all'
	option target 'REJECT'
	option extra '-m iprange --src-range 162.142.125.0/24'

config rule
	option src 'wan'
	option name 'CenSysBlock3'
	option proto 'all'
	option target 'REJECT'
	option extra '-m iprange --src-range 167.248.133.0/24'

config rule
	option src 'wan'
	option name 'CenSysBlock4'
	option proto 'all'
	option target 'REJECT'
	option extra '-m iprange --src-range 192.35.168.0/23'

Hope it works. will let you know.

I have clarified my situation in my new reply. Do you mind providing some further suggestion to soluve my issue?

I provided the information needed. And in fact, you put a normal drop rule on the first device in the stream, as long as the rule is first rule.

My suggestion???

No, why do you keep using the option extra???

config rule
	option family 'ipv4'
	option proto 'all'
	option src '*'
	option target 'DROP'
	option name 'CenSysBlock'
	list src_ip '74.120.14.0/24'
	list src_ip '162.142.125.0/24'
	list src_ip '167.248.133.0/24'
	list src_ip '192.35.168.0/23'

(BTW, REJECT sends an ICMP error to the SRC, so I used DROP.)

2 Likes

According to

It seems that the syntax just support individual ip address.not support subnet mask. And i search it on the web. somebody just had the same issue and used the iprange parameter. So I did it like that. I will try your cofigurateion. Thanks.

1 Like

Perhaps you can edit that if it confused you. The underlying software (iptables) does in fact support CIDR notation (hence including IP masks/ranges). This includes everything - from a single /32 up to the addressing the whole Internet via /0.

3 Likes

Note that when you are using only src zone, then it is implied INPUT, than means to the router.
If you use src and dst zones, then it is implied FORWARD, which is what you want from my understanding

3 Likes

I accidentally removed the option dst '*'* portion. Thanks for noting that.

2 Likes

No problemo, it was missing in general so I thought I'd bring it up.

1 Like

I am successfully using CIDR in ipsets:

config ipset
        option name 'foo'
        option match 'dest_ip'
        option family 'ipv4'
        option storage 'hash'
        option enabled '1'
        option maxelem '65536'
        option timeout '7200'
        list entry '...'
        list entry '80.228.111.1/24'

instead of

option iprange '51.103.5.1/24'

which I dind't get working with ipsets.

Alternatively CIDR can be used in rules:

config rule
        option name 'TESTRULE'
        option target 'REJECT'
        list proto 'all'
        option src 'wlan_fw_kn'
        list src_ip '192.168.150.87'
        option dest 'wan'
        list dest_ip '80.228.111.1/24'

If I knew that before I wouldn't have fiddled to much with ipsets.... :grinning:

Because you are using hash and not bitmap. As per ipset manual, the iprange is used in bitmap.

1 Like

I tried iprange together with different storages.

option storage 'hash:net'

gave me

/etc/init.d/firewall reload
Warning: Option @ipset[0].storage has invalid value 'hash:net'
Warning: Section @ipset[0] (IP-Bereiche) has invalid options
Warning: Section @ipset[0] (IP-Bereiche) defines no storage method, assuming 'bitmap'
Warning: Section @ipset[0] (IP-Bereiche) maxelem ignored
 * Clearing IPv4 filter table
...

While using

    option storage 'bitmap'
    option iprange '51.103.5.1/24'

I got

/etc/init.d/firewall  restart
Warning: Section @ipset[0] (IP-Bereiche) maxelem ignored
 * Flushing IPv4 filter table
 * Flushing IPv4 nat table
 * Flushing IPv4 mangle table
 * Flushing IPv6 filter table
 * Flushing IPv6 mangle table
 * Deleting ipset IP-Bereiche
 * Flushing conntrack table ...
 * Creating ipset IP-Bereiche
ipset v7.3: Element is out of the range of the set
ipset v7.3: Element is out of the range of the set
ipset v7.3: Element is out of the range of the set
...

Worked fine for me:

root@magiatiko / > ipset list dropcidr
Name: dropcidr
Type: bitmap:ip
Revision: 3
Header: range 42.56.0.0-42.56.1.2
Size in memory: 128
References: 1
Number of entries: 3
Members:
42.56.0.1
42.56.0.2
42.56.0.3
root@magiatiko / > uci show firewall.@ipset[-1]
firewall.cfg3c6e2a=ipset
firewall.cfg3c6e2a.name='dropcidr'
firewall.cfg3c6e2a.match='dest_ip'
firewall.cfg3c6e2a.storage='bitmap'
firewall.cfg3c6e2a.enabled='1'
firewall.cfg3c6e2a.iprange='42.56.0.0-42.56.1.2'
firewall.cfg3c6e2a.entry='42.56.0.1-42.56.0.3'
root@magiatiko / > uci show firewall.@rule[-1]
firewall.cfg3d92bd=rule
firewall.cfg3d92bd.dest='wan'
firewall.cfg3d92bd.ipset='dropcidr'
firewall.cfg3d92bd.proto='icmp'
firewall.cfg3d92bd.target='DROP'
firewall.cfg3d92bd.name='test drop'
firewall.cfg3d92bd.enabled='1'
firewall.cfg3d92bd.family='ipv4'
root@magiatiko / > ping -c 1 42.56.0.1
PING 42.56.0.1 (42.56.0.1) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
--- 42.56.0.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
1 Like