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!

So I tried installing today, after upgrading from .67 to .68alpha2... seems ipset6 isn't installed with the alpha firmware?
If it matters, I'm also running the latest ab-solution script (been working fine for some time), and an ovpn server on this router. Here's the debug out:

Code:
Router Model: RT-N66U
Skynet Version: v5.1.3 (12/08/2017)
iptables v1.3.8 - (eth0)
ipset v4.5, protocol version 4.
Kernel module protocol version 4.
FW Version: 380.68_alpha2-g6527cb2 (00:41:18 EDT )
Install Dir; /jffs (8.0M Space Available)
Boot Args;
Install Dir Writeable
Startup Entry Not Detected
Cronjobs Not Detected
IPSet Doesn't Support Comments - Please Update To 380.68_alpha1 / V26E3 Or Newer Firmware
Autobanning Disabled
Debug Mode Disabled
No Duplicate Rules Detected In RAW
No Duplicate Rules Detected In FILTER
Whitelist IPTable Not Detected
Skynet IPTable Not Detected
Whitelist IPSet Not Detected
BlockedRanges IPSet Not Detected
Blacklist IPSet Not Detected
Skynet IPSet Not Detected
Skynet: [Complete]  IPs /  Ranges Banned. 0 New IPs / 0 New Ranges Banned.  Inbound /  Outbound Connections Blocked! [1s]

Am I doing something wrong, or is this just not going to work on my older router?

Thanks,
Kevin

[edit: NM, after further reading I realize my n66u doesn't have ipset6 (and I guess won't ever get it), so I can't use your script. I'll look at ya-malware instead, since it supports ipset4 thanks.]
 
Last edited:
... after further reading I realize my n66u doesn't have ipset6 (and I guess won't ever get it), so I can't use your script. I'll look at ya-malware instead, since it supports ipset4 thanks.]

Sure you can run Skynet, just not the current release. While reading back, you probably missed this post: https://www.snbforums.com/threads/s...-manual-ip-blocking.16798/page-38#post-340725

It works like a charm and support by @Adamm is as good as it gets. Just because there's a newer release, doesn't mean the previous release is suddenly useless. I've tried them all, and kept coming back to Skynet each and every time, and to persuade me to use something different, one has to come up with something that offers unequalled advantages over Skynet, otherwise I´ll rather stick with Skynet. It just works, is well documented and @Adamm rocks. Just my 2 cents.
 
I did see that... just that being new to ipset, I wasn't sure how safe it would be going forward with 'old scripts' in the long run. I also am not familiar with the specific differences between skynet and ya-malware, etc. Some reading is in order... but I still wish my router could grow up (to like ac68u, lol).

Kevin
 
[edit: NM, after further reading I realize my n66u doesn't have ipset6 (and I guess won't ever get it), so I can't use your script. I'll look at ya-malware instead, since it supports ipset4 thanks.]

Yeah dont support the ancient IPSet unfortunately. This is only for models with IPSet 6
 
A question for the people with more knowledge:

Yesterday I noticed a device broadcasting DHCP messages in my LAN. I can't traceroute (times out after 30 hops) the IP, it doesn reply to ICMP , and it appears that it's IP is in the range of private IP's. I have a hunch, based on its MAC address, that the DOCSIS 3.0 router from my ISP (which is functioning as bridged modem, as my RT-AC68U receives the WAN IP) suddenly has started to function as a DHCP server on my network, or actually outside it, as it's on the other (WAN) side of my RT-AC68U. I found a remote software update in the logfiles of the ISP modem. Yet, its connection attempts are being accepted by the RT-AC68U onto my LAN. Apparently it's trying to find devices to configure, which I definitely don't want.

