What's new

How to Dynamically Ban Malicious IP's using IPSet (Martineau version)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I didn't hit that button. I just did an unban and it works.
Where is that button?
Sorry! I have to take a break. Got to get food for some others.
 
I didn't hit that button. I just did an unban and it works.
Where is that button?
Sorry! I have to take a break. Got to get food for some others.

If you click on the URL in the previous post

https://www.snbforums.com/threads/h...t-martineau-version.38748/page-14#post-326413

the button should be in the middle of the page.

NOTE: If you have 'dig' installed from entware-ng, the new script will also check a database to see if it is blocked,...just checked and the IP address doesn't appear to be currently on a known' blacklist database.
 
If you click on the URL in the previous post

https://www.snbforums.com/threads/h...t-martineau-version.38748/page-14#post-326413

the button should be in the middle of the page.

NOTE: If you have 'dig' installed from entware-ng, the new script will also check a database to see if it is blocked,...just checked and the IP address doesn't appear to be currently on a known' blacklist database.
Oh! I got you now! I didn't understand(Tired from setting up the two scripts IS and HP).
I use this to check on some of the ip's my son-in-law goes to cause he has not regard for safety.
Thank you! I have installed the new script into production. Are you going to make any more changes in the near future? It is hard to make changes, since the new script goes into use within an hour of the previous IPSET save.
P.S. I don't have "Entware" installed. Don't want to load extra stuff and bog the router down.
 
Last edited:
Are you going to make any more changes in the near future? It is hard to make changes, since the new script goes into use within an hour of the previous IPSET save.

I'm sorry, I don't understand what you mean by this question/statement. :confused:
 
I apologize. I meant to ask if 4.02 was the new version you are going to post for everyone or are you going to revise it?

Well it depends....if v4.02 crashes your router! :p

