Skynet Skynet - Router Firewall & Security Enhancements

[MarCoMLXXV]

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

Quilty as charged sir. Sound like a typical case of RTFM (on my side) to me. Thanks!

 

[MarCoMLXXV]

I noticed that firewall wasn't restarted (at least, it doesn't show up in syslog, as I expected, after your reply a couple of posts back), so I restarted it manually after updating:

May 16 18:33:04 dMP17 Skynet: [New Version Detected - Updating To v4.0.2]... ... ...
May 16 18:33:04 dMP17 Skynet: [Skynet Sucessfully Updated]
May 16 18:35:29 dMP17 dropbear: Child connection from xxx.xxx.xxx.xxx:32476
May 16 18:35:29 dMP17 dropbear: Exit before auth: Exited normally
May 16 18:35:38 dMP17 Skynet: [IP Banning Started] ... ... ...
May 16 18:35:39 dMP17 Skynet: [Complete] 32 IPs / 0 Ranges banned. 5 New IPs / 0 New Ranges Banned. 0 IP / 0 Range Connections Blocked! [1s]

Is that intended?

 

[Adamm]

I noticed that firewall wasn't restarted (at least, it doesn't show up in syslog, as I expected, after your reply a couple of posts back), so I restarted it manually after updating:

May 16 18:33:04 dMP17 Skynet: [New Version Detected - Updating To v4.0.2]... ... ...
May 16 18:33:04 dMP17 Skynet: [Skynet Sucessfully Updated]
May 16 18:35:29 dMP17 dropbear: Child connection from xxx.xxx.xxx.xxx:32476
May 16 18:35:29 dMP17 dropbear: Exit before auth: Exited normally
May 16 18:35:38 dMP17 Skynet: [IP Banning Started] ... ... ...
May 16 18:35:39 dMP17 Skynet: [Complete] 32 IPs / 0 Ranges banned. 5 New IPs / 0 New Ranges Banned. 0 IP / 0 Range Connections Blocked! [1s]

Is that intended?

I actually just reintroduced the "auto-restart" by coincidence after you posted and reminded me. I previously disabled it until I added a solution to adding debug mode during startup (which I added a few hours ago). So thanks for the reminder So in future updates it should take care of this step for you.

 

[Adamm]

seperate section in ipset.txt or even a commend at the end of the line (if possible) would suffice.

Turns out I was wrong, there's actually an IPSet module just for this, let me see if I can add support without breaking anything else in the process.

Uh, looks like the feature is broken, references to it in the source (and help page) but command isn't recognised.

