What's new

Skynet Skynet - Router Firewall & Security Enhancements

  • 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!

Not currently possible to exclude specific IP's. But as a compromise I pushed v6.1.6 which contains the ability to remove logs based on a specific port/IP.

Code:
sh /jffs/scripts/firewall stats remove IP xxx.xxx.xxx.xxx

sh /jffs/scripts/firewall stats remove port xxxxx
After installing 6.1.6 I had no blocked ips. Running banmalware after the install fixes this.
 
After installing 6.1.6 I had no blocked ips. Running banmalware after the install fixes this.

Nothing major in that aspect changed so not sure how that could have happened unless skynet.ipset was modified by other means (or the IPSet flushed).
 
Happy belated birthday to Skynet! And thank you so much for your wonderful script, Adamm ;)
 
After updating to 6.16 I had no custom blocks including outgoing IP's for 10 minutes... allowing that to leak out. Though there are incoming blocks (I don't believe they are custom blocks however) so its not totally down. It started blocking 8.8.8.8 shortly on its own. I guess when the NTP got through. This reoccurs on every reboot, NTP is not getting through and not allowing Skynet to load; So many programs / scripts seem way too dependent on ntp; they should use local fallback systems and backup files if the server is down or blocked by adversarial isp or something of the like.

I'm seeing

May 7 22:28:03 dnsmasq[1122]: query[A] pool.ntp.org from 127.0.0.1
May 7 22:28:03 dnsmasq[1122]: forwarded pool.ntp.org to 127.0.0.1
May 7 22:28:03 dnsmasq[1122]: dnssec-query[DS] ntp.org to 127.0.0.1
May 7 22:28:03 dnsmasq[1122]: dnssec-query[DNSKEY] org to 127.0.0.1
May 7 22:28:03 dnsmasq[1122]: reply pool.ntp.org is 88.159.1.197
May 7 22:28:03 dnsmasq[1122]: reply pool.ntp.org is 83.98.201.134
May 7 22:28:03 dnsmasq[1122]: reply pool.ntp.org is 87.233.197.123
May 7 22:28:03 dnsmasq[1122]: reply pool.ntp.org is 129.250.35.251
May 7 22:28:30 dnsmasq[1122]: query[A] pool.ntp.org from 127.0.0.1
May 7 22:28:30 dnsmasq[1122]: forwarded pool.ntp.org to 127.0.0.1
May 7 22:28:30 dnsmasq[1122]: dnssec-query[DS] ntp.org to 127.0.0.1
May 7 22:28:30 dnsmasq[1122]: dnssec-query[DNSKEY] org to 127.0.0.1
May 7 22:28:30 dnsmasq[1122]: reply pool.ntp.org is 88.159.1.197
May 7 22:28:30 dnsmasq[1122]: reply pool.ntp.org is 83.98.201.134
May 7 22:28:30 dnsmasq[1122]: reply pool.ntp.org is 87.233.197.123
May 7 22:28:30 dnsmasq[1122]: reply pool.ntp.org is 129.250.35.251
May 7 22:28:57 dnsmasq[1122]: query[A] pool.ntp.org from 127.0.0.1
May 7 22:28:57 dnsmasq[1122]: forwarded pool.ntp.org to 127.0.0.1
May 7 22:28:57 dnsmasq[1122]: dnssec-query[DS] ntp.org to 127.0.0.1
May 7 22:28:57 dnsmasq[1122]: dnssec-query[DNSKEY] org to 127.0.0.1
May 7 22:28:58 dnsmasq[1122]: reply pool.ntp.org is 88.159.1.197
May 7 22:28:58 dnsmasq[1122]: reply pool.ntp.org is 83.98.201.134
May 7 22:28:58 dnsmasq[1122]: reply pool.ntp.org is 87.233.197.123
May 7 22:28:58 dnsmasq[1122]: reply pool.ntp.org is 129.250.35.251
May 7 22:29:25 dnsmasq[1122]: query[A] pool.ntp.org from 127.0.0.1
May 7 22:29:25 dnsmasq[1122]: forwarded pool.ntp.org to 127.0.0.1
May 7 22:29:25 dnsmasq[1122]: dnssec-query[DS] ntp.org to 127.0.0.1
May 7 22:29:25 dnsmasq[1122]: dnssec-query[DNSKEY] org to 127.0.0.1
May 7 22:29:25 dnsmasq[1122]: reply pool.ntp.org is 88.159.1.197
May 7 22:29:25 dnsmasq[1122]: reply pool.ntp.org is 83.98.201.134
May 7 22:29:25 dnsmasq[1122]: reply pool.ntp.org is 87.233.197.123
May 7 22:29:25 dnsmasq[1122]: reply pool.ntp.org is 129.250.35.251

