No ads? Contribute with BitCoins: 16hQid2ddoCwHDWN9NdSnARAfdXc2Shnoa
May 202017
 

I just love messing around with run-time languages that I know relatively little about (and if your sarcasm detector isn’t flashing red about now, take it out and give it a good talking to).

The problem detailed here is something that you are unlikely to encounter unless you get into weird stuff like running an odd-ball window manager, aren’t content with the version of said window manager distributed with your Linux distribution, and are used to re-compiling things from scratch.

It all started when I upgraded Ubuntu on my work machine (to Zesty Zapus). The window manager version was upgraded from 3.5 to 4.0, which broke on my configuration file (3.5); not a big problem I thought, as I had already upgraded my window manager at home to 4.1 and reconfigured the configuration file. I copied the updated configuration file from home into place.

And it failed. Apparently I use 4.1-isms within the file. As I was not happy about tinkering with the file to downgrade it (in a language I know relatively little about), I decided to re-compile Awesome 4.1 instead.

Which failed with a weird error :-

» awesome --version
awesome v4.1 (Technologic)
 • Compiled against Lua 5.3.3 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.4
 • LGI version: [string "return require('lgi.version')"]:1: module 'lgi.version' not found:
	no field package.preload['lgi.version']
	no file '/usr/local/share/lua/5.3/lgi/version.lua'
	no file '/usr/local/share/lua/5.2/lgi/version.lua'
	no file '/usr/local/share/lua/5.3/lgi/version/init.lua'
	no file '/usr/local/share/lua/5.2/lgi/version/init.lua'
	no file '/usr/local/lib/lua/5.3/lgi/version.lua'
	no file '/usr/local/lib/lua/5.3/lgi/version/init.lua'
	no file '/usr/share/lua/5.3/lgi/version.lua'
	no file '/usr/share/lua/5.3/lgi/version/init.lua'
	no file './lgi/version.lua'
	no file './lgi/version/init.lua'
	no file '/usr/local/lib/lua/5.3/lgi/version.so'
	no file '/usr/lib/x86_64-linux-gnu/lua/5.3/lgi/version.so'
	no file '/usr/lib/lua/5.3/lgi/version.so'
	no file '/usr/local/lib/lua/5.3/loadall.so'
	no file './lgi/version.so'
	no file '/usr/local/lib/lua/5.3/lgi.so'
	no file '/usr/lib/x86_64-linux-gnu/lua/5.3/lgi.so'
	no file '/usr/lib/lua/5.3/lgi.so'
	no file '/usr/local/lib/lua/5.3/loadall.so'
	no file './lgi.so'

Which had me stumped for a while, and it turns out that DuckDuckGo didn’t have an obvious fix (one of the reasons for writing this).

Eventually I figured out that awesome was not finding the LGI module (I can be slow at times) which was odd because it was definitely installed. However it turns out that it was installed in /usr/share/lua/5.2/lgi. So despite having lua 5.3 installed, extra lua modules can only be seen if you have lua 5.2 installed?

The “fix” for this was to create an environment variable telling LUA to search for files in rather more places before starting Awesome :-

export LUA_PATH="/usr/local/share/lua/5.3/?.lua;/usr/local/share/lua/5.2/?.lua;/usr/local/share/lua/5.3/?/init.lua;/usr/local/share/lua/5.2/?/init.lua;/usr/local/lib/lua/5.3/?.lua;/usr/local/lib/lua/5.3/?/init.lua;/usr/share/lua/5.3/?.lua;/usr/share/lua/5.2/?.lua;/usr/share/lua/5.3/?/init.lua;/usr/share/lua/5.2/?/init.lua;./?.lua;./?/init.lua"

This was created by running lua from the command line and running print(package.path) to display the default setting, and adding the 5.2 equivalent for many elements.

As to whether it works or not, well I cannot be sure (I’m not going into work on a weekend just to check if the window manager fires up), but Awesome itself seems happy with the result :-

» awesome --version
awesome v4.1 (Technologic)
 • Compiled against Lua 5.3.3 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.4
 • LGI version: 0.9.1

So it can find LGI, but whether it can do anything useful with it remains to be seen!

