Apr 012024
 

So I was reading 𝕏 and came across one of those memes showing “Chinese bots” making connections to “open” SSH ports to Internet accessible servers. The suggestion to turn off password authentication in favour of public/private key authentication was certainly a sensible suggestion (on a very simplistic level it effectively makes a very strong “password”).

But the “Chinese bots” thing sort of irritated me a bit, so I decided to trawl my personal firewall logs looking for attempts to connect to my ssh port(s). Even ignoring the IPv6 probes, there were 1251 different addresses probing my network (just one public IPv4 address) in the months of March so far.

Why is this irritating? Because the addresses of the machines attempting to break into a non-existent ssh service here are those of compromised machines. They may be in China, or the USA, Russia, etc. but that in no way betrays who is controlling those “bots”.

Anyway, for some data :-

CountCountry
502,US USA 840 United States
128,CN CHN 156 China
97,KR KOR 410 Korea, Republic of
33,SG SGP 702 Singapore
27,BG BGR 100 Bulgaria
26,RU RUS 643 Russian Federation
22,HK HKG 344 Hong Kong
22,GB GBR 826 United Kingdom
20,DE DEU 276 Germany
16,SE SWE 752 Sweden

And “China” isn’t even in the lead in this case! I have included just the top 10 as a long list of random countries with one or two robots isn’t very enlightening.

The key point here is that the national identity of the compromised host attacking tells you nothing about where the true attacker is from. Russia is quite a likely candidate given it’s status as a rogue nation with a known tolerance for cyber criminals (as long as they co-operate with the state when the state needs their skills), but that is just background knowledge.

Dec 042023
 

Just for fun (I have admittedly a very weird sense of fun), I thought I’d have a look at one of the phishing emails that came into me. I’ll go through this bit by bit, picking out bits that first occurred to me …

Subject: LastPass : Required action needed regarding your account

Eh? Do I even have a LastPass account? I keep my passwords stored somewhere else, but it’s not impossible – I’ve been known to sign up to things just to test them out. Including cloud-based password managers.

But all the same, let’s give it a point on the suspicion scale. Running total: 1.

From: LastPass <yoji-okugawa1975@tg8.so-net.ne.jp>

Well LastPass certainly use a funny looking email domain (the bit to the right of the “@”), but Marketing departments sometimes aren’t aware of how important that email domain really is. On the other hand, “tg8.so-net.net.jp” does look particularly uncorporate, so let us give it a suspicion point.

Running total: 2

On the other hand, it is too easy to fake domains – I could very easily send you an email from the-management@lástpáss.com (and even more subtle equivalents of “a” – “а”, “ạ”, “ą”, “ä”, “à”, “á”, “ą”). And just to demonstrate something that looks identical can actually be quite different :-

In [8]: print(ord('а'))
1072

In [9]: print(ord('a'))
97

Now this isn’t to suggest that you should run your email headers through some Python code, but just that because something looks like lastpass.com doesn’t mean it really is. The next thing that jumped out at me was the body of the email – I may be well trained, but something new and shiny is still distracting :-

Now the first thing that jumps out at me is that red “Confirm my information” box. Screams “click here” doesn’t it? Well don’t click on it! In my email client (something you’re quite likely not using – claws-mail), if I hold the mouse pointed above a link, it’ll tell me where that link goes in the status bar of the client. In this case it shows up as https://tg8.benchurl.com/…. doesn’t look very much like lastpass.com does it? That’s sufficiently suspicious that I’ll award it 3 suspicion points.

Running total: 5

Notice how they don’t add a “Dear ${name}” to the top of the email? Not personally addressing email is ever so convenient to scammers that want to get your details – because they don’t necessarily know your name. That’s a suspicion point all on its own.

Running total: 6

Next note how it tries to rush you … “log in before January 16, 2024”. It’s subtler than many phishing scams, but it’s still trying to rush you. Add another suspicion point.

Running total: 7

There’s further details we could dig into, but that’s more than enough that the Delete button is the only thing this email should attract. That running total? It was just for fun, it’s not intended as a guideline for when to count something as a phishing email.

In the case of doubt, contact the company via other means.

Mar 302022
 

Just set up a UDM pro to replace a really old Cisco 881W and had some initial thoughts on it :-

  1. 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).
  2. 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.
  3. 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.
  4. 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.
  5. 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!

The Bench
Nov 062021
 

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'”.

Jan 032021
 

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.

Seagull Over Sea