handyfloss

I guess it is not very uncommon, since it has happened twice to me, in two sites I have worked. “Over-cautious” sysadmins decide that the University, Institute, Corporation, or whatever, would be safer if connections to the [[LAN]] from outside of it were banned, including the [[Secure Shell|port 22]]. In an effort to avoid making security trample service (how considerate!) the usual solution to allow remote conection is to use [[VPN]].

While VPN might have some advantages over SSH, I prefer the latter by far, and don’t think a proper SSH setup has any lack of security, specially comparing to poorly implemented VPNs. For example, I would never trust something as vital as VPN software to a private company, yet most popular VPNs are proprietary (at least the University of the Basque Country uses the Cisco VPN). It is at least paradoxical that a free and open SSH implementation as e.g. [[OpenSSH]], tested in such a throughout way, and for so long, is dumped, and a black-box solution developed by a profit-driven organization is used instead.

But I digress. I am not interesting in justifying why I want SSH. What I want to show here is a trick I learned reading tuxradar.com. Esentially, allows one to connect (with SSH) from machine A to machine B, even if machine B has all ports closed (so SSH-ing using another port would be useless either).

The idea (see below) is to connect from machine B to A, which is allowed (and is also the exact reverse of what we actually want to do), in a way that opens a canal for a “reverse” connection from A to B:

Then we will be able to use port 1234 (or whatever port we specify in the ssh -R command above) in machine A to connect to machine B, as long as the original ssh -R holds:

The picture shows it better:

SSHing from A to B (dashed red arrow) is disallowed, but the reverse (in black) is not. The ssh -R command line (see code above), opens up the link between ports 22 and 1234 (two-headed black arrow), so that a ssh -p to port 1234 in machine A will redirect us to machine B. If we are asked for a password (at the ssh -p stage), they are requesting the one for machine B, since we are being redirected to machine B.

Please, recall that the above recipe is no less secure than a regular SSH from A to B (if it were allowed), since anyone SSHing to port 1234 in machine A will be automatically redirected to machine B, but undergoing the same security checks as usual (password, public/private key…). Note also that I am talking about what is possible, not necessarily desirable or comfortable. It’s just another tool if you want to use it.

Pedazo de noticia que he leído vía EmpresaDigitala.net. Según esta, Microsoft apuesta por la seguridad para diferenciarse del software libre.

¡Oh, sorpresa! MS, la empresa que produce el ubícuo sistema operativo Windows, tan conocido por su invulnerabilidad ante ataques de software malicioso y su práctica ausencia de bugs y errores, ha decidido seguir por el camino de la perfección que la caracteriza, para diferenciarse del software libre, que tantos agujeros de seguridad sabemos que tiene, y cuyos bugs sabemos que se tardan tanto en solucionar. ¡Menos mal! Estoy ya harto de los virus y troyanos en mi Debian. Es que cada vez que me mandan un e-mail tengo miedo de abrirlo, no sea que se me infecte el ordenador. Además el antivirus que tengo todo el tiempo corriendo en segundo plano me come muchos recursos, y no puedo trabajar a gusto. ¡Ojalá pueda pasarme a Windows, y olvidarme de todo este rollo del [[malware]]!

¡Venga ya!

Following some security policy updates (not necessarily for better) in my workplace, a colleague and I discussed the vulnerability of user passwords in the accounts of our computers. He assured that an attack with a cracker program such as John the Ripper could potentially break into someone’s account, if only the cracker would have access to an initial user account.

I am by no means an expert on cryptography and computer security, but I would like to outline some ideas about the subject here, and explain why my colleague was partially wrong.

How authentication works

When we log in to an account in a computer, we enter a password. The computer checks it, and if it is the correct one, we are granted access. For the computer to check the password, we must have told it beforehand what the correct password is. Now, if the computer knows our password, anyone with access to the place where it is stored could retrieve our password.

We can avoid that by not telling the computer our password, but only an encrypted version. The encrypted version can be obtained from the password, but there is no operation to obtain the password from its encrypted form. When the computer asks for a password, it applies the encrypting algorithm, and compares the result with the stored encrypted form. If they are equal, it infers that the password was correct, since only from the correct password could one obtain the encrypted form.

