Skynet Skynet - Router Firewall & Security Enhancements

[Adamm]

You got the sequence right. My hypothesis seems to hold. Skynet is actually accepting INVALID packets that are normally dropped. Here's a better workaround command instead of the iptables delete. This will keep the whitelist active for the other chains.

iptables -I logdrop -m state --state INVALID -j DROP

Thanks John! I'll give that a try and report back tomorrow....

I did install tcpdump and ran it. Hard (for me) to fully understand the output, but it is easy to see a pattern where the Amazon device looks up a DNS record, initiates a connection, gets the acknowledgement, then starts streaming. It does that for each of the "news briefing" segments. When one stalls (i.e., when Skynet is active and autoban=yes), the acknowledgement never makes it to tcpdump.... So the packet (SYN ACK?) must be getting dropped somewhere. I'd blame it on the content distribution server, except it works fine with Skynet disabled (or autoban=no). So something about how iptables is identifying those packets.

Thanks for your help, I'll check back in tomorrow with further results!

Well if the whitelist rule is the issue, that's by far the oddest one I've heard of so far. Strange how allowing some invalid packets is causing issues

 

[Adamm]

Skynet is reporting "190 Outbound Connections Blocked! however using debug to view the lists, skynet listed only x2 https outbound @ "8.8.8.8"

Why is that? Could someone be messing with the log? I had another router hacked today behind the Asus ac66u with the latest alpha 68u firmware; a GL-MT300N.

This counter is accurate, you can get an overview of hits from the stats command (that is if debug mode is enabled ofc);

sh /jffs/scripts/firewall stats

@Adamm also I would like to suggest a feature request, that being added options for viewing block records so users can scroll through all blocked ips (or over a given time period), starting with the latest blocks. This would be extremely useful for people.

I believe what you are describing is possible with the various stats commands.

Any way to block all but http requests much like peerblock? Would be a great feature to prevent hackers in particular, nation wide. It would be great to BDS the whole of Israel, though their tentacles are everywhere, as they have, at least at the time they pulled of 911, already penetrated every western intelligence agency in existence.

Currently it is only possible to block all requests from IP's. As for blocking entire countries there is a built in function for that.

 

[Butterfly Bones]

Skynet is reporting "190 Outbound Connections Blocked! however using debug to view the lists, skynet listed only x2 https outbound @ "8.8.8.8"

Why is that? Could someone be messing with the log? I had another router hacked today behind the Asus ac66u with the latest alpha 68u firmware; a GL-MT300N.

@Adamm also I would like to suggest a feature request, that being added options for viewing block records so users can scroll through all blocked ips (or over a given time period), starting with the latest blocks. This would be extremely useful for people.

That is an ongoing issue for me as well. I know from a post by RMerlin that Google devices are hardcoded to use Google DNS. I have five Google Home speakers, two chromecasts and three android mobile devices on my network. I've abandoned trying to force them to use my preferred DNS via DNSCrypt instead trying to allow them through Skynet. Sadly Skynet keeps dropping outbound connections from my Google devices to 8.8.8.8.

I get variations of this 3-4 times a week. I just noticed they are all UDP or ICMP protocal blocks. I edit logs to simplify them. The first one if from a built in chromecast / Sony Vizio, the second is a Google Home Max speaker.

Apr  2 18:29:41 kernel: [BLOCKED - OUTBOUND] DST=8.8.8.8 LEN=61 TOS=0x00 PREC=0x00 TTL=64 ID=47717 DF PROTO=UDP
Apr  2 18:29:41 kernel: [BLOCKED - OUTBOUND] DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP

Input IP Or Range To Whitelist:

[IP/Range]: 8.8.8.8

Input Comment For Whitelist:

[Comment]: Google DNS

Whitelisting 8.8.8.8
ipset v6.32: Element cannot be added to the set: it's already added

Input IP Or Range To Whitelist:

[IP/Range]: 8.8.4.4

Input Comment For Whitelist:

[Comment]: Google DNS

Whitelisting 8.8.4.4
ipset v6.32: Element cannot be added to the set: it's already added

