Skynet Skynet ban IP not banning...

[ss_pam]

Hello, I tried to add the IP of one of my LAN devices to ban via ssh. I followed the prompts however left comments blank because I just want all traffic for specific LAN ip blocked. Process completed via skynet ssh but then I went to test whether the LAN device was blocked by attempting to access internet, and it was able to connect to interenet sites. Can anyone advise potential reasons the ban is not working. Also, what is the purpose of adding a "comment" when adding a ban ip? Thank for any help

 

[Viktor Jaep]

Hello, I tried to add the IP of one of my LAN devices to ban via ssh. I followed the prompts however left comments blank because I just want all traffic for specific LAN ip blocked. Process completed via skynet ssh but then I went to test whether the LAN device was blocked by attempting to access internet, and it was able to connect to interenet sites. Can anyone advise potential reasons the ban is not working. Also, what is the purpose of adding a "comment" when adding a ban ip? Thank for any help

Can't say I've ever tried that, but I was under the impression that Skynet's BAN command only applied to public IPs/domains. You would probably have better luck just banning your private IP using the Asus-Merlin UI, under firewall -> network services filter?

 

[ss_pam]

Thanks, I use netwrok services filter already as a whitelist. The issue I have is that NSF only allows you to add one rule per ip at a time and there are a limited amount of rules you can add. I wanted to do a similar thing with Skynet that would enable me to use whitelist lists that I can easily edit. i.e block all connections from a source (LAN) IP then manually add whatever I need to the whitelist based on source and destination ip.

In regard to Skynet, It's based on iptables, so assume it has the function to block source ip addresses. It also gives outbound block stats so again assumed you could set rules based on source (LAN) IP. Maybe someone can confirm whther or not this is possible.

 

[BreakingDad]

Also, what is the purpose of adding a "comment" when adding a ban ip?

So you can see what the ban applies to. Probably more useful when whitelisting.

 

[Slapdaddy]

Hello, I tried to add the IP of one of my LAN devices to ban via ssh. I followed the prompts however left comments blank because I just want all traffic for specific LAN ip blocked. Process completed via skynet ssh but then I went to test whether the LAN device was blocked by attempting to access internet, and it was able to connect to interenet sites. Can anyone advise potential reasons the ban is not working. Also, what is the purpose of adding a "comment" when adding a ban ip? Thank for any help

Well I'm speculating here but I think Skynet was meant to ban incoming/outgoing communications from IPs outside your LAN, therefore I would assume that there's probably some hard-coded whitelist for LAN IPs so you don't accidentally ban someone in your home. Or it might operate entirely different lol.

Adding a comment makes it easier for you to see why you banned an address and easier to batch operate numerous commented IPs or IP blocks.

 

[nbi]

Just encountered this issue myself which is a real bummer as I was counting on Skynet to help shut down a rogue IP on my private subnet. Not sure I understand why it would make a difference whether the IP is public (external) or private (192.168.x.x). In either case the iptables solution is to disable packets to/from the offending address. Please don't protect us from ourselves - if knowing any potential risks we want to shut down a private IP that should be our choice. If there is an under the covers policy that prevents private IP bans then that should be reported to the user when a private IP ban is requested.

 

[visortgw]

Just encountered this issue myself which is a real bummer as I was counting on Skynet to help shut down a rogue IP on my private subnet. Not sure I understand why it would make a difference whether the IP is public (external) or private (192.168.x.x). In either case the iptables solution is to disable packets to/from the offending address. Please don't protect us from ourselves - if knowing any potential risks we want to shut down a private IP that should be our choice. If there is an under the covers policy that prevents private IP bans then that should be reported to the user when a private IP ban is requested.

Look at option 5 (Unban PrivateIP) within Skynet Settings.

 

[nbi]

Look at option 5 (Unban PrivateIP) within Skynet Settings.

Thanks, but I got into trouble with this perhaps because I don't understand the intent of this setting. So by default it looks like:

[5] --> Unban PrivateIP | [Enabled]

And when this is selected we get:

Select Filter PrivateIP Option:
[1] --> Enable
[2] --> Disable