On the other hand, no-one can possibly obtain the original password, even by inspection of the contents of the host computer, because only the encrypted form is available there.

How password cracking works

I will only deal with brute force attacks, i.e., trying many passwords, until the correct one is found.

Despite the “romantic” idea that a cracker will try to log in to an account once and again, until she gets access, this method is really lame, since such repeated access tries can be detected and blocked.

The ideal approach is to somehow obtain the encrypted password that the computer stores, and then try (in the cracker’s computer) to obtain the plain password from it. To do so, the cracker will make a guess, encrypt it with the known encrypting method, and compare the result with the encrypted key, repeating the process until a match is found. This task is the one performed by tools such as John the Ripper.

Why this shouldn’t work in a safe (Linux) system

The security of a password relies heavily on the difficulty of guessing it by the cracker. If our password is the same as our user name, this will be the first guess of the cracker, and she’ll find it immediately. If our password is a word that appears in a dictionary, they’ll find it quickly. If it is a string of 12 unrelated characters, plus digits, dots or exclamation marks, then it will take ages for the cracking program to reach the point where it guesses it.

The second hurdle for the cracker is that, even if she gets access to a regular user account, the file where the encrypted passwords are stored is only readable by the root (administrator) user (in a Linux system). Information about users and their passwords is stored in /etc/passwd (that any user can read) and /etc/shadow (that only root can read). The encrypted password is stored only in the latter. In the past all info was in /etc/passwd, but later on it was split, to increase the security.

In short: you need root access to start trying to crack passwords in a machine… but, if you have root access, why bother? You already have full access to all accounts!

The following shows why crytograpy methods shoud be public. There is some common misconception, that assumes that the most secure crypto methods are “proprietary” or “secret” ones. This is a terrible error, since only knowing the “recipe” (the algorithms) behind a given method can assure us that it is actually robust.

The question can rise: how can a publicly known crytographic method be secure? By definition, everyone will know how it works! Not quite. The operation method can be known to all, and an eavesdroper could know what method we are using, but if the method is secure, the eavesdroper will not be able to decipher a given message. It might be tempting to think that if an eavesdroper doesn’t even know what encryption we are using, or she knows the “name”, but the method behind is secret, then the security of the message is increased. This is called security through obscurity, and is actually a very dangerous error, because it might lead us to be less exigent in the robustness of the encryption algorithm. A communication can only be considered secure if even knowing the encryption algorithm, an eavesdropper could not decrypt it.

To achieve this, it is vital that the encryption algorithm be publicly known, and rigorous tests applied. This is the case of the crypto standards of the North-American NIST. All the standards “accepted” by them have to be subject to open scrutiny, which happens to be a Good Thing(tm). You’ll see it if you read the following articles in The Register and Wired.

In summary: one of the components of cryptographic methods is random number generation. One of the ones approved this year by the NIST (called Dual_EC_DRBG), relied on a set of initial numbers to generate the “random” result (I’ll call this set P, public). This is normal, and correct. The problem comes from the fact that this set of numbers is apparently related to another (unknown) set of numbers (that I’ll call B, backdoor), knowledge of which could empower someone to break the resulting encryption. The way I understand it, is like having the known set of numbers P = (6,12,18,24,30), but then realizing that they are all built from the set B = (2,3). In the Dual_EC_DRBG method, some experts have realized that the set P is related to another set, but they still haven’t found what are the elements of B.

Now, the scary part is that (life’s full of casualities) the Dual_EC_DRBG was introduced in the standard proposed, and pushed, by the NSA of the USA, aka “the eavesdroppers of the world”. So I’ll invent a little fiction, with no relationship with the reality: imagine that a given government agency N of nation U takes a set of numbers B, and comes up with an encryption method M that produces the apparently innocent set P from it, and then M uses P to perform encryption. If the encryption method M becomes a standard, and people all around the world use it for anything from private e-mail to secure government or militar communications… guess who has a the key to read all these messages? (a backdoor).

Thanks $GOD, this is science fiction, is it not?