# sh /jffs/scripts/firewall whitelist list ) List All Whitelist Entries (edited)

8.8.8.8 comment "CDN-Whitelist"

8.8.4.4 comment "CDN-Whitelist"

# sh /jffs/scripts/firewall stats search malware 8.8.8.8
Debug Data Detected in /tmp/mnt/SNB/skynet/skynet.log - 1.5M
Monitoring From Apr 1 07:55:54 To Apr 3 09:02:47
5576 Block Events Detected
1050 Unique IPs
63 Autobans Issued
5 Manual Bans Issued
Exact Matches;
https://iplists.firehol.org/files/coinbl_hosts.ipset - 8.8.8.8
Possible CIDR Matches;
Skynet: [Complete] 115921 IPs / 1715 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 1528 Inbound / 0 Outbound Connections Blocked! [stats] [5s]

 

[ScottW]

You got the sequence right. My hypothesis seems to hold. Skynet is actually accepting INVALID packets that are normally dropped. Here's a better workaround command instead of the iptables delete. This will keep the whitelist active for the other chains.

iptables -I logdrop -m state --state INVALID -j DROP

I reinstalled Skynet with default configuration this morning, i.e., with autobans ON and banmalware ON. I was able to easily reproduce the "abrupt stream end" problem again with that install.

I then inserted the new "drop invalids" rule at top of logdrop chain, using the command John provided above. After that, I was unable to reproduce the problem. To verify, I repeated the entire sequence again (i.e., reinstall with defaults, reproduce problem, insert rule, unable to reproduce) just to make sure. To verify again, I just deleted the new rule (with iptables -D logdrop 1), no other changes, and the problem came back.

So... I am convinced that the whitelist accepting invalid packets somehow leads to the problem -- still not clear why, but some invalid packet must be coming through that "confuses" the Amazon device's network stack. In any case, dropping the invalids ahead of the whitelist accept rule appears to solve the issue.

To be clear, here's what the iptables chain looks like with the new rule in place:

Chain logdrop (8 references)
target     prot opt source               destination        
DROP       all  --  anywhere             anywhere             state INVALID
ACCEPT     all  --  anywhere             anywhere             match-set Skynet-Whitelist src
DROP       tcp  --  anywhere             anywhere             multiport sports www,https,imap2,imaps,pop3,pop3s,smtp,ssmtp state INVALID
ACCEPT     icmp --  anywhere             anywhere             icmp time-exceeded
ACCEPT     icmp --  anywhere             anywhere             icmp destination-unreachable
ACCEPT     tcp  --  anywhere             anywhere             tcpflags: FIN,SYN,RST,PSH,ACK,URG/FIN,PSH,ACK
ACCEPT     tcp  --  anywhere             anywhere             tcpflags: FIN,SYN,RST,PSH,ACK,URG/FIN,ACK
ACCEPT     tcp  --  anywhere             anywhere             tcpflags: FIN,SYN,RST,PSH,ACK,URG/RST
ACCEPT     tcp  --  anywhere             anywhere             tcpflags: FIN,SYN,RST,PSH,ACK,URG/RST,ACK
           all  --  anywhere             anywhere             recent: SET name: TRACKINVALID side: source
LOG        all  --  anywhere             anywhere             state INVALID recent: UPDATE seconds: 300 hit_count: 2 name: TRACKINVALID side: source LOG level warning tcp-sequence tcp-options ip-options prefix "[BLOCKED - NEW BAN] "
SET        all  --  anywhere             anywhere             state INVALID recent: UPDATE seconds: 300 hit_count: 2 name: TRACKINVALID side: source add-set Skynet-Master src
DROP       all  --  anywhere             anywhere

And here, with the new "drop invalids" rule in place, is what an iptables -nvL reports after running steps that previously reproduced the issue:

