Yes. But bear in mind that I am not able to identify absolutely every single attack for what it is probing for.
Netgear, Cisco, some GPON (fibre optic) router or modem, some IP camera, Turris (LuCI) … and a bunch of network equipment that must run some distro of Linux but have really shitty security.
I also see attacks targeting specific software rather than specific hardware e.g. GIT, Druid, PHP, SONiC (operating system), Hudson, GeoServer. (Are people really exposing this stuff to the internet?)
And that’s just January so far looking at logs on one computer that is exposed to the internet.
And protocols generally: SMB, RDP, HTTP.
My VPSs could no doubt add to the above lists but I don’t want to trawl more logs just now.
Indeedy. So it’s about knowing what your attack surface is, deciding whether it can and should be reduced, and monitoring.
So far, I’m impressed by the Turris Omnia. The setup defaults in the simpler of the two interface versions (“reForis” vs. “LuCI”) helped.
It took some research to find out how to add the RaspberryPi/Pi-hole into the mix, but I got that set up, as well, in LuCI.
The only thing I haven’t figured out yet is how to force one device, the ATA for my VOIP line, to not route through Pi-hole. I don’t need to filter that one… and it generates lots of log entries in Pi-hole. So, I would prefer that the ATA use the router’s upstream DNS instead. Still trawling through Turris and openWRT forums looking for the answer.
That would depend on how the ATA gets its network parameters. Does the ATA use DHCP or is it statically configured?
If it is statically configured then it should be easy enough to specify the DNS server IP address that you want to use. So I assume DHCP.
If it uses DHCP then the next question would be … where is the DHCP server? In the Turris? Somewhere else? If it’s in the Turris then you would be looking for more advanced DHCP server functionality whereby there is a default set of network parameters that is handed out to every DHCP client but that can be overridden, in whole or in part, for specific DHCP clients?
If you can find a text file that is used to configure the DHCP server, maybe private message me with a representative sample. Or is the DHCP server only configured through a GUI?
To be honest, in my environment, the DHCP server can’t do different configs for different clients, and every DHCP client uses the same DNS server, and hence the ATA just goes through the local DNS server like everything else. With the understanding that everything about my environment is different from yours, this doesn’t seem to cause a problem. Yes, I can see a lookup for sip.<censored>.net.au from the ATA about once every half hour (probably actually the SIP registration period, which you may be able to lengthen if it is bugging you).
Yes, it could. I would have to be able to distinguish between legitimate remote access/management requests and requests to the minipot - and, not owning a Turris device, I don’t have enough information to do that.
In AsusWRT-Merlin, my router provided DHCP. I gave every device, including the ATA, a static IP (for ssh/sftp/bookmarking convenience), and made the router broadcast the Rpi/Pi-hole’s IP address for DNS. It was easy to exclude the ATA and tell it to instead use the router’s IP for upstream DNS (Quad9).
In the Turris, too, the router provides DHCP. I’ve assigned a static IP to every device using the reForis (simpler) interface, and made the router broadcast the Rpi/Pi-hole’s IP address for DNS, as per comment #1here, in the “DHCP and DNS” section of the LuCI interface. (You can use either interface after logging into the router.)
In the Turris, I haven’t yet found a setting for assigning an alternate DNS server per device. Maybe it’s not possible, which is not necessarily a big deal for me, but it would be nice to exclude the ATA and its 10,000+ daily “hellos” to my VOIP provider from Pi-hole. (And there’s nothing to block there, anyway.)
With OpenWRT, I think it’s possible to do a lot of configuration via ssh, but I’m not sure I want to go there.
Continue to badger Turris / OpenWRT for enough information to do this if it can be done or a clear statement that it cannot.
Set a completely static config on the ATA i.e. don’t use DHCP on the ATA.
Move the DHCP server somewhere else. For IPv4 at least there is no real reason to have the DHCP server in the internet gateway and it can be argued that the DHCP server should not be in the internet gateway.
Increase the SIP registration period. What is it currently set to?
Set up a second “DNS server” that frontends the Pi-Hole. Everything on the network uses that new DNS server. The new DNS server has negligible logic: if source IP address is that of the ATA then relay to upstream (ISP) DNS server else relay to Pi-Hole - and handle responses coming back. (It may be that the Pi-Hole box with a second IP address could itself play this role.)
Add the needed functionality to your router. Job done. It’s open source, right?
On balance the second is probably the path of least resistance if you don’t get anywhere with Turris Support. Those last two options might require some software skills, particularly the last.
Yes, me too. Not just those conveniences but also
troubleshooting, and
it is easier to reconfigure the entire network if you have to do so, if everything is using DHCP. That is, DHCP with static mapping from MAC address to IP address is the best of both worlds - the convenience of fixed IP addresses but ease of reconfiguration (e.g. move DNS server somewhere else) if you had to.
If it is possible at all, it really won’t be that difficult.
I played at doing your 2nd one, starting at the ATA settings, changing from DHCP to Static and applying the same/current IP address… but then wasn’t quite sure how to adjust the router settings to exclude the ATA from DHCP (other than just deleting it… but that didn’t go so well. Lol. So I reverted to the way it was.
I’ve been waiting a couple of days for Turris to approve my forum account so I can get a definitive answer.
That’s complicated because routers that contain a DHCP server exhibit inconsistent behaviour regarding whether fixed mappings should be inside or outside the DHCP range etc.
(If you want me to elaborate on that point then you would have to clarify what the subset of the subnet that is being used for DHCP is and whether fixed mappings are inside or outside that range - on your particular router.)
In this case I would have just left the DHCP fixed mapping for the ATA there in the router. It is unlikely that the router will block the traffic just because it sees a device that is using an IP address that it hasn’t been validly issued (unless that functionality specifically exists in the router and you have enabled it) - and it is unlikely that a DHCP server would issue an IP address that has a fixed mapping against it to another DHCP client (hence making it highly desirable to leave the entry there, for those routers where fixed mappings are inside the DHCP range).
In other words, don’t adjust the router. Just leave it there. The DHCP server will never see a DHCP request that matches the entry by MAC address but that isn’t a problem. (On my router, I leave such an entry there because it’s a clear placeholder that the address is assigned to a device even if the device is not in fact using DHCP.)
I’ve found a way to exclude the ATA’s connections from the Pi-hole logs.
I created a new “Group” and moved the ATA into it. Then, in “Clients,” I restricted the ATA to the new group, disabling it in the “Default” group. That excluded it from filtering, but didn’t stop it from logging its numerous entries every few seconds. To exclude it from logging, the following was necessary:
In Pi-hole Settings > Web Interface/API > Exclusions, add the IP address of the ATA to the “Clients to be excluded from Top Client Lists and Query Log” box.
In the “Domains to be excluded from Top Domain Lists and Query Log,” specific domains can also be excluded, e.g. myvoipproider.com or myvoipproider.net, either as an exact match, or partial match via regex.
Then in Pi-hole’s System settings, I flushed the logs to start afresh. Now the Top Lists and Query Log display the items I actually want to see, without all the clutter from the ATA.
The total query counter still registers the “invisible” ATA queries, but at least I don’t have to wade through them.
Of course, but if SSH is turned off, it’s behind the Starlink NAT and the it doesn’t accept https log from outside the internal LAN, how vulnerable is it?
I am not intimately familiar with this exploit but I think you are missing the point.
There is a serious vulnerability in the ASUS device (some set of models).
The vulnerability is allowing the device to be taken over (arbitrary command execution).
The fact that the current way of utilising that is to enable SSH in the ASUS router is neither here nor there. A sophisticated attacker can tunnel SSH through in other ways if SSH is what they want. However you can’t even assume that SSH is all that they want.
Worst case the attacker can probably completely replace the firmware on the ASUS router and then you wouldn’t even be able to turn off SSH.
Risky but maybe. It depends on several unknowns:
Are there any paths from the internet to the ASUS router itself? (This is unknown to me but could be known to you i.e. you know your setup.)
Are there any other ways of exploiting similar vulnerabilities in the ASUS router? (This would likely be unknown to both of us but I would never underestimate the level of motivation and sophistication of an unknown attacker. I see attempted router break-ins all day every day.)
My answer would be: if your model is still supported then apply fix ASAP else pull trigger.
You haven’t clearly explained (that I could see) whether you are using double NAT and/or what the roles are of the two devices.
In any case, your starting point (hypothetically speaking) is to jump on the ASUS router and see what ports it is listening on and for those ports whether it is bound to a specific interface e.g. the LAN interface or to the ANY interface or to the WAN interface or …
In my experience with my own router the code can be very lax about this. YMMV.
As a small amount of comfort, you might run a port scanner from the internet to your outer router’s WAN IP address.
Double NAT, clean port scan and SSH confirmed off from the control panel. I admit, there was some “devil’s advocate” vibe embedded in my question and the answers were largely as expected/deserved.
I’m gonna buy the Omnia. Once it is configured and in service I’ll try to salvage the ASUS with OpenWRT. Never flashed a home router before, so it should be fun. If all goes well, I put the winner in service and still have a great spare.
It’s open source, right?