Florin Andrei wrote:

...

...

The options are: L2TP, PPTP and IPSec. If you were to install a VPN endpoint on CentOS, which protocol would you prefer?

I know this doesn't answer your question as put, but it may be worth taking a different tack and supplying whatever services wrapped with SSL/TLS instead - I guess it depends exactly what you want the VPN for.

What's driving it at this point is IMAP access. Sure, I could expose the IMAP-over-SSL port to the Internet, but somehow that sounds even more scary than using a second-rate VPN server. I am using Cyrus IMAPd, but regardless, I just have a bad feeling about allowing everyone and their dog to poke directly at the software holding all my emails.

If you have a decent password (on all accounts) I wouldn't worry about about it too much. Move it to an odd port or even require a client certificate if your client software supports it.

The usual problem with IPSec is trying to make it work through a NAT router. Does your server have a public address of its own? SSL and OpenVPN can work through port-forwarding routers.

on 3-26-2009 1:02 PM Florin Andrei spake the following:

Les Mikesell wrote:

...

If you have a decent password (on all accounts) I wouldn't worry about about it too much. Move it to an odd port or even require a client certificate if your client software supports it.

The non-standard port is a good trick, but even assuming the iPhone does support it (which is far from certain, the interface is very simple and terse), I'm still a bit uncomfortable. All it takes is a stupid buffer overflow, and a script kiddie with patience and a portscanner - even if you send packets to DROP, it's still scannable, it just takes much longer. Port knocking is probably not doable (or not easily) from the iPhone.

Maybe I don't trust the IMAP server enough to expose it. Maybe I should.

...

The usual problem with IPSec is trying to make it work through a NAT router. Does your server have a public address of its own? SSL and OpenVPN can work through port-forwarding routers.

I'm aware of the NAT issues. I've a decent amount of experience with IPSec in the enterprise actually, just not with Linux as a concentrator. The usual trick is to enable some sort of UDP tunneling, and then a good part of those issues is alleviated. The question is whether the Linux IPSec server supports UDP encapsulation (and whether the iPhone client does too).

The machine has a public interface exposed directly to the Internet, so that simplifies things a bit.

I have several IMAP servers exposed. I just run fail2ban and it drops the script kiddies and the brute force attacks after a couple of tries. Unless the attacker already knows the username and password, that should stop them cold.

Les Mikesell wrote:

Florin Andrei wrote:

...

Maybe I don't trust the IMAP server enough to expose it. Maybe I should.

Anything that can survive in a university environment should be safe enough for the rest of us.

That's a good point.

Okay, I have a few things to try now.

Joseph L. Casale wrote:

...

The non-standard port is a good trick,

Here's just an opinion: Security by obscurity only makes >you< feel good, it does nothing in reality. Anyone sufficiently talented to hack a service in order to gain root or do something useful would not be fooled by that. Set whatever your doing up right so that any false sense of security is not deemed necessary.

I've seen this before - when the non-standard port trick is mentioned, somebody usually gets up and goes "it's security by obscurity! it does nothing to protect you! it only gives you the fuzzies!"

I think that's a nice example of pervasive fallacious binary thinking, combined with an old tired slogan that by all rights should be dead by now.

First off, it's doesn't do "nothing". It does make things a bit harder for the attacker. Not much, but it's not zero either. It does eliminate a whole class of attacks actually - the mass scanbots or the most moronic script kiddies, which by the way represent the highest volume of malicious traffic on almost any public network. If I can do something to avoid getting 0wned by a pimple-face armed with a zero-day exploit and a bunch of bots scanning the Internet for standard ports, by all means I'll do it. I can't do this for a public server, which by definition must stand out in the clear; but for private-use stuff, why not if it's not too cumbersome for me? All I need is buy myself 24 hours of respite, until I get the patch, and the non-standard port may well do that for me. Or not. It's a gamble, yes, like everything else in the real world.

Secondly, nobody said that was the only line of defense. I do use other mechanisms as well. That's how security works, by wrapping your stuff in several layers of protection. You deploy several different measures, working in various ways, and hope they cover each other's holes.

Lastly, there is *absolutely no security measure* that is perfect. By the same token, we should not use firewalls, because they can be circumvented by people who are skilled enough, nor use passwords, because they can be guessed or brute-forced. And so on.

If a security measure doesn't make things too hard for the user and/or for the administrator (and it this case it doesn't, myself being one of the very few users and the sole admin), and it's not too expensive, then it should probably be used. It's one more peel added to the security "onion" and it's a plus, not a minus or a zero.

Ironically, exactly the people claiming to give security "advice" by saying this measure or another "does nothing in reality" because it's "security by obscurity", it's them who, in my view, show they don't really understand what security actually is. Brandishing a bunch of slogans does not equate with being knowledgeable in this field. Technical skills, experience, and a measure of realism and common sense are required instead.

You may want to read about the various cryptographic algorithms - they work, in essence, by "obscuring" the cleartext. The patterns are still there, they are just made hard to distinguish from the pseudo-noise by the algorithm - the better the crypto, the fainter the patterns. That's how some ciphertext-only attacks work, by looking for evanescent patterns in the sea of seeming randomness. It's a scary thought if you spend time considering it, but in practice strong crypto does work to some extent. But if it's just "security by obscurity" should we not use crypto either?

Yes, "security by obscurity" is useless when it's alone, but it can be good if used appropriately and combined with various other measures. We should put this slogan to rest by now, it's 2009 already. Sheesh.

Let me introduce myself:

Robert Moskowitz, ICSAlabs, an Independent Division of Verizon Business Systems.

