Hacker's ramblings

My home Linux box is always on and to make sure it stays on I have an uninterruptible power supply for it. APC is very well supported in Linux by open-source apcupsd. Pretty much all other UPSes are supported by NUT, but for some strange reason APC has a separate project.

Update 20th May 2018: There is a new post about APC UPS batteries here.

Couple days ago the UPS started to beep. My house had electricity and there was no apparent fault. Except that I got an e-mail from apcupsd "UPS battery needs changing NOW". Aow crap! The batteries had reached their end of life. I confirmed the status with apcaccess and got status of:
STATUS : ONLINE REPLACEBATT NOBATT

Every 12 hours, the UPS releases a burst of beeps and I find that very annoying. It was time to go shopping for new batteries. Luckily my unit uses Replacement Battery Cartridge #7, which is popular and generally well available and the price ~200 € isn't too bad. The next thing is to get the old ones out and new ones in. APC user's manual says that battery pack is hot-swappable, so it should be an easy thing to do. Apparently the first thing to do is remove the front cover:

It has nice holes on the sides. I guess the idea is to put your fingers into them an pull hard.

When the front cover is loose, a ribbon-cable and a metal cover is revaled.

There are two phillips-head screws to hold the metal cover in place:

When the metal cover is removed, the battery pack is visible:

There is a plastic tab at the bottom. I guess it is there, so that batteries can be pulled out. Now that the metal cover is removed, the batteries are not attached to anything:

The final thing to do is to disconnect the battery pack:

Now the UPS keeps beeping a lot. It is annoyed by the fact, that it cannot find a battery. Since I don't have any original APC software on my computer I found out that the audible beep can be silenced. First make sure that the apcupsd is not running:
systemctl stop apcupsd.service

Now the apctest can be used to change any of the UPS-parameters:

Current alarm setting: ENABLED
Press...
 E to Enable alarms
 D to Disable alarms
 Q to Quit with no changes
Your choice: Select function: d

New alarm setting: DISABLED

Now there is the blissful silence. It is much nicer to operate with the new battery pack.

Obviously the idea is to reverse the instruction. Connect the new battery, slide it in and tighten the screws and attach the front cover back.

I guess, the new battery should last at least 3 years before I'll be getting a completely new UPS. There simply is no point in running a really old UPS with brand new batteries. I guess the UPS technology will still evolve so that a new tech is required after half a decade.

Today, this tuesday, is the last time Windows XP gets security updates from Microsoft. Apparently Dutch and UK governments are willing to pay seven figure sums per year to keep their XPs running, but the rest of us, anything smaller than a government we don't get to have those. Last autumn I visited Windows 8.1 release in Helsinki and there a Microsoft MVP said "Microsoft is not that evil company, they just might release something really critical if it comes down to that". There was some chuckling in the crowd. Anyway, very interesting things will happen to XP, see the CVE-list for non-fixed flaws.

In Finnish media, the XP has gotten a lot of media coverage all year. I guess it got to the point of scaring regular users in the national TV. This I figured when my mother called me about her Windows 7. The another thing was at my neighbor's computer. She has an old XP-box with really poor specs. She asked for my help, but after initial assessment there was nothing I could do with her old computer. I happened to have an old Dell OptiPlex GX260 desktop computer with steroids, a SSD-drive in a ATA-to-SATA -adapter. I was about to do the decent thing and comply with EU 2002/96/EC directive, aka. throw the electronic junk where all electronic junk ends up at. The computer has only 512 MiB memory, but given the 2,0 GHz Pentium 4 CPU, it runs 2009 released Windows 7 in a reasonable acceptable manner. The best part for my neighbor was, that I promised to donate the hardware free of charge. It was only a matter of getting a license key for Windows 7.

My old OptiPlex booted from installation DVD without problems, I must say I was amazed about that. Any old low-quality CD/DVD-drive typically has issues with dust in the lens and the read head eventually deteriorates to the point, that the drive refuses to read anything. Anyway, the Windows 7 installer found the SATA-connected SSD-drive, the installer copied the files, booted for the initial Out-Of-the-Box-Experience. Everything seemed to be ok, I had network connectivity and even some sound.

What every legacy PC does after install is, that the display resolution is something unbelievable. This case I had a VGA 640x480. It sure looked nice on my 22" LCD-screen!
The thing is: no W7 drivers for my Dell. It seems to have a built-in Intel 82845G graphics adapter in it. The Dell support knows about my machine and the display driver in its Download Center, but the latest supported OS they have is Windows XP. WDDM driver model was introduced in Vista and XDDM drivers was the last one Intel ever did for 82845G. This was confirmed in Microsoft TechNet's Windows 7 IT Pro forums discussion How do I get Windows 7 Graphic driver for the Intel 82845G Graphics Controller?