May 172017
 

It may not be very funny, but the funny thing about WannaCrypt is that it is somewhat of a failure! Unless the authors are spectacularly stupid (not entirely impossible incidentally), they have no way to recover their ill-gotten gains. The pile of looted bitcoins they have acquired is fully visible, so any attempt to use those coins will almost certainly result in them being tracked down – they have attracted too much attention.

Which is another aspect of the WannCrypt malware – it has highlighted the vulnerability (MS17-010) and caused a huge vulnerability hunt. Which is causing those who wrote other malware (such as Adylkuzz) to gnash their teeth, because otherwise their malware would have quietly worked away in the background. The malware authors behind Adylkuzz have probably made more money than the WannaCrypt malware authors … and may well get away with their loot too.

Which is why other malware authors “wannacry” – the attention that WannaCrypt has gotten has ruined MS17-010 for them.

May 172017
 

It seems rather strange when you discover it, but Windows Update sometimes lies about what updates have been installed. I am not sure how often this happens, but it does happen from time to time. Which with WannaCrypt rampaging around is somewhat unfortunate.

What seems to happen is that Windows Update gets confused about what patches it has installed – it’s internal database gets corrupt. One possible fix for this is to remove the database :-

net stop wuahuserv
cd %systemroot%
ren SoftwareDistribution SoftwareDistribution.old
net start wuauserv
rd /s/q SoftwareDistribution.old

When using Windows 10, you may well have to start (net start wuahuserv) Windows Update services before stopping them. Once you have removed the directory, the next time you run Windows Update in the gooey, it will spend some time rebuilding it’s database and hopefully will then pick up the missing updates. No promises but this worked on at least one server that had unacknowledged missing patches.

Of course without a proper vulnerability scanner it may be tricky to determine when Windows is lying about being fully patched. The best bet is to assume it is lying whenever something like WannaCrypt comes along.

The other possibility is to look into something like Autopatcher which is intended for offline updates – you can download the Microsoft updates and use the tool to patch Windows computers from the downloads.

Apr 302017
 