Chain logdrop (8 references)
 pkts bytes target     prot opt in     out     source               destination        
    3   660 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
    0     0 ACCEPT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            match-set Skynet-Whitelist src
    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            multiport sports 80,443,143,993,110,995,25,465 state INVALID
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 11
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 3
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x19
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x11
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x04
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x14
    0     0            all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            recent: SET name: TRACKINVALID side: source
    0     0 LOG        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            state INVALID recent: UPDATE seconds: 300 hit_count: 2 name: TRACKINVALID side: source LOG flags 7 level 4 prefix "[BLOCKED - NEW BAN] "
    0     0 SET        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            state INVALID recent: UPDATE seconds: 300 hit_count: 2 name: TRACKINVALID side: source add-set Skynet-Master src
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

 

[Adamm]

That is an ongoing issue for me as well. I know from a post by RMerlin that Google devices are hardcoded to use Google DNS. I have five Google Home speakers, two chromecasts and three android mobile devices on my network. I've abandoned trying to force them to use my preferred DNS via DNSCrypt instead trying to allow them through Skynet. Sadly Skynet keeps dropping outbound connections from my Google devices to 8.8.8.8.

I get variations of this 3-4 times a week. I just noticed they are all UDP or ICMP protocal blocks. I edit logs to simplify them. The first one if from a built in chromecast / Sony Vizio, the second is a Google Home Max speaker.

Does this happen for periods longer then a few seconds? The only time this should ever happen is when Skynet dumps and updates its whitelist (which if you update banmalware daily would be then)

 

[ScottW]

I think this is a minor issue, may not need fixing -- but when using "temporarily disable" Skynet, the default firewall logging is lost.

Before running Skynet, logdrop chain looks like this (note the default LOG action):

Chain logdrop (8 references)
target     prot opt source               destination       
LOG        all  --  anywhere             anywhere             state NEW LOG level warning tcp-sequence tcp-options ip-options prefix "DROP "
DROP       all  --  anywhere             anywhere

While Skynet is running (Default LOG action replaced with custom LOG action):

Chain logdrop (8 references)
target     prot opt source               destination       
ACCEPT     all  --  anywhere             anywhere             match-set Skynet-Whitelist src
DROP       tcp  --  anywhere             anywhere             multiport sports www,https,imap2,imaps,pop3,pop3s,smtp,ssmtp state INVALID
ACCEPT     icmp --  anywhere             anywhere             icmp time-exceeded
ACCEPT     icmp --  anywhere             anywhere             icmp destination-unreachable
ACCEPT     tcp  --  anywhere             anywhere             tcpflags: FIN,SYN,RST,PSH,ACK,URG/FIN,PSH,ACK
ACCEPT     tcp  --  anywhere             anywhere             tcpflags: FIN,SYN,RST,PSH,ACK,URG/FIN,ACK
ACCEPT     tcp  --  anywhere             anywhere             tcpflags: FIN,SYN,RST,PSH,ACK,URG/RST
ACCEPT     tcp  --  anywhere             anywhere             tcpflags: FIN,SYN,RST,PSH,ACK,URG/RST,ACK
           all  --  anywhere             anywhere             recent: SET name: TRACKINVALID side: source
LOG        all  --  anywhere             anywhere             state INVALID recent: UPDATE seconds: 300 hit_count: 2 name: TRACKINVALID side: source LOG level warning tcp-sequence tcp-options ip-options prefix "[BLOCKED - NEW BAN] "
SET        all  --  anywhere             anywhere             state INVALID recent: UPDATE seconds: 300 hit_count: 2 name: TRACKINVALID side: source add-set Skynet-Master src
DROP       all  --  anywhere             anywhere

Then, after "9-Temporarily Disable Skynet" (custom LOG action unloaded, but default LOG action not restored):

Chain logdrop (8 references)
target     prot opt source               destination       
DROP       all  --  anywhere             anywhere

@Adamm, would it be possible to put back the default LOG action when unloading the custom entries?

 

[Butterfly Bones]

Does this happen for periods longer then a few seconds? The only time this should ever happen is when Skynet dumps and updates its whitelist (which if you update banmalware daily would be then)