Lucky for me, somebody had posted a link to another article For Older Hardware to Run on Windows 7 How to Install intel 82845G graphics driver on Window 7, and there was a solution for my exact problem. I didn't realize that it was possible to still use XDDM drivers, but it is possible. In device manager, there is a Add Legacy hardware:

I took the 82845G driver package 14.10.3, unzipped it and Windows 2000 XDDM driver installed. After rebooting the Windows 7, everything was ok. The driver actually claims it can go up to 2048x1536, but given the analog VGA-connector I chose not to go that far.

Finally, I installed Microsoft Security Essentials into it and I was done. My neighbor had a nice "new" computer till year 2020. I'm wishing people would upgrade before that, but knowing that doing nothing is always the preferred action on non-hackers, so plenty of people will be taken by surprise when Windows 7 updates run out.

Us server guys are becoming a rare breed. Any server-related tasks can be outsourced to any free-of-charge cloud service provider. One very good example of that is e-mail, nobody runs their own mail server nowadays. Companies are using external services and any regular Joe and Jane have gone for Gmail years ago. However, once in a while something funny happens and people want a NSA-free e-mail account.

The fact is that every Linux-installation has a mail server installed and running in it. The purpose for the mail server is to deliver local in-server mail to user(s), also depending on your Internet-connection it may be possible to send outgoing mail to the wild wild Net. Most ISPs block this due to excessive spamming from consumer's computers.

Setting up a receiving Postfix MTA is outside of this blog post, but my idea is to present you configuration help to:

1. Configure Postfix to tunnel outgoing e-mail via you ISP's SMTP
2. (optional) Redirect root's e-mail to an external mailbox
3. (optional) Increase mail transport security by using TLS encryption for e-mail
   

So ... here goes.

Configure Postfix to tunnel outgoing e-mail via you ISP's SMTP

To fight spam most (all reasonable) ISPs have blocked outgoing TCP/25 traffic. This very effectively makes your computer not being able to inject new e-mails into receiving servers. Because of this, for example Google instructs users to use TCP-ports 465 or 587 instead, see their setup instructions.

For a mail server (like your Postfix), that is not a solution. Your box must be able to deliver e-mail to any server's TCP/25. All ISPs I've ever seen share a SMTP-server for their customers. The idea is to route all your external e-mail to that server, it will relay the e-mail to the final destination. Remember, that as a spam prevention measure, the amount of mail you can send via ISP's SMTP is limited. For example my ISP has a 50 e-mails per hour policy. It simply refuses to serve any excess requests based on IP-address of the sender.

The subject of routing outgoing e-mail is covered (among many others) in this article with title Configuring postfix to forward all email to a smtp gateway. All you have to do is add:
transport_maps = hash:/etc/postfix/transport
into your Postfix's main.cf. Typically there is a transport-file, but it does not contain your ISP's configuration in it.

Example:
My ISP TeliaSonera Finland has a SMTP running @ mail.inet.fi. Initially I had following line in my transport-file:
*         smtp:mail.inet.fi

But it didn't work! Looking into source code src/trivial-rewrite/resolve.c reveals that Postfix keeps resolving the address via MX-record. The correct one will be:
*         smtp:195.156.147.15

This setting will skip any resolving of the given address and use the given IP-address as-is.

Test the setup by sending e-mail to one of your own external addresses. It can be achieved by running something like this:
date | mail -s "Testing outgoing mail" test@user.at.somewhere

Confirm the functionality from Postfix's log, it should read something like this:

postfix/pickup[12869]: D13F8209AF: uid=0 from=<user>
postfix/cleanup[13427]: D13F8209AF: message-id=<20140407161546.D13F8209AF@my.linux.box>
postfix/qmgr[2185]: D13F8209AF: from=<user@my.linux.box>, size=482, nrcpt=1 (queue active)
postfix/smtp[13429]: D13F8209AF: to=<test@user.at.somewhere>, relay=195.156.147.15[195.156.147.15]:25, delay=0.35, delays=0.06/0.01/0.04/0.24, dsn=2.0.0, status=sent (250 <529734CF0ADA3B46> Mail accepted)
postfix/qmgr[2185]: D13F8209AF: removed

It clearly says "Mail accepted" and Postfix's queue manager eventually removes the outgoing mail from outgoing queue. Remember to confirm, that the mail landed to the external mailbox.

Redirect root's e-mail to an external mailbox

A good starting point is to look at /etc/aliases. For example OpenSuse has this in it:

# It is probably best to not work as user root and redirect all
# email to "root" to the address of a HUMAN who deals with this
# system's problems. Then you don't have to check for important
# email too often on the root account.

