Skynet Skynet - Router Firewall & Security Enhancements

[Alfsu]

Output to debug info:

Checking Install Directory Write Permissions...         [Passed]
Checking Firewall-Start Entry...                        [Passed]
Checking Services-Stop Entry...                         [Passed]
Checking CronJobs...                                    [Failed]
Checking IPSet Comment Support...                       [Passed]
Checking Log Level 7 Settings...                        [Passed]
Checking For Duplicate Rules In RAW...                  [Passed]
Checking Inbound Filter Rules...                        [Failed]
Checking Inbound Debug Rules                            [Failed]
Checking Outbound Filter Rules...                       [Failed]
Checking Outbound Debug Rules                           [Failed]
Checking Whitelist IPSet...                             [Failed]
Checking BlockedRanges IPSet...                         [Failed]
Checking Blacklist IPSet...                             [Failed]
Checking Skynet IPSet...                                [Failed]
Checking For AB-Solution Plus Content...                [Passed]

Output in syslog when restarting:

Apr  4 21:00:48 Skynet: [Complete]  IPs /  Ranges Banned. 0 New IPs / 0 New Ranges Banned.  Inbound /  Outbound Connections Blocked! [debug] [1s]
Apr  4 21:03:23 Skynet: [INFO] Restarting Skynet...

I will uninstall again and try to clean up all files b4 re-installing again.

Cheers!

 

[Alfsu]

It worked this time... uninstall via menu, deleted firewall-start file in /jffs/scripts and install via amtm

Thank you Adamm!

 

[Adamm]

It worked this time... uninstall via menu, deleted firewall-start file in /jffs/scripts and install via amtm

Thank you Adamm!

It appears the issue was with the firewall-start file so Skynet was never actually starting up, maybe it was edited by another script or yourself by accident. In any case glad its working now.

 

[Butterfly Bones]

Today it seems Skynet has stopped.
SNB does not like too many lines (over 1000), here is the full paste - https://pastebin.com/twMZxfge

Apr  4 16:51:24 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=216.58.207.195 DST=AA.BB.CC.DD LEN=107 TOS=0x00 PREC=0x00 TTL=41 ID=36848 PROTO=TCP SPT=443 DPT=36004 SEQ=3500941238 ACK=3284783871 WINDOW=175 RES=0x00 ACK PSH URGP=0 OPT (0101080A5DFA3B5500412883) MARK=0x8000000
Apr  4 16:51:25 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=172.217.11.161 DST=AA.BB.CC.DD LEN=115 TOS=0x00 PREC=0x00 TTL=57 ID=50576 PROTO=TCP SPT=443 DPT=38865 SEQ=1087222590 ACK=2773420509 WINDOW=176 RES=0x00 ACK PSH URGP=0 OPT (0101080AAC97277CFFFFA86C) MARK=0x8000000
Apr  4 16:51:27 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=216.58.207.195 DST=AA.BB.CC.DD LEN=107 TOS=0x00 PREC=0x00 TTL=41 ID=20731 PROTO=TCP SPT=443 DPT=53601 SEQ=1316513842 ACK=2148763322 WINDOW=175 RES=0x00 ACK PSH URGP=0 OPT (0101080A344CF334004C3D80) MARK=0x8000000
Apr  4 16:51:28 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=216.58.217.46 DST=AA.BB.CC.DD LEN=115 TOS=0x00 PREC=0x00 TTL=55 ID=1435 PROTO=TCP SPT=443 DPT=54501 SEQ=840033652 ACK=3525969282 WINDOW=295 RES=0x00 ACK PSH URGP=0 OPT (0101080A06360917FFFFA972) MARK=0x8000000
Apr  4 16:51:28 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=172.217.11.174 DST=AA.BB.CC.DD LEN=107 TOS=0x00 PREC=0x00 TTL=58 ID=40208 PROTO=TCP SPT=443 DPT=41448 SEQ=3423693243 ACK=1849399203 WINDOW=208 RES=0x00 ACK PSH URGP=0 OPT (0101080AD36B8E9C004ABDB2) MARK=0x8000000
Apr  4 16:53:12 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=8x:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=191.101.167.73 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=243 ID=51933 PROTO=TCP SPT=45527 DPT=2500 SEQ=436175813 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000
Apr  4 16:54:05 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=8x:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=185.143.223.90 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=238 ID=6056 PROTO=TCP SPT=48849 DPT=33398 SEQ=1202115842 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000
Apr  4 16:54:58 kernel: DROP IN=eth0 OUT= MAC=8x:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=45.227.253.249 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=237 ID=52283 PROTO=TCP SPT=56420 DPT=3393 SEQ=1527218598 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000
Apr  4 16:55:43 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=8x:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=188.166.109.163 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=237 ID=54321 PROTO=TCP SPT=43070 DPT=4222 SEQ=3246228719 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0x8000000

