How many of you are using IPSec

[Dr. Psy]

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!

[Aspman]

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.

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.

[zencoder]

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:

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.

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.

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.

[Aspman]

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

[IKnowNot]

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

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?

[zencoder]

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!

[Dr. Psy]

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.

It has changed from IPSec to IPv6 ( not that that is bad!, IMHO )

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!

How did Dr. Psy come up with.....

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.

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? )

The kernel recompile took little time, really. And where is the ip6tables documented and how did I find it so fast?
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.

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 ??????

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.

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?

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.

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. )

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.

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!

[IKnowNot]

Sorry for the confusion there! Now you understand. correct? lol!

I followed every word, but the next line explained it all to me:

My mind seems to take a subject and expand it in several different directions at once.

Oh, so your one of those ( or is that us ? ) Now I understand, hopefully others will too.

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?