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've had to stop using this script again, odd issue where DNS would stop/start, and Android would connect to WiFi but say no internet, when there was. Flushing the lists sorted it.
 
Yeah to OpenDNS, but I thought I had whitelisted their anycast IP
I don't use DNSCrypt and I am not having any problems. So I suspect that is where the problem lies.
 
I don't use DNSCrypt and I am not having any problems. So I suspect that is where the problem lies.
That's my gut instinct too, but I wouldn't know where to start. Well, my attempt was whitelisting the IP that DNSCRYPT was proxying to, and that obviously isn't right! Haha
 
I tried whitelisting opendns ips while using dnscrypt. I also didn't find their ips in the blocklist.
I have several variables in play and am slowly working my way through the permutations to see which may be the culprit. It doesn't happen instantly, only after a couple of hours. I didn't remember the commands that were recommended to run when it happened last night (and I had not printed them out...:) It could be a dnscrypt/trendmicro rather than a dnscrypt/ipsetblock.

That's my gut instinct too, but I wouldn't know where to start. Well, my attempt was whitelisting the IP that DNSCRYPT was proxying to, and that obviously isn't right! Haha
 
I tried whitelisting opendns ips while using dnscrypt. I also didn't find their ips in the blocklist.
I have several variables in play and am slowly working my way through the permutations to see which may be the culprit. It doesn't happen instantly, only after a couple of hours. I didn't remember the commands that were recommended to run when it happened last night (and I had not printed them out...:) It could be a dnscrypt/trendmicro rather than a dnscrypt/ipsetblock.
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
 
Here is a small utility script to download IPSET_Block.sh and HackerPorts.sh, format for Linux and chmod 755 on the files. Call whatever you want (e.g. get-ipblock-scripts.sh), just remember to chmod to be executable. e.g. chmod 755 get-ipblock-scripts.sh.

Code:
#!/bin/sh

#Get IPSET_Block.sh script from pastebin, convert to linux format and set permissions to 755
wget https://pastebin.com/raw/zQ3KEe8P -O /jffs/scripts/IPSET_Block.sh; dos2unix /jffs/scripts/IPSET_Block.sh
chmod 755 /jffs/scripts/IPSET_Block.sh

#Get HackerPorts.sh script from pastebin, convert to linux format and set permissions to 755
wget https://pastebin.com/raw/LRHJih8Z -O /jffs/scripts/HackerPorts.sh; dos2unix /jffs/scripts/HackerPorts.sh
chmod 755 /jffs/scripts/HackerPorts.sh
Hey, Xen!
That script d/l version 2.05 of HackerPorts. I had to revert back to v. 2.03 to work with IPSET.
Martineau must be setting up a new version, so we need to be careful when using the wget I think!
I think I found my problem!
When you and I were discussing the firewall-start and services-start. I had changed my firewall-start and edited out the init part of the script, so it wasn't re-running the init. After running it manually. It seems to be working again!
 
Last edited:
Hey, Xen!
That script d/l version 2.05 of HackerPorts. I had to revert back to v. 2.03 to work with IPSET.
Martineau must be setting up a new version, so we need to be careful when using the wget I think!
I think I found my problem!
When you and I were discussing the firewall-start and services-start. I had changed my firewall-start and edited out the init part of the script, so it wasn't re-running the init. After running it manually. It seems to be working again!
Yes, if he changes the pastebin link, then the http in the script needs to change to reflect the new url. I wondered about that. The init is the key to getting it working correctly.
 
I tried whitelisting opendns ips while using dnscrypt. I also didn't find their ips in the blocklist.
I have several variables in play and am slowly working my way through the permutations to see which may be the culprit. It doesn't happen instantly, only after a couple of hours. I didn't remember the commands that were recommended to run when it happened last night (and I had not printed them out...:) It could be a dnscrypt/trendmicro rather than a dnscrypt/ipsetblock.
My experience has led to using these scripts and turning ai-protection off. It uses far to much ram to be doing more than what these add on scripts do. I think it is a little Asus bloat actually.
 
Yes, if he changes the pastebin link, then the http in the script needs to change to reflect the new url. I wondered about that. The init is the key to getting it working correctly.
Yes!
I think you are right.
I have another question.
Is there a safe way to stop logging the "Block In"'s from the syslog without messing up the function of the IPSET script?
I know there is some explanation within the script, but that seems to be over my head. Could you break that down in simple idiot English?
 
Yes!
I think you are right.
I have another question.
Is there a safe way to stop logging the "Block In"'s from the syslog without messing up the function of the IPSET script?
I know there is some explanation within the script, but that seems to be over my head. Could you break that down in simple idiot English?
This is my understanding and I could be wrong. So caveat warning applies.

I think you are referring to the nolog option. But if this option is used, no 'Block =' messages will be generated in the system log file, which the report reads from. So, no messages in system log means no data in the report.

I see a comment in HackerPorts.sh
Code:
'IPSET_Block.sh v4.xx' optionally uses an IPSET as a crude database for logging the hack attempts as well as, or in place of, Syslog messages)
This leads me to believe that a version 4.xx of IPSET_Block.sh is in the works that will use the IPSET as a database to report from. Perhaps logging to the System Log will then no longer be necessary. I am sure @Martineau will be back once the weekend roles around and correct me ;)
 
