Benjamin Scott wrote:
[SNIP....]
> I have heard some rumbling that FreeS/WAN, while very promising, is not
> quite ready for prime time, even in security critical areas. Anyone have any
> comments on this? I have not played with FreeS/WAN yet, myself, and the
> rumbling I have heard was just in public Internet discussion formus, so I
> cannot exactly call it reliable. But it was enough to make me wonder.
I have used FreeS/WAN extensivly. Usually when people talk about it
being unstable, it is because it is not an easy configuration to get
your hands around, and if you mess up the config, you could leave a
gaping hole. There was also a boot-time encryption hole (which existed
in 1.3 and earlier) where the network was vulnerable before FS was
started. That hole could always be fixed by starting proper firewall
before starting FS.
There was also a flaw in the authentication keying in 1.3 and earlier
where the gey generation exludied the prepending of "0x" to the public
key. However, this bug increased the security of the system because it
simply didn't allow *any* connections ;-)
I have tested the encryption, stability, and general security in FS
v1.5, and everything has always been secure.
> Also: Anyone have experience connecting a Windows client with a dynamic IP
> to a Linux-based FreeS/WAN host? Preferably with Open Source, or at least
> free (gratis) or cheap, software?
Can't be done. There are only a handful of products for Windoze that can
do IPSEC, and even fewer that support IKE and Pluto (which are essential
for interaction with FreeS/WAN). All of these products are commercial
(PGPNet, F-Secure client, and InterGate). The Freeware versions of these
products don't work because they don't support tunnel mode. There are
problems with the commercial versions, as well. There are a set of
scripts written by Kai Matrtius (one of the developers) that you need to
use to extract the keys from the "keyrings" and then separate the actual
keys from the binary garbage needed for Windows.
> > There is also PoPToP (http://www.moretonbay.com/vpn or
> > http://poptop.lineo.com), which is a pptp implimentation for Linux
> > (Without the M$ extensions and embracements).
>
> Actually, PoPToP is designed specifically to *include* the MS extensions and
> embracements. PPTP is largely a Microsoft protocol, anyway. :-(
PoPToP only includes the MS extensions if you allow it to. You can
actually set it up so that MS clients can't even connect. This is not
the default, of course, but it can be done.
> > [PoPToP] can use 128-bit rc4 encryption (not all that great, but OK)
>
> Ummm, I believe conventional wisdom says that with modern algorithms, session
> encryption keys longer then 100 bits or so is just a waste of resources. In
> fact, I just checked, and the FreeS/WAN website makes reference to this.
I wasn't refering to the key length, here, I was refering to rc4. rc4 is
considered to be one of the weaker algorhythms out there as compared to
3DES, Blofish, twofish, etc.
> If, on the other hand, you are talking about *authentication* keys, well,
> PPTP does not use PPKs for authentication at all. Which is where its real
> weakness is (assuming you have disallowed the brain damage in MSCHAPv1).
> Passwords are patheticly weak compared to even 128-bit authentication keys.
Even MSCHAPv2 has quite a bit of braindamage, but it is better. However,
the lack of authentication keys is a major blow to the security of the
system.
> > With all of this having been said (twice now), I have one more suggestion.
> > Don't use your firewall as a VPN box.
>
> While this is good advice for many, if not most, cases, it is worth making
> the point that simply moving the VPN to another box is not a panacea. You
> still have to punch a hole through the firewall to the VPN host, and if the
> VPN host is compromised though that channel, the game is largely up.
I fully agree with this. However, my point was not aimed completely at
the generic concept of security. A firewall box needs to be extremely
stable in order to do it's job. A Linux firewall (for the most part),
uses IPChains, which is kernel based, and uses primarily the CPU to
process packets. Now, if you add a VPN system on top of that, you are
pushing the CPU even harder. This is not to say that todays CPU
technology can't handle it, but imagine if, you will, this scenario:
The box: a PIII 600MHz system, 256MB RAM, yadda yadda yadda..... A good
system. Using a moderate IPChains script, port-forwarding, NAT, etc. And
let's say that there are about 1000 hits to the firewall per hour (not
counting port-scans and other enomolies). This is a fairly stable
system. Traffic flows well. No real bottlenecks. Now, on top of that we
add FreeS/WAN. Since we want FS to be secure, we use RSA (`CUZ WE
CAN!!!!!) 4096-bit authentication keys, rekey the session keys every 15
minutes, and let's say that you have 5 simultanious tunnels per
connection (this is actually a low number of tunnels per connection).
You have just multiplied your CPU usage 12x.
Now, this doesn't make the box insecure, but under heavier traffic, it
could become unstable. It introduces a bottleneck on the firewall, where
you probably don't it. Also, if the system goes down because of the
load, then the one route out of the network is down.
> There is a far too common attitude that simply by placing things behind a
> firewall, you are secure. That is bogus. Most exploits are made possible by
> bugs or mis-configurations in network software. You must want to use at least
> *some* of that software, or you would not be using a firewall (you just
> wouldn't connect to the Internet in the first place). Such bugs can be
> exploited just as well through a firewall.
This is 100% true. If the service is exploitable, it's exploitable no
amtter where is is, as long as the service is available.
> Which is not to say that this makes Kenny's advise invalid; it doesn't.
> Just remember that there are no easy solutions to any security problem.
I disagree. The are no remote *OR* local exploits for an abacus ;-)
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
