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.
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
As the subject says, this blog has been offline for just over a week because of a hardware failure. Just when I wanted to moan about all the GDPR hissy fits that people are throwing.
Noticed some websites are blocking you because of the GDPR?
That’s the hissy fit. Seems that some international web site operators who previously assumed that GDPR didn’t apply to them, are suddenly realising that it does. Which is an indication that they have been impersonating an ostrich for a couple of years now.
Smaller businesses get a free pass on that one, but any reasonably sized company should have been aware of GDPR by now. It was put in place and deliberately put on hold for two years to allow people to get started with complying with GDPR. Anyone involved in the security business has been hearing “GDPR” for over two years now.
So there are those who claim they’ve not heard of it, and are now panicking and trying to catch up, making a mountain out of a molehill, and claiming that it’s a dumb law. Technically it isn’t actually a law but an EU regulation that member states are required to make law.
Anyway onto some of the biggest arguments against the GDPR …
The Whois Question
This is a great example of what happens when you ignore a situation and then panic.
When you register a domain (such as zonky.org) or a netblock (a set of IP addresses), you are expected to provide contact details for the individual(s) involved in the registration process – to allow for billing, and contact to be made in the event of operational issues.
Storing that information is perfectly reasonable.
Publishing that information is perfectly reasonable given informed consent.
Ideally the domain registration would offer a choice to the registrant – public listing of personal details, public listing of role contact information, or public listing of indirect contacts (i.e. keeping the contact details private).
There is a German court case decision saying that it isn’t necessary to have contact information for registering a domain; all I can say is that the German court obviously didn’t have the full facts.
GDPR’s “Right To Be Forgotten”
One of the misconceptions is that the “right to be forgotten” is an absolute human right; for a start it’s not a a human right, but a right under the law. And it is not absolute; the text of the GDPR includes numerous exceptions to the right to be forgotten, such as :-
A legal or regulatory obligation to keep the personal information.
An overriding public interest.
Ongoing legitimate business processes still require that personal information.
The key is that if you are an ethical business (in particular don’t plan to sell personal information and/or keep spamming people) then the right to be forgotten isn’t anything to worry about.
GDPR: The Fines
The strange thing is that there is doubt over the level of fines that can be levied under the GDPR which is remarkable as the language is quite clear – the lower level of breach can be fine of up to either €10 million or 2% of annual turnover.
Or to put it another way, for the lower level of breach, the maximum fine is whichever is greater €10 million or 2% of annual turnover. The maximum.
Do you know how often the ICO has imposed the maximum level of fine under existing legislation? Never.
The Jurisdiction Issue
Now here there is some legitimate grounds for grievance; after all whenever the US starts imposing its laws outside of the US, people outside the US start jumping up and down. And yes, the EU does expect non-EU companies to obey the GDPR regulation if they store data on EU citizens.
In practice, the EU isn’t going to try going after small companies outside the EU; particularly not small companies that are just ordinary business and not engaged in Cambridge Analytica type business.
The other way of looking at the global reach of the GDPR is whether it would be a good idea for there to be a world-wide law in relation to the protection of personal information. The Internet means that world-wide laws are necessary in this area, or those abusing personal information will merely move to the jurisdiction with the weakest protection of personal information.
Of course doing this command-by-command is a little tedious, so a more permanent solution is to re-enable all the supported key exchange algorithms. The relevant algorithms can be listed with ssh -Q kex, and they can be listed in the server-wide client configuration in /etc/ssh/ssh_config :-
According the OpenSSH developers, the latest version of ssh are refusing to use certain key exchange algorithms (and other cryptographic ‘functions’).
Their intention is perfectly reasonable – by default the software refuses to use known weak crypto. I’m fully behind the idea of discouraging the use of weak crypto.
But the effect of disabling weak crypto in the client is unfortunate – all of a sudden people are unable to connect to certain devices. The developers suggest that the best way of fixing the problem is to upgrade the server so that it supports strong cryptography.
I fully agree, but there are problems with that :-
Some of the devices may very well be unsupported with no means to upgrade the ssh dæmon. Now in an ideal world, these devices wouldn’t be on the network, but in the real world there are such devices on the network.
Some devices may not be capable of being upgraded because of processor or memory limitations. Network switches are notorious for having slow processors and tiny amounts of memory, and it is entirely possible that such a device would not be capable of running more exotic and modern crypto. Similarly lights out management processors are often severely limited.
Even if a device is capable of being upgraded, there are the standard problems – the vendor may be slow at releasing updates, change control gets in the way, and lastly resourcing may be an issue – upgrading several hundred switches manually with just one or two people doing it is not going to be a quick job.
Lastly, whilst security is important, breaking things just to make a point is a little extreme. Whilst it is possible to fix the problem, it is something that isn’t immediately obvious to someone who doesn’t routinely configure ssh. And someone, somewhere has had this breakage occur just before they really need to fiddle with a switch Right Now.
There is a far better option available – leave the weak crypto enabled, but warn noisily about its use :-
WARNING!!!!! (2 second delay)
WARNING!!!!! (2 second delay)
The device you are connecting to only supports known weak crypto which means this connection
is subject to interception by an attacker.
You should look at upgrading the device as soon as possible.
Telling people what is wrong noisily and continuing to work is far better than simply breaking with a rather terse message.