How many of you are using IPSec?
Printable View
How many of you are using IPSec?
We use it, however I am not the one who imletmented it nor am I the one who manages it so unfortunatley I know little about it.
We are and I am the one who designed, implemented and manage it. What do you want to know other than who is using it as that seems like a rather worthless statistic.
Well, it's not particularly worthless to me, as I am very curious as to how many people have already deployed IPSec on their networks. I think IPSec will eventually become a standard for private networking, and the amount of people using IPSec currently tells me a lot about where we are in that progress.
So perhaps worthless to you, but not to myself :-) One man's trash is another man's treasure.
I am also interested in knowing how many people have deployed IPSec on their wireless network.
Sorry, thehorse13 if this doesnt interest you. Skip the thread and move on to another one if you arent interested. I asked because it IS of interest to me. I would like to know how much progress IPSec has made towards becoming a standard.
None.
Here's why. The protocol is too complicated and flakey. As soon as funding is available, it's going out the window here.
Why do you think it will be a standard when encryption is already built into the IPv6 spec? What benefit will IPSec have when IPv6 is widely deployed?
If I wasn't interested, I wouldn't have responded nor would I have asked a follow up question. Play nice.Quote:
Sorry, thehorse13 if this doesnt interest you. Skip the thread and move on to another one if you arent interested.
What benefit would IPSec give you over wireless? I'd say that authentication would be the area that would concern me most. With WPA out there already, where is the benefit in IPSec?
Well, that, in and of itself is absolutely true th13. However, I have a few doubts about when IPv6 is going to be widely deployed. NOT because of the protocol itslef. I wish to hell it WAS being widely adopted now! I have often 'bitched' about this with other people. You have no idea just how much I want to see IPv6 in place! I think we will get there eventully, however...when is another matter.Quote:
Why do you think it will be a standard when encryption is already built into the IPv6 spec? What benefit will IPSec have when IPv6 is widely deployed?
In the meantime, I would hazard to guess that IPSec would take it's place, if it is going to be as long as I think it's going to be before IPv6 is in place.
All just guesses of course, but were that the case, as I said, I am curious to know how far IPSec has come adoption-wise. Thats all.
In that case, I do apologize. You know as well as I do that it is very hard to guess another's 'tone' when online ;-)Quote:
If I wasn't interested, I wouldn't have responded nor would I have asked a follow up question. Play nice.
Well, no more than the same benefit that IPSec has on non-wireless networks. IPSec DOES have it's benefits. What benefit? Encrypted packets! If someone was successful in sniffing your wire [or wireless as the case may be!], would you not at least want to be sure that the information they could obtain would be minimal? Would you deploy a wireless network without IPSec?Quote:
What benefit would IPSec give you over wireless? I'd say that authentication would be the area that would concern me most. With WPA out there already, where is the benefit in IPSec?
Sorry, did not see that part the first time. Again, How many people are actually using WPA?Quote:
With WPA out there already, where is the benefit in IPSec?
IPSec and WPA, both are crackable, no?
That in itself is no good. Who wants to use security features which are crackable? However, there is not much choice at the moment if you are going to go wireless.
When it comes down to it th13, the question you asked about what advantage does IPSec have over WPA...the answer is none. Neither are a viable solution for those who cannot afford to have their security compromised.
But then again, thats a whole 'nother discussion! As I said, I am simply curious as to how many people have adopted the use of IPSec.
Your questions do add value to the post, dont get me wrong. Just wasn't quite where I was going with this thread!
Well, while we're on the subject, I may as well pick the brain of TH13 or anyone else watching. So it looks like I'm going to be in charge of VPN connectivity here at our office. Right now we have about 10 folks that VPN into our office from different locations around the country, just single users. Now I've looked around a little bit and from what I've seen, companies use IPsec for site to site VPNs not really the little remote users. Now they want to implement more VPNs here to the remote users bringing the number up to around 30 or so and I don't want that much traffic going through the mail server (the current set up, wasn't my idea.) Anyway I'm probably going to get them to purchase a Cisco 3000+ series or a Sonicwall. Do you have an opinion on which one of these will perform better. Would it be prudent to bump the security up to IPSec or would that just slow things down? I've heard IPsec is a little slower than MPPE which I believe is what windows is using by default for pptp.
Thanks,
GEL
In fact, now that you bring it up and we are on the subject, how many Linux compatible wireless cards are out there (namely the higher speed 11g cards) have drivers which dont yet even support encryption? Quite a few!
Mind you, I do not do wirless. I would love to be able to do so, and have researched the options pretty extensively. However, considering the dimsal state of security in wireless at the moment...I will not use wireless technology any further than for research purposes.
As far as I am concerned, at the moment anyway, wireless=no security
And on the subject of IPv6, I was having a conversation just the other day about this with a friend. IPv6 far surpasses IPv4 in security, and it drives me nuts that IPv6 has been available to us for sometime, and we are still stuck on IPv4. We all know why.....well we should all know why anyways. It's mainly the problem with IPv4and IPv6 compatibility issues.
When IPv6 is finally in place, then the issues we are discussing here now will no longer be of relevance. We will move on to new issues like vulnerabilities found in IPv6. However, many of the problems we currently face will be solved with the security features of IPv6. I absolutely cannot wait until we finally have this thing in place! Can we get moving please! lol!
But at the moment, that is not really an option for us. And security is still a very important issue. So what do we do until such time as we have all made the switch? Well, we have to look into things like IPSec and WPA encryption.
Problem is, aside from those of us who are concerned with and knowledgable in security, not many people have implemented these options. That considered, I was moved to post this thread in an attempt to enumerate the people who have thus far implemented some of these options.
On one hand [on the surface], I was slightly irritated at your response. I mean, does it matter why? Hey, I'm a curious kinda guy! On the other hand, I value your input as it has driven this thread a little further into the subject and has added some additional value to it. So by that token, I appreciate your input th13 ;-)
care to show me any encryption method that is 100% not crackable?Quote:
IPSec and WPA, both are crackable, no?
WPA is excellent, and many people are using it. the constraint at this time is everyone with older equipment that does not support it, but as time passes people will buy newer equipment and adopte that form of encryption. It is strong and hard to crack when implemented correctly.
XTC46,
You're right about WPA. If implemented correctly (basic rule, use a complex passphrase) it is very hard to break. WPA requires someone to capture an enormous amount of packets in crack it.
About IPSec, some security is better than none. We use certificate authentication with RSA two-factor authentication as well as 3DES on our VPNs.
I must admit, we fell for the hype driven around IPSec a number of years back when it was touted as the golden egg of security. What we quickly found is that AH (authentication header) would not work through NAT devices and that ESP (encapsulated payload) carried a decent size overhead. Long and short, we were bamboozled.
IPv4 has encryption capabilities only they're not used. What a shame. This little known fact eats at me daily knowing that the foundation is there but no one will step up and build the house.
Now, the next lesson in IPSec was learned after we hooked up site to site tunnels. This worked wonderful for other locations we operate, however, when you hook up a site to site tunnel to an outside agency, all you've done is make a nice encrypted tunnel to an untrusted network.
Today, IPSec has a very limited role as we phase in newer technologies. I have deployed EAP-FAST for wireless and I now use the Juniper SSL VPN. Both have proven to be the right way to fly. But will they endure? No. In steps regulatory compliance, NIST 800 and and the infamous 2 factor auth. I'm not sure where we will be tomorrow. The ride is always an adventure.
What about the fact that IPSec will be [edit: IS part of] included in the IPv6 standard?
We don't have any IPsec VPN. We're moving towards rolling out SSL VPN using Netilla and possibly Juniper.
We have no wireless at all within the organisation we don't think we have a need for wireless that outweighs the security issues it has.
I was at a presentation by http://www.fortresstech.com/ earlier in the year. They took apart wireless IPsec quite comprehensively (to sell their products).
What's that old saying? Just because it's in there doesn't make it good.Quote:
What about the fact that IPSec will be [edit: IS part of] included in the IPv6 standard?
I'm actively watching some of the far eastern Countries which currently have IPv6 implementations running. I'm curious how the protocol flys in the real world instead of on paper.
IPSec has certainly been a let down for me (and others I have spoken to in the industry). Let's see if it rises from the ashes in IPv6, but I wont be betting the farm on it, that's for sure.
Aspman, could you run by us some of the highlights of the benefit of IPSec wireless that was presented to you by fortresstech.com?
TH13, you have actually done me a HUGE favor here. For some reason, I did not realize that I could compile in support for IPv6 in my kernel and still have IPv4 functionality. For some reason, I thought it was either IPv4 or IPv6, not both.
So I did just that, recompiled kernel for IPv6 support, and everything is working great! I am very happy about this! And I would not of even thought to try this were ity not for your feedback. So thanks a million ;-) Like I said, I did not realize that I could do IPv6 internally and still have IPv4 functionality externally. That is awesome!
One problem with this however, is what are my options for internal servers on my network that need to be accessed by the IPv4 web? I have heard of translators for this, but my understanding is that they slow things down considerably. That being the case, do I have any other options, or are those internal servers going to have to remain IPv4 [externally] / ipv6[internally]?
Unfortunately, you're stuck for now. The translators you speak of are indeed crappy and slow. This is another reason why I'm watching others instead of running my own IPv6 experiments (for now).
Yep, all the major distros allow you to compile IPv6 support into the kernel while keeping IPv4. Some people don't compile the support but I have done so ever since it was available. Even though I have no real use for it right now, you never know when something might present itself.
If you want to play, there is a site which will give you addresses to pure IPv6 hosts. Again, this would only be for you to stretch the legs of the protocol. If you want I can dig that info up.
Also, since each interface has two addresses [1 IPv4 and 1 IPv6], how can I enforce the use of IPv6 only on internal interfaces? IPv6 uses IP6tables, and IPv4 - iptables. Can I put IPv6 rules in IPv4 iptables? If this is the case, then I could just drop all IPv4 packets on the internal interfaces while accepting IPv6 packet. However, since IPv6 uses IP6tables, I have a feeling I cannot do this, or can I? If not, would there be another way to enforce the use of IPv6 only internally?
Good question. I've never tried this out, however, I don't *believe* you'll be able to mix the IPTABLE rules.
As far as forcing IPv6 only on the inside, there has to be a config file somewhere that will allow you to do this. Again, I haven't played with it in my own lab only because I have tons of other tests queued up that take priority over my own curiousity. Hehe.
If you do find success, please post it here so we can all benefit.
Well, I just tryed that out and ip6tables rules DO work in my IPv4 firewall script.
So, all I need to do to enforce the use of IPv6 internally is drop all IPv4 packets using something like
iptables -A INPUT -i eth1 -p all -j DROP
and then add
ip6tables -A INPUT-i eth1 -p all -J ACCEPT
[EDIT:] Actually, I stated that incorrectly. iptables itself is not using ipv6 rules, the firewall script runs, and drops everything on eth1 using IPtables rules, and then adds the ACCEPT rules to ip6tables. The script itself is, of course neither IPv4 nor IPv6!
I still have the information pack but I can't remember the detail of the presentation:
My only notes are:
VPNs - still send unicast and multicast in clear,
CDP reveals network info
ARP packets sent in clear
The blurb from the info pack on IPSEC is from a whitepaper published by Elwers (www.elwers.co.uk) but I can't see it on the website. Elwers sell to public bodies here, police & NHS mostly.
Quote:
The Role of VPNs
To protect their wireless infrastructures, some enterprises have implemented VPNs on wireless gateways. VPNs are designed to offer strong encryption using AES, and combined with a remote authentication Dial-in user service (RADIUS) or Terminal access controller access control system plus (TACACS+) server, VPNs can provide strong user authentication. However, VPNs were never designed to encrypt a LAN - they were designed to protect traffic travelling from LAN to LAN - and therefore do not encrypt all LAN traffic. This is an inherent vulnerability in a WLAN since a great deal of intelligence about the LAN can be gained by simply monitoring broadcast traffic - which VPNs do not encrypt., because the were not designed to. Hackers can glean information such as the identities of the Domain Controllers, the domain name of the network, which hosts are routers and what the routed topology looks like, and so on. ARP packets are also vulnerable, which can be sniffed and used in ARP poisoning DoS attacks.
Hmmm. Is this entirely in context? There are some pretty broad general statements (Incorrect ones...at least they aren't definitive) that I could take issue with:
VPN's have been around a lot longer then AES encryption. What was used before then, encryption-via-osmosis? Authentication does not HAVE to be RADIUS or TACACS+. And the VPN itself has nothing to do with user authentication; in fact, in the original conception I would bet VPN's had nothing to do with users, but where intended for site-to-site connectivity.Quote:
To protect their wireless infrastructures, some enterprises have implemented VPNs on wireless gateways. VPNs are designed to offer strong encryption using AES, and combined with a remote authentication Dial-in user service (RADIUS) or Terminal access controller access control system plus (TACACS+) server, VPNs can provide strong user authentication.
This sounds like a description of a client-VPN (i.e. application and/or hardware that an end user utilizes to connect while out of the office.) It also sounds like a personal white paper or a term paper; or at the very least, a white paper written to a very specific audience with an intended target or reaction.
Sorry Aspman, I'm not picking on you, I just take exception to these generalities being offered up without clarification.
No, it's fair comment. It would be no great surprize that the paper presented an uneven view Elewers were reselling FortressTech equipment as an addon wireless security device.
I can't remember the detail of the presentation so I was just presenting what I had. We're opposed to wireless here. We don't belive the benefits to be had here outweigh the negatives and the presentation provided us with more ammunition to turn down those pushing for wireless.
I should have made it clear that the text comes from a source with a vested interest in highlighting wireless security problems including ipsec. My bad :(
This thread is really haunting me!!!!!
It has changed from IPSec to IPv6 ( not that that is bad!, IMHO )
First, I have played with IPSec very little as my gut told me not to.
Second, I find several things very strange, unless I missed a PM or something.
How did Dr. Psy come up with???Quote:
TH13, you have actually done me a HUGE favor here. For some reason, I did not realize that I could compile in support for IPv6 in my kernel and still have IPv4 functionality. For some reason, I thought it was either IPv4 or IPv6, not both.
For some reason, in eight and a half hours and without discernable reason he recompiled a kernel ( doable, even on an i486, ) but then in eleven minutes realized the difference between IP6tables and iptables ( where is that documented? How did he find it so quick? ), then in another thirty-seven minutes had tried ip6tables rules in IPv4 firewall script which worked, no wait, fourteen minutes later edited to state ( I think ) that he needed to use iptables ( IPv4 ruleset ) to drop everything then it defaults to the ip6tables rules ??????
I have thought for quite a while that IPv6 ( again, my gut instincts ) was the answer to many questions and could not understand why it was not been embraced wholeheartedly by the industry. That said, so far, as I understand it, iptables can not " translate " IPv4 to IPv6, and visa versa ( including, most importantly, NATing ).
OK, if anyone is following here ( only if you are as drunk as me I expect ) I was under the assumption ( it has been a few months ) that there were Internet Servers that one could test IPv6 on, but one would have to tunnel to them via IPv4. Is this still the case?
And how does one test IPv6 firewall rules unless both sides ( internal and external ) are both using IPv6? ( Dr. Psy must have set up internally multiple IPv6 machines in that eight and a half hours? Again, doable, but nothing stated as such. )
I am not attacking, just inquiring. I am fairly proficient ( in my mind ) with iptables, but have yet to conquer, while working with iptables since it's inception, the nuances of IP6tables. You ( Dr. Psy ) have seemed to grasp it in hours. Could you enlighten us? Could you explain your testing procedures?
No, not your bad at all. I wasn't taking issue with you, just the paper you quoted, and you made it perfectly clear it was info presented to you. "I'm good." ;)
I would agree with you on wireless, except I really can't take that position. I have a client that has said "We are deploying wireless. We are paying you to help secure it." So, our response was "Great. We'll be instituting 802.11i with certificate based authentication as well as several other measures that are not implicitly part of 11i."
Surprisingly, IPSec or SSL vpn is not part of the solution...at least, not in the form I commonly think of them (Check Point Secure Remote/Client, various Nortel app's, Cisco VPN client, etc.) One could probably make an argument that the authentication and access control measures could constitute a client-VPN over wireless solution. I'll have to think on it more.
Cheers!
LOL!
IKnowNot, You didn't miss anything other than thoughts which were going on inside myself throughout this thread. My mind seems to take a subject and expand it in several different directions at once. So dont feel bad, you missed nothing. Bring up a subject and my mind just does that to me.
So at any rate, let me try to address each issue or question you had.
true. But on the other hand, that is also the logical progression happening in real life as well. Had I had the knowledge earlier that I got from this post, I would have more likely asked the question, how many of you are using IPv6. Again, I did not realize that one could have both in the kernel. I thought you either needed to implement IPv6 all the way around or leave it at IPv4. And then th13 brought up the issue about IPv6, and now, several topics are being disucssed here including, IPSec, IPv6, Wireless and WPA!Quote:
It has changed from IPSec to IPv6 ( not that that is bad!, IMHO )
Again, this was an internal process happening in my mind as the thread unraveled. Nothing of that exact nature was discussed on this board. It was just the direction this post led my mind in.Quote:
How did Dr. Psy come up with.....
The kernel recompile took little time, really. And where is the ip6tables documented and how did I find it so fast?Quote:
For some reason, in eight and a half hours and without discernable reason he recompiled a kernel ( doable, even on an i486, ) but then in eleven minutes realized the difference between IP6tables and iptables ( where is that documented? How did he find it so quick? )
Google. After having recompiled the kernel and booted it, my first thought was my firewall [always thinking security first]. Looked it up as this thread was unraveling.
No, no, no. Originally I was trying to figure out how I could enforce the use of IPv6, and figured I would need to do it with firewall rules. But wasnt sure if I could use ip6tables rules in ipv4 ruleset. I wasnt sure if one could actually use iptables and ip6tables rules at the same time [which I now know, you can) So I simply added the ip6tables rules to the firewall script that I already had. And it worked. Appended iptables rule to drop everything on eth1 on my already running firewall with iptables. And also appended ip6tables rules to the script, which allowed IPv6 on the same interfaces via ip6tables.Quote:
then in another thirty-seven minutes had tried ip6tables rules in IPv4 firewall script which worked, no wait, fourteen minutes later edited to state ( I think ) that he needed to use iptables ( IPv4 ruleset ) to drop everything then it defaults to the ip6tables rules ??????
As far as I know, yes. If you are setup via IPv6, you can connect to other systems running IPv6 via a tunnel. However, thisis not what I am doing. I am running IPv6 strictly internally. I am still 100% IPv4 externally.Quote:
OK, if anyone is following here ( only if you are as drunk as me I expect ) I was under the assumption ( it has been a few months ) that there were Internet Servers that one could test IPv6 on, but one would have to tunnel to them via IPv4. Is this still the case?
Yes, this is the case. On my external interface, I am still using IPv4. But internally, am using IPv6 set up on multiple systems. Which is, of course how I could test this myself at both ends. On the question of testing procedures, no 'thorough' testing has been done yet TH13. Obviously, thre hasn't been time for that. I simply tested IPv6 accessibility by setting up two systems which were IPv6 enabled. The IPv6 firewall rules were added and an echo request was sent to system number two, while system number two was running tcpdump in IPv6 mode to capture the IPv6 ICMP echo request packet, and vice versa.Quote:
And how does one test IPv6 firewall rules unless both sides ( internal and external ) are both using IPv6? ( Dr. Psy must have set up internally multiple IPv6 machines in that eight and a half hours? Again, doable, but nothing stated as such. )
I agree with you 110% IKnowNot. I really wish that this IPv6 thing was in place across the entire net. Wish it was already standard. Being as security oriented as I am, I am always trying to think of ways to add more security to whatever I do. It's not that I am the paranoid type really. And it's not that I have nuclear Missle Launch Codes on my system that I must protect with my life! It's just that I LOVE computer security! It's what I eat for dinner! This being the case, and knowing a little bit about IPv6, I know that it is much more robust and secure than IPv4. I want this thing in place ASAP! But I know the reasons why it is taking so long.
So... I was really extremely happy to come to the realization that IPv6 could be set up on my internal network, while still maintaining IPv4 connectivity and functionality. I realize that nobody said that here. It was not discussed or posted. But while this thread was unravelling, another window on my computer had a console open, and yet another, was running searches on Google. So I understand your confusion. However I thanked TH13, because simply by him bringing up the subject in this context, it led me to look some things up as I wondering about a few things on the subject of IPv6, which then led me to discover that I indeed could have both IPv6 and IPv4 running on my system at the same time. Realizing this, I whipped out make menuconfig and recompiled my kernel [all that needed to be done to my existing kernel was check about 7 or 8 options for IPv6 fuinctionality). Compiled it, booted it, and came back here and thanked TH13! And while the thread was still unravaling, I was testing various things in another open window, and still researching on google. I posted the question about iptables and ip6tables after I had started thinking about how I could enforce the use of IPv6 internally, since any servers I had open to the public would still need an IPv4 interface. They would also have an IPv6 interface but how would I force the use of IPv6 only internally if the interface was also accessible via IPv4. And while posting that, I was researching the issue. Didnt find anything exactly pertaining to that, so I started testing it myself to find out. When I discovered that I could use iptables and ip6tables together at the same ime through the use of a script. I came back and posted that this was possible.
So, as you can see there was a lot more going on on my side of things inside my own head rather than just wht was posted on this thread, I was researching, compiling and testing throughout this thread.
Sorry for the confusion there! Now you understand. correct? lol!
I followed every word, but the next line explained it all to me:Quote:
Sorry for the confusion there! Now you understand. correct? lol!
Oh, so your one of those ( or is that us ? ;) ) Now I understand, hopefully others will too.Quote:
My mind seems to take a subject and expand it in several different directions at once.
I haven't yet had the time ( one of the many projects on my lists for some time ) to do just what you did ( my wife's lists always seem to take precedence somehow. ) I have had both compiled into the kernel on my firewall box, in fact all my linux machines, for some time. My IPv6 firewall rules: log then DROP everything. I'm hoping someday I'll actually see reference to a dropped packet. Maybe when I see that it will move up the priority on my testing?
Thanks for the info on your testing, you answered a few questions floating in the back of my head for a while. But now some of the old questions are coming back.
For one, how do I set up my DNS server?
Are the existing and new protocols being developed for VoIP compatible with IPv6?