Skynet Skynet - Router Firewall & Security Enhancements

[RMerlin]

BTW, I do have a firewall-start script at the moment (left over from a test I was doing and forgot to remove), and I just checked - the two rules inserted by the script do appear in my iptables.

 

[Adamm]

Okay that got me thinking, and I found the cause. When the system executes firewall-script, it doesn't how I was redirecting output of stdout and stderr, but when manually executing the file it works as intended which is why debugging got me so confused. I made the necessary adjustments and it works as expected. Thanks for the insight.

 

[a_lunatic]

I just did factory default reset and updated to 380,66 and installed this and when running the save command I get this

[Saving Blacklists] ... ... ...
cat: can't open '/tmp/syslog.log-1': No such file or directory
sed: /tmp/syslog.log-1: No such file or directory

 

[Adamm]

I just did factory default reset and updated to 380,66 and installed this and when running the save command I get this

[Saving Blacklists] ... ... ...
cat: can't open '/tmp/syslog.log-1': No such file or directory
sed: /tmp/syslog.log-1: No such file or directory

You can safely ignore that error, ill silence it in the next update I push. Just means the file didn't exist when it was attempting to clean up the logs.

 

[redhat27]

but as of 380.66 there has been a functionality change (the script is initiated multiple times at boot)

No quite so... The multiple calling of the firewall-start existed much before 380.66 See March 2016 thread. The reason being that script is called whenever the firewall rules needs to be reloaded. It is event driven.

I thought so, I wondered why iblocklistloader and ya-malware recommended the one time run. I suppose that's a question for @redhat27 !

That is the purpose of that reinstatement snippet in the wiki that is to be part of the firewall start script.

 

[Adamm]

No quite so... The multiple calling of the firewall-start existed much before 380.66 See March 2016 thread.

Strange, I never experienced it until recently

I just did factory default reset and updated to 380,66 and installed this and when running the save command I get this

[Saving Blacklists] ... ... ...
cat: can't open '/tmp/syslog.log-1': No such file or directory
sed: /tmp/syslog.log-1: No such file or directory

Okay pushed a small fix in the event the syslog hasn't been rotated by the system yet and the file doesn't exist.

 

[HardCat]

@Adamm I know you are looking into perhaps why "firewall start" does not set up the iptables rules after a reboot and execution of /jffs/scripts/firewall-start.

Router Model: RT-AC3100
Skynet Version: v3.9.4 (16/05/2017)
iptables v1.4.14
ipset v6.29, protocol version: 6
FW Version: 380.66_0
Startup Entry Detected
Cronjob Detected
Autobanning Enabled
Whitelist IPTable Not Detected
BlockedRanges IPTable Not Detected
Blacklist IPTable Not Detected
Whitelist IPSet Detected
BlockedRanges IPSet Detected
Blacklist IPSet Detected

However, I noticed that after a reboot a lot of false positives get added to the whitelist before I can execute "firewall start" manually. I had 39 added almost right away. I think I prefer not
having false positives added to the whitelist. Not sure if that would be the right thing to do either.

For your consideration...

 

[Adamm]

@Adamm I know you are looking into perhaps why "firewall start" does not set up the iptables rules after a reboot and execution of /jffs/scripts/firewall-start

This issue should be fixed as of the latest update, make sure your firewall-start file looks like this, and if you're still having issues use the following command then check again;

service restart_firewall

However, I noticed that after a reboot a lot of false positives get added to the whitelist before I can execute "firewall start" manually. I had 39 added almost right away

These IP's should be safe to whitelist, they are HTTP(s) traffic from websites you visit that by accident send an "invalid" packet and get flagged by the firewall. The check I added only scans for autobans (functionality added by the script), so this doesn't affect anything from a malware list or manually blacklisted item. Even sites such as SNBFourms and Github for example get picked up occasionally and led to accidental website blocking which is why I added this feature. If you look at the IP's whitelisted, you will see most are from well known providers, a lot being CDN servers.

That being said, just because they are whitelisted, doesn't give them free roam. It just means they won't be blocked right off the bat, they still have to follow the same "rules" as other traffic. The goal for this project is to be able to let it manage itself with little user interference necessary.

 

[RMerlin]

This issue should be fixed as of the latest update, make sure your firewall-start file looks like this, and if you're still having issues use the following command then check again;

I haven't looked at how your code works, but two ways you could possibly ensure that multiple executions don't cause issues:

1) Start by flushing the ipsets/chains you are creating before re-filling them
2) Set up a temp file in /tmp/ and us that as a "marker" that your script already completed its setup (a simple "touch /tmp/skynet.started" and then an "if [ -f /tmp/skynet.started ]" or something like that).

 

[Adamm]

I haven't looked at how your code works, but two ways you could possibly ensure that multiple executions don't cause issues:

1) Start by flushing the ipsets/chains you are creating before re-filling them
2) Set up a temp file in /tmp/ and us that as a "marker" that your script already completed its setup (a simple "touch /tmp/skynet.started" and then an "if [ -f /tmp/skynet.started ]" or something like that).

Yeah I already implement #1 which is why its not really an issue, every time the start function is run it unloads then reloads everything IPTables related. I had another solution where I was scanning the process list then throwing in a sleep timer (so multiple executions could catch it) but it seemed a bit of an overkill.

 