Code:
Aug 13 23:39:21 dMP17 kernel: ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:5c:79:5c:XX.XX.XX SRC=10.220.80.1 DST=255.255.255.255 LEN=367 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=347
Aug 13 23:39:36 dMP17 kernel: ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:5c:79:5c:XX.XX.XX SRC=10.116.112.1 DST=255.255.255.255 LEN=419 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=399
Aug 13 23:39:36 dMP17 kernel: ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:5c:79:5c:XX.XX.XX=10.116.112.1 DST=255.255.255.255 LEN=419 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=399
Aug 14 01:52:24 dMP17 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:5c:XX.XX.XX SRC=10.254.6.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=308
Aug 14 01:52:40 dMP17 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:5c:79:5c:XX.XX.XX SRC=10.254.6.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=308
Aug 14 01:53:42 dMP17 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:5c:79:5c:XX.XX.XX SRC=10.254.6.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=308
Aug 14 01:55:55 dMP17 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:5c:79:5c:XX.XX.XX SRC=10.254.6.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=308
Aug 14 01:57:09 dMP17 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:5c:79:5c:XX.XX.XX SRC=10.254.6.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=308
Aug 14 01:58:49 dMP17 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:5c:79:5c:XX.XX.XX SRC=10.254.6.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=308
Aug 14 02:01:17 dMP17 kernel: ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:5c:79:5c:XX.XX.XX SRC=10.254.6.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=308
Aug 14 02:02:44 dMP17 kernel: ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:5c:79:5c:XX.XX.XX SRC=10.254.6.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=308
Aug 14 02:07:41 dMP17 kernel: ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:5c:79:5c:XX.XX.XX SRC=10.254.6.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=308

Before midnight, I've manually banned (one of) the IP's (10.254.6.1) using Skynet, where most of the broadcasts apparently originate from, but after 2am, the DHCP broadcast messages are being accepted again, while I was asleep. I have no idea why? Different IP's are being used, all in the private range according to ARIS/IANA, but the originating MAC address is always the same.

Is there anything else I can do to prevent this, besides calling my ISP to have them remotely disable DHCP and WiFi, as they both shouldn't be active? It'll take most likely take some time to get to talk to right people, as the first line call centre agents probably won´t have a clue what I'm trying to explain (been down that road before). The UI of the ISP router is crippled when remotely put in bridged mode, every section that should be off, isn't available to home users, so there's nothing I can do to change the configuration of ISP's router/bridged modem myself.

I justed banned the IP above again but I have a feeling it will only last as long as my firewall rules are being saved by cron running /jffs/scripts/firewall?
 
Hi @Adamm

I installed Skynet on a second router running 380.68 alpha 2. It does not seem to install correctly. For the fourth time, I did the command
.
Code:
/firewall stats info
which returns
Code:
--cut out menu options--
!!! Debug Mode Is Disabled !!!
To Enable Use ( sh ./firewall install )
No Debug Data Detected - Give This Time To Generate

But I have already run the install several times and selected the debug option and save to USB after seeing this message. So, I did another install. Instead of rebooting the router this time, it restarted the firewall. Here is the output from debug info:

Code:
Router Model: RT-AC88U
Skynet Version: v5.1.3 (12/08/2017)
iptables v1.4.14 - (ppp0)
ipset v6.32, protocol version: 6
FW Version: 380.68_alpha2-g4b3b19c (Aug 11 2017)
Install Dir; /tmp/mnt/RT-AC88U/skynet (994.6M Space Available)
Boot Args; /jffs/scripts/firewall start debug banmalware autoupdate usb=/tmp/mnt/RT-AC88U
Install Dir Writeable
Startup Entry Detected
Cronjobs Not Detected
IPSet Supports Comments
Autobanning Disabled
Debug Mode Disabled
No Duplicate Rules Detected In RAW
No Duplicate Rules Detected In FILTER
Whitelist IPTable Not Detected
Skynet IPTable Not Detected
Whitelist IPSet Not Detected
BlockedRanges IPSet Not Detected
Blacklist IPSet Not Detected
Skynet IPSet Not Detected
Skynet: [Complete]  IPs /  Ranges Banned. 0 New IPs / 0 New Ranges Banned.  Inbound /  Outbound Connections Blocked! [1s]

I had no issues with the first router. Let me know if I missed a step. Thanks!
 
which returns

That error is kind of "stupid" in a sense, it only checks if the IPTable rule exists to base that message (not the actual command line), as it appears Skynet hadn't fully booted yet it shows that message somewhat incorrectly, I'll modify it in a future update.

So, I did another install. Instead of rebooting the router this time, it restarted the firewall. Here is the output from debug info:

It seems the install went fine judging by some of the checks, but Skynet just is failing to start (or you checked too early when Skynet hadn't fully booted yet?). There are actually only 3 possible ways for Skynet to fail upon startup which would produce an error in the syslog, but the debug info command shows me all these requirements are met. So I suggest check the following;

Are firewall-start & Skynet files executable? (chmod +x)

Are there any errors upon startup in the syslog?
 
Last edited:
Before midnight, I've manually banned (one of) the IP's (10.254.6.1) using Skynet, where most of the broadcasts apparently originate from, but after 2am, the DHCP broadcast messages are being accepted again

This is because Skynet during its save every hour runs the function "Unban_PrivateIP". What this does basically is scan the syslog for private IPs being blocked (usually incorrectly) and whitelists them. As the whitelist then takes priority over the blacklist it stays unbanned in this case.

If you wish to ban this IP (or any other private IP), I suggest a manual IPTables rule in firewall-start
 
If you wish to ban this IP (or any other private IP), I suggest a manual IPTables rule in firewall-start

That explains it, thanks. Will have to do some catching up on creating a rule manually for IPTables, knowledge is a bit rusty, but I'll figure it out.
 
Yesterday I noticed a device broadcasting DHCP messages in my LAN.
They are SPT=67, DPT=68, DHCP bootp. That's how your ISP assigns your internet IP and has to be allowed (there is a specific iptables rule to accept these packets). Why it suddenly went 'crazy' I don't know. It may be that your ISP decided it didn't like you using other than their equipment.
 
@john9527 Thanks for your addition. A little (lot...) background info between the brackets below. (@Adamm, sorry in advance, if this clutters your thread, just let me know, I'll remove it as soon as I read it as it's off topic, but it was a joy spilling my guts)

With this cable provider (the largest Dutch cable provided), it's completely legit to use your own hardware, as long as you use their modem (because they remotely throttle your bandwidth with it, by provisioning a config file which and how much channels it's allowed to use).

Recently I had a set top box/PVR for HDTC replaced after three visits by three different cable guys and to my surprise, I noticed the cable guy swiftly replaced the modem as well for a new model. All fine be me, as this one is supposed to be ready for future changes on their network. Suddenly three days ago, I noticed a very strong bgn signal with an unknown SSID (stronger than my own router) which I didn't recognize. Around here, it's overcrowded with SSID's so getting channels with less interference, almost requires optimized alternative firmware, in my experience.

So I checked the bottom of the new router they placed, did some googling, and found out that the beginning of the SSID is a temporary name, which starts with the name of the manufacturer of the WiFi chips used in the router they had just replaced, which should have been replaced by the name of the ISP on first run. But the cable guy never configured anything, he just plugged it in, connected it to the COAX wall outlet, connected my router to LAN 1 and turned it on and asked me to reboot my router. No problem, a few minutes later my RT-AC68U got assigned a new WAN IP. So I googled some more, found out what IP it was active on when in bridged mode, logged into it with the default user/pass on the bottom and confirmed that it wasn't set up (but still working by the provisioned config file). So I went through the initial setup, and got access to the (crippled) menu, where I could access the logs. There I discovered they remotely pushed a provisioning config update and a firmware update and got confirmation that the WiFi had been turned on, as there are loglines that confirm it's switching channels because of interference.

Now, this particular ISP has a free service for (nearly all of their customer) called WiFiSpots, throughout the country, which is basically a third radio in their customers' routers, creating a huge roaming network, you can freely use. Except... when you decide to have your modem bridged, which only they can do remotely, in that case you no longer have access to WiFiSpots anywhere and they shutdown WiFi on their router, as well as the entire router functionality and the menu is crippled, to hide all other options you no longer have access to. Only VoIP and LAN port 1 works, that's it. And there you have it: a bridged router/modem. Fine by me, their routers are well-known for weak WiFi performance.

Well, that should be it. A few months ago I discovered, with my own previous router (Netgear R6300v2 running dd-wrt) that their (previous) bridged router had started broadcasting an SSID again, or actually two: one for WiFiSpots and one for the customer itself. However I was no longer entitled to use WiFiSpots, the two routers (theirs and mine) were constantly circling around each other battling for a free channel or at least one with less interference. So I demanded they remotely turned it off, which they did. Now that I noticed that with a new router they pulled the same trick again, I'm wondering whether they purposely try to re-enable the radio for (expanding) WiFiSpots again, after some time has gone by. Unfortunately in this case it didn't turn out as they expected, as the cable guy never finished setup. I did a factory restore on their router (knowing the thing will immediately phone home after rebooting to get its config) but it kept the factory SSID and the DHCP queries kept showing up in my logs.