Using IPSETs to track the hacker attempts rather than 'cluttering' the Syslog with the tracking messages has a downside, namely the use of memory. :(

The 'status' command
Code:
./IPSET_Block.sh    status

   v4.03 © 2016-2017 Martineau, Dynamic IPSET Blocking.....
 
Name: Blacklist                                                Name: Whitelist                                 Name: BlacklistTRK
Header: family inet hashsize 8192 maxelem 65536 timeout 259200 Header: family inet hashsize 1024 maxelem 65536 Header: family inet hashsize 2048 maxelem 65536 timeout 604800
Size in memory: 286648                                         Size in memory: 8500                            Size in memory: 143940
Members:                                                       Members:                                        Members:
(Total=13724)                                                  (Total=0)                                       (Total=7424)

 Summary Blacklist: 510+0 Successful blocks! ( 13703 IPs currently banned - 21 added since: May 23 09:00 ), Entries auto-expire after 3 days 00:00:00 hrs
 
v2.06 © 2016-2017 Martineau, Hacker Port attacks Report.....

Retrieving IPSET BlacklistTRK data for 'eth0' violations, please wait.....

7424 members retrieved from IPSET (BlacklistTRK - Entries auto-expire after 7 days 00:00:00 hrs)

23 May 09:48:07: # Unique Ports attacked via 'eth0': 258 (out of 7410 attempts) tracked via IPSET

shows that additional memory is consumed (even for an empty Whitelist IPSET!) and I want to be sure that the size/trimming of the tracking IPSET is being managed correctly i.e. hopefully I have adequately (see 'restore 'command) allowed the tracking IPSET to be dynamically auto resized without the need for manual intervention or cron jobs etc. i.e. allowing the reporting on demand yet automatically removing obsolete reporting data from the IPSET to free up the memory footprint.

In truth v4.xx has been in use on my router for many weeks and I have not noticed any detrimental effect, although I have restarted IPSET_Block.sh many times for testing etc.

v4.03 has a couple of minor reporting tweaks...i.e. display the timeout value in a more human-friendly way to now show days if necessary (e.g. 604800 secs == 7 days 00:00:00 hrs) etc., but it depends if there is a need/demand to release v4.03+ as a public release.
 
Last edited:
At the moment the combination of: dnscrypt, ipset_block, ABsolution and TM AIprotection malicious sites blocking seems to work. I am going to give it a few more days, When I turn on Vulnerability Protection something gets hosed several hours later. I don't think IPSET_Block is the issue, but some interaction between dnscrypt and TM Vulnerability Protection maybe after a periodic update?

Same, not instant, can be 10-15 minutes, or several hours, with the latest being overnight. I have TrendMicro enabled, perhaps I will disable it and see how it goes
 
Last edited:
Well it depends....if v4.02 crashes your router! :p

Using IPSETs to track the hacker attempts rather than 'cluttering' the Syslog with the tracking messages has a downside, namely the use of memory. :(

The 'status' command
Code:
./IPSET_Block.sh    status

   v4.03 © 2016-2017 Martineau, Dynamic IPSET Blocking.....
 
Name: Blacklist                                                Name: Whitelist                                 Name: BlacklistTRK
Header: family inet hashsize 8192 maxelem 65536 timeout 259200 Header: family inet hashsize 1024 maxelem 65536 Header: family inet hashsize 2048 maxelem 65536 timeout 604800
Size in memory: 286648                                         Size in memory: 8500                            Size in memory: 143940
Members:                                                       Members:                                        Members:
(Total=13724)                                                  (Total=0)                                       (Total=7424)

 Summary Blacklist: 510+0 Successful blocks! ( 13703 IPs currently banned - 21 added since: May 23 09:00 ), Entries auto-expire after 3 days 00:00:00 hrs
 
v2.06 © 2016-2017 Martineau, Hacker Port attacks Report.....

Retrieving IPSET BlacklistTRK data for 'eth0' violations, please wait.....

7424 members retrieved from IPSET (BlacklistTRK - Entries auto-expire after 7 days 00:00:00 hrs)

23 May 09:48:07: # Unique Ports attacked via 'eth0': 258 (out of 7410 attempts) tracked via IPSET

shows that additional memory is consumed (even for an empty Whitelist IPSET!) and I want to be sure that the size/trimming of the tracking IPSET is being managed correctly i.e. hopefully I have adequately (see 'restore 'command) allowed the tracking IPSET to be dynamically auto resized without the need for manual intervention or cron jobs etc. i.e. allowing the reporting on demand yet automatically removing obsolete reporting data from the IPSET to free up the memory footprint.

In truth v4.xx has been in use on my router for many weeks and I have not noticed any detrimental effect, although I have restarted IPSET_Block.sh many times for testing etc.

v4.03 has a couple of minor reporting tweaks...i.e. display the timeout value in a more human-friendly way to now show days if necessary (e.g. 604800 secs == 7 days 00:00:00 hrs) etc., but it depends if there is a need/demand to release v4.03+ as a public release.
So far! It is running perfectly.
The address 112.210.232.84 is showing up in the HackerPorts on "Speedguide" as a "red" in Spamhouse on the "Blacklist" button. Should that be banned?
 
The address 112.210.232.84 is showing up in the HackerPorts on "Speedguide" as a "red" in Spamhouse on the "Blacklist" button. Should that be banned?

Well this is disconcerting...doesn't bode well for v4.xx :eek:

Clearly if HackerPorts.sh has reported the unsolicited access attempt, then the I/P address should already be banned.

Presumably the following does show that the Blacklist IPSET is actually being populated?
Code:
./IPSETBlock.sh   status

So if you issue the following commands:
Code:
ipset test Blacklist 112.210.232.84

ipset list BlacklistTRK | grep  112.210.232.84

grep 112.210.232.84 /tmp/syslog.log

grep 112.210.232.84 /mnt/xxx/HackerReport.txt
do any of the commands return results for 112.210.232.84?...if they don't, then I'm not sure why the expected 'ipset add Blacklist' could have failed. :oops:

NOTE: As I posted previously, if entware's 'dig' utility is installed then HackerPorts.sh v2.05 will include the message confirming in 'HackerReport.txt' that 112.210.232.84 is a 'known' address to Spamhaus.org.
(The intention was that IPSET_Block.sh v4.xx would then be able to auto-set 112.210.232.84 etc. as a permanent Blacklist IPSET entry (given the external confirmation by Spamhaus.org) and as such would never auto-expire.)
 
Last edited:
Well this is disconcerting...doesn't bode well for v4.xx :eek:

Clearly if HackerPorts.sh has reported the unsolicited access attempt, then the I/P address should already be banned.

Presumably the following does show that the Blacklist IPSET is actually being populated?
Code:
./IPSETBlock.sh   status

So if you issue the following commands:
Code:
ipset test Blacklist 112.210.232.84

ipset list BlacklistTRK | grep  112.210.232.84

grep 112.210.232.84 /tmp/syslog.log

grep 112.210.232.84 /mnt/xxx/HackerReport.txt
do any of the commands return results for 112.210.232.84?...if they don't, then I'm not sure why the expected 'ipset add Blacklist' could have failed. :oops:

NOTE: As I posted previously, if entware's 'dig' utility is installed then HackerPorts.sh v2.05 will include the message confirming in 'HackerReport.txt' that 112.210.232.84 is a 'known' address to Spamhaus.org.
(The intention was that IPSET_Block.sh v4.xx would then be able to auto-set 112.210.232.84 etc. as a permanent Blacklist IPSET entry (given the external confirmation by Spamhaus.org) and as such would never auto-expire.)
Here is the output of those commands:
admin@RT-AC3100-0000:/tmp# grep 112.210.232.84 /tmp/HackerReport.txt
8 http://www.speedguide.net/port.php?port=51413 e.g. https://www.speedguide.net/ip/112.210.232.84
1 https://www.speedguide.net/ip/112.210.232.84
https://www.speedguide.net/ip/112.210.232.84
8 http://www.speedguide.net/port.php?port=51413 e.g. https://www.speedguide.net/ip/112.210.232.84
but I don't have "Entware" installed
 

So the ipset commands report nothing?
 
So the ipset commands report nothing?
Here is the output of the ./IPSET_Block.sh starus:
admin@RT-AC3100-0000:/jffs/scripts# ./IPSET_Block.sh statur

v4.02 © 2016-2017 Martineau, Dynamic IPSET Blocking.....

Summary Blacklist: 902+0 Successful blocks! ( 7982 IPs currently banned - 233 added since: May 23 12:00 ), Entries auto-expire after 168:00:00 hrs


v2.05 © 2016-2017 Martineau, Hacker Port attacks Report.....

Scanning /tmp/syslog.log for ANY interface (IN=eth0) violations, please wait.....

314 records scanned from Syslog ('/tmp/syslog.log')


23 May 12:52:25: # Unique Ports attacked via ANY interface: 2 (out of 11 attempts) tracked via SYSLOG, May 23 12:50:09 - May 23 12:52:25


Top 3 Ports attacked:
8 http://www.speedguide.net/port.php?port=51413 e.g. https://www.speedguide.net/ip/118.19.102.25
3 http://www.speedguide.net/port.php?port=23 e.g. https://www.speedguide.net/ip/176.8.157.65

Top 3 attackers:
1 https://www.speedguide.net/ip/118.19.102.25
1 https://www.speedguide.net/ip/176.8.157.65

Last 3 most recent attackers:
https://www.speedguide.net/ip/176.8.157.65
https://www.speedguide.net/ip/118.19.102.25
 
Here is the output of the ./IPSET_Block.sh starus:
admin@RT-AC3100-0000:/jffs/scripts# ./IPSET_Block.sh statur

v4.02 © 2016-2017 Martineau, Dynamic IPSET Blocking.....

Summary Blacklist: 902+0 Successful blocks! ( 7982 IPs currently banned - 233 added since: May 23 12:00 ), Entries auto-expire after 168:00:00 hrs


v2.05 © 2016-2017 Martineau, Hacker Port attacks Report.....

Scanning /tmp/syslog.log for ANY interface (IN=eth0) violations, please wait.....

314 records scanned from Syslog ('/tmp/syslog.log')


23 May 12:52:25: # Unique Ports attacked via ANY interface: 2 (out of 11 attempts) tracked via SYSLOG, May 23 12:50:09 - May 23 12:52:25


Top 3 Ports attacked:
8 http://www.speedguide.net/port.php?port=51413 e.g. https://www.speedguide.net/ip/118.19.102.25
3 http://www.speedguide.net/port.php?port=23 e.g. https://www.speedguide.net/ip/176.8.157.65

Top 3 attackers:
1 https://www.speedguide.net/ip/118.19.102.25
1 https://www.speedguide.net/ip/176.8.157.65

Last 3 most recent attackers:
https://www.speedguide.net/ip/176.8.157.65
https://www.speedguide.net/ip/118.19.102.25

I am not interested in the './IPSET_Block.sh status' command check your spelling!!!!!!

...but I never asked for this information.

Please answer the question:

Do the two ipset commands return any data.
 
I am not interested in the './IPSET_Block.sh status' command check your spelling!!!!!!

...but I never asked for this information.

Please answer the question:

Do the two ipset commands return any data.
Here is the output of those commands:
admin@RT-AC3100-0000:/jffs/scripts# ipset test Blacklist 112.210.232.84
112.210.232.84 is in set Blacklist.
admin@RT-AC3100-0000:/jffs/scripts#
admin@RT-AC3100-0000:/jffs/scripts# ipset list BlacklistTRK | grep 112.210.232.84
ipset v6.29: The set with the given name does not exist
admin@RT-AC3100-0000:/jffs/scripts#
admin@RT-AC3100-0000:/jffs/scripts# grep 112.210.232.84 /tmp/syslog.log
admin@RT-AC3100-0000:/jffs/scripts#
admin@RT-AC3100-0000:/jffs/scripts# grep 112.210.232.84 /tmp/HackerReport.txt
8 http://www.speedguide.net/port.php?port=51413 e.g. https://www.speedguide.net/ip/112.210.232.84
1 https://www.speedguide.net/ip/112.210.232.84
https://www.speedguide.net/ip/112.210.232.84
8 http://www.speedguide.net/port.php?port=51413 e.g. https://www.speedguide.net/ip/112.210.232.84
 
Here is the output of those commands:

ipset test Blacklist 112.210.232.84

112.210.232.84 is in set Blacklist.

grep 112.210.232.84 /tmp/HackerReport.txt

8 http://www.speedguide.net/port.php?port=51413 e.g. https://www.speedguide.net/ip/112.210.232.84

So clearly this answers your own query:
The address 112.210.232.84 is showing up in the HackerPorts on "Speedguide" as a "red" in Spamhouse on the "Blacklist" button. Should that be banned?
 
I use neorouter and every so often one of my far flung neorouter connected machines drops off and I have determined that IPSET_Block is placing their IPs in the block list. I have whitelisted a few, but some of them do not keep the same IPs. My code reading ability is not the best, but I have not been able to find the part of the script which does the magic. I see that lists are loaded, deleted or saved, but What criteria will place an IP on the banned list? Can that criteria be changed?
 
I use neorouter and every so often one of my far flung neorouter connected machines drops off and I have determined that IPSET_Block is placing their IPs in the block list. I have whitelisted a few, but some of them do not keep the same IPs. My code reading ability is not the best, but I have not been able to find the part of the script which does the magic. I see that lists are loaded, deleted or saved

What criteria will place an IP on the banned list?

The only criteria is that the blocking iptable rule chain detected an unsolicited access attempt using either protocol TCP or UDP to any local port.

Can that criteria be changed?

Probably.

However, if the Whitelist IPSET is populated correctly, i.e. with known exceptions that should be allowed then hopefully the script is working as designed?

Having an IP/CIDR in both Blacklist and Whitelist is clearly a waste of memory (if not ambiguous), so v4.03 does allow you to query if an I/P address has been incorrectly added to Blacklist, and conveniently allows you to move it to the Whitelist
Code:
unban   xxx.xxx.xxx.xxx   whitelist

Clearly you need to know the range of valid source addresses in order to whitelist them, but although IPSETs are extremely efficient (regardless of the number of members), the question is "is the processing of a sequence of iptables rules more efficient?"

i.e. You should be able to add say the IP/CIDR range to the Whitelist or do you want to have the IP/CIDR range defined in the iptables rule to ensure the IP/CIDR range is never added to the Blacklist IPSET (or perhaps have the iptables rule auto-add the IP/CIDR to the Whitelist IPSET!?)

My point is I'm not clear what filter criteria you would wish to add?
 
Last edited:

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top