However I do not see these being blocked by the firewall. IIt seems protections and blocks are entirely dependent upon the weakest link, a clean connection to NTP servers rather than local ipset backups. Thats a recipe for disaster. Anyway to revert to previous version at command line?

Update
So to sum it up, NTP is not getting through, Skynet no longer blocks outgoing or any custom ip's until NTP takes hold; I'm at nearly 20 minutes and counting and its still down.

nvram set ntp_ready=1
nvram commit

Allows me to get into skynet,

I'm getting
Checking Inbound Filter Rules... [Failed]
Checking Outbound Filter Rules... [Failed]
Checking Whitelist IPSet... [Failed]
Checking BlockedRanges IPSet... [Failed]
Checking Blacklist IPSet... [Failed]
Checking Skynet IPSet... [Failed]

Zero locked files, gotta restart skynet. Wait 60 seconds and finally blocking starts 20 minutes after boot. Its looking pretty rough atm, how can I revert to 6.15? I'd like to confirm if this is the primary issue; I'm testing other scripts and its not practical without skynet working properly.
 
Last edited:
Not currently possible to exclude specific IP's. But as a compromise I pushed v6.1.6 which contains the ability to remove logs based on a specific port/IP.

Code:
sh /jffs/scripts/firewall stats remove IP xxx.xxx.xxx.xxx

sh /jffs/scripts/firewall stats remove port xxxxx

Great work @Adamm this will be very handy for a lot of people! Much appreciated.
 
So NTP is not getting through, it no longer blocks outgoing for a while; takes 15 minutes or longer to get to that point. Im at nearly 20 minutes and counting, still not blocking outgoing, and likely all custom rules).

nvram set ntp_ready=1
nvram commit

Allows me to get into skynet,

I'm getting


Zero locked files, gotta restart skynet. Wait 60 seconds and finally blocking starts 20 minutes after boot. How can I revert to the previous version?

Skynet relies on NTP working for accurate logging, after 5 minutes if NTP still hasn't started Skynet will exit its startup process. Reverting to a previous version won't fix anything, you need to find out why NTP is failing.
 
Ok so to break skynet, just cut the NTP connection. Personally, I feel not being hacked takes precedents over accurate logs... seems zero custom blocks take place at all if NTP is being disrupted by an adversary, isp, or misconfiguration. This can mean the difference between life and death in certain circumstances, like a war zone for example.
 
Ok so to break skynet, just cut the NTP connection. Personally, I feel not being hacked takes precedents over accurate logs... seems zero custom blocks take place at all if NTP is being disrupted by an adversary, isp, or misconfiguration. This can mean the difference between life and death in certain circumstances, like a war zone for example.

This is only checked once during startup.
 
Well I guess a nvram set ntp_ready=1 cronjob could bandaid the issue. You were right, I think I've found the culprit, removing server=/255.in-addr.arpa/ in dnsmasq.conf stopped the ntp issues; from what I have learned this address technically should only be used for local querys; the above setting enforces that strictly, and for whatever reason was responsible; the ntp query occurred a bit later than I was expecting as well; it was one of the last things to take place prior to loading the firewall. I was expecting it to take place during init. Does this appear normal?