Despite how long I have been running Windows in virtual machines (as far back as Vmware Workstation 1.0), I have never gotten around to looking at the virtio network interface – except for naïvely turning it on once, finding it didn’t work, and turning it off – so I decided to have a look at it. I was prompted to do this by a suggestion that emulating the NIC hardware as opposed to simply using a virtual communications channel to the host would hurt network performance. Good job I chose a long weekend because I ran into a few issues :-

  • Getting appropriate test tools took a while because most of the tools I know of are very old; I ended up using iperf2 on both the Linux main host and the Windows 10 guest (within the “Windows
  • The “stable” virtio drivers (also called “NetKVM”) drivers didn’t work. Specifically they could send packets but not receive them (judging from the DORA conversation that was more of a DODO). I installed the “latest” drivers from https://fedoraproject.org/wiki/Windows_Virtio_Drivers. Note to late readers: this was as of 2017-04-30; different versions may offer different results.
  • Upgrading my ancient Debian Jessie kernel to 4.9 on the off-chance it was a kernel bug turned into a bit of an exercise what with ZFS disappearing after the upgrade, and sorting out the package dependencies to get it re-installed was “interesting” (for small values of course). No data loss though.

I ran two tests :-

  1. sudo nping –tcp -p 445 –count 200 –data-len 1280 ${ip of windows guest) – to judge how reliable the network connection was.
  2. On the Linux host: sudo iperf -p 50001 
  3. On the Windows guest (from within the Ubuntu-based environment): sudo iperf -p 50001 -c ${ip of Linux host}
Device nping result iperf result
Windows guest (virtual Intel Pro 1000 MT Desktop 1 lost 416 Mbits/sec
Windows guest (virtio) 0 lost 164 Mbits/sec
CuBox running ARM Linux n/a 425 Mbits/sec

Which is not the result I was expecting. And yes I did repeat the tests a number of times (I’ve cheated and chosen the best numbers for the above table), and no I did not confuse which NIC was configured at the time of the tests nor did I get the tests mixed up. And to those who claim that the use of the Ubuntu environment screwed things up, that appears not to be the case – I repeated the test with a Windows compiled version of iperf with much the same results.

So it seems despite common sense indicating that a NIC “hardware” custom designed for a virtual environment should perform better than an emulation of a hardware NIC, the actual result in this case was the other way around. Except for the nping result which shows the loss of a single packet with the emulated hardware NIC.

Apr 062017
 

One of the possibilities when setting a password is to use non-ASCII characters, such as ¨þ¨ (that is a thorn). Well perhaps something a little more secure than just a single character.

But just how sensible is it?

The first thing to bear in mind is that you need to be able to enter the password reliably in all circumstances. A tale from the mists of time: I once set a root password on a Unix machine that included the ¨@¨ character, which normally worked fine but failed on the system console because on that terminal the old Unix tty was still active and ¨@¨ would erase a line, making it impossible to enter the password.

Fortunately I realised what the problem was before it became more than a little annoying.

But the point still remains – if you cannot type a password, you cannot authenticate. So for passwords such as firmware passwords, system encryption passwords, or normal computer account passwords, a password containing Unicode characters is probably a very bad idea.

But for when you have full control over your computer(s), such as for web account passwords, a password containing Unicode characters is worth considering.

So how safe is a password containing a Unicode character anyway? Well, on my usual password cracking machine, john the ripper is unable to crack the password ¨þ¨ in approximately 24 hours. Of course that is a bit of a cheat as john the ripper does not by default check Unicode characters, and if it did it would be able to crack a one character password. But it would take longer; adding Unicode characters increases the space that john the ripper needs to search in order to find your password.

And perhaps more importantly makes it less likely for a password guesser (Hydra for example) to be successful.

So if you normally use a password such as thistlethinthorn, changing it to þistleþinþorn is worth considering. Or indeed changing the separator between words in a multiword password to a Unicode character: thistle☠thin☠thorn, or red¡whistle¡wheel.

Apr 032017
 

Since getting a HiDPI screen, I have been plagued with claws mail merrily doing the right thing with proper emails, but showing HTML emails at a tiny size.

Whilst it doesn’t appear to be a preference you can change in the normal way, there is a zoom variable you can change within the Claws preferences file. Quit claws, and edit ~/.claws-mail/.clawsrc and scroll down through the file until you find the “[Fancy]” section :-

[fancy]
enable_images=1
enable_remote_content=1
enable_scripts=0
enable_plugins=0
open_external=1
zoom_level=100
enable_java=0
enable_proxy=0

Change the “zoom_level” to a suitable percentage (such as 200).

Mar 182017
 

The TiPro programmable keyboards are quite fun for those who are into their keyboards, but with one big problem: the programming tool is Windows only. Well at least if you happen to have a USB-based TiPro; otherwise you need to set up the serial interface as the PS/2 interface is only usable for programming with a 32-bit Windows.

As it turns out, if you try to run it under a virtual machine and assign the USB device of the keyboard to the virtual machine, it still fails – somehow it doesn’t like staying assigned to the virtual machine. However there is a fix for this – using the command-line VirtualBox tools to set up a permanent USB filter.

To assign, first of all determine the name of your virtual machine with :-

VboxManage list vms

Next, add a USB filter – you can normally assign it to “slot” (or index) 1, but you may have to check what slots are available if you already do this :-

VBoxManage usbfilter add 1 --target "W10" --name TiPro --vendorid 0x1222 --productid 0xfaca

Once that is done, the Windows tool should be able to find the keyboard to start programming it. If necessary, reboot the virtual machine or try assigning the USB device via the menu option.

During programming it is helpful to remember than raw USB HID codes can be used by right-clicking in the input field for a key, selecting “Text Input” and inputing the code in the form “/${hex hid code} ${hex hid code}\” – such as “/69 69\” (a list can be found at: http://www.usb.org/developers/hidpage/Hut1_12v2.pdf)

Removal at the end:

VBoxManage usbfilter remove 1 --target "W10"

After the removal it seems that disconnecting and reconnecting the device is necessary for Linux to pick it up (or possibly a udevadm trigger).

b

Feb 272017
 

Strictly speaking how some cloud services do mail wrong, but whilst it is not all, there are still quite a few that do which is why there are no names contained within this rant.

When you have some cloud-based service send email, it makes sense for the “From” header (i.e. what sensible normal people think of as the sender address) to contain the email address of the person using the cloud-based service.

Fair enough.

But if the real sender address or envelope sender address (which is contained within the SMTP transaction) comprises the email address of the person using the cloud-based service you may well run into problems. Many organisations publish an SPF record in their DNS to indicate what network addresses are approved for, and many mail servers check the envelope sender against the published authorised network addresses.

If the network address used by the cloud service provider does not match what is in the organisation’s SPF record then the recipient’s mail server is free to reject the mail. And they often do.

Now the most obvious “fix” for this is to add the cloud service provider’s network address to the organisation’s SPF record.

The only trouble with that is that it isn’t always possible. There are various limits to how long an SPF record can be so adding addresses to the SPF record recklessly is unwise, and a sensible DNS administrator will only add to the SPF record for important services. So if the cloud service is being evaluated or being used by something less important, or is being used for non-work related purposes, then it likely won’t meet the “important enough to get added to the SPF record” criteria.

So why not fix the source of the problem?

All that has to be done is to use a different address for the envelope sender, and you can even arrange things to send bounces back to the right place.

Set the envelope sender to something like “customer+${original email}@${cloud service address}” (obviously when replacing the ${original email} you will have to change the “@” sign to something reversible). All of a sudden you are no longer “forging” the envelope sender, and not tripping over anyone’s spam defences.

Process the bounces to “customer@${cloud service address}” and you can send the bounces to the right place.

Feb 122017
 

A very long time ago, I used to collect spam in order to graph how much spam a single mail server was likely to get over time, and almost as long ago, I lost interest in maintaining it. As a consequence I still get a ton of spam every day and after a long period of procrastination I have been slowly raising defences against spam.

This particular recipe is not really a defence against spam – it verifies that the remote server is properly DNS registered with a reverse DNS registration – in other words that the IP address it is connecting from is registered. This is a requirement for all mail servers, and as it turns out, spammers don’t care for registering their servers in the DNS.

This ACL snippet goes into the ACL for checking the recipient or for checking the message :-

 deny
   message = Your mail server is not properly DNS registered
   log_message = BLOCKED: No rDNS
   condition = ${if eq{$host_lookup_failed} {1} {1}{0}}
   # Check rDNS and block if not registered

There are three items of interest :-

  1. The message is intended to be easily read by recipients to determine what the problem is. It turns out that many people do not read NDRs, but if we get the message right at least we are doing the right thing.
  2. The log_message is intended to make automating log parsing easier.
  3. Within the condition, the $host_lookup_failed variable indicates that the reverse DNS lookup returned NXDOMAIN and not that it timed out (which would be $host_lookup_deferred).

That’s all there is to this little piece of configuration.

Feb 082017
 

One of the things that come up whenever IPv6 is mentioned on certain news sites, is that there are people out there who think that NAT solves all of the address size problems and doesn’t have any negatives. I could present a whole series of blog articles on why NAT is the work of the devil, and presents a clear and present danger to life, liberty, and the pursuit of happiness (I might be exaggerating just a touch here).

The naive approach to a security issue originating from a certain network address is to block that network address permanently, pending an appropriate response, or temporarily. Not a bad idea although it does resemble a game of hunt the wumpus, and to assist in this, there are community based collective blocklists.

But what happens when you block an address, and that address is the public address of a NAT device? You block everyone sharing that public address, which could be just a household or it could be thousands of unconnected people. For instance, I have up to 32,000 people behind a handful of public IP addresses.

And yes I do regularly see problems where blocks have been put in place, and from what I can see this is a problem that is widely shared amongst people who NAT.

And once you are blocked in this way, you may be able to get it removed if you manage to identify which blocklist you are on, stop the network abuse and it has a well-run mechanism for removal. Most blocklists (including the ones I run) don’t work this way.

Every IP address has a reputation associated with it, and if you share a public IP address that has a poor reputation, parts of the Internet will disappear for you, and these include some well known services.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close