What's new

Skynet Skynet v8 - Router Firewall & Security Enhancements

If you search the system log for firewall-start, does it always show wan0?
Code:
grep firewall-start /jffs/syslog.log-1 /jffs/syslog.log
no, this is the order

Jan 4 15:11:35 custom_script: Running /jffs/scripts/firewall-start (args: wan0)
Jan 4 15:11:35 Skynet: Startup Initiated... ( skynetloc=/tmp/mnt/Asus/skynet )
Jan 4 15:11:35 custom_script: Running /jffs/scripts/firewall-start (args: wan0)
Jan 4 15:11:35 WEBDAV_Server: daemon is stopped
Jan 4 15:11:35 Mastiff: Got SIGTERM
Jan 4 15:11:35 Skynet: [✘] Lock File Detected (/jffs/scripts/firewall start skynetloc=/tmp/mnt/Asus/skynet) (pid=15741, runtime=0s) - Exiting

Dec 31 18:01:11 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Dec 31 18:01:11 dnsmasq[2419]: failed to send packet: Network is unreachable
Dec 31 18:01:11 custom_script: Running /jffs/scripts/firewall-start (args: eth0)

Dec 31 18:01:24 custom_script: Running /jffs/scripts/firewall-start (args: wan0)

Jan 4 15:13:39 custom_script: Running /jffs/scripts/firewall-start (args: wan0)
Jan 4 15:13:39 rc_service: udhcpc_wan 3336:notify_rc stop_samba
Jan 4 15:13:39 custom_script: Running /jffs/scripts/service-event (args: stop samba)
Jan 4 15:13:39 wsdd2[3417]: terminating.
Jan 4 15:13:39 Samba_Server: smb daemon is stopped
Jan 4 15:13:40 Skynet: [✘] Lock File Detected (/jffs/scripts/firewall start skynetloc=/tmp/mnt/Asus/skynet) (pid=2760, runtime=6s) - Exiting
 
Last edited:
no, this is the order

Jan 4 15:13:39 custom_script: Running /jffs/scripts/firewall-start (args: wan0)
Jan 4 15:13:39 custom_script: Running /jffs/scripts/firewall-start (args: wan0)
Dec 31 18:01:11 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Dec 31 18:01:11 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Dec 31 18:01:24 custom_script: Running /jffs/scripts/firewall-start (args: wan0)
Jan 4 15:13:39 custom_script: Running /jffs/scripts/firewall-start (args: wan0)
I guess this is the heart of the problem. The wan interface name is part of the Skynet rules, and yours seems to start as eth0 then change to wan0. Never seen that before.
 
I guess this is the heart of the problem. The wan interface name is part of the Skynet rules, and yours seems to start as eth0 then change to wan0. Never seen that before.
i reposted log with lockfile arguments above, do you think that could be the issue?
 
Last edited:
I've pushed v8.0.9

Updated the display logic for banned countries in the status menus to truncate the list to 82 characters and append a '+' if it exceeds this length.
Fixed the update function to respect the check flag.
 
Thank you for including the entire selected country code list in the skynet.cfg now as well... much easier to finally see what was included and what was not. :)
 
Thank you for the 'fast fixes', much appreciated.
The nice banner is no longer 'ruined' by my mega country code list !!! :cool::D
 
I had the option to auto update skynet to a new version set to 'disable' (I do so because there have been versions in the past that were caused issues).
However, it seems like this latest version (8.0.9) auto-updated anyway. I have double checked my setting was indeed 'disabled'.
Was this option bypassed somehow by this release or is there a bug ?
Also, as many of us use our routers for business use, can there be a a preprod version published so people can test? Maybe it is only me but we should not push something without testing.
 
I had the option to auto update skynet to a new version set to 'disable' (I do so because there have been versions in the past that were caused issues).
However, it seems like this latest version (8.0.9) auto-updated anyway. I have double checked my setting was indeed 'disabled'.
Was this option bypassed somehow by this release or is there a bug ?
Also, as many of us use our routers for business use, can there be a a preprod version published so people can test? Maybe it is only me but we should not push something without testing.
This is odd...I have all default settings in skynet and mine didn't automatically update. I don't think I never had Skynet update automatically.
 
