Lock It Down or Get Bricked

[D-Dan]

To respond, yes, I’m probably over-protective of Linux systems. And I accept that the manufacturers are probably more at fault than the users. However, a majority of users are using Linux (Android), and whilst Google do a better job than most, there has to be some responsibility for device security on the user. I would much rather see that security exposed to the end user (as has been highlighted) and at the very least, a first time prompt to set a unique password.

Arch Linux, on a Ryzen 7 1800X, 32 GB, 5 (yes -5) HDs inc 5 SSDs, 4 RPi 3Bs + 1 RPi 4B - one as an NFS server with two more drives, PiHole (shut yours), Plex server, cloud server, and other random Pi stuff. Nice CoolerMaster case, 2 x NV GTX 1070 8GB, and a whopping 32" AOC 1440P monitor.

[Ed P]

An example where the user never gets an opportunity to set a password is given by this DVR exploit. (Luckily not one that seems to affect the UK). This one looks to be unfixable unless the DVR owner has registered their equipment.

[Richard]

I am not sure which versions of the TP-Link router people are using but this is a warning about some versions,

http://www.theregister.co.uk/2017/04/10/tplink_3gwifi_modem_spills_credentials_to_an_evil_text_message/

Sorry it is a long link that splits.

Richard

[Richard]

Ed P wrote:

An example where the user never gets an opportunity to set a password is given by this DVR exploit. (Luckily not one that seems to affect the UK). This one looks to be unfixable unless the DVR owner has registered their equipment.

Quite; surely this a prime example of the sort of stuff that should not be allowed to connect anywhere near any sane user’s internet connection? I assume that it could benefit from some form of front end processor as an external gatekeeper to hide its existence.

[Author]

Posts