Skynet Skynet - Router Firewall & Security Enhancements

[Adamm]

@Adamm any way to silence Skynet in systemlog?

That's definitely not usual output, I'm going to say there's a bug with ipset/iptables. It should look like the following;

Oct 30 01:36:14 kernel: [BLOCKED - INBOUND] IN=ppp0 OUT= MAC= SRC=181.214.87.239 DST=xx.xx.xx.xx LEN=40 TOS=0x00 PREC=0x00 TTL=243 ID=25940 PROTO=TCP SPT=58223 DPT=5555 SEQ=1858422464 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0
Oct 30 01:37:06 kernel: [BLOCKED - INBOUND] IN=ppp0 OUT= MAC= SRC=189.59.8.121 DST=xx.xx.xx.xx LEN=48 TOS=0x00 PREC=0x00 TTL=109 ID=63113 PROTO=TCP SPT=40284 DPT=22 SEQ=485371945 ACK=158781377 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B401010402)
Oct 30 01:37:52 kernel: [BLOCKED - INBOUND] IN=ppp0 OUT= MAC= SRC=114.67.129.28 DST=xx.xx.xx.xx LEN=40 TOS=0x00 PREC=0x00 TTL=41 ID=10891 PROTO=TCP SPT=59527 DPT=22 SEQ=979383847 ACK=0 WINDOW=40605 RES=0x00 SYN URGP=0
Oct 30 01:38:20 kernel: [BLOCKED - INBOUND] IN=ppp0 OUT= MAC= SRC=93.174.95.106 DST=xx.xx.xx.xx LEN=40 TOS=0x00 PREC=0x00 TTL=113 ID=8009 PROTO=TCP SPT=58022 DPT=4848 SEQ=2769959851 ACK=0 WINDOW=3856

Does this happen with debug mode disabled via the installer?

Please also post the output of;

iptables -L

iptables --line -t raw -vnL

 

[.TT.]

Installed with vanilla and selecting 11->1 (disable debug) does not change output.
Default message log level :notice
Log only messages more urgent than: debug
Firewall: Logged packets type; dropped
output: https://pastebin.com/rncNn2zZ

 

[Adamm]

Okay now we are getting somewhere.

A malformed rule exists, specifically this one;

LOG        all  --  anywhere             anywhere             state NEW LOG level warning tcp-sequence tcp-options ip-options prefix "--log"

Considering the rule in the log-accept chain is the same which we don't modify at all, I think this is an error with the show dropped/accepted packets feature that's baked in the firmware, although I couldn't find the obvious error in firewall.c @RMerlin

If you post the output of iptables-save I can give you a quickfix to throw into your firewall-start file until this is resolved in the firmware.

 

[.TT.]

Thanks for putting your time and effort in to this! =)
https://pastebin.com/HGhbWZTj

 

[Adamm]

Thanks for putting your time and effort in to this! =)
https://pastebin.com/HGhbWZTj

Okay try throw this in the bottom of /jffs/scripts/firewall-start then restart Skynet from the menu;

iptables -D logdrop -m state --state NEW -j LOG --log-prefix --log --log-tcp-sequence --log-tcp-options --log-ip-options

After doing so you should be able to use features like debug mode etc, this seems to be an issue on the firmware side.

 

[.TT.]

Thanks again! =)
Syslog is nice and clean.

 

[Adamm]

I've pushed v5.4.0 with the fix for .382 codebase above until its fixed in the firmware. Some other changes since 5.3.9 include;

Shaved about 20s+ off banmalware execution time
Shaved about 15s off Whitelist_Shared ()
"stats search malware xxx.xxx.xxx.xx" is about x3 faster
Skynet uses fewer IPTables rules now which in theory should give better preformance
Improved aesthetics on the debug info command / main menu

 

[RMerlin]

Considering the rule in the log-accept chain is the same which we don't modify at all, I think this is an error with the show dropped/accepted packets feature that's baked in the firmware, although I couldn't find the obvious error in firewall.c @RMerlin

An uninitialized buffer was fixed a while back, make sure you're on 380.68_4.

 

[Adamm]

An uninitialized buffer was fixed a while back, make sure you're on 380.68_4.

The user who reported it has a AC86U, so maybe the fix wasn't ported over to the new codebase?

 

[gLWxSJeSsEA]

Hmm... has this changed or is my mind playing tricks on me?

I could have sworn I used to use the unban command like below (without the "ip" flag) to quickly unban an IP.

sh /jffs/scripts/firewall unban xxx.xxx.xxx.xxx

Now it won't recognize the command unless I specify it's an IP

