Just set up a UDM pro to replace a really old Cisco 881W and had some initial thoughts on it :-
The firewall configuration is more than a little clunky; the version I was using still seems to require the legacy interface to configure IPv6 firewall rules. Plus configuring a set of IPv4 rules and a seperate set of IPv6 rules added to the clunkiness – why not allow tcp any to ${addresses} eq ssh rather than repeat the same rule with different address types? Anything to keep firewall rule sets simple is good (but I deal with another firewall that has over 200 rules).
Whilst we’re on the subject of the firewall, it would be nice if the firewall supported the “apps” identified in the traffic management; not really an easy thing to do, but a firewall relying on port numbers is a bit 1990s to those of us used to next-generation firewalls.
Device identification is just a little bit rough; to be fair I’m using a separate DHCP server. But to identify a Linux container as a Windows PC is more than a little off! I had to check that my virtual Windows 10 machine wasn’t actually running when I first saw this.
The topology diagram is all very well but very boring if you’re not using all Ubiquiti gear. Not everyone is going to replace all their switches just to get this to work straight away – I have three switches not counting the ethernet-over-power devices that also count as switches. It would be handy if the UDM would at least go to some effort to identify third-party network devices.
Oh, and ssh access to the command-line is … confusing. The gooey implies that you set up a password and a username, but it seems that whatever the username you use it really only works with the user root. And the username you supply isn’t contained within /etc/passwd on the device.
Oh! And requiring access to the cloud to generate the first admin (“owner”) account could well be problematic. Apart from the obvious problem of allowing the Cloud admin-level access to a firewall – something the more paranoid may regard as a killer misfeature, what happens if something goes wrong during the creation of a cloud-based account?
And having SNMP mentioned within the gooey but requiring command-line “bodges” (from here) to actually get it running is not acceptable. Strange that such a feature isn’t supported on a network device!
Someone asked me about this – a zsh function which I use to generate random passwords :-
✓ mike@pica» rpass noise
oOg6vsM+V0It4he6US4Xk6DuZPja9okyOpQyUCfW6NQ=
✓ mike@pica» rpass words
patternmaker+meio+tubicolous+misbelievingly
It’s too small and simple for me to classify as “open source” but there’s no harm in sharing the function :-
✓ mike@pica» which rpass
rpass () {
case "$1" in
("noise") dd if=/dev/random bs=1 count=32 status=none | base64 -i ;;
("words") punct=("," "." "<" ">" "/" ";" ":" "-" "+" "=")
onep=${punct[$(($RANDOM % ${#punct[@]} + 1 ))]}
w1=$(shuf -n 1 /usr/share/dict/words | sed -e "s/'.*$//")
w2=$(shuf -n 1 /usr/share/dict/words | sed -e "s/'.*$//")
w3=$(shuf -n 1 /usr/share/dict/words | sed -e "s/'.*$//")
w4=$(shuf -n 1 /usr/share/dict/words | sed -e "s/'.*$//")
echo "${w1}${onep}${w2}${onep}${w3}${onep}${w4}" ;;
("*") echo $1 not understood ;;
esac
}
This is just a simple zsh function with all sorts of little “issues” – not least is that it could at least say “$1 not understood – try ‘words’ or ‘noise'”.
Picture the scene – someone has bought a new service and they want you to “make it work”. And because they’re kind, they virtually toss you a 2,000 page PDF manual.
Somewhere within that manual there is a list of tcp port numbers that the service listens to and access to which is required for functionality. Which is just great if this was the 2000s – it would have made my life back then far easier.
But this isn’t the distant past (in technology terms). We don’t run simple stateful packet filters that can’t distinguish between some application making an API call over tcp/443 and some klutch watching cat videos over tcp/443.
We should be getting application specific rules – that can distinguish between legitimate application traffic and attack traffic. Surely it is not beyond the wit of application vendors to work with the firewall vendors to come up with such rules?
And application vendors who work with the firewall vendors to come up with proper firewall rules will gain a bit of a competitive edge. And in the wake of the SolarWinds breach, customers may be asking about security.
Well mine does (which I would recommend, but I’ve no idea what it is), but I don’t know about yours.
Send me it with some cash in it, and I’ll take a gander.
But …
Just how practical is RFID or NFC scanning anyway? The scaremongers would claim that there are people out there, slapping payment terminals to your bum and siphoning off your bank account.
I know from my own attempts at scanning (and you will know similarly from “tap & pay”) that the distance at which you can read RFID or NFC is normally fairly minimal. Sure you can get antennas which can read at distances of up to 700m, but they tend to resemble those old TV antennas.
Which is kind of obvious for someone trying to be at least relatively stealthy.
And if they do grab details they get to make a single limited payment (even a bank isn’t dumb enough to miss multiple payments) and you’ve probably got a good claim against the bank any way.
So it is pretty unlikely, the damage is limited (and may even be none).
So is an RFID/NFS blocking wallet really necessary? Well if you are in need of a new wallet any way, getting one with that feature makes sense. But it probably isn’t worth throwing away a perfectly fine wallet to get one.
I recently bought a second-hand camera – but this is not specific to photography (but perhaps particularly relevant). The seller threw in an old SD card which was nice of them (although unnecessary for me).
After doing the photo thing with the new-to-me camera, and having carefully replaced the SD card, it occurred to me that I could test a file recovery tool to see if there was any previously shot photos on the card.
Using photorec, I fired it off and came back 30m later – not because it’s particularly slow but I have spent far too much time watching the equivalent of a progress bar, and I would rather get on and do something useful.
By the time I came back, it had recovered in excess of 1,000 images and videos. It turns out to be probably the most boring collection of photos you can imagine – an ordinary collection of family (not your own) photos would be interesting in comparison.
I won’t be including any of those recovered photos here because that would be unprofessional and potentially embarrassing to the camera seller (although they would most likely never find out).
But you can easily imagine how such a recovery could be potentially embarrassing; even distressing. We usually choose whether a photo should be made public or not.
So how do you protect such things from happening? Is it sufficient to format a card in camera?
No it isn’t. Tools such as photorec are designed to recover images from cards where the images have been deleted or when the card has been formatted. Surprisingly enough, formatting a card does not overwrite all of the data blocks on a storage device; it merely replaces the data structures that allows an operating system to find files with a new blank structure.
So what are the solutions to keep your private photos to yourself?
It should be emphasised that this is advice intended to protect you from personal embarrassment; if there are legal or risk to life issues involved, seek professional advice.
The first rather obvious solution is to never give away or sell old cards; if you want to dispose of the cards, destroy them. It is not as if you could recover much by selling them – who wants a 5-year old 512Mbyte SD card?
If you do want to let others use your old cards, then use a special utility to destroy the contents completely; optionally (but nice for the recipient) is to then format the cards afterwards.
If you are using Windows (or macOS although the following Linux recipe can be adapted), then you will need a tool such as SafeWiper. There are those who claim that Windows format can do the job, but I wouldn’t trust it – the “quick format” option is the default which definitely doesn’t erase the data from the disk, and I have not personally checked that a “slow format” really removes the data beyond recovery with normal tools.
Whatever method you choose, check, double-check, and triple-check that the device you are erasing really
The first step under Linux is to identify the block device path to erase. You may well find that your SD card is automatically mounted when you plug it in. So running df from the command-line will give you a device path (/dev/sdb
Note that how we have “USB SD Reader” alongside /dev/sdb and that it’s size is just 4Gbytes. So we have three confirmations that this is the device we want to erase.
To erase it, first we unmount it, run a hdparm command to erase it, and erase it a second time :-