When we send e-mails (specially mass forwards) we might not be aware that on the other side of the wire there is some person that could be annoyed by some of our acts. We could help others behave nicely with us if we started behaving correctly with others. This post tries to help you with that.

All the following is my opinion, but I’m not asking you to do it because it’s my opinion. I think that, besides, it’s also sensible. Judge yourself.

Avoid HTML messages at all costs

In fact, only plain text e-mails should ever be sent (and anything else as an attachment). Sophocles, Shakespeare, Cervantes… they all used plain text, and managed to get their message through, didn’t they?

The reason to use plain text is dual. Firstly, it merely adds bloat. The e-mail will be unnecessarily fat, without adding the slightest actual content. Secondly, and maybe even more importantly, HTML is used in e-mails by spammers and crackers to force the receiver to execute unwanted actions, including: visiting unsolicited web pages, sending private data (as, e.g., the confirmation of the actual existence of the receiver, something very valuable for a spammer), and, if the HTML includes malicious Java, JavaScript or ActiveX code and the receiver is not correctly protected (*cough* Windows users *cough*), anything from crashing the mail client to setting your screen on fire and killing the little puppy you got yesterday.

For the second reason in the previous paragraph, any knowledgeable user will abhor receiving HTML e-mails (I do), and will have it completely deactivated (the mail client will not interpret the HTML code, and will display it literally instead, which is 100% safe, except if ugly symbols hurt your eyeballs). Thus, your pretty HTML message will not be correctly read by the receiver, and will at least charge him with the annoyance of either activating the HTML back, or reading the source code. And in this day and age, even allowing HTML e-mails in a per-sender basis is risky as can be, since anyone can forge anyone else’s e-mail address.

So, don’t ever send HTML messages, and also deactivate the rendering of HTML messages you receive altogether. The first thing will make your receivers happier, and the second one will keep you safer.

Use care if sending mass forwards

Can you name something more unpleasant than those silly mass forwards of 2MB PowerPoints with “witty” sentences, and almost always ending in “send it to 1000 friends or die a slow and painful death”?

For me, there are two kinds of forwards: the ones I name above, and the ones with funny, interesting and/or useful data. The first one: avoid them like the plague. Don’t ever send/answer/forward them. The only use they can have is negative: they clutter the net, they slow down the download of other (possibly important) e-mails for the receiver, they waste bandwidth and connection time for those who have either or both limited, and they don’t actually add anything to the life of the receiver, except anger towards a sob who pretends to be her “friend”, and then blackmails her to spread the same message or “suffer consequences”.

For the (veeery few) contents you want to spread to legitimately help/amuse/enlighten the receivers: choose a suitable format! If the content is a joke or similar, send it in plain text. It works all the same! Don’t send a huge PowerPoint just for the sake of it. If the content is a (presumably big) file (a movie file, a presentation that is amusing in itself, an article with images and links…), put it online and send a link instead! Sending just a link is much more comfortable for the receiver, since the size of the e-mail is tiny, and she can choose whether or not to download the file, after all. Not everyone has a personal web page, but at times it proves invaluable… look for online storage solutions, as there are many free ones.

Also take into account that mass forwards can be used by spammers to get a list of valid addresses to bomb with their mails. The more “evil” a spammer, the more friendly she’ll pretend to be, to be included in the more people’s distribution lists, so that she’ll be sent all their mass forwards, along with the addresses of maybe hundreds of victims.

To avoid that, try to send your forwards only to people you actually know, and think are not spammers. Even safer: DO NOT DISCLOSE the addresses of all the receivers of your e-mails to every other receiver. It’s easy: with any half-decent e-mail client (KMail, Thunderbird and even Outlook can) you can chose to make any receiver “To:”, “CC: or “BCC:” (“Para:”, “CC” and “CCO” in the Spanish version of Outlook Express). Send all your forwards with BCC to be on the safe side.

Trim the excess

Whenever you answer to or forward an e-mail, depending on the configuration of your e-mail client it will automatically attach the original message, quoted. Now, if the receiver answers to your answer, she’ll quote your text AND your quotation of her original message. Then you answer and… you get the picture: e-mails flying around with hundreds of lines that only add: a) superfluous size excess and b) confusion, since sometimes it is not easy to find exactly the new material (coloring quotations helps, though).