@Martineau
I want to make sure AB-Solution does not block the domains used for your script's lists.
I'd like to include the url list file this script uses to whitelist them in AB-Solution.
Is there a permanent file stored on the users device with the url's?
If so, please let me know the standard path/filename to it.
Thanks
 
@Martineau
I want to make sure AB-Solution does not block the domains used for your script's lists.
I'd like to include the url list file this script uses to whitelist them in AB-Solution.
Is there a permanent file stored on the users device with the url's?
If so, please let me know the standard path/filename to it.
Thanks

There are currently no defined URL lists used by my script.
By default only the LAN subnet is added, although there is the caveat that the user should consider manually adding Whitelist entries to suit their environment i.e. VPN etc.
 
I think you are referring to the nolog option. But if this option is used, no 'Block =' messages will be generated in the system log file, which the report reads from. So, no messages in system log means no data in the report.

I see a comment in HackerPorts.sh
Code:
'IPSET_Block.sh v4.xx' optionally uses an IPSET as a crude database for logging the hack attempts as well as, or in place of, Syslog messages)
This leads me to believe that a version 4.xx of IPSET_Block.sh is in the works that will use the IPSET as a database to report from. Perhaps logging to the System Log will then no longer be necessary. I am sure @Martineau will be back once the weekend roles around and correct me ;)

@Xentrk I see from your post yesterday

https://www.snbforums.com/threads/i...-for-ipset-v6-and-v4.37976/page-9#post-325388 that you appear to still be using this script?

If you want to have a copy of IPSET_Block v4.01 then let me know.
NOTE: HackerPorts v2.03 already has support for reporting the stats from the IPSET (rather than the syslog messages).
 
@Xentrk I see from your post yesterday

https://www.snbforums.com/threads/i...-for-ipset-v6-and-v4.37976/page-9#post-325388 that you appear to still be using this script?

If you want to have a copy of IPSET_Block v4.01 then let me know.
NOTE: HackerPorts v2.03 already has support for reporting the stats from the IPSET (rather than the syslog messages).
Yes Please! I would like to test v4.01. And thank you for clarifying the HackerPorts v2.03 functionality. I saw the comment but did not realize the feature was available. I did not see a link to the 4.01 version in the forum unless I missed it. The link on the wiki goes to version. 3.04.
 
Yes Please! I would like to test v4.01.

I have uploaded IPSET_Block.sh v4.01 and HackerPorts v2.04 as this has been tweaked etc.
(As you are adept at reading the code headers you can probably work out what has been added etc. ;))

If you wish to implement tracking using the IPSET technique yet preserve your current Blacklist, you should manually issue the following:
Code:
./IPSET_Block.sh   save
./IPSET_Block.sh   backup

./IPSET_Block.sh   init   reset   ipset
./IPSET_Block.sh   restore

./IPSET_Block.sh   status

Code:
./IPSET_Block.sh status

   v4.01 © 2016-2017 Martineau, Dynamic IPSET Blocking.....
 
Name: Blacklist                                                 Name: Whitelist
Type: hash:ip                                                   Type: hash:net
Revision: 0                                                     Revision: 0
Header: family inet hashsize 4096 maxelem 65536 timeout 604800  Header: family inet hashsize 1024 maxelem 65536
Size in memory: 174168                                          Size in memory: 8500
References: 3                                                   References: 2
Members:                                                        Members:
(Total=11044)                                                   (Total=0)


 Summary Blacklist: 157+0 Successful blocks! ( 11047 IPs currently banned - 3 expired since: May 18 20:00 ), Entries auto-expire after 168:00:00 hrs

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

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

4177 members retrieved from IPSET (BlacklistTRK)

18 May 20:15:49: # Unique Ports attacked via 'eth0': 177 (out of 4177 attempts) tracked via IPSET

 Top 3 Ports attacked:
 2488 http://www.speedguide.net/port.php?port=23    e.g. https://www.speedguide.net/ip/1.180.214.77       
  293 http://www.speedguide.net/port.php?port=22    e.g. https://www.speedguide.net/ip/101.69.196.100     
  187 http://www.speedguide.net/port.php?port=81    e.g. https://www.speedguide.net/ip/103.239.74.110     

 Top 3 attackers:
    1 https://www.speedguide.net/ip/1.180.214.77
    1 https://www.speedguide.net/ip/101.69.196.100
    1 https://www.speedguide.net/ip/103.239.74.110

 Last 3 most recent attackers:
      https://www.speedguide.net/ip/109.236.91.106
      https://www.speedguide.net/ip/94.142.139.243
      https://www.speedguide.net/ip/122.114.173.66

Hopefully you should see the extended summary (i.e. 'status' shows how much memory is occupied by the Blacklist/Whitelist IPSETs which may have a bearing on the 'timeout' directive?)

The report should show that the tracking IPSET was used rather than the existing Syslog messages.

To view the report based on the existing Syslog messages (rather than the new tracker IPSET) you will need to supply the 'noipset' directive.
Code:
./IPSET_Block.sh   status   noipset

The downside to only using the tracking IPSET is that you will lose the ability to see the details of the actual reporting period since there are no timestamps when the tracking IPSET is updated with the new entries.

Of course, the plus side is that there are no tracking (noise) messages needed in Syslog!.

So you will need to edit services-start to add the 'nolog' directive, and before you reboot to ensure that 'init nolog' will be able to correctly restore the tracking IPSETs @ boot I suggest you manually issue:
Code:
./IPSET_Block.sh   save
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

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