So, I put this into my aliases:

root:           test@user.at.somewhere

There is a catch ... Having that in /etc/aliases won't work for your system's internal e-mails. Now that your box is not a receiving mail server, all of you mail is internal. You can confirm the non-functionality by:
date | mail -s "Testing outgoing root mail" root

Your maillog will read something like in the previous example. Mail will be routed to your ISP's SMTP, but the problem is, that the e-mail address is wrong. It will read root@your.server.name, your ISP does not have a clue what to do with such a mail, and it will bounce back. Now that your server cannot receive mail, the bounce will be dropped and is lost.

There is a fix for that. The two articles of Rewriting to address on postfix local aliases and Postfix masquerading or changing outgoing SMTP email or mail address will contain clues how to do it. I added following line into my main.cf:
smtp_generic_maps = hash:/etc/postfix/generic

The /etc/postfix/generic will read:
root@your.server.name        test@user.at.somewhere

Postmap the transport-file, reload the postfix-service and test again. Now Postfix will re-write the outgoing e-mail properly as planned. The re-write can not be confirmed from the maillog, it will display the original root@your.server.name in there. However, on the receiving end the e-mail address will be correct.

Increase mail transport security by using TLS encryption for e-mail

The last item on my checklist is to start encrypting the mail. Note that this is pointless if your ISP does not support encryption. If it does and your Postfix is not configured to use encryption, you will get a lot of "warning: no entropy for TLS key generation: disabling TLS support" in your maillog.

As a prerequisite, you will need a SSL-certificate. Any certificate will do, even a crappy self-signed one. I'd never recommend using self-signed certificates, but if you're lazy and don't want to get a free one from the net, go for the path of least resistance. This is what I have in main.cf:

# SSL/TLS
# SMTP (sending)
smtp_tls_security_level = may
smtp_tls_key_file = /etc/ssl/private/the.certificate.key
smtp_tls_cert_file = /etc/ssl/certs/the.certificate.cer
smtp_tls_CApath = /etc/ssl/certs

To confirm that TLS is being used will look like this on received e-mails headers:

Received: from mail.inet.fi ([2001:15d8:172::]) by
 mx.google.com with ESMTPS id 1si12730620lam.174.2014.04.07.09.57.37 for
 <test@user.at.somewhere> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256
 bits=128/128); Mon, 07 Apr 2014 09:57:37 -0700 (PDT)
Received: from your.server.name ([172.16.141.138])
 (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested) by mail.inet.fi (Postfix) with
 ESMTPS id E75004355F for <test@user.at.somewhere>; Mon,  7 Apr 2014 19:57:35
 +0300 (EEST)

Notice how both servers specify the TLS cipher used. In this case Google's server uses only 128-bit encryption.

Note:
You don't need to enable tlsmgr in master.cf for any this to work. I've seen incorrect instructions about that. To repeat: For sending TLS-encrypted e-mail having tlsmgr is not necessary.

An active contributor for this blog, Mr. nos_com71 was kind enough to notify me about a firmware he found. It is from Polkomtel, a Polish telco. You can download the package from this link @ Norton Zone cloud. I had issues with the download, but using a different browser on another machine solved it for me.

I didn't install the firmware into my s-12, but as usual, I extracted it and confirmed its contents and version of V100R001C69SP103, which is quite new. In the Bjørn Grønli's spreadsheet the newest one he found is a SP102, but this Polish one seems to be a notch newer.

If any of you test this one out, please tell us about it.

One day I came back to my computer and saw a firewall notice about netsession_win.exe requesting access to listen UDP-requests.

Ok, I thought, that happens sometimes. An application needs permission to access The Net. This time it was a permission to receive traffic. Wait a minute! I don't remember installing anything that would require building a server on my box.

Apparently I'm not alone with my question, Mr. Scott Hanselman at CSI: My Computer - What is netsession_win.exe from Akamai and how did it get on my system? is pondering the same issue. He chose to keep it running, I chose not to.

Reasoning:

• I confirmed the facts from Mr. Hanselman blog post: the Akamai signature in the binary is valid, at least it looks like a valid one to me. This alone is definitely not a reason to kill the app.
  
• I don't know any purpose for such an application.
  
• A server binary is located at my %LOCALAPPDATA%, definitely not the place for a piece of server software to be running from.
• Anybody who installed the application and made it run did not ask for my permission for doing so.
• The application will run on each login based on a registry setting placed into HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run Mr. Hanselman located a service in his computer. My computer did not have that. I still don't like unknown applications to run all the time.
• It does not feel legit to me. All these combined make the application shady and it gives me chills.
  

Guys at Akamai:
This is not the way to do it! Revise your policy of putting spyware into people's computers.