AOL are planning to charge for emails. Mass mailers will be able to pay for a higher priority delivery, bypassing the AOL spam filters and ensuring that mail is received directly in the end users inbox.

This is, obviously, a bad thing since spammers will be able to pay a small offset to ensure that their messages are delivered direct to the end users inbox, whilst legitimate messages will face the AOL spam filter gauntlet. Programmes such as this will only see a rise in spam, and a fall in the success rate of legitimate mail being successfully delivered.

Tags: News, Privacy-&-Anonymity, Real-World Issues, Security Policies

Categories: News, Privacy & Anonymity, Real-World Issues, Security Policies

Comments Off

Many people I speak to think that simply because they are on a switched network, they are immune to packet sniffing, a process whereby a computer listens for packets not intended for that address, and logs them, potentially gathering usernames, passwords, and other useful information within network traffic. For example, every time you log into a website which does not use SSL (Secure Sockets Layer), your username and password are transmitted in plain text as part of the HTTP (HyperText Transfer Protocol) request. If another user is running packet sniffing software, this request will get logged for later analysis, which could lead to that user gaining access to the website you visited, under your account.

Packet sniffing was easy on networks connected using hubs, as a hub is a device which sends every packet it receives to every computer connected. This is bad for a number of reasons, including reducing transfer rates due to collisions and unnecessary transmission; if data is not destined for a computer, it would still be sent there. It does, however, also allow for easy packet sniffing; simply set a network card to pass every packet up to the application layer, instead of only those addressed to the specific computer. These can be logged for later analysis.

On a switched network, packets usually go only to the computer to which they are addressed, based on MAC address resolution of the IP. The switch then sends packets to the port hosting that MAC address, and only that port.

So, how is it that switched networks are still vulnerable to packet sniffing, if packets only get transmitted to their destination?

This is where ARP Poisoning comes in. ARP is the Address Resolution Protocol, and maps IP addresses to MAC addresses. In an ARP Poisoning attack, a system sends out faked ARP responses claiming to be the MAC associated with an IP. As such, packets destined for that IP will be sent to the computer doing the ARP poisoning, as they traverse the switch, instead of the real destination.

Using this mechanism, it is possible to redirect packets between a computer on the network to the border router, forcing them to be delivered to a system running a packet sniffer, instead. From here, they can be logged and then sent on to the real MAC address of the router. This is known as a man-in-the-middle ARP Poisoning based network sniffing attack, and is effective against switched networks.

Because this attack is based on ARP requests and responses, which are a local network mechanism, this attack cannot traverse routers or any other level 3 or higher device.

Tags: Network Security, Real-World Issues, Review, Security Policies

Categories: Network Security, Real-World Issues, Review, Security Policies

Comments Off

It seems that Microsoft have released (or, were planning to, I’m on Linux so no way to check this) their patch to the .WMF exploit which has been in the news lately. I don’t know much about this, since it generally doesn’t concern me what Microsoft do with their buggy software, but I thought it was important enough that I should post about it here, such that people running Windows can update as soon as possible. I am led to believe this patch is available through the standard Windows Update mechanism.

Microsoft were originally planning on releasing this patch on Tuesday January 10th, 2006. This is an example of what Microsoft do best, postponing security updates for no good reason. From what I hear, this has been known about for at least 3 months, and probably longer. If a Linux kernel or major application had a similar security issue, this would be fixed in a matter of days, with patches available and all source trees updated. Microsoft, knowing about this for months, are generous enough to release a patch around 4 days earlier than they originally planned.

Microsoft, I have news for you. Security patches are not major PR events. They are not product launches, they do not need to be scheduled and have a big welcome party, just patch your software as soon as you develop the patch (which should be as soon as the software vulnerability becomes known, that is known either by yourselves or known publically).

Don’t wait until this becomes a big media issue; I know there is the “any press is good press” philosophy associated with some large companies, but it really isn’t. The better stories would be the word-of-mouth of those “in the know” about computer security saying “Hey, Microsoft release patches on time. Windows is a stable, secure platform to work on”. Now, everyone “in the know” is running round telling people that Microsoft shouldn’t have waited so long. That is not good press, that is a bad reputation.

For everyone else reading this, I urge you to pressure Microsoft as much as possible into improving their security. If they don’t, there is a simple way you can get the message across to them – stop buying their software. If enough people stop buying, they’ll realise that there is a problem and they might actually do something about it (probably not; they’re Microsoft, they don’t care).

I feel I should note that this article is opinion, mostly. Not everyone sees Microsoft in the same light, such people are what I’d call misguided!

Tags: Operating Systems

Categories: Operating Systems

1 Comment

It is possible, using X11, the graphical system for UNIX and Linux, to display the interface to a program on another user’s X display. In order for this to happen, they have to allow access to their display, which is not the default, but it may be set on certain systems, especially poorly configured multi-user systems.

You can, of course, try this on any system. Simply run the command

xhost +

This removes access restrictions. Now, you can launch X programs as another user on the same machine, or as a user on a different machine, by setting your DISPLAY environment variable. For example, if an X session is running on 10.0.0.5 and access restrictions have been removed, it is possible to run Firefox on another computer, say, 10.0.0.26, and have it display on 10.0.0.5′s screen.

DISPLAY=”10.0.0.5:0″ firefox

Note that you don’t need to log in to 10.0.0.5 over SSH, the X system makes use of port 6000/tcp to communicate between the program and the X display.

The xhost – command can be used to enable access control, but on systems where it is useful to have other users share a display (for instance, if you have two user accounts but only one monitor, and want to use GUI applications from both accounts) the X port should be firewalled.

X11 uses TCP port 6000, and the following iptables command should prevent access to the X port from ethernet interfaces. Use wlan+ for wireless devices, or simply use -i ! lo to block all X access except from localhost.

iptables -A chainname -i eth+ -p tcp –dport 6000 -j DROP

Tags: Network Security, Operating Systems

Categories: Network Security, Operating Systems

1 Comment

Transmarit is a guide to hardening Slackware Linux 10.2.0. It was written by Jeffrey Denton in January 2006, and covers most of the steps you’d want to take to securely lock down a Slackware server.

Locking down a system this much is probably unsuitable for home users, or on most workstations, but in the server environment, most of the security precautions mentioned make sense.

Of course, locking down a system brings with it inconvenience as well as security, and most sites will want to find a balance between security and usability. The document does lean somewhat more toward security, though.

There are actually some interesting tricks in there, such as checking if a user with UID zero is in fact root, and, if not, killing their processes and e-mailing the real root.

For those wishing to secure their Slackware servers, this makes an excellent read. In fact, even if you’re just looking to slightly increase the security of your home system, I’d say that reading this document would be a good place to start getting some ideas as to what you can and can’t do, and what sort of thing makes for good security.

Hardening a Linux system is the topic of many books and documents. Some try to be generic and cover the things you can do regardless of distribution, but many are written for the “popular” enterprise distributions such as RedHat and SuSE. It’s nice to see a Slackware one out there, and with such sound security information in it, Slackware should keep its reputation for security as well as speed and stability.

Tags: Operating Systems, Security Policies

Categories: Operating Systems, Security Policies

1 Comment