Long story short, I'll call them again, probably for 40th time since I became customer (again) in February this year. I have no intention cancelling, as they simply outperform by far every other ISP in the Netherlands when comes to price comparison. They're the only one on the cable, the rest is either (ancient) copper or glass fiber. I had fiber before, which was good but expensive in comparison, so I went back after a couple of years. Not sure anymore whether that was the wisest decision, but now that they've recently merged with Europe's largest cellular provider, they've become one of the strongest players in the (European) market and I'm having two cellular contracts, 150/15 Mbit internet, HDTV and a landline at a price no one else can beat. They just shouldn't start pulling tricks like this on me... With a background in several positions at several ISP's, before I got sick and ultimately physically disabled, I still have more knowledge than the average first line agent at the other side of the line... Always a joy waiting for the 'hold on, I'll put you through to one of my colleagues...' :D

TL;DR: Just skip to the next post... (just a grumpy guy spilling his guts, but nothing Skynet related, I love Skynet :))
 
Are firewall-start & Skynet files executable? (chmod +x)

Are there any errors upon startup in the syslog?
No errors in syslog. I don't see the message that checks for other scripts that I saw on the other router. I took a nvram and jffs backup before I installed 380.68 Alpha 2. I can try and do a factory reset, then restore nvram and jffs using the backup and restore procedure. Then reinstall skynet. I have a maintenance window Thursday night where I can try this.
 
No errors in syslog. I don't see the message that checks for other scripts that I saw on the other router. I took a nvram and jffs backup before I installed 380.68 Alpha 2. I can try and do a factory reset, then restore nvram and jffs using the backup and restore procedure. Then reinstall skynet. I have a maintenance window Thursday night where I can try this.

I mean it sounds like firewall-start isn't being executed thus Skynet is never being executed, or it is failing to execute due to permissions or possibly line endings?

What happens if you execute it manually;

Code:
sh /jffs/scripts/firewall-start

And if that fails to get the ball rolling, try run the Skynet startup manually that firewall-start _should_ be doing.

Code:
sh /jffs/scripts/firewall start debug banmalware autoupdate usb=/tmp/mnt/RT-AC88U
 
I mean it sounds like firewall-start isn't being executed thus Skynet is never being executed, or it is failing to execute due to permissions or possibly line endings?

What happens if you execute it manually;

Code:
sh /jffs/scripts/firewall-start

And if that fails to get the ball rolling, try run the Skynet startup manually that firewall-start _should_ be doing.

Code:
sh /jffs/scripts/firewall start debug banmalware autoupdate usb=/tmp/mnt/RT-AC88U

The problem is with firewall-start. I had some legacy code in the file. It looks like the code to start the firewall got appended to the end of the done line rather than after the line:

Code:
!/bin/sh
# Reinstate the ipset rules if they have been created already
[ "$(uname -m)" = "mips" ] && MATCH_SET='--set' || MATCH_SET='--match-set'
for ipSet in $(ipset -L | sed -n '/^Name:/s/^.* //p'); do
  case $ipSet in
    AcceptList) iptables-save | grep -q "$ipSet" || iptables -I INPUT -m set $MATCH_SET $ipSet src -j ACCEPT;;
    WhitelistDomains) iptables-save | grep -q "$ipSet" || iptables -t raw -I PREROUTING -m set $MATCH_SET $ipSet src,dst -j ACCEPT;;
    TorNodes|BlockedCountries|CustomBlock) iptables-save | grep -q "$ipSet" || iptables -I INPUT -m set $MATCH_SET $ipSet src -j DROP;;
    MicrosoftSpyServers) iptables-save | grep -q "$ipSet" || iptables -I FORWARD -m set $MATCH_SET $ipSet dst -j DROP;;
    YAMalwareBlock*) iptables-save | grep -q "$ipSet" || iptables -t raw -I PREROUTING -m set $MATCH_SET $ipSet src -j DROP;;
    *) iptables-save | grep -q "$ipSet" || iptables -t raw -I PREROUTING -m set $MATCH_SET $ipSet src,dst -j DROP;;
  esac