These 2 setting levels seem contradictory. "Unban PrivateIP | [Enabled]" suggests private IPs cannot be banned whereas "Select Filter PrivateIP Option" (enabled) suggests the opposite. So which is it - do we want enabled or disabled? Neither of these work. The default "enabled" allows banning and the ban is listed via the web interface, but it doesn't actually "ban" the IP which still is shown on arp-scans and responds to pings. So I foolishly tried "disabled" which not only doesn't work neither, but it had the catastrophic effect of knocking my wireless repeaters offline (there's a serious bug somewhere - either in Skynet or the asuswrt-merlin firmware). I was sweating blood as I thought the router got bricked? Fortunately I regained control via a router lan port and recovered the network by rebooting the repeaters. Bottom line though is that this rogue IP is still not blocked and I'm getting nervous about having been hacked.

What am I trying to block/mute? This obscure IP which I can't correlate to any of my hardware started showing up on the RT-AC68U client list and on arp-scans:
192.168.1.184 SHENZHEN BILIAN ELECTRONIC CO.，LTD

I did some research on this and the claims are that this is generated by common networking hardware which just isn't identifying itself correctly. I've got issues with such assertions. Whatever this is it obtains its IP via DHCP. And all my wireless devices are already accounted for. It also creates an entry in the routing table, why?:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.184 RT-AC68U-A448. 255.255.255.255 UGH 3 0 0 br0

And a nmap scan shows:
PORT STATE SERVICE
6668/tcp open irc

FWIW, I tried the suggestion given earlier in this thread of using the Network Services Filter. This has the effect of hiding this IP from the RT-AC68U client list and now it rarely appears on arp-scans, but it still responds to pings so it's still camped onto my network. Unfortunately out of sight is not out of mind. I was hoping Skynet would be my savior. Oh well. Looks like I may be getting my hands dirty with iptables and tcpdump.

 

[visortgw]

Thanks, but I got into trouble with this perhaps because I don't understand the intent of this setting. So by default it looks like:

[5] --> Unban PrivateIP | [Enabled]

And when this is selected we get:

Select Filter PrivateIP Option:
[1] --> Enable
[2] --> Disable

These 2 setting levels seem contradictory. "Unban PrivateIP | [Enabled]" suggests private IPs cannot be banned whereas "Select Filter PrivateIP Option" (enabled) suggests the opposite. So which is it - do we want enabled or disabled? Neither of these work. The default "enabled" allows banning and the ban is listed via the web interface, but it doesn't actually "ban" the IP which still is shown on arp-scans and responds to pings. So I foolishly tried "disabled" which not only doesn't work neither, but it had the catastrophic effect of knocking my wireless repeaters offline (there's a serious bug somewhere - either in Skynet or the asuswrt-merlin firmware). I was sweating blood as I thought the router got bricked? Fortunately I regained control via a router lan port and recovered the network by rebooting the repeaters. Bottom line though is that this rogue IP is still not blocked and I'm getting nervous about having been hacked.

What am I trying to block/mute? This obscure IP which I can't correlate to any of my hardware started showing up on the RT-AC68U client list and on arp-scans:
192.168.1.184 SHENZHEN BILIAN ELECTRONIC CO.，LTD

I did some research on this and the claims are that this is generated by common networking hardware which just isn't identifying itself correctly. I've got issues with such assertions. Whatever this is it obtains its IP via DHCP. And all my wireless devices are already accounted for. It also creates an entry in the routing table, why?:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.184 RT-AC68U-A448. 255.255.255.255 UGH 3 0 0 br0

And a nmap scan shows:
PORT STATE SERVICE
6668/tcp open irc

FWIW, I tried the suggestion given earlier in this thread of using the Network Services Filter. This has the effect of hiding this IP from the RT-AC68U client list and now it rarely appears on arp-scans, but it still responds to pings so it's still camped onto my network. Unfortunately out of sight is not out of mind. I was hoping Skynet would be my savior. Oh well. Looks like I may be getting my hands dirty with iptables and wireshark.

Security light/camera purchased from Lowe's? That is exactly what shows up on a friend's network that I manage...

 

[nbi]

Security light/camera purchased from Lowe's? That is exactly what shows up on a friend's network that I manage...

That's what I thought at first, but my Reolink camera is unplugged (and it doesn't use batteries). A neighbor's camera couldn't have latched onto my network by accident. A camera also shouldn't produce that routing table entry. All my wireless gear is accounted for - each item has a known IP. Supposedly that address is commonly used for router admin pages. There are several problems with that. I've never used it before nor have I seen it until recently. And it cannot be accessed via a browser - the nmap scan only shows port 6668 open so the router admin page theory doesn't hold up. Sigh. This is going to be a bugger to unravel.

UPDATE: I think I successfully neutered it via iptables. I blocked all traffic to/from this IP including ICMP. Also disabled DHCP responses based on the MAC so the next time it pokes its head up it won't be getting an address. Don't see it anymore - good riddance. Everything is working flawlessly so apparently it was not a needed component.