Quoting the e-mail we answer to can be useful, but when answering to an answer, be nice an take the ten seconds you need to properly delete what is not needed.

Also remember that blindly forwarding messages can make you disclose to third parties information that the original sender wanted just you to read. Watch out for that!

Don’t overspread e-mail addresses

Don’t make spammers’ day by providing them with your e-mail, much less with mine!

Spammers are out there, like the truth in The X-Files. They never sleep. They have no mercy. They will relentlessly go on an on, harvesting e-mail addresses to prey upon. You have to understand that the most valuable thing for a spammer is a list of valid e-mail addresses. Valid e-mails are those that will be actually read, or at least received.

The ways in which spammers build their lists include:

* Unprotected addresses publicly amenable on the Web
* Being included in a “mass forward” (see above)
* Random spam

Unprotected public addresses include valid e-mail addresses that appear literally in a web page, or sent to USENET or other discussion forums. For that reason, if you want to protect your address, while still making it possible for others to contact you, don’t ever put your address on the web like that:

myname@mydomain.com

Instead, put something like:

myname AT mydomain DOT com

or:

mynameIHATESPAMMERS@mydomain.com

Or any other combination that makes the literal e-mail completely invalid, but a human reader can realize how to handle to get the correct address. You have to understand that the spammers use robots to harvest e-mails from the web, that is, there are computer programs looking for e-mails, not human beings (even stretching the meaning of “human being” to include scum like spammers). An address that needs human “logic” to be read will not be parsed correctly by robots.

In that regard, beware that both “protected” addresses above are far from perfect. It’s trivial to write a robot program that translates every “AT” with an “@”, and any “DOT” with a “.”, and/or eliminates spaces, capital letters or words like “SPAMMER(S)” etc. So be colorful, and think like a robot can’t think :^)

A second approach to protecting your e-mail could be to use a specific anti-spam address. There are companies like Bluebottle who provide such a service. As you can see, the e-mail I provide in this Web site belongs to that category, and is a completely free account (they offer further services, that I do not need, for a fee).

These “anti-spam” e-mail accounts basically contact the sender each time they receive an e-mail. Then the sender has to perform some kind of basic action (click a button or similar) to assure that they are valid senders, and if they fail to, the e-mail is filtered. The validation action has the sole actual purpose of making sure that the sender is human. ANY human sender is let through, but the spam robots normally don’t have the wit to answer properly when prompted by the Bluebottle server. Yes, this might piss off the legitimate senders, because they are required to click a silly button before their message goes through. However, this is done only once. After the first authentication, all the e-mails coming from that address will be automatically accepted.

Being included in a mass forward is discussed above, and random spam messages are those offering medicines or pornography. If you answer to one of them, you might not get infected with a virus or anything, but the sender might secretly know that you actually exist (because she is notified when you answer or click the link), and remember: valid addresses are what spammers seek.

Already out of ideas for blog posts, I will shamelessly copy some material from my web site.

When connecting to a remote machine (called, e.g., Orpheus), we used to do the following to open a remote X client application:

localmachine> xhost +orpheus
localmachine> ssh orpheus
orpheus> setenv DISPLAY localmachine:0.0
orpheus> xeyes

Doing so is insecure, because 1) all the info sent from/to Orpheus through the xeyes process is transported unencripted (maybe not a big concern with xeyes, but what if the remote application is a dialog where we insert some password?) and 2) xhost only checks for the IP we atribute to Orpheus to accept X input. Any user connected to Orpheus, or even any cracker who knows how to fake a different IP address (that of Orpheus) can send us X input that our computer will accept (e.g., move our mouse, close windows, simulate keystrokes, and display unwanted images in our screen).

The solution would be to forward X traffic over SSH. What we do is basically connect to a machine through SSH, and then accept locally only the X input coming from the remote machine that originates from the SSH process we started.

To do so we must insert the following line into the ~/.ssh/config file in our “localmachine” computer (create the file if it doesn’t exist):