[Spydawg]

I installed this on my RT-AC66U before I read it's not compatible.. what the command to uninstall it?

 

[Adamm]

I installed this on my RT-AC66U before I read it's not compatible.. what the command to uninstall it?

Just simply delete the files you downloaded to /jffs/scripts

 

[Adamm]

I noticed that after a reboot a lot of false positives get added to the whitelist

So I was thinking about this and think I found a good middle ground solution and pushed an update. Before it would whitelist an IP if its ban was based on HTTP(s) traffic. I've changed how this works.

If an IP sends an invalid packet on port 80/443 it gets banned and then is unbanned at the end of the current hour and is logged. If this happens 3 times only then is the IP whitelisted (a good sign its legitimate traffic). This in theory should also be more secure while at the same time issuing less whitelist requests.


Banmalware also now removes all entries from previous runs before importing fresh lists, this is part of our goal for a long term unattended solution as users can run the banmalware command on a regular basis (e.g cronjob) without a massive list of IPs accumulating.

 

[MarCoMLXXV]

So I was thinking about this and think I found a good middle ground solution and pushed an update.

What's the easiest way to update to the latest version if other executables are using firewall-start to? I'm using DNSCrypt, which uses firewall-start and whas wondering whether there's a way to update without manually altering files regularly. Or is it just a matter of dowloading a fresh copy of firewall and leave firewall-start as is?

Another question: I too noticed a lot of IP's banned and then later being unbanned again and whitelisted. After installation I added an IP address manually to whitelist, as this daily used for remote pentesting and I don't want it blocked. However, I would like very much to be able to distinguish the user-added IP's on the whitelist and the auto-added IP's. Is there any way you can implement that? A seperate section in ipset.txt or even a commend at the end of the line (if possible) would suffice.

Thanks for your efforts, and keep up the good work

 

[Adamm]

What's the easiest way to update to the latest version if other executables are using firewall-start to? I'm using DNSCrypt, which uses firewall-start and whas wondering whether there's a way to update without manually altering files regularly. Or is it just a matter of dowloading a fresh copy of firewall and leave firewall-start as is?

I try not to touch firewall-start for this reason, there's only ever been one time this file has needed changing (when I rewrote how the script was started) and I plan to avoid changing this at all costs. This file does not get modified by the update feature (only the core script does) and in the event It does require editing I'll tell users to over forcing changes.

To update the script its as simple as typing in SSH;

sh /jffs/scripts/firewall update

Another question: I too noticed a lot of IP's banned and that unbanned and whitelisted. After installation I added an IP address manually to whitelist, as this daily used for remote pentesting and I don't want it blocked. However, I would like very much to be able to distinguish the user-added IP's on the whitelist and the auto-added IP's. Is there any way you can implement that? A seperate section in ipset.txt or even a commend at the end of the line (if possible) would suffice.

As of a few hours ago I upped the requirements for a IP to be considered a false positive and whitelisted. That being said, the only notification I can give at this time is in the syslog as the ipset.txt file is auto-generated and doesn't really give us the ability to add descriptions to IP's. Without adding the overhead of another IPSet to scan or log file I don't see any clean way to add this. One method would be to use skynet.log but that file gets auto-deleted after 7 days to prevent excessive JFFS usage.

That being said, I'll keep your suggestion in mind for future updates, but rest assured that the IP's being whitelisted are for good reason and go through a vetting process so to speak, and are mostly from companies like Twitter/Microsoft/Akamai/Amazon among other CDN servers and legitimate websites. Also just because an IP is whitelisted, doesn't mean it bypasses the rules all traffic has to follow, it just means it won't be banned without question.

 

[MarCoMLXXV]

Okay, thanks for the quick reply and the clarification. So, just to be shure, if I run:

wget -O /jffs/scripts/firewall https://raw.githubusercontent.com/Adamm00/IPSet_ASUS/master/firewall.sh
chmod +x /jffs/scripts/firewall
service restart_firewall

... I'm running the latest release?

 

[Adamm]

Okay, thanks for the quick reply and the clarification. So, just to be shure, if I run:

wget -O /jffs/scripts/firewall https://raw.githubusercontent.com/Adamm00/IPSet_ASUS/master/firewall.sh
chmod +x /jffs/scripts/firewall
service restart_firewall

... I'm running the latest release?

Correct, the update command also does this exactly (if it detects a change in version number) if you're lazy like me

 

[goatdog]

I installed this on my RT-AC66U before I read it's not compatible.. what the command to uninstall it?

delete the two files and delete the cron job it insert

cru l --> to list

cru d Firewall_save -->to delete.

 

[goatdog]

any work around for the RT-N66U with older ipset/iptables ?

 

[Adamm]

any work around for the RT-N66U with older ipset/iptables ?

Unfortunately at this time I don't plan to support ipset v4.5, there's just too many features that depend on one of the core changes which is maxelems. Not saying porting this would be impossible, but I just don't have the motivation to add a bunch of code for a legacy device. Having to dynamically calculate and split lists into 65536 and set iptables rules is a bit of a hassle especially considering I don't own a device running it. Sorry about that.