Plusnet One Hub, openwrt-21.02.1-lantiq-xrx200-bt_homehub-v5a-squashfs-sysupgrade.bin just installed. I'm just requesting you remove the port 4919 Failsafe is removed from the WAN / RJ11 connection. Thanks.
pfSense blocked 192.168.1.1:41656 to 192.168.1.255:4919 using UDP. I don't use the 192 port range just 10.0.0.1 range which is why it stood out in the logs.
The failsafe mode only listens to connection on the ethernet ports, I cannot imagine how could it listen to connections on the ADSL line.
Unless the pfsense box is sitting between the router and the ADSL connection, I do not understand what makes you think that OpenWrt is accepting connections on WAN interface.
The Plusnet One has OpenWrt which does the ADSL (dial up) and pfSense is the firewall which everything else is attached to. The exact message was:
Feb 13 08:17:17 WAN Block private networks from WAN block 192.168/16 (12004)
192.168.1.1:41656 192.168.1.255:4919 UDP
As far as pfSense is concerned OpenWrt is the WAN.
It’s clearly coming from The Plusnet One running OpenWrt and pfSense isn’t having any of it. Like I say there is no WiFi running, there is an RJ11 cable supplying internet (WAN) and Ethernet going to pfSense, which pfSense is treating as the WAN.
They clearly had a connection established on OpenWrt with the IP 192.168.1.1 which they then tried to connect to pfSense on and failed. The whole network is running on the 10.0.0.1 range (OpenWrt and pfSense) - it must have come from the internet through the RJ11 cable. No other possibility.
To be honest I’ll just modify the source code and recompile. I believe this is the Failsafe code:
So, you are connecting the LAN side of your OpenWrt box to your pfSense WAN side and are now wondering why that gives you a regular 192.168.1.1 failsafe there? Well, it's just the LAN side after all.
As @sumo commented, the pfsense box is seeing those packets on its WAN interface, that is connected to the LAN interface from the OpenWrt router.
There is nothing coming from the ADSL port, it's all on the ethernet port.
It should also be noted that the packets being picked up (i.e. to 192.168.1.255:4919) are broadcast packets to the entire 192.168.1.0/24 subnet (the default for OpenWRT) to notify that a button needs to be pressed on the router if you want to enter failsafe mode. They're notifications, not attempts to connect to anything.
Thank you. The OpenWrt router is set to a static 10.0.0.1 IP, with DHCP set to run between 10.0.0.100 to 10.0.0.110. pfSense gets its WAN IP from this range. So how did it manage to get the 192.168.1.1 range? More to the point, nobody is really answering why it randomly rebooted, or why I have never seen this being logged by pfSense before? Also, since it's been flashed it's not doing it any more. I have had this set up for some time now and would have noticed this before.
Anyway, regardless as to the true cause it's not doing it now - let's just hope it remains that way!
Because that's what the u-boot environment defaults to before the full firmware (and config files) get loaded.
Routers crash. It happens. But there are many reasons why it can happen and without spending a fair bit of time on diagnostics, various testing steps, and seeing config files and logs it's very difficult to say exactly why the crash occurred.
I can't answer why it's not been logged in pfSense before, but assuming the failsafe code is still in the newly flashed image the router will send out a broadcast packet when rebooting. However, it's completely harmless. It has nothing to do with anything on the internet side of the router.
You have some valid points there - it could just be random crashes of the router. However, considering that it hasn’t crashed since it’s been flashed I would rule out hardware, which really just leaves software. Just imagine if Tesla took that attitude... Perhaps it was a buffer overflow with some very unusual circumstances. I get that writing near perfect software is difficult - maybe Rust would help prevent that?
Now that it’s established that it is Failsafe - why is it running every time it starts? Wouldn’t it be best practice to have the router start as normal without Failsafe running and only drop down to Failsafe when it’s unable to start properly? That way the attack surface is significantly reduced.
There's simply not enough information to conclude whether the issue was software or hardware related. The fact it hasn't crashed since being flashed doesn't rule out an intermittent hardware fault. But either way, if it's not crashing on a regular basis (or at all anymore) it's probably not worth spending a lot of time trying to diagnose it.
How is the initial boot environment supposed to know whether or not OpenWRT is going to load successfully?
What attack surface do you think there actually is here?
So on some MIPS based routers one can use:
cat /sys/kernel/debug/crashlog > last_crash_log
to get some information about a crash after the following warm-reboot, sometimes this works and is actually helpful... also not clear whether that still works on 5.N kernels...
Nowadays one would use PSTORE ramoops.
That is rather involved and requires to built a new kernel/firmware image. The beauty of the old method was that is basically was available by default. Well, what can you do....
If you can assign OSI layer 3 IP addresses with Failsafe then there must be a sufficient amount of the embedded Linux OS system running that would allow storage in some form or fashion. I’m pretty sure there are quite a few registers that could be used.
A primitive form of setting a “success” variable initially to false. Upon a successful boot it’s set to true. The next time it starts if success is set to true then normal boot is done, however if it’s set to false then it never completed the boot sequence and it then it runs the Failsafe and tries to continue with boot sequence as it does at the minute.
Surely this has got to be better than exposing port 4919 with Root access Telnet every time Openwrt boots?
Have you managed to actually log into the router via telnet on 192.168.1.1 as root without a password? According to the wiki this packet is really just informing you that if you press any button on the router now you will find your self in failsafe mode (this information can be helpful for routers without or broken LEDs that signal the same failsafe is trigger-able right now period to an observer ). And only after the user pressed a button in the right period will the router actually boot into fail safe mode.
Note how pressing a button means you have or easily could have physical possession of the router, at that point it is game over anyway, no?
The window in which a button press does boot into failsafe mode is also limited to 2 seconds. And as you say, if an attacker has physical access to the device then you have bigger issues to worry about anyway.
And as side note to the OP, failsafe requires squashfs, so if you do not want that available on your router do to your threat model, just use don't use squasfs (assuming your router model allows that).
If I’m reading this correctly and you’re asking about my personal knowledge and ability then all I can say is I can remember using Pumpkin with TFTP access and DD-WRT as far back as the Windows XP days.
As for squashfs, it’s not exclusive to Openwrt - DD-WRT and some Linux live CD’s use squashfs. I fail to see how this is relevant to Failsafe?
Back on topic, the problem is this: Failsafe and a back door look pretty similar to me. There is no need for Failsafe to run each and every time the router boots. On the other hand a back door would require to be run every time the router boots.
I’ve already pointed out how easy it would be to change this. Personally, I don’t think this is a good idea, but I can see that we are never going to agree on this. Running Failsafe each and every time is a bad design which can lead to unauthorised access.
Matum Stabilis
If someone wanted to break into your network then by the time they've got physical access to the OpenWRT device to reset it and activate the failsafe mode they've got plenty of other options to achieve their aims anyway.
Edit: Even if the failsafe method was altered so it only was available after a failed boot it'd be likely that anyone with physical access would be able to interrupt a normal boot sequence in such a way as to trigger that option.
No my question is whether in the current situation you have been able to convert the failsafe signalling to gain passwordless root access to the modem without pressing a button on the router? That would be a backdoor.
Simple, if you build your OpenWrt firmware with a different filesystem than squashfs (probably any read write fs) the failsafe machanism is documented to not work. So not even with pressing a button on the router in the right time window will your attacker/hacker be able to gain passwordless root access via the failsafe mechanism.
Certainly a position to take.
Well unless it runs automatically and always surely the method used to deduce whether to run or not can go pear shaped. But this is open source, if you come up with an elegant way to avoid that (e.g. only offer failsafe access once ofter each coldboot) I am sure people will look at your patches.
As I said your attacker needs physical access to the router (unless you demonstrate successful login as root without password and without pushing the buttons, in which case I agree you would have found a bug) and at that point your better assume your router is already taken over.
So could I convince you to try logging in without pressing a button, please?