I'm a long-time Linux user and I use a PowerBook for admin and development duties. (I also admin Win2K machines with it.)
It's really outstanding. I can NFS mount drives in either direction, allowing me to pick the most convenient path of building on my laptop or on my dev Linux box. The PB comes with X, so I can fire up any Linux GUI tool I need. I have bash so I can script everything I need. And, best of all, I can mimic my run environment (Tomcat and PostgreSQL) on my laptop for completely portable development.
Hey--guess how I back up my laptop! I use a cron job that invokes rsync over ssh to a Linux box. Oh, the joys of having a Unix-based laptop!
The only awkward part would be switching between Sys V and BSD style commands (ps -elf vs. ps -aux, for example).
In one sentence: yes, it can be secure (as far as we know), but you have to use it correctly.
The weakness with PPTP comes from the fact that you can use a dictionary attack on the password. Dictionary attacks work when you have weak passwords, i.e. passwords that appear in (or are easily derived from) words that appear in a dictionary.
If you read the article (or any article on PPTP weaknesses), you'll see that you are generally considered safe if you use a strong password. If you have access to a Unix box, you can do the following:
The output you see would qualify as a strong password, and if you use this technique you should be safe. Notice, though, that it's a massive pain to use and type: no one can memorize it.
Another option, though not guaranteed to be as secure, is a rule of thumb I learned a long time ago: pick three unrelated words, and separate them with punctuation characters. For example, I choose boat, touch, and George, and I come up with: boat*touch!George as my password. To be super secure, I've heard that it should be at least 20 characters long, though I don't know the mathematical justification for a length of 20.
You don't need a training class. If you go through the Cisco web site, you'll see that all of the manuals are right there. While lengthy, those manuals provide very comprehensive discussion around the specific commands/steps to implement the concepts. If you look at the tech notes, you'll find all sorts of information on the theory. Together, you get a comprehensive picture of both the high-level concepts and the low-level commands.
I just went through a CallManager/CRS installation, and spent most of my time reading the Admin Guides and the System Guides, and spent some quality time with the VoIP-specific IOS guides to setup my gateways. Really, look in the manual, and you'll see: Step 1: bla, Step 2: bla, To Verify Setup: bla. No training, no certification, just a working system. Those manuals are great, and TAC will help you out on the rare occasion you get stuck.
From your question, it really looks like you've figured out the CallManager stuff, and are now just optimizing your network. The thing to keep in mind about VoIP is that it's oIP. All of the knowledge that you already have about traffic optimization applies directly to the voice traffic.
Spend your training bucks elsewhere, preferably at a conference that takes you to Tahiti.
It's true, the new Prescott chips take a huge step back in TDP, essentially giving up the ground they gained when they introduced the Northwood core. However, IIRC, the Williamette TDP was better than the AMD competition at the time, meaning the Northwood beat the pants of the comparable AMD chip, TDP-wise.
I know for certain that it's the CPU fans that are responsible for the noise. The noise increased dramatically when I replaced the CPU fans, which I had to do to keep the thermal alarm on the motherboard from sounding after a couple hours of use. FWIW, the system in question is a dual AMD Athlon-MP running at 1.8.
AMD chips run significantly hotter than Intel chips. I have a dual-AMD box that, to remain stable, moves enough air to make a helicopter jealous. As an added bonus, it acts as a heater for the entire room, while making enough noise to bug neighbors two or three blocks away. I run it as little as possible.
By comparison, I have an Intel server that runs 24/7, is inaudible, and makes no difference in the ambient room temperature.
It's worth the (mostly negligible) cost/performance difference for quiet/heat-free computing.
Cable ISPs have no experience running a teleco, but they have a marginal technical advantage over a non-ISP VoIP provider simply because of better network routing
Actually, I think that, by owning the network end point (i.e. the consumer VoIP gateway) as well as all of the switching fabric between the end point and the VoIP-to-POTS gateway, the ISP has a substantial advantage in terms of quality of service.
Think about it this way: by using the QoS features that come with the switches, the ISP could guarantee a much better user experience for their customers, while third-party VoIP providers would have to trust best effort. (In fact, if they ISPs are less-than-moral, they could also use QoS on their network to ensure that they had better voice quality than any competitors that also rode their network.)
I use a T-Mobile with a Nokia 6310, a triband GSM phone that supports Bluetooth and GPRS. I have an older 15" TiBook that doesn't have built-in Bluetooth, so I picked up the D-Link USB Bluetooth Adapter.
OS X recognizes the D-Link device and the phone, and I use it quite regularly to do email, ssh, and/. as I travel around various cities. It's a little pokey, but it works well enough to recommend: I've used it to do emergency service on a Linux box from the back of a cab that was driving through Seattle, and it saved my bacon.
I believe you would have similar success with the Nokia 3650, which appears to retail for $50 with contract.
I'm just guessing, but you'd probably implement the same ECC mechanism in software that ECC memory does in hardware.
A quick google shows that ECC memory typically uses Hamming codes (or similar variations), which is pretty much what you'd expect. Skimming a few of the links, it would appear that most ECC memory is designed to correct a 1-bit error on a word. It is entirely possible that you can have the right combination of bit-errors that will slip past the ECC, regardless of whether it was implemented in hardware or software.
It does seem a bit tedious to implement it in software, though. Each read and write to memory would have to be wrapped in the code that reads/detects or generates/writes the ECC bits to another location in memory.
For the curious, you can learn more about Hamming codes here.
I've used the Adaptec card before, and I learned the hard way that you need to be aware of heat. Two modern high-speed IDE drives generate a large amount of heat, and if you mount the two directly next to one another in the case you may well burn one out, as I did.
The dead drive may have had some other defect, but I doubt it as the thermal alarm on the MB would sound after a few hours of usage. Even after replacing the drive (and being sure the two drives were mounted far enough apart to allow airflow), the machine still occasionally comes up with blank disks, requiring an OS reinstall.
Just something to keep in mind when you're building your system--YMMV.
I understand where you're coming from, but EAP/TLS clients were written by people who also understand this (at least the ones I've played with). Thus, when validation of the server certificate fails, you don't get an option that says "proceed anyway". On Win XP, you get something that looks
like this. No option to accept.
That's not to say that you can't turn validation off. You can, but it requires that the user go into some in-depth options on their NIC configuration. I, the evil uber-hacker, could attempt to persuade my victim to walk through these steps or, better yet, download and install a key from my evil-CA which I would then use on the evil-rogue-AP to spoof a session.
Shoot, at that point it's just as easy to persuade said user to download and install a trojan, which works equally well on both wired and wireless networks, rendering the security differences moot. And, as a bonus, the wired network doesn't even require that I construct and install an evil-spoofing-AP!
All the same, if you have a link to the demo you mentioned, please post it. I'd be interested, for sure.
EAP/TLS requires that you have PKI in place. To deploy it, you have to set up a CA. Presumably anyone worth their beans will have used a secure connection to distribute the root certificate and client keys to the wireless users.
The authentication process verifies that both the client and the server are who they claim to be using certificates. If someone tries to forge packets, say with a rogue AP, they won't know the authenticator's secret key and thus the client will reject the connection.
How does your exploit pretend to be the real AP and authenticator if it doesn't know the correct secret key, or can't fake the CA chain? Welcome to the world of asymetric cryptosystems!
If you're not familiar with EAP/TLS, a quick google comes up with a whitepaper from Cisco. It covers the concepts of PKI, CA, etc.
If you can defeat 1024 bit PKI, then I think there are much more profitable things to hack aside from WLAN!
First, you can create a secure wireless network. It's complex, and requires a fair amount of kit, but you can do it. The basic premise is to avoid giving an attacker enough data encrypted with the same WEP key--i.e. rotate your keys frequently. There are several options to do this: EAP/TLS, LEAP, and PEAP to name three. Set your key rotation frequency to 3600 seconds, and you're pretty much set. If you have APs that support EAP/TLS, there is an open source solution.
OTOH, find an out-of-the-way conference room with an open wired port and you're off to the races. For the longest time the default shipping configuration for Cisco switches came with all ports in monitor mode, allowing you to sniff away. (Fortunately, this appears to no longer be the case.)
Slashdot Mirror
I'm a long-time Linux user and I use a PowerBook for admin and development duties. (I also admin Win2K machines with it.)
It's really outstanding. I can NFS mount drives in either direction, allowing me to pick the most convenient path of building on my laptop or on my dev Linux box. The PB comes with X, so I can fire up any Linux GUI tool I need. I have bash so I can script everything I need. And, best of all, I can mimic my run environment (Tomcat and PostgreSQL) on my laptop for completely portable development.
Hey--guess how I back up my laptop! I use a cron job that invokes rsync over ssh to a Linux box. Oh, the joys of having a Unix-based laptop!
The only awkward part would be switching between Sys V and BSD style commands (ps -elf vs. ps -aux, for example).
Highly, highly, recommended.
In one sentence: yes, it can be secure (as far as we know), but you have to use it correctly.
The weakness with PPTP comes from the fact that you can use a dictionary attack on the password. Dictionary attacks work when you have weak passwords, i.e. passwords that appear in (or are easily derived from) words that appear in a dictionary.
If you read the article (or any article on PPTP weaknesses), you'll see that you are generally considered safe if you use a strong password. If you have access to a Unix box, you can do the following:
On my Mac, the output looks like this:
The output you see would qualify as a strong password, and if you use this technique you should be safe. Notice, though, that it's a massive pain to use and type: no one can memorize it.
Another option, though not guaranteed to be as secure, is a rule of thumb I learned a long time ago: pick three unrelated words, and separate them with punctuation characters. For example, I choose boat, touch, and George, and I come up with: boat*touch!George as my password. To be super secure, I've heard that it should be at least 20 characters long, though I don't know the mathematical justification for a length of 20.
You don't need a training class. If you go through the Cisco web site, you'll see that all of the manuals are right there. While lengthy, those manuals provide very comprehensive discussion around the specific commands/steps to implement the concepts. If you look at the tech notes, you'll find all sorts of information on the theory. Together, you get a comprehensive picture of both the high-level concepts and the low-level commands.
I just went through a CallManager/CRS installation, and spent most of my time reading the Admin Guides and the System Guides, and spent some quality time with the VoIP-specific IOS guides to setup my gateways. Really, look in the manual, and you'll see: Step 1: bla, Step 2: bla, To Verify Setup: bla. No training, no certification, just a working system. Those manuals are great, and TAC will help you out on the rare occasion you get stuck.
From your question, it really looks like you've figured out the CallManager stuff, and are now just optimizing your network. The thing to keep in mind about VoIP is that it's oIP. All of the knowledge that you already have about traffic optimization applies directly to the voice traffic.
Spend your training bucks elsewhere, preferably at a conference that takes you to Tahiti.
It's true, the new Prescott chips take a huge step back in TDP, essentially giving up the ground they gained when they introduced the Northwood core. However, IIRC, the Williamette TDP was better than the AMD competition at the time, meaning the Northwood beat the pants of the comparable AMD chip, TDP-wise.
I know for certain that it's the CPU fans that are responsible for the noise. The noise increased dramatically when I replaced the CPU fans, which I had to do to keep the thermal alarm on the motherboard from sounding after a couple hours of use. FWIW, the system in question is a dual AMD Athlon-MP running at 1.8.
AMD chips run significantly hotter than Intel chips. I have a dual-AMD box that, to remain stable, moves enough air to make a helicopter jealous. As an added bonus, it acts as a heater for the entire room, while making enough noise to bug neighbors two or three blocks away. I run it as little as possible.
By comparison, I have an Intel server that runs 24/7, is inaudible, and makes no difference in the ambient room temperature.
It's worth the (mostly negligible) cost/performance difference for quiet/heat-free computing.
Cable ISPs have no experience running a teleco, but they have a marginal technical advantage over a non-ISP VoIP provider simply because of better network routing
Actually, I think that, by owning the network end point (i.e. the consumer VoIP gateway) as well as all of the switching fabric between the end point and the VoIP-to-POTS gateway, the ISP has a substantial advantage in terms of quality of service.
Think about it this way: by using the QoS features that come with the switches, the ISP could guarantee a much better user experience for their customers, while third-party VoIP providers would have to trust best effort. (In fact, if they ISPs are less-than-moral, they could also use QoS on their network to ensure that they had better voice quality than any competitors that also rode their network.)
I use a T-Mobile with a Nokia 6310, a triband GSM phone that supports Bluetooth and GPRS. I have an older 15" TiBook that doesn't have built-in Bluetooth, so I picked up the D-Link USB Bluetooth Adapter.
OS X recognizes the D-Link device and the phone, and I use it quite regularly to do email, ssh, and /. as I travel around various cities. It's a little pokey, but it works well enough to recommend: I've used it to do emergency service on a Linux box from the back of a cab that was driving through Seattle, and it saved my bacon.
I believe you would have similar success with the Nokia 3650, which appears to retail for $50 with contract.
I'm just guessing, but you'd probably implement the same ECC mechanism in software that ECC memory does in hardware.
A quick google shows that ECC memory typically uses Hamming codes (or similar variations), which is pretty much what you'd expect. Skimming a few of the links, it would appear that most ECC memory is designed to correct a 1-bit error on a word. It is entirely possible that you can have the right combination of bit-errors that will slip past the ECC, regardless of whether it was implemented in hardware or software.
It does seem a bit tedious to implement it in software, though. Each read and write to memory would have to be wrapped in the code that reads/detects or generates/writes the ECC bits to another location in memory.
For the curious, you can learn more about Hamming codes here.
I've used the Adaptec card before, and I learned the hard way that you need to be aware of heat. Two modern high-speed IDE drives generate a large amount of heat, and if you mount the two directly next to one another in the case you may well burn one out, as I did.
The dead drive may have had some other defect, but I doubt it as the thermal alarm on the MB would sound after a few hours of usage. Even after replacing the drive (and being sure the two drives were mounted far enough apart to allow airflow), the machine still occasionally comes up with blank disks, requiring an OS reinstall.
Just something to keep in mind when you're building your system--YMMV.
I understand where you're coming from, but EAP/TLS clients were written by people who also understand this (at least the ones I've played with). Thus, when validation of the server certificate fails, you don't get an option that says "proceed anyway". On Win XP, you get something that looks like this. No option to accept.
That's not to say that you can't turn validation off. You can, but it requires that the user go into some in-depth options on their NIC configuration. I, the evil uber-hacker, could attempt to persuade my victim to walk through these steps or, better yet, download and install a key from my evil-CA which I would then use on the evil-rogue-AP to spoof a session.
Shoot, at that point it's just as easy to persuade said user to download and install a trojan, which works equally well on both wired and wireless networks, rendering the security differences moot. And, as a bonus, the wired network doesn't even require that I construct and install an evil-spoofing-AP!
All the same, if you have a link to the demo you mentioned, please post it. I'd be interested, for sure.
Ok, let's take EAP/TLS.
EAP/TLS requires that you have PKI in place. To deploy it, you have to set up a CA. Presumably anyone worth their beans will have used a secure connection to distribute the root certificate and client keys to the wireless users.
The authentication process verifies that both the client and the server are who they claim to be using certificates. If someone tries to forge packets, say with a rogue AP, they won't know the authenticator's secret key and thus the client will reject the connection.
How does your exploit pretend to be the real AP and authenticator if it doesn't know the correct secret key, or can't fake the CA chain? Welcome to the world of asymetric cryptosystems!
If you're not familiar with EAP/TLS, a quick google comes up with a whitepaper from Cisco. It covers the concepts of PKI, CA, etc.
If you can defeat 1024 bit PKI, then I think there are much more profitable things to hack aside from WLAN!
This is simply not true.
First, you can create a secure wireless network. It's complex, and requires a fair amount of kit, but you can do it. The basic premise is to avoid giving an attacker enough data encrypted with the same WEP key--i.e. rotate your keys frequently. There are several options to do this: EAP/TLS, LEAP, and PEAP to name three. Set your key rotation frequency to 3600 seconds, and you're pretty much set. If you have APs that support EAP/TLS, there is an open source solution.
OTOH, find an out-of-the-way conference room with an open wired port and you're off to the races. For the longest time the default shipping configuration for Cisco switches came with all ports in monitor mode, allowing you to sniff away. (Fortunately, this appears to no longer be the case.)