ForwardX11 yes

The next step is more complex, since only the administrator of the remote machine can acomplish it. As root, we have to open the /etc/ssh/sshd_config file (notice the “d”) in the remote machine (e.g. Orpheus), and search for the lines:

#X11Forwarding no
#X11DisplayOffset 10

And set them to:

X11Forwarding yes
X11DisplayOffset 10

After that, we have to restart the SSH daemon. On Debian:

% /etc/init.d/ssh restart

On Slackware:

% /etc/rc.d/rc.sshd restart

A couple of final notes:

The environment variable DISPLAY should NOT be set by ~/.login or some other login script, because this would override the above procedure, and make the X client run over regular TCP. To use the SSH tunneling:

localmachine> ssh -X orpheus
orpheus> xeyes

et voilà!

To take advantage of this system, and make our computer more secure, no machine should be allowed to send X input through xhost, that is, issueing the xhost command should output the following:

localmachine> xhost
access control enabled, only authorized clients can connect

with no "INET:Orpheus.sq.ehu.es"-like lines.

About 5 months ago I made a post explaining how to use SSH to connect from computer A to computer B without going through the hassle of introducing the password each and every time.

As it happens, my instructions were far from complete, because they relied upon not setting any passphrase, and thus saving the SSH password unencrypted in the hard disk. That way, a malicious user, if able to read your account in computer A, can connect in your name to computer B with no restriction (thanks agapito for pointing this out in a comment to my post).

Next step is, thus, to use use passphrases, but avoiding mayor hassles with ssh-agent.

I will repeat here the instructions in my old post, and extend them. First generate a public/private key pair in computer A:

% ssh-keygen -t dsa

and answer the questions you will be asked, not forgetting to enter a passphrase.

This will create two files in your ~/.ssh/ dir: id_dsa and id_dsa.pub, whith your private and public keys, respectively.

Now, you have to copy the contents of id_dsa.pub into a file named ~/.ssh/authorized_keys in computer B. From that moment on, you will be able to connect to B through SSH without being prompted for your user password in computer B. However, you will be prompted for a password: namely the passphrase that unencrypts the wallet to your actual password (they one you set with ssh-keygen).

To avoid having to introduce this passphrase each time we want to make a connection, we can take advantage of ssh-agent, in the following way. First, we run the agent:

% eval `ssh-agent`

Then we add our key to the agent:

% ssh-add

The above will look, by default, for ~/.ssh/id_dsa, and will ask for the passphrase we introduced when generating it with ssh-keygen.

After the above, all further connections from that terminal (and its children) will benefit from passwordless SSH connections to computer B (or any number of computers that have your A computer’s public DSA key in their ~/.ssh/authorized_keys file). This benefit will be lost whenever ssh-agent stops running, of course.

OK, but I want to have passwordless connections from ALL my consoles!

Then you have to take advantage of the following sintax:

% ssh-agent command

where, command and all of its children processes will benefit from ssh-agent. command could be, of course, startx, or any command you use to start the desktop environment. You will still have to execute ssh-add, and enter the passphrase, but only once in your whole session. You will have to enter the passphrase again only if you log out of the desktop environment and log in again.

OK, but how do I make scripts benefit from this

You will find yourself automating the execution of some scripts sooner or later, for example putting some backups in a cron.

To do so, a ssh-agent must be already running, and you have to make the script somehow hook to it. To do so, include the following code chunks in your scripts:

Perl:

Create the following subroutine:

###################################################
#                                                 #
# Check that ssh-agent is running, and hook to it #
#                                                 #
###################################################

sub ssh_hook
{
  my $user = $_[0] or die "Specify a username!\n";

  # Get ID of running ssh-agent:
  chomp(my $ssh_id = `find /tmp/ssh* -name 'agent.*' -user $user`);
  die "No ssh-agent running!\n" unless $ssh_id;

  # Make this ID available to the whole script, through
  # environment variable SSH_AUTH_SOCK:
  $ENV{SSH_AUTH_SOCK} = $ssh_id;
};

and call it (before any SSH call in the program), like this:

&ssh_hook(username);

tcsh:

setenv SSH_AUTH_SOCK `find /tmp/ssh* -name 'agent.*' -user username`

bash:

export SSH_AUTH_SOCK=$(find /tmp/ssh* -name 'agent.*' -user username);

In all cases username is the user name of the user making the connection (and having run ssh-agent).

A lot of info was taken from this Gentoo HowTo and this HantsLUG page, and googling for “ssh without password”.

I just received a spam e-mail with the following subject:

Linux is covered by the GNU General Public License (GPL), which allows free distribution of the code please read the GPL in appendix

Except poor punctuation, the sentence makes sense, and covers a subject I could actually be interested on :^)

This e-mail is one of the things I have found most interesting recently.

Well, at least among the ones I’ve sent to complete oblivion with a key press.

I finally made my new laptop connect with WPA encryption to my WiFi router!!

I could already connect it to WiFi networks with WEP encryption (or no encription at all), but WPA proved harder.

Mini HowTo

1) My setup is the following:

WiFi router: SMC Barricade WBR14-G2
WiFi card in laptop: Intel PRO/Wireles 3945
OS: Ubuntu 6.06 LTS (Dapper Drake)

2) The router settings:

Wireless encryption: WPA/WPA2 Only
Cipher suit: TKIP+AES (WPA/WPA2)
Authentication: Pre-shared Key (yes, I know 802.1X would be more secure… sue me)
Pre-shared key type: Passphrase (8~63 characters)

3) The package one needs to install:

# aptitude install wpasupplicant

4) Making WPA supplicant run:

First, create a config file, by the name /etc/wpa_supplicant.conf, and inside it, write:

ctrl_interface=/var/run/wpa_supplicant
ap_scan=1

network={
  ssid="your_ssid_name"
  scan_ssid=0
  proto=WPA RSN
  key_mgmt=WPA-PSK
  pairwise=TKIP CCMP
  group=TKIP CCMP
  psk="your_preshared_key"
  priority=5
}

At that point, you should make sure that the WiFi is turned on, and that the correct driver is loaded. In my case:

# modprobe ipw3945

Then, to test the WPA supplicant, run:

# wpa_supplicant -Dwext -ieth1 -c /etc/wpa_supplicant.conf

Recall I have used the wext device, instead of the ipw one, that would seem the appropriate one. Well, I read somewhere, that with 2.6.16 kernels and newer, this should be the case. Now I recall that my kernel is 2.6.15… nevermind, it works that way, and not the other (with -Dipw).

Recall also that my wireless device is eth1. Your mileage may vary (but each wireless card model gives rise to a precise device name, don’t worry).

If everything went fine, the output for the above command should be something like:

# wpa_supplicant -Dwext -ieth1 -c /etc/wpa_supplicant.conf
Trying to associate with xx:xx:xx:xx:xx:xx (SSID='xxxxxxxx' freq=0 MHz)
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
Authentication with 00:00:00:00:00:00 timed out.
Associated with xx:xx:xx:xx:xx:xx
WPA: Key negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP]
CTRL-EVENT-CONNECTED - Connection to xx:xx:xx:xx:xx:xx completed (auth)

If you see that “negotiation completed”, it worked (Ctr-C to exit the above).

5) Automating the WPA connection when bringing wireless interface up

Next, I’ll explain the small changes one has to make to /etc/network/interfaces to correctly bring up the interface. As I said, my wireless interface is eth1, so, I added the lines below to the aforementioned config file:

iface eth1 inet dhcp
wireless-essid my_wireless_essid
pre-up wpa_supplicant -Bw -Dwext -ieth1 -c /etc/wpa_supplicant.conf
post-down killall -q wpa_supplicant

And that’s all! Whenever you ifup eth1, you’ll bring up the wireless interface, with WPA encryption working.

I read, via Kriptopolis (es), that “Tim Eades, senior vice-president of sales at security company Sana Security said that 38 per cent of malware is already Vista-compatible.”

Apparently, and according to an article at ITPro.co.uk, more malware than anti-malware has been already ported to Windows Vista.

Go, Vista, go!