run the following:

Code:
cru l | grep Skynet

You should get

Code:
cru l | grep Skynet

[Ignore the actual values, look at the #labels]

25 20 * * * sh /jffs/scripts/firewall banmalware #Skynet_banmalware#
20 1 * * Mon sh /jffs/scripts/firewall update check #Skynet_checkupdate#
0 * * * * sh /jffs/scripts/firewall save #Skynet_save#
31 */12 * * * sh /jffs/scripts/firewall debug genstats #Skynet_genstats#

If you get something labeled as '#Skynet_autoupdate#' such as :

Code:
30 1 * * Mon sh /jffs/scripts/firewall update #Skynet_autoupdate#

the old autoupdate cron entry is still there !!!???

Ensure that you have set in settings (option 11) the following:

Code:
[1]  --> Skynet Auto-Updates        | [Disabled]

run the following to remove the 'autoupdate' cron entry:

Code:
cru d Skynet_autoupdate

ensure you have the #Skynet_checkupdate# labeled entry.

(This is set when you set 'Skynet Auto-Updates' to 'Disabled')
 
Last edited:
I had the option to auto update skynet to a new version set to 'disable' (I do so because there have been versions in the past that were caused issues).
However, it seems like this latest version (8.0.9) auto-updated anyway. I have double checked my setting was indeed 'disabled'.
Was this option bypassed somehow by this release or is there a bug ?
Also, as many of us use our routers for business use, can there be a a preprod version published so people can test? Maybe it is only me but we should not push something without testing.
Speaking for myself (Not the creator of the script)
It is tested ... BUT mistakes can be made ... (Only human !!!)

Understand the concern but this is not a commercial product ...
I accept it as 'Best Efforts' and appreciate that it is created/supported for free !!!

I accept that there is a risk using something that I am not paying for and ensure that I can recover from any problem quickly by understanding what these additions do and how to 'reverse' out of a problem.

1. Backups ... BACKUPMON will copy the complete configuration of your SSD/USB Stick so you can quickly (10 mins) roll back to a previous setup.

2. There are backup options in 'Skynet' which can also roll back any update/change.

Do not depend on 'Black Boxes' ... understand what these scripts/additions do for your own safety !!!
 
Maybe this is my fault, so please help me to understand

Config:
I discovered that even if I am only doing "Inbound", some outbound connections from LAN devices (laptop, tablet,...), like going to some websites, could not be reached until I disable Skynet.
I looked in the log and I saw that domains/ips are blocked by the Malware filter list.

2 questions:
  • Doing "Inbound only", is it normal that the Malware list is still blocking the ips/domains when the source is a local device, so initiating an outbound connection?
  • When I was searching in logs, I was unable to find any entries in the real time logs (using "firewall debug watch", with or without "ip" parameter). I was only seeing "Inbound" blocked connections, which is aligned with the Filter Traffic rule as "Inbound" only.
    • The only way to confirm that Skynet was blocking was to disable Skynet and to do a search in "Stats" to discover is was blocked as an inbound connection, by Malware list.
Thanks
 
I had the option to auto update skynet to a new version set to 'disable' (I do so because there have been versions in the past that were caused issues).
However, it seems like this latest version (8.0.9) auto-updated anyway. I have double checked my setting was indeed 'disabled'.
Was this option bypassed somehow by this release or is there a bug ?
It was a bug that was fixed in 8.0.9, so the next version update (8.1.0?) should not auto-upgrade. Anything between 8.0 and 8.0.8 will likely auto-upgrade to 8.0.9.
Doing "Inbound only", is it normal that the Malware list is still blocking the ips/domains when the source is a local device, so initiating an outbound connection?
Yes, Skynet blocks incoming WAN connections matching the ban list regardless of whether it is in response to an outbound request. Most firewall traffic outside of Skynet will allow return traffic to pass, but Skynet operates in the netfilter raw table which ignores any existing conntrack states.
 
run the following:

Code:
cru l | grep Skynet

You should get

Code:
cru l | grep Skynet

[Ignore the actual values, look at the #labels]

25 20 * * * sh /jffs/scripts/firewall banmalware #Skynet_banmalware#
20 1 * * Mon sh /jffs/scripts/firewall update check #Skynet_checkupdate#
0 * * * * sh /jffs/scripts/firewall save #Skynet_save#
31 */12 * * * sh /jffs/scripts/firewall debug genstats #Skynet_genstats#

If you get something labeled as '#Skynet_autoupdate#' such as :

Code:
30 1 * * Mon sh /jffs/scripts/firewall update #Skynet_autoupdate#

the old autoupdate cron entry is still there !!!???

Ensure that you have set in settings (option 11) the following:

Code:
[1]  --> Skynet Auto-Updates        | [Disabled]

run the following to remove the 'autoupdate' cron entry:

Code:
cru d Skynet_autoupdate

ensure you have the #Skynet_checkupdate# labeled entry.

(This is set when you set 'Skynet Auto-Updates' to 'Disabled')
Thx. I checked and there are no 'old' skynet cron jobs, only current, AND the setting for 'Skynet Auto-Updates' is indeed 'Disabled' . Seems like , per post 234, that there is a known bug.
 
It was a bug that was fixed in 8.0.9, so the next version update (8.1.0?) should not auto-upgrade. Anything between 8.0 and 8.0.8 will likely auto-upgrade to 8.0.9.

Yes, Skynet blocks incoming WAN connections matching the ban list regardless of whether it is in response to an outbound request. Most firewall traffic outside of Skynet will allow return traffic to pass, but Skynet operates in the netfilter raw table which ignores any existing conntrack states.
Thanks @dave14305 for letting me know of the existing 'bug'. I'll see what happens whenever the next version of skynet is relaesed.
 
Yes, Skynet blocks incoming WAN connections matching the ban list regardless of whether it is in response to an outbound request. Most firewall traffic outside of Skynet will allow return traffic to pass, but Skynet operates in the netfilter raw table which ignores any existing conntrack states.
Thank you very much.

What is "disturbing" in this situation (Skynet doing inbound only and Malware list) is the fact that real time logs don't display information, we have to guess to find what is causing the trouble.
I have no idea how to achieve this but it would be very nice to display in the logs what is blocked (whatever the config is, like in my situation only blocking Inbound connection but these blocks are not display in the logs because initiated by a local device, so outbound, but blocked by Malware list), and maybe change the color when it is blocked by malware list.

Again, thank you @dave14305 for your reply/explanations and @Adamm for your hard work.
 
What is "disturbing" in this situation (Skynet doing inbound only and Malware list) is the fact that real time logs don't display information, we have to guess to find what is causing the trouble.
With logging enabled in Skynet, it should be logging any blocked connection regardless of direction. What do your rules look like?
Code:
iptables -t raw -S
 
With logging enabled in Skynet, it should be logging any blocked connection regardless of direction. What do your rules look like?
Code:
iptables -t raw -S
Here is the output:
XXXX@RT-AX86U-CBC0:/tmp/home/root# iptables -t raw -S
-P PREROUTING ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -i eth0 -m set ! --match-set Skynet-MasterWL src -m set --match-set Skynet-Master src -j LOG --log-prefix "[BLOCKED - INBOUND] " --log-tcp-sequence --log-tcp-options --log-ip-options
-A PREROUTING -i eth0 -m set ! --match-set Skynet-MasterWL src -m set --match-set Skynet-Master src -j DROP
XXXX@RT-AX86U-CBC0:/tmp/home/root#

Maybe I have to be more precise: I do see logs in real time, but only Inbounds and unfortunately, not the one related to Malware. I was able to find it when I search in the Stats, using domain or ip, and then I saw it was because of the Malware list.

Thank you very much for your help, very appreciated (and for my education :))
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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