Security IS my business and I am a bit of a 'maverick' even in the labs on my positions. ICSAlabs is the company that certifies products: Firewalls, malware, IDS, IPsec, SSLvpn, etc.

Florin Andrei wrote:

Joseph L. Casale wrote:

...

...

The non-standard port is a good trick,

Here's just an opinion: Security by obscurity only makes >you< feel good, it does nothing in reality. Anyone sufficiently talented to hack a service in order to gain root or do something useful would not be fooled by that. Set whatever your doing up right so that any false sense of security is not deemed necessary.

I've seen this before - when the non-standard port trick is mentioned, somebody usually gets up and goes "it's security by obscurity! it does nothing to protect you! it only gives you the fuzzies!"

I think that's a nice example of pervasive fallacious binary thinking, combined with an old tired slogan that by all rights should be dead by now.

Binary thinking will get you 0wned in security. Defense in depth and raising the bar.

First off, it's doesn't do "nothing". It does make things a bit harder for the attacker. Not much, but it's not zero either. It does eliminate a whole class of attacks actually - the mass scanbots or the most moronic script kiddies, which by the way represent the highest volume of malicious traffic on almost any public network. If I can do something to avoid getting 0wned by a pimple-face armed with a zero-day exploit and a bunch of bots scanning the Internet for standard ports, by all means I'll do it. I can't do this for a public server, which by definition must stand out in the clear; but for private-use stuff, why not if it's not too cumbersome for me? All I need is buy myself 24 hours of respite, until I get the patch, and the non-standard port may well do that for me. Or not. It's a gamble, yes, like everything else in the real world.

Just moving SSH to a high port, will stop a lot of traffic coming in on your DSL/cable link. When the bots find port 22, they start pounding. They don't portscan (at least not today), there are too many opertunities at port 22 for them. This is one of the first steps I do whenever I build a Linux system. It also cuts down on logging of all of those failed logins that end up in your nightly cron report.

Then I DO set up rate limiting using shorewall, but this does not help me much with IPv6 SSH on Centos...

Secondly, nobody said that was the only line of defense. I do use other mechanisms as well. That's how security works, by wrapping your stuff in several layers of protection. You deploy several different measures, working in various ways, and hope they cover each other's holes.

Rate limiting on some services is another tool. Look for what makes sense for you and look at your total picture. Perhaps you only have one system that you tunnel into that gives you access to all others. So that one system is really hardened. But the others are not neglected, but perhaps don't need the same level of protection.

Yes make things obscure as one of the first steps and go from there.

Lastly, there is *absolutely no security measure* that is perfect. By the same token, we should not use firewalls, because they can be circumvented by people who are skilled enough, nor use passwords, because they can be guessed or brute-forced. And so on.

If a security measure doesn't make things too hard for the user and/or for the administrator (and it this case it doesn't, myself being one of the very few users and the sole admin), and it's not too expensive, then it should probably be used. It's one more peel added to the security "onion" and it's a plus, not a minus or a zero.

Ironically, exactly the people claiming to give security "advice" by saying this measure or another "does nothing in reality" because it's "security by obscurity", it's them who, in my view, show they don't really understand what security actually is. Brandishing a bunch of slogans does not equate with being knowledgeable in this field. Technical skills, experience, and a measure of realism and common sense are required instead.

What is the threat. What is your risk. What is the cost.

If any of those is zero, the product is zero. (per Dr. Peter Tippet, my boss).

You may want to read about the various cryptographic algorithms - they work, in essence, by "obscuring" the cleartext. The patterns are still there, they are just made hard to distinguish from the pseudo-noise by the algorithm - the better the crypto, the fainter the patterns. That's how some ciphertext-only attacks work, by looking for evanescent patterns in the sea of seeming randomness. It's a scary thought if you spend time considering it, but in practice strong crypto does work to some extent. But if it's just "security by obscurity" should we not use crypto either?

Now you are playing with semantics. IMHO.

Yes, "security by obscurity" is useless when it's alone, but it can be good if used appropriately and combined with various other measures. We should put this slogan to rest by now, it's 2009 already. Sheesh.

And next year is the last that NIST says we can use SHA-1...

The END is near, the sky is falling.

:) Too much IETF discuss time. But boy did it feel good. Like the drug it is.

Ralph Angenendt wrote:

Florin Andrei wrote:

...

So far, OpenVPN has been working very well for me. Unfortunately, the iPhone doesn't have (yet?) an OpenVPN client, so I'm forced to work with what's available.

The options are: L2TP, PPTP and IPSec. If you were to install a VPN endpoint on CentOS, which protocol would you prefer?

IPSEC.

That's only a few entries in a file in /etc/sysconfig/network-scripts away from a working solution >:)

http://www.centos.org/docs/5/html/5.2/Deployment_Guide/s2-networkscripts-interfaces-ipsec.html

Okay, so it's included with the OS and some documentation is available. Good.

Now, from a practical perspective, how trustworthy is it? I'm looking for something to setup and forget. E.g. I am running Postfix instead of Sendmail precisely for the setup-and-forget nature of the software - the security track record of Postfix is remarkably good, so I can use it without having to worry too much. I threw the server away into a cabinet in the living room, it's hidden from view, it just works, very much like an appliance. Minimizing the admin time is crucial.

Same with OpenVPN. Turn it on and it just works, solid as a rock, no excessive worries about nasty security bugs every three months.

I haven't used IPSec VPN with Linux endpoints very much, so that's why I'm a bit unfamiliar with how robust these things are, from a security history perspective.