I watch for entries using "sh /jffs/scripts/firewall debug watch" as I see the above in the syslog, but only this in the Skynet terminal.

Apr  4 16:53:12 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=8x:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=191.101.167.73 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=243 ID=51933 PROTO=TCP SPT=45527 DPT=2500 SEQ=436175813 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000
Apr  4 16:54:05 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=8x:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=185.143.223.90 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=238 ID=6056 PROTO=TCP SPT=48849 DPT=33398 SEQ=1202115842 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000
Apr  4 16:55:43 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=8x:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=188.166.109.163 DST=AA.BB.CC.DD LEN=40 TOS=0x00 PREC=0x00 TTL=237 ID=54321 PROTO=TCP SPT=43070 DPT=4222 SEQ=3246228719 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0x8000000 ]/CODE]

I've tried restarting, complete uninstall, reboot router, reinstall Skynet. Most syslog entries are kernel DROP IN and not kernel: [BLOCKED - INBOUND] indicating that Skynet is missing most packets, and just the router SPI firewall is getting them.

 

[JaimeZX]

Related to the above - I've spent some time on the Googles; is anyone aware of a quick-reference to decoding the firewall logs? Some items (PROTO, IN=eth0, etc.) are obvious but some aren't as intuitive.

Ex:

Apr  4 19:55:13 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=94.102.49.190 DST=24.107.xxx.xxx LEN=44 TOS=0x00 PREC=0x00 TTL=116 ID=10274 PROTO=TCP SPT=22601 DPT=4786 SEQ=710238014 ACK=0 WINDOW=32610 RES=0x00 SYN URGP=0 OPT (020405B4)

Note: I XXed out the MAC because I assume (not certain) it was the router MAC.

 

[Butterfly Bones]

Related to the above - I've spent some time on the Googles; is anyone aware of a quick-reference to decoding the firewall logs? Some items (PROTO, IN=eth0, etc.) are obvious but some aren't as intuitive.

Ex:

Apr  4 19:55:13 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=94.102.49.190 DST=24.107.xxx.xxx LEN=44 TOS=0x00 PREC=0x00 TTL=116 ID=10274 PROTO=TCP SPT=22601 DPT=4786 SEQ=710238014 ACK=0 WINDOW=32610 RES=0x00 SYN URGP=0 OPT (020405B4)

Note: I XXed out the MAC because I assume (not certain) it was the router MAC.

Yes, redacted just like this for my IP.

DST=AA.BB.CC.DD

 

[Butterfly Bones]

Related to the above - I've spent some time on the Googles; is anyone aware of a quick-reference to decoding the firewall logs? Some items (PROTO, IN=eth0, etc.) are obvious but some aren't as intuitive.

Partial list -

TOS, for Type of service,
DST is destination ip,
SRC is source ip
TTL is time to live, a small counter decremented each time a packet is passed through another router (so if there is a loop, the package destroy itself once to 0)
DF is "don't fragment" bit, asking to packet to not be fragmented when sent
PROTO is the protocol (mostly TCP and UDP)
SPT is the source port
DPT is the destination port

 