May 7 23:57:01 asuz: Started pixelserv-tls (AB-Solution) from /jffs/scripts/services-start.
May 7 23:57:01 asuz: AB-Solution added entries via ab_dnsmasq_postconf.sh
May 7 23:57:01 asuz: AB-Solution linked ab_dnsmasq_postconf.sh via /jffs/scripts/dnsmasq.postconf
May 7 23:57:02 iTunes: daemon is stopped
May 7 23:57:02 FTP_Server: daemon is stopped
May 7 23:57:03 Samba_Server: smb daemon is stopped
May 7 23:57:03 kernel: gro disabled
May 7 23:57:04 Timemachine: daemon is stopped
May 7 23:57:17 kernel: SHN Release Version: 2.0.1 3529123_patch
May 7 23:57:17 kernel: UDB Core Version: 0.2.14 r3529123
May 7 23:57:17 kernel: Init chrdev /dev/idpfw with major 191
May 7 23:57:18 kernel: IDPfw: IDPfw is ready
May 7 23:57:18 kernel: sizeof forward pkt param = 192
May 7 23:57:20 ntp: start NTP update
May 7 23:57:24 rc_service: udhcpc 506:notify_rc start_firewall
May 7 23:57:25 dhcp_client: bound xx.11.11.62 via xx.11.11.1 during 3923 seconds.
May 7 23:57:26 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May 7 23:57:26 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
May 7 23:57:49 ntp: start NTP update
May 7 23:59:43 rc_service: ntp 536:notify_rc restart_diskmon
 
Last edited:
Dear @Adamm. Just curious, lets say I initiated ntp_ready=1, and then at a later time I or skynet automatically invoked an official NTP update; would the logs reflect the time change as well, or does this only occur during the initialization of skynet? If the time does change (or if skynet could automatically reload upon successful NTP initiation), then skynet load times & router security could be enhanced. So, something like, you load skynet... skynet says "Skynet waiting for NTP server to synchronize. Press "such and such" to bypass; it then updates NTP officially when possible. Then an option in the menu to enforce that upon boot for automation. Think about the potential usefulness. Skynet is always there to protect you.

If you could also enforce no internet activity until skynet initiated, that would complete the package imo.
 
Last edited:
Dear @Adamm. Just curious, lets say I initiated ntp_ready=1, and then at a later time I or skynet automatically invoked an official NTP update

Skynet doesn’t invoke NTP updates, it just waits for it to startup by its self.

Skynet waits for NTP otherwise every time the router boots up you will get log entries with random time/date scattered throughout, not to mention other functions that rely on accurate logging.

I don’t intend to support edge cases where someone is intentially breaking NTP for no good reason.
 
My kids complained their xbox one live gold games were not working, they have not played for a few weeks and skynet went in since the last time they tried.

I looked at the logs and these two IP's were being blocked outbound from the xbox.

111.221.29.193
111.221.29.174

I added them to the whitelist and it is all back to life.

Is this a normal thing ?
 
My kids complained their xbox one live gold games were not working, they have not played for a few weeks and skynet went in since the last time they tried.

I looked at the logs and these two IP's were being blocked outbound from the xbox.

111.221.29.193
111.221.29.174

I added them to the whitelist and it is all back to life.

Is this a normal thing ?
Both belong to Microsoft Corp, Singapore.

So addresses are good.

I suppose this is normal for an xbox to contact Microsoft addresses !!!???
(Not an xbox owner/user :) )
 
Ahhhhhh - that may make sense. I blocked sg country using skynet as my router was getting a load of hack attempts from addresses there.
I read these are just bot's but I thought better safe that sorry......
 
Im getting this error
1d44fb868cb2212cb2e20e2b9818035a.jpg
 

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