@RMerlin Any idea on this one, or is this broken from the source (Don't have a linux machine to test on atm)

 

[dvohwinkel]

I'm running Skynet 4.0.4 and just started and enabled debug.. when I run stats I notice my cable-modem's WAN ip in the "Last 10 Connections Blocked;", "Last Autobans", and in the "Top 10 Attackers"

3x https://otx.alienvault.com/indicator/ip/xxx.xxx.xxx.xxx

 

[Adamm]

I'm running Skynet 4.0.4 and just started and enabled debug.. when I run stats I notice my cable-modem's WAN ip in the "Last 10 Connections Blocked;", "Last Autobans", and in the "Top 10 Attackers"

3x https://otx.alienvault.com/indicator/ip/xxx.xxx.xxx.xxx

Must be sending an invalid packet for whatever reason, just to be clear the IP is the same as when you run the following command? (if so we can just whitelist it by default)

nvram get wan_ipaddr

 

[john9527]

Must be sending an invalid packet for whatever reason, just to be clear the IP is the same as when you run the following command? (if so we can just whitelist it by default)

nvram get wan_ipaddr

Don't use wan_ipaddr, use wan0_ipaddr (wan_ipaddr is a construct used by the gui to manage multiple wans).

Things get a bit more complicated if you want to support dual-wan environments.

 

[Adamm]

Don't use wan_ipaddr, use wan0_ipaddr (wan_ipaddr is a construct used by the gui to manage multiple wans).

Things get a bit more complicated if you want to support dual-wan environments.

Thanks for the heads up, pushed a fix.

Also, I have updated firewall-start as per RMerlins request. The cron line is no longer needed, and I have provided an uninstall function (who needs this right )

If you're unsure how to remove the legacy code manually, issue the following command in SSH;

sed '\~cru a Firewall_save ~d' /jffs/scripts/firewall-start

 

[dvohwinkel]

Must be sending an invalid packet for whatever reason, just to be clear the IP is the same as when you run the following command? (if so we can just whitelist it by default)

nvram get wan_ipaddr

It is the same. It's set by the cable ISP so I can not whitelist it permanently(it can change).

 

[dvohwinkel]

Thanks for the heads up, pushed a fix.

Also, I have updated firewall-start as per RMerlins request. The cron line is no longer needed, and I have provided an uninstall function (who needs this right )

If you're unsure how to remove the legacy code manually, issue the following command in SSH;

sed '\~cru a Firewall_save ~d' /jffs/scripts/firewall-start

It's still showing up in the blocked lists. Did you push a fix for the WAN ip needing to be whitelisted? I'm on v4.0.5

 

[john9527]

It is the same. It's set by the cable ISP so I can not whitelist it permanently(it can change).

@Adamm - This is actually a good point.....not sure how you are managing the whitelist, but this can change on every reboot or renew. You may need to keep track of the last value, and remove it when whitelisting the new value.

 

[Adamm]

It's still showing up in the blocked lists.

The IP should be whitelisted upon script startup, to remove the old logs use the following command;

sh /jffs/scripts/firewall stats reset

not sure how you are managing the whitelist, but this can change on every reboot or renew

I just whitelist the value on boot (aka restart_firewall event). There's no great way to track it as I'd rather not dedicate nvram space or a logfile to it, but I figure "safe" IPs like this can be left alone. You could get issued 10 IPs per day and after a year not have any effect on IPSet performance. Debatable its 'bad security', but just because an IP is whitelisted doesn't give it any special privileges over other traffic besides being banned without question.

 

[dvohwinkel]

The IP should be whitelisted upon script startup, to remove the old logs use the following command;

sh /jffs/scripts/firewall stats reset

I just whitelist the value on boot (aka restart_firewall event). There's no great way to track it as I'd rather not dedicate nvram space or a logfile to it, but I figure "safe" IPs like this can be left alone. You could get issued 10 IPs per day and after a year not have any effect on IPSet performance. Debatable its 'bad security', but just because an IP is whitelisted doesn't give it any special privileges over other traffic besides being banned without question.

Perhaps if it was always the first entry in the whitelist then you would know which one to delete when it changed... or perhaps allow comments in the file and then tag it. Just an idea from the peanut gallery.

 

[Adamm]

Perhaps if it was always the first entry in the whitelist then you would know which one to delete when it changed... or perhaps allow comments in the file and then tag it. Just an idea from the peanut gallery.

My first idea was to add comments, unfortunately that feature is broken in our IPSet implementation. Maybe @john9527 or @RMerlin can let us know if its the IPSet source in general or just our implementation as its a very undocumented feature.

 

[Adamm]

Also for all other users. I have added a new install feature which I recommend all users run.

sh /jffs/scripts/firewall update
sh /jffs/scripts/firewall install

This will remove all legacy code safely from firewall-start, and gives you the option to change boot-args on the fly. This can be run multiple times without affecting your current installation or blacklists, all it does is change boot arguments and make installing easier!

 

[a_lunatic]

I had to disable it for now as it has blocked Discord from connecting until I can find the time to work out what IP's to whitelist.

 

[Adamm]

I had to disable it for now as it has blocked Discord from connecting until I can find the time to work out what IP's to whitelist.

Strange, discord has never blocked itsself for me in the past 3 years, but lets try track it down anyway.

First thing you will need todo is enable extended debug output, this can be done by;

sh /jffs/scripts/firewall install

(Select option 3)

Now while doing this we will want to keep any heavy web based applications closed for the time being so we can track it down easier.

Before opening discord, refresh your syslog a few times, you will get a general idea of how frequently IP's are being blocked etc. Now I want you to open discord and refresh syslog, you _should_ start seeing a flood of (BLOCKED - RAW) for one specific IP coming in, this is most likely your culprit. Discord generally uses port range 45000-60000 if that helps.



Now if that doesn't work, here's a much more specific method. Disable the firewall, now in the discord channel, it should tell you which server its connected to, in my case its us-east37 . So first we want to grab the servers ip;

ping us-east37.discord.gg

Now we have the servers IP, lets confirm its banned;

sh /jffs/scripts/firewall stats search ip IPHERE

Hopefully it should tell you which blacklist the IP is in and give you some log examples, great! Now lets whitelist this IP and get discord working again;

sh /jffs/scripts/firewall whitelist domain us-east37.discord.gg

Hope this helps

 

[dvohwinkel]

Also looks like imugr.com is getting blocked somehow. I whitelisted (firewall whitelist imgur.com) imgur.com and it didn't find it.. still blocked. I whitelisted (firewall whitelist i.imgur.com) i.imgur.com and that found it and unblocked it.

 

[Adamm]

Also looks like imugr.com is getting blocked somehow.

Because of the stricter auto-whitelist rules, it will take a little longer for such websites. False positives are scanned for at the end of every hour and unbanned (and whitelist if detected 3 times within 2 weeks, I may bump this down to 2 times). To bypass this process simply do;

sh /jffs/scripts/firewall whitelist domain imgur.com

EDIT;

I just pushed v4.0.9 , this slightly lowers the requirements for false positive detection and will pick up more legitimate sites. Update and run the stat command and it should unban anything fitting the new requirements.

I also added two new commands "unban port PORTHERE" and "whitelist port PORTHERE". These will unban/whitelist any autobans issued on traffic from the specified ports. Should be helpful for debugging in future.

 

[a_lunatic]

I whitelisted these 4

discordapp.com
gateway.discord.gg
status.discordapp.com
sydney95.discord.gg