donesh /jffs/scripts/firewall start debug banmalware autoupdate usb=/tmp/mnt/RT-AC88U # Skynet Firewall Addition

In the original code, there is a blank line after the done line.

I fixed the code in firewall-start, then rerun the Skynet install. My SSH session then locks up and I also can no longer access the Web GUI. I have to do a factory reset by holding down the WPS button for 10 seconds while powering on. Then, restore using the nvram backup and restore utility.

I will try again later as I have to run some errands now. Before the next attempt though, I will /dev/null firewall-start file.
 
AcceptList) iptables-save | grep -q "$ipSet" || iptables -I INPUT -m set $MATCH_SET $ipSet src -j ACCEPT;;
Am I reading this wrong?
In case there is an AcceptList, do:
iptables-save <PIPE THROUGH> grep -q "$ipSet" <OR> iptables -I INPUT -m set $MATCH_SET $ipSet src -j ACCEPT
 
I fixed the code in firewall-start, then rerun the Skynet install. My SSH session then locks up and I also can no longer access the Web GUI.

Im going to chalk this one up as your "legacy code" interfering with Skynet and creating conflicting rules. I suggest you start fresh and try then. This block of code is definitely not needed for Skynet and will actually cause big problems as you have a wildcard entry (amung other issues) which will in turn block everything on Skynets whitelist which lead to the issues described.

In the original code, there is a blank line after the done line.

Can't reproduce this either, whenever I append an echo to a text file it creates a new line as per expected.
 
Last edited:
Im going to chalk this one up as your "legacy code" interfering with Skynet and creating conflicting rules. I suggest you start fresh and try then. This block of code is definitely not needed for Skynet and will actually cause big problems as you have a wildcard entry (amung other issues) which will in turn block everything on Skynets whitelist which lead to the issues described.



Can't reproduce this either, whenever I append an echo to a text file it creates a new line as per expected.
Thank you for looking into this. Yes, the legacy code is no longer required. So I will blow it away before the next install attempt. Not sure why it worked with no issue on the other router. On the other router, I had an iptables command to block a client from making a connection to the router after the legacy code. So there was a small difference. I'll have to wait for Thursday night or Sunday afternoon before trying again.

Do you suggest a do a touch on firewall-start to clear out the file or delete the firewall-start before I attempt the install of Skynet?
 
Am I reading this wrong?
In case there is an AcceptList, do:
iptables-save <PIPE THROUGH> grep -q "$ipSet" <OR> iptables -I INPUT -m set $MATCH_SET $ipSet src -j ACCEPT
@redhat27 was the author of the code. I'll let him chime in on this one.
 
Not sure why it worked with no issue on the other router.

If the same code block is in place you run the very same risk on that router also. What this "legacy code" does from my brief look is;

  1. A for loop listing all current loaded IPSets
  2. If the IPSet name matches a particular name, it checks for an IPTables rule via a very basic pattern check. If there are no grep matches it creates a new rule
  3. If the IPSet name doesn't match any of the listed patterns, it defaults to the wildcard match. This will basically force a IPTables drop rule regardless of the IPSets intended purpose.
I personally find the need for this code quite bad from a scriptwriters standpoint. I think that scripts should be smart enough to handle their own rules and "fix" themselves in the event something goes wrong. Because in this case, a wildcard rule has caused a complete loss of connectivity.

Now the question is what exactly happened to your setup. I can see a point of failure being if Skynet is initially loaded correctly, then the firewall-start event is called again. During this event only IPTables rules are flushed (not the IPSets themselves). So upon restart this "legacy code" would have listed all Skynets IPSets still loaded in ram and defaulted to the wildcard drop entry listed. This means all 3 IPSets (including the Whitelist with a bunch of important Private IP's) would have had some generic drop entry.

Usually if this code wasn't present, Skynet is smart enough to deal with situations like this and proceed as expected. So I highly suggest removing this code from both routers.

Do you suggest a do a touch on firewall-start to clear out the file or delete the firewall-start before I attempt the install of Skynet?

You can just simply delete it, Skynet will generate the file during the install process with a shebang and the appropriate permissions etc.
 
Last edited:
Installed this on a new router. Testing.......In progress.
I cannot believe there is no additional config after selecting vanilla install method!
@Adamm this is a great script! It covers all the bases and no impact to ram or processor.
I'm impressed!!
 
Last edited:

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