It last long enough to stop the casting from my phone to TV and Hulu prompts with a network error.
Banmalware runs at 02:25 (am PDT - I'm asleep)

Apr  3 02:25:29 Skynet: [Complete] 115921 IPs / 1715 Ranges Banned. 1567 New IPs / 21 New Ranges Banned. 864 Inbound / 0 Outbound Connections Blocked! [banmalware] [29s]

Yesterdays blocks were at 18:29 (6:29 pm PDT) while I'm casting basketball.

Apr  2 18:29:41 kernel: [BLOCKED - OUTBOUND] DST=8.8.8.8
Apr  2 18:29:41 kernel: [BLOCKED - OUTBOUND] DST=8.8.8.8

 

[Adamm]

It last long enough to stop the casting from my phone to TV and Hulu prompts with a network error.
Banmalware runs at 02:25 (am PDT - I'm asleep)

Apr  3 02:25:29 Skynet: [Complete] 115921 IPs / 1715 Ranges Banned. 1567 New IPs / 21 New Ranges Banned. 864 Inbound / 0 Outbound Connections Blocked! [banmalware] [29s]

Yesterdays blocks were at 18:29 (6:29 pm PDT) while I'm casting basketball.

Apr  2 18:29:41 kernel: [BLOCKED - OUTBOUND] DST=8.8.8.8
Apr  2 18:29:41 kernel: [BLOCKED - OUTBOUND] DST=8.8.8.8

So there's no indication of any command being run around that time?

The problem is for that notification, the destination IP wouldn't be on the whitelist.

! match-set Skynet-Whitelist dst match-set Skynet-Master dst LOG flags 7 level 4 prefix "[BLOCKED - OUTBOUND] "

To translate this rule - "If IP isn't in Whitelist & Is on Blacklist = Print block message"

In any case, I'll look into reducing the time whitelisted entries are removed during the refresh period.

 

[Butterfly Bones]

So there's no indication of any command being run around that time?

The problem is for that notification, the destination IP wouldn't be on the whitelist.



To translate this rule - "If IP isn't in Whitelist & Is on Blacklist = Print block message"

In any case, I'll look into reducing the time whitelisted entries are removed during the refresh period.

No commands I can see in history. I edit out most of the normal hourly reports and left the two banmalware from yesterday and today. All the activity at 18:29 is me searching whitelist and banmalware lists.
I was cooking dinner and watching the game, not on the computer at all. When Hulu stopped with the network error, I went to the computer and started checking.

Thank you, the ipset rules are still foreign language to me, though I'm learning. Thanks for checking. I don't mean to make more work, I reported since this just baffles my understanding of why blocks occur when IPs are whitelisted. If you think this is important to do, then please do. If it is just to stop my whining just leave it, no big deal to me.

Apr  2 02:00:02 Skynet: [Complete] 114270 IPs / 1677 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 2420 Inbound / 0 Outbound Connections Blocked! [save] [2s]
Apr  2 02:25:31 Skynet: [Complete] 114355 IPs / 1694 Ranges Banned. 85 New IPs / 17 New Ranges Banned. 2636 Inbound / 0 Outbound Connections Blocked! [banmalware] [31s]

Apr  2 17:00:03 Skynet: [Complete] 114355 IPs / 1694 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 905 Inbound / 0 Outbound Connections Blocked! [save] [2s]
Apr  2 18:00:02 Skynet: [Complete] 114355 IPs / 1694 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 979 Inbound / 0 Outbound Connections Blocked! [save] [2s]
Apr  2 18:29:59 Skynet: [Complete] 114355 IPs / 1694 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 0 Inbound / 0 Outbound Connections Blocked! [start] [21s]
Apr  2 18:31:07 Skynet: [Complete] 114355 IPs / 1694 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 1 Inbound / 0 Outbound Connections Blocked! [3s]
Apr  2 18:32:13 Skynet: [Complete] 114355 IPs / 1694 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 2 Inbound / 0 Outbound Connections Blocked! [3s]
Apr  2 18:32:39 Skynet: [Complete] 114354 IPs / 1694 Ranges Banned. -1 New IPs / 0 New Ranges Banned. 4 Inbound / 0 Outbound Connections Blocked! [2s]
Apr  2 18:33:52 Skynet: [Complete] 114354 IPs / 1694 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 6 Inbound / 0 Outbound Connections Blocked! [2s]
Apr  2 18:35:12 Skynet: [Complete] 114354 IPs / 1694 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 7 Inbound / 0 Outbound Connections Blocked! [2s]
Apr  2 19:00:02 Skynet: [Complete] 114354 IPs / 1694 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 41 Inbound / 0 Outbound Connections Blocked! [save] [2s]

Apr  3 02:25:29 Skynet: [Complete] 115921 IPs / 1715 Ranges Banned. 1567 New IPs / 21 New Ranges Banned. 864 Inbound / 0 Outbound Connections Blocked! [banmalware] [29s]

 

[Adamm]

No commands I can see in history. I edit out most of the normal hourly reports and left the two banmalware from yesterday and today. All the activity at 18:29 is me searching whitelist and banmalware lists.
I was cooking dinner and watching the game, not on the computer at all. When Hulu stopped with the network error, I went to the computer and started checking.

Thank you, the ipset rules are still foreign language to me, though I'm learning. Thanks for checking. I don't mean to make more work, I reported since this just baffles my understanding of why blocks occur when IPs are whitelisted. If you think this is important to do, then please do. If it is just to stop my whining just leave it, no big deal to me.

Apr  2 02:00:02 Skynet: [Complete] 114270 IPs / 1677 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 2420 Inbound / 0 Outbound Connections Blocked! [save] [2s]
Apr  2 02:25:31 Skynet: [Complete] 114355 IPs / 1694 Ranges Banned. 85 New IPs / 17 New Ranges Banned. 2636 Inbound / 0 Outbound Connections Blocked! [banmalware] [31s]

Apr  2 17:00:03 Skynet: [Complete] 114355 IPs / 1694 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 905 Inbound / 0 Outbound Connections Blocked! [save] [2s]
Apr  2 18:00:02 Skynet: [Complete] 114355 IPs / 1694 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 979 Inbound / 0 Outbound Connections Blocked! [save] [2s]
Apr  2 18:29:59 Skynet: [Complete] 114355 IPs / 1694 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 0 Inbound / 0 Outbound Connections Blocked! [start] [21s]
Apr  2 18:31:07 Skynet: [Complete] 114355 IPs / 1694 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 1 Inbound / 0 Outbound Connections Blocked! [3s]
Apr  2 18:32:13 Skynet: [Complete] 114355 IPs / 1694 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 2 Inbound / 0 Outbound Connections Blocked! [3s]
Apr  2 18:32:39 Skynet: [Complete] 114354 IPs / 1694 Ranges Banned. -1 New IPs / 0 New Ranges Banned. 4 Inbound / 0 Outbound Connections Blocked! [2s]
Apr  2 18:33:52 Skynet: [Complete] 114354 IPs / 1694 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 6 Inbound / 0 Outbound Connections Blocked! [2s]
Apr  2 18:35:12 Skynet: [Complete] 114354 IPs / 1694 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 7 Inbound / 0 Outbound Connections Blocked! [2s]
Apr  2 19:00:02 Skynet: [Complete] 114354 IPs / 1694 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 41 Inbound / 0 Outbound Connections Blocked! [save] [2s]

Apr  3 02:25:29 Skynet: [Complete] 115921 IPs / 1715 Ranges Banned. 1567 New IPs / 21 New Ranges Banned. 864 Inbound / 0 Outbound Connections Blocked! [banmalware] [29s]

Your logs here show Skynet restarted at "Apr 2 18:29:59" which would mean the blocks at "Apr 2 18:29:41" were within the 21 second startup window. As suspected these came as the whitelist was being refreshed. I'll work on a more seamless fresh in a future version, but for now this should only happen when the whitelist is refreshed.

 

[Adamm]

@ScottW I've pushed v6.1.0

I've gone ahead and removed autobanning functionality based on invalid packets from the SPI firewall. This feature started off with good intentions, but due to the variations in home network setups users have its hard to keep a ruleset that works for everyone without false positives. This functionality will be reverted to Asus's implementation where invalid packets are just dropped.

Autobanning will still be present, but now only for SSH connection attempts when SSH is exposed to WAN (which is a bad idea in the first place).

 

[DonnyJohnny]

@ScottW I've pushed v6.1.0

I've gone ahead and removed autobanning functionality based on invalid packets from the SPI firewall. This feature started off with good intentions, but due to the variations in home network setups users have its hard to keep a ruleset that works for everyone without false positives. This functionality will be reverted to Asus's implementation where invalid packets are just dropped.

Autobanning will still be present, but now only for SSH connection attempts when SSH is exposed to WAN (which is a bad idea in the first place).

Strangely the autoban issue never happened to me and I don’t even have a single autoban ip since the day I use Skynet.. lol.. well.. I am basic user with no game console nor iot gadgets. So maybe that’s why...
In most cases, I don’t really see the power of the invalid autoban yet so I assume it is not that common used Attack. Maybe against web server... but not with home router.

 

[Adamm]

@Butterfly Bones I also just pushed a temporary fix for the google dns issue. The IP's will now be excluded from any banmalware update. So after updating (you will need to force update if you downloaded v6.1.0 already) and running banmalware you should no longer have this issue.

 

[Butterfly Bones]

@Butterfly Bones I also just pushed a temporary fix for the google dns issue. The IP's will now be excluded from any banmalware update. So after updating (you will need to force update if you downloaded v6.1.0 already) and running banmalware you should no longer have this issue.

Thank you. I did the force update then ran banmalware command, then just to see, I ran
"sh /jffs/scripts/firewall stats"

Here are the Outbound blocks, knowing this is drawn from old history.

Last 10 Unique Connections Blocked (Outbound);
https://otx.alienvault.com/indicator/ip/8.8.8.8
Last 10 Unique HTTP(s) Blocks (Outbound);
Top 10 HTTP(s) Blocks (Outbound);
Top 10 Blocks (Outbound);
10x https://otx.alienvault.com/indicator/ip/8.8.8.8
Top 10 Blocked Devices (Outbound);
4x 192.168.1.xxx HomeMax
3x 192.168.1.xxx Vizio
2x 192.168.1.xxx HomeMini
1x 192.168.1.xxx HomeMini

The OTX Alienvault report on that url is interesting.
https://otx.alienvault.com/indicator/ip/8.8.8.8

 

[daviworld]

@ScottW I've pushed v6.1.0

I've gone ahead and removed autobanning functionality based on invalid packets from the SPI firewall. This feature started off with good intentions, but due to the variations in home network setups users have its hard to keep a ruleset that works for everyone without false positives. This functionality will be reverted to Asus's implementation where invalid packets are just dropped.

Autobanning will still be present, but now only for SSH connection attempts when SSH is exposed to WAN (which is a bad idea in the first place).

Like the user above, I never had an issue with autobanning and I have various gadgets, on top of my day to day job includes networking & security events.

So, your script is very fun for me, when analyzing firewall log's lol. Would it be possible to make this feature optional for more advanced user's, while not overcomplicating thing's for basic user's?

Sent from my LG-H830 using Tapatalk

 

[Adamm]

Like the user above, I never had an issue with autobanning and I have various gadgets, on top of my day to day job includes networking & security events.

So, your script is very fun for me, when analyzing firewall log's lol. Would it be possible to make this feature optional for more advanced user's, while not overcomplicating thing's for basic user's?

Sent from my LG-H830 using Tapatalk

Yeah the feature was really was user dependant, I personally never had issues either but had to constantly water down rules to suit everyone’s needs and prevent false positives.

It’s on my todo list in future updates to add more customisation for various options and the ability to toggle singular items from the install menu without going through the whole process, so I’ll defenetly consider readding it at some point in that capacity. Just balancing the struggles of free time and motivation to work on it

 

[ScottW]

@ScottW I've pushed v6.1.0

I've gone ahead and removed autobanning functionality based on invalid packets from the SPI firewall. This feature started off with good intentions, but due to the variations in home network setups users have its hard to keep a ruleset that works for everyone without false positives. This functionality will be reverted to Asus's implementation where invalid packets are just dropped.

Autobanning will still be present, but now only for SSH connection attempts when SSH is exposed to WAN (which is a bad idea in the first place).

Unfortunately, I think that is the best solution. I understand why people liked the autoban feature, but I'm not sure they all understand the side effects or the complexity of trying to research and eliminate those side effects while keeping the functionality working. The autoban function was a small part of Skynet, yet would take an increasing amount of effort to refine and keep it working without undesired side effects (and false positives).

To be clear, my problem wasn't with "false positives" because those are easily identified and fixed when they occur. My problem was with the side effect of invalid packets being accepted onto the LAN from whitelisted hosts. The risk of maliciously crafted invalid packets from whitelisted hosts is low, though not necessarily zero. More importantly, there are lots of "normal" conditions that result in invalid packets even in sessions with trusted hosts. In my case, those invalid packets making it to the LAN from some whitelisted Amazon CDNs were causing certain TCP connections to be closed prematurely on certain devices. There are good reasons why invalid packets -- for example, those with incorrect sequence numbers, or retransmits of packets for connections already acknowledged or closed -- should be dropped and not accepted, even from whitelisted/trusted hosts. It's just not a good idea to have those on the LAN.

THANKS for your attention to the problem, @Adamm!! I have installed 6.1.0 and it's working great; no more invalid packets accepted and no more terminated connections. Really appreciate all your work with Skynet, and with your fast response to issues like this!

 

[Alfsu]

Updated to 6.1.0 and appears to not work in the 56U:

Router Model; RT-AC56U
Skynet Version;  (04/04/2018)
iptables v1.4.15 - (eth0 @ 192.168.56.1)
ipset v6.32, protocol version: 6
FW Version; 384.4_2 (Mar 24 2018) (2.6.36.4brcmarm)
Install Dir; /tmp/mnt/1GB/skynet (586.8M / 965.0M Space Available)
SWAP File; /tmp/mnt/1GB/myswap.swp (256.3M)
Boot Args; /jffs/scripts/firewall start skynetloc=/tmp/mnt/1GB/skynet

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]

I did uninstall followed by a fresh install to no avail. When selecting to check for updates it shows 6.1.0 as an available update, and a force update does nothing to the behavior.

FYI, also updated an 86U and it worked just fine!

 

[Twiglets]

Updated to 6.1.0 and appears to not work in the 56U:

Router Model; RT-AC56U
Skynet Version;  (04/04/2018)
iptables v1.4.15 - (eth0 @ 192.168.56.1)
ipset v6.32, protocol version: 6
FW Version; 384.4_2 (Mar 24 2018) (2.6.36.4brcmarm)
Install Dir; /tmp/mnt/1GB/skynet (586.8M / 965.0M Space Available)
SWAP File; /tmp/mnt/1GB/myswap.swp (256.3M)
Boot Args; /jffs/scripts/firewall start skynetloc=/tmp/mnt/1GB/skynet

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]

I did uninstall followed by a fresh install to no avail. When selecting to check for updates it shows 6.1.0 as an available update, and a force update does nothing to the behavior.

FYI, also updated an 86U and it worked just fine!

I have installed 6.1.0 on RT-AC56U and all working OK !
Check no residual files are 'left behind' that are 'breaking' install etc.

 

[Adamm]

Updated to 6.1.0 and appears to not work in the 56U:

Router Model; RT-AC56U
Skynet Version;  (04/04/2018)
iptables v1.4.15 - (eth0 @ 192.168.56.1)
ipset v6.32, protocol version: 6
FW Version; 384.4_2 (Mar 24 2018) (2.6.36.4brcmarm)
Install Dir; /tmp/mnt/1GB/skynet (586.8M / 965.0M Space Available)
SWAP File; /tmp/mnt/1GB/myswap.swp (256.3M)
Boot Args; /jffs/scripts/firewall start skynetloc=/tmp/mnt/1GB/skynet

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]

I did uninstall followed by a fresh install to no avail. When selecting to check for updates it shows 6.1.0 as an available update, and a force update does nothing to the behavior.

FYI, also updated an 86U and it worked just fine!

Post the output of;

sh /jffs/scripts/firewall debug info

And when you restart Skynet, are there any errors in the syslog?

sh /jffs/scripts/firewall restart