[JaimeZX]

Thanks! Helpful.

 

[Butterfly Bones]

Thanks! Helpful.

I'm still trying Google to find the complete list, but my Google Fu is failing me.

 

[lukaszzsch]

hi all,

i would like to add following countries to the ban list: China, South and North Korea

Which country code should i use?

 

[Adamm]

I've tried restarting, complete uninstall, reboot router, reinstall Skynet. Most syslog entries are kernel DROP IN and not kernel: [BLOCKED - INBOUND] indicating that Skynet is missing most packets, and just the router SPI firewall is getting them.

As I stated in the v6.1.0 release, we removed SPI autobanning functionality from Skynet. So anything dropped by the SPI firewall is now out of Skynets control. While I could rebrand these logs, I'm not sure doing so would make sense.

This also means users don't need to have "Logged packets type" in the WebUI set to dropped anymore as Skynet no longer hijacks this functionality.

 

[Adamm]

hi all,

i would like to add following countries to the ban list: China, South and North Korea

Which country code should i use?

You can reference this list here, and find the abbreviations you are looking for are; cn kp kr


Interesting fact, North Korea only has 1024 IP addresses and 36 websites.

 

[Twiglets]

Related to the above - I've spent some time on the Googles; is anyone aware of a quick-reference to decoding the firewall logs? Some items (PROTO, IN=eth0, etc.) are obvious but some aren't as intuitive.

Ex:

Apr  4 19:55:13 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=94.102.49.190 DST=24.107.xxx.xxx LEN=44 TOS=0x00 PREC=0x00 TTL=116 ID=10274 PROTO=TCP SPT=22601 DPT=4786 SEQ=710238014 ACK=0 WINDOW=32610 RES=0x00 SYN URGP=0 OPT (020405B4)

Note: I XXed out the MAC because I assume (not certain) it was the router MAC.

See https://docs.microsoft.com/en-us/pr.../it-pro/windows-server-2003/cc758040(v=ws.10)

Article is about "Interpreting the Windows Firewall Log", it should give enough info to allow, with a bit of 'guesstimation', for the firewall logs to be understood.
(Pay attention to tcpflags abreviations as they are slightly different e.g. urg is urgp in the router logs.)

Hope this helps.

Also see https://ubuntuforums.org/showthread...77735e91c1eedbbe60eb2&p=12361050#post12361050

 

[Butterfly Bones]

As I stated in the v6.1.0 release, we removed SPI autobanning functionality from Skynet. So anything dropped by the SPI firewall is now out of Skynets control. While I could rebrand these logs, I'm not sure doing so would make sense.

This also means users don't need to have "Logged packets type" in the WebUI set to dropped anymore as Skynet no longer hijacks this functionality.

Ah, got it. Sorry for the noise. I read what you stated on v.6.1.0, but did not fully understand the technical implications from the router standpoint. When the kernel DROP messages came flooding in as the bot level increased into the evening (for me - as it unusually does), I did not make the connection to the Skynet feature change.

I know I contributed to the decision to remove autobanning. Now I feel it was a feature that is important, in spite of the work needed by the user to track down false positives. It should relieve the questions for you with the autobans not issued. I'm going to go back and read that sequence of messages as you and John worked through that with Scott.

Again, thank you for the work on Skynet.

 

[skeal]

@Adamm For what it is worth I liked the old way better. I liked it when skynet was auto banning.

 

[DonnyJohnny]

@Adamm For what it is worth I liked the old way better. I liked it when skynet was auto banning.

I see that invalid packet generated is common in IoT gadgets which I don’t have any to see the autoban at work. But agree that autoban is a nice feature to have when in comes to ddos from the outside rather than from inside which user should have track and see why the devices is generating invalid packet.

Whatever it is, I respect the decision made by Adamm but I do hope autoban stay.

 