sh /jffs/scripts/firewall unban ip xxx.xxx.xxx.xxx

Skynet v.5.4.0

 

[Adamm]

Hmm... has this changed or is my mind playing tricks on me?

I could have sworn I used to use the unban command like below (without the "ip" flag) to quickly unban an IP.

sh /jffs/scripts/firewall unban xxx.xxx.xxx.xxx

Now it won't recognize the command unless I specify it's an IP

sh /jffs/scripts/firewall unban ip xxx.xxx.xxx.xxx

Skynet v.5.4.0

Yes unfortunately it was a necessary change when I rewrote the functions, the trade-off being faster/easier to maintain code that is now inline with other functions. Changing commands is something I try to avoid at all costs, so its a rare occurrence at that.

 

[gLWxSJeSsEA]

Yes unfortunately it was a necessary change when I rewrote the functions, the trade-off being faster/easier to maintain code that is now inline with other functions. Changing commands is something I try to avoid at all costs, so its a rare occurrence at that.

Thanks! Good to know I'm not going insane.

Maybe the error message could be changed to suggest the user try the ip flag (at least for a couple of versions, until people become acquainted with the change). Though, it's admittedly not a big deal, since you can do it through the new menu interface.

Anyway, thanks for the awesome work Adamm!

 

[RMerlin]

The user who reported it has a AC86U, so maybe the fix wasn't ported over to the new codebase?

Or it could be a new bug - Asus did a lot of cleanup in the firewall code with 382, so the code has changed a fair bit.

I'll have to see if I can reproduce it.

 

[SeaConn]

Okay try throw this in the bottom of /jffs/scripts/firewall-start then restart Skynet from the menu;

iptables -D logdrop -m state --state NEW -j LOG --log-prefix --log --log-tcp-sequence --log-tcp-options --log-ip-options

After doing so you should be able to use features like debug mode etc, this seems to be an issue on the firmware side.

Had the same issue as @.TT with copious amounts of "logIN=eth0" comments in my system log. Followed your instructions above and it's no longer reporting this particular comment. Good work (assuming it's just an IPTable logging issue)!

 

[RMerlin]

This is an odd one. The rule is properly entered in /tmp/filter_rules, manually running it works properly, but when the file is applied through iptables-restore it gets corrupted. Makes me wonder if the issue wouldn't be in iptables itself (tho I did update it to match the same version as AM380).

EDIT: bug is definitely in iptables, not in the router. I get a bogus entry with iptables-restore, but it gets properly added if I add it through the command line.

I spotted this commit upstream:

https://git.netfilter.org/iptables/commit/?h=v1.4.15&id=2165f38d2582e88e8a9dd9416f34eca7a7672e5a

Going to give it a try.

 

[SeaConn]

This is an odd one. The rule is properly entered in /tmp/filter_rules, manually running it works properly, but when the file is applied through iptables-restore it gets corrupted. Makes me wonder if the issue wouldn't be in iptables itself (tho I did update it to match the same version as AM380).

Does AB-Solution use iptables at all? I've been running it since alpha2 and haven't had any issues with it all beyond getting entware and pixelserv to load up correctly. Nothing goofy in the System Log I can point at, anyway.

 

[thelonelycoder]

Does AB-Solution use iptables at all? I've been running it since alpha2 and haven't had any issues with it all beyond getting entware and pixelserv to load up correctly. Nothing goofy in the System Log I can point at, anyway.

No, never has, never will.

 

[RMerlin]

Confirmed - that iptables patch from 1.4.15 fixes the issue.

Chain logaccept (10 references)
 pkts bytes target     prot opt in     out     source               destination         
    3   156 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW LOG flags 7 level 4 prefix "ACCEPT "
  171 31907 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain logdrop (8 references)
 pkts bytes target     prot opt in     out     source               destination         
    5   208 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW LOG flags 7 level 4 prefix "DROP "
    5   208 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

 

[RMerlin]

Does AB-Solution use iptables at all? I've been running it since alpha2 and haven't had any issues with it all beyond getting entware and pixelserv to load up correctly. Nothing goofy in the System Log I can point at, anyway.

No, altho the issue can randomly impact RT-AC86U users, it will mostly affect users that enable logging of dropped and/or accepted packets.

 

[2992]

Skynet v5.3.9:
"Skynet: [Complete] 152 IPs / 0 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 0 Inbound / 0 Outbound Connections Blocked! [47s]"
Is this normal? With the previous version (few days ago with v5.3.7 if I remember correctly) I recall I've seen much more IPs over there...