[skeal]

I see that invalid packet generated is common in IoT gadgets which I don’t have any to see the autoban at work. But agree that autoban is a nice feature to have when in comes to ddos from the outside rather than from inside which user should have track and see why the devices is generating invalid packet.

Whatever it is, I respect the decision made by Adamm but I do hope autoban stay.

I realize and respect his decision (@Adamm ) however I already miss it. lol

 

[ScottW]

I see that invalid packet generated is common in IoT gadgets which I don’t have any to see the autoban at work.

Invalid packets are not in any way limited to IoT devices. Some are malicious, some occur naturally during communications between internal LAN devices and hosts on the internet.

A side-effect of Skynet's autoban implementation was that invalid packets were accepted onto the LAN from whitelisted hosts. Did you know that maliciously-crafted invalid packets, the kind intended to cause network problems / ddos, can include a spoofed IP? That's just one good reason invalid packets should not be accepted, even when they appear to come from a whitelisted (trusted) host. But beyond that, naturally occurring packets (retransmits, lost sequence numbers, corrupted packets, etc.) can cause issues, too. They should never be accepted onto the LAN regardless of their "apparent" source.

Autoban is a fun feature, but the implementation -- making it work, work right, and work without side-effects or lowering security using the tools available on the platform -- is NOT a simple task. If @Adamm eventually has time to work through that, great, but in the meantime I trust his judgement that eliminating Autoban is the best course at the moment.

 

[skeal]

Invalid packets are not in any way limited to IoT devices. Some are malicious, some occur naturally during communications between internal LAN devices and hosts on the internet.

A side-effect of Skynet's autoban implementation was that invalid packets were accepted onto the LAN from whitelisted hosts. Did you know that maliciously-crafted invalid packets, the kind intended to cause network problems / ddos, can include a spoofed IP? That's just one good reason invalid packets should not be accepted, even when they appear to come from a whitelisted (trusted) host. But beyond that, naturally occurring packets (retransmits, lost sequence numbers, corrupted packets, etc.) can cause issues, too. They should never be accepted onto the LAN regardless of their "apparent" source.

Autoban is a fun feature, but the implementation -- making it work, work right, and work without side-effects or lowering security -- is NOT a simple task. If @Adamm eventually has time to work through that, great, but in the meantime I trust his judgement that eliminating Autoban is the best course at the moment.

Agreed! Thanks for the explanation. It makes total sense.

 

[DonnyJohnny]

Invalid packets are not in any way limited to IoT devices. Some are malicious, some occur naturally during communications between internal LAN devices and hosts on the internet.

A side-effect of Skynet's autoban implementation was that invalid packets were accepted onto the LAN from whitelisted hosts. Did you know that maliciously-crafted invalid packets, the kind intended to cause network problems / ddos, can include a spoofed IP? That's just one good reason invalid packets should not be accepted, even when they appear to come from a whitelisted (trusted) host. But beyond that, naturally occurring packets (retransmits, lost sequence numbers, corrupted packets, etc.) can cause issues, too. They should never be accepted onto the LAN regardless of their "apparent" source.

Autoban is a fun feature, but the implementation -- making it work, work right, and work without side-effects or lowering security -- is NOT a simple task. If @Adamm eventually has time to work through that, great, but in the meantime I trust his judgement that eliminating Autoban is the best course at the moment.

Question.
If Skynet let invalid packet come in due to whitelist, does the router own spi would have drop it? When we say whitelist, we are just letting in the packet to be process by the router?

My understanding is first line of defence is Skynet ipset at raw stage, then enter mangle and filter and nat? There is filter iptables blocking those invalid packet? That is what i see in the iptables.

-A INPUT -m state --state INVALID -j DROP
-A FORWARD -m state --state INVALID -j DROP


For me what I did was I add in the following to block them at mangle table where even before the packet are process by the router
iptables -t mangle -A PREROUTING -m conntrack --ctstate INVALID -j DROP