As someone who works with Ciscos and works for a Cisco Gold Partner:
Thanks for going public. I hope you get a chance to read this, but as far as I'm concerned and will tell anyone who asks that you did everything right and it was Cisco who screwed themselves.
(Not that non-monolithic systems are necessarily exempt from the patch breaking other systems)
However (while off topic), it should be noted that 12.2XR (7600 only, today, but where else are you going to see this level of change) is no longer monolithic. It's a HUGE change in the architecture brought about to address just the type of issues discussed.
While there are advantages to having a more complex system from a security standpoint there are some... largish problems as well. Not the least of which is that there's a strong need to move beyond the password for the average user in the average community and that complex systems to log on to your machine in the morning just aren't going to work.
For high security -- very high security -- environments, perhaps. But my personal feeling is that this isn't where we're going (thumbprint scanners on iPaq's and Thinkpads leap to mind) and I bet a hashing technique so you can't reverse engineer (easily) the original has advantages even if it is less secure.
I have to admit that I'm just not a big IDS/IPS fan. FAR too few people have the time (at least in my experience) to use them well. It doesn't matter what the product is.
What is generally lacking is a policy (which, sadly, security is mostly about) and a concrete idea of what to do when an 'attack' is detected.
And people then buy an expensive new IDS, or spend time to implement one, or whatever. Think it's exciting for a while. And then I come back 3 months later and it's turned off in the corner.
And in the meantime people aren't exploiting the information they already have. Not just the bandwidth graphs but firewall logs, system logs, etc. I personally would recommend finding an event correlation system (anyone know of a good open source one?) along the lines of Netforensics or the former Protego and implementing/that/. And then seeing if an IDS is of any additional use.
IPS -- I haven't had enough personal experience with an in-line IDS to make even a remotely intelligent comment. I like the idea of such a platform but it (as MJR frequently points out) falls foul of being an 'allow everything not specifically denied' platform and thus limited. This is not an outright condemnation, since otherwise you run into best being the enemy of good, but it's something to be considered...
Grip safetys are a feature of 1911's (and, admittedly, others -- but primarily 1911s). And while John Moses Browning's design is still extremely popular (I own two and am getting, I think, a third) it's not exactly modern. Even the Browning High Power (P35) doesn't have a grip safety.
Many modern guns are 'slick slides', as an earlier poster said. My Sig P229 (relatively modern) has no 'active' safety -- it has a firing pin block and a decocker but if you pull at the trigger with a round in the chamber it will go BANG.
I think almost all the handguns I can think of are at least 3 button, though. Even the Colt Single Action Army, though the hammer is one hell of a big 'button':)
No... all NAT traversal does is to wrap the ESP packet in a UDP packet (to the best of my understanding, at any rate).
So if you have the integrity trailer turned on -- which, as the original poster said, is good practice -- it should make no difference if it's a raw ESP packet or an ESP packet in the payload of a UDP packet.
There also look to be some fairly large technical difficulties with implementing the attack, not the least of which is that you have to bit flip arbitrarily to recover the data and depending on your SA lifetime that might not be terribly productive.
Yes, it's a flaw in IPSec and that's bad, but I think it's technically a very difficult attack AND relatively easy to work around.
... and in a WWW based format, as opposed to the executable from an AV company. I think it was two of their researchers -- Colleen Shannon and David Moore.
The animation for Code Red is here .
Sadly, 'the web' appears to be slowly mutating into 'the internet'. I've seen it on technical documents and even the somewhat mocking 'interweb' used.
It's like DMZ or hacker. Not worth fighting, since I'm sure that 90% of the people who use the term automatically include mail and other applications in that term.
(Hey. Mail is web, right? Just look at Yahoo!, Hotmail or even Outlook Web Access!)
I think it's still easier to find an acceptably competent Windows admin in most markets that an acceptably competent Linux/UNIX admin, especially given the salaries that most mid-sized organisations are willing to pay.
Add that to the inherent resistance to change, the cost of retraining users to work on a Linux system at the desktop (or at the mail server, since Exchange/Outlook is a large component of many organisations, together with the tightly integrated AD) and it is an uphill struggle.
I use Linux at the desktop; we have a couple of linux servers doing some tight applications. The majority of our 'core' applications (Mail/Calendaring and accounting, as well as AAA services) are all Windows based and will remain so for the forseeable future because I don't have a viable alternative that I can give to my management that justifies the change and retraining.
I couldn't agree with the above more: respect is not something you're ever given, it something you earn by the way you behave.
I tend to think there's more than competence and confidence; it's a manner of bearing and of how you treat people that'll affect their attitude as well, and confidence can too easily pleaed into 'percieved arrogance'.
Treat people as you'd want to be treated. Be polite, ESPECIALLY to people you don't like. Admit to what you don't know, and come up with a plan to learn it IF you need to.
This doesn't surprise me in the least; depending on the organisation he could well have been asked to leave.
Many of the Universities I work with have Acceptable Use Policies that dictate that you WILL NOT attempt to do things like this without 'appropriate permission', which I gather your friend did not have. In doing so, while he might have thought he was contributing to security (and may in fact have been) he was, to all legal intents and purposes, a cracker attempting to compromise this system -- a stance that has been supported in a (US) Court of Law.
The second part of this is that there are issues with limiting passwords -- there is a point where the limitations actually reduce the search space rather than increase it (an issue, I believe, with one of the FIPS standards).
And finally -- passwords, in general, are soft. One factor authentication is pretty much weak by definition and the combination of rapidly increasing processor power, distributed cracking tools such as this and the various RC projects and tools such as Rainbowcrack are rapidly decreasing their utility. Even Bill Gates has said that the password will have to become a passphrase of 30-40 characters if it survives at all.
It is. However. The only sane tool for most organisations today. And so I come back to a point I made elsewhere; security is a human issue. Choice of weak passwords is a human issue.
I think it's not entirely that they don't care but that you have to find appropriate ways to pass on that information, and appropriate alternatives that'll work for the masses.
(Yes; there will always be some people who just won't care. Then they can get scammed and it'll keep the various law enforcement agencies busy with useless work, etc, etc. And they probably deserve it, since I believe that deliberate ignorance should be punished. But that's my grumpy cynical Monday morning full of meetings side getting control of my outside voice)
The real moral is that security is, at root, a human issue and one that is extremely hard to address via machines and technology only.
The answer is training for users, in a fashion that is understandable explaining at least some of the details of security and concepts. And it must be repeated, and done in different fashions to have as wide an exposure as possible and as wide an impact as possible ('loose lips sink ships', anyone?)
But this is a) Hard b) expensive c) hard to measure the impact of
This means that most organisations who are truthfully more concerned about the appearance of security than the actual impact will NOT take these steps and thus people are vulnerable to identity theft and companies are more vulnerable to social engineering.
DoD is already planning a migration...
on
The Next Net
·
· Score: 1
At least according to this article. And adoption by a major US Government Agency will if not force at least strongly encourage organisations doing business in that arena to follow. And then their upstreams. And so on.
Also, in all honesty, I fear that the 4 billion number is low, not high and NAT/PAT are only stopgap measures. (Especially with the relatively wide range of protocols that require application level awareness to actually translate, including such staples as H.323 and the rest of the multimedia stable).
Add to that the large blocks that are allocated AS large blocks and only fractionally used (or not at all; at one stage one of my former customers had a registered Class B for 200 or so employees. And that entire network space was NAT'd to someone else's space prior to reaching the Internet) and the traction will have to happen, regardless of if your ISP understands it now.
Personally, I like being able to remember IP addresses, and not having to totally rely on DNS. But that's not going to be feasible forever.
You know... the first two questions and the answers are excellent.
I'm not sure that having it FIPS-140 certified buys a vast amount from a technical perspective above and beyond the first two. It's a necessary step for getting the Federal government to use it, but I'd trust the external peer review prior to that.
However -- there's the two points addressed: open standard and accepted for review. Given some time to analyse and review it, this sounds like a decent addition to the arsenal, IF it passes said review.
(I'm no cryptographer. I don't even play one on/.)
It's the standard crypto algorithm; I, personally, would be happy if they turn the algorithm over to open peer review. Anything else smacks of security by obscurity to me.
If the algorithm is openly available and openly reviewed it may well be a viable alternative, though my understanding was that one of the reasons Rijndael was selected as the AES algorithm was it's ease of implementation in hardware and low memory footprint as compared to several of the other contenders.
If it's not? Snake oil, or at least possibly. And I hate 'possibly'.
The ILECs (Incumbant Local Exchange Carriers) were required by the 1996 Telecom Act to open up their copper plants to other carriers (CLECs, or competitive local exchange carriers) for a certain period of time, in order to be allowed to provide long distance services. I believe this was to further limit the monopoly that each baby bell had in their area since they'd already got the most expensive side of the arena, the physical wiring.
...well. Will many people read them, on-line? Even working in the IT industry; even with good LCD monitors, laptops, eBooks and whatever I've still noticed a strong tendency (and one that I'm very guilty of) to destroy great swathes of forest to generate the paper to print out the on-line doc so I can digest it better.
I do; I have the awesome Codeweaver's Crossover Office installed on my laptop so I/can/ use MS apps if and when I have to, but I try and do most of my word processing and spreadsheet functionality in OO. This is mainly since I've become increasingly irritated with the Office suite, not just for bloat but for the automated sidebars and whatever the HELL they did to styles in XP and 2K3. Mind you -- final versions of almost everything are in MS Office format so my cow-orkers can deal with them.
I've found that Writer is, in general, solider that Word for large documents; it's style support is definitely superior and the outline numbering for headers and integration into ToC's is better. It took adjustment, but I'm happier producing documentation and deliverables with it than I ever was in word.
Math seems a little quirkier to me; I use it less and tend to fall back to Excel more. However, for the basic accounting, budgeting and proposal type spreadsheets that are all I need in my job role, I find I can do 90% of my work in it.
Impress? Sorry. Still got to be Powerpoint for those pre-sales presos and post-sales trainings. Again, that could be a familiarity issue on my part, but the difficulties I've found in handling dedicated title slides and section breaks plus the lack of some of the auto-scaling geatures made me unhappy. (I'd love someone to tell me I'm being dumb, since I'd rather use it over PPT...)
From what I've seen, yes -- it's not/good/ to have packet loss. And, yes, it can be a syllable.
But not always, and people are adept at filling in the blanks in that sort of thing; analagous to talking to someone with a radically different accent to what you're used to.
Actually, the point about games is well made. Most of those other protocols (especially SMTP) are FAR less sensitive to latency, though they generate far more aggregrate traffic than voice.
In fact, I suspect that you could simply do this on packet size and actually accelerate the performance of 'traditional' apps while still negatively impacting VoIP. Just shove a few of those big packets on the wire first.
Mind you, this wouldn't be exactly foolproof, but it'd be an interesting approach. I'm not a lawyer, so I've no idea if it's actually defendable in court, either.
You know. I just read what I posted. The above poster is totally correct; voice can stand limited packet loss, absolutely, thanks to the small payload per packet.
What it cannot take is the latency or jitter.
It's obviously time to shut up and stop posting when I'm making that blatant of an error.
On cell phones: that can be unacceptable. In a VoIP environment, from the testing I've done, above 250ms things start getting seriously strange thanks to the packet switched stuff.
And I think QoS is an answer (not the answer) even when there is sufficient bandwidth -- for the reason above. Latency and avoiding inappropriate delays. I want to shove my (usually small) voice packets on the wire in a reasonable time frame. I want to interleave them with larger packets; I may even want to deliberately fragment those larger packets to make for a more efficient interleaving model (ATM QoS on a Cisco relies on multilink PPPoA just so I/can/ interleave; many of the frame QoS techniques do similar things to their layer 2 transport frames).
In an IP Telephony network we, as an organisation, do QoS on gig links. And no, those gig links aren't heavily utilised. But we'd like to ensure that even at a bad time the phone works; people REALLY REALLY like the phone to work.
Packet loss? Video is less sensitive than voice to packet loss. I can lose a packet, yes. But I'd like to avoid it since people know what a phone sounds like and people know what voice is, and since I want to use UDP to avoid overhead on my traffic (small data per packet; don't oversubscribe. In fact, it's common to use compressed headers to further reduce the VoIP overhead).
And on bandwdith; that's all codec and header compression dependent, now, isn't it?
Slashdot Mirror
As someone who works with Ciscos and works for a Cisco Gold Partner:
Thanks for going public. I hope you get a chance to read this, but as far as I'm concerned and will tell anyone who asks that you did everything right and it was Cisco who screwed themselves.
I've heard few people say differently, either.
You have to follow that requirement, today.
(Not that non-monolithic systems are necessarily exempt from the patch breaking other systems)
However (while off topic), it should be noted that 12.2XR (7600 only, today, but where else are you going to see this level of change) is no longer monolithic. It's a HUGE change in the architecture brought about to address just the type of issues discussed.
While there are advantages to having a more complex system from a security standpoint there are some ... largish problems as well. Not the least of which is that there's a strong need to move beyond the password for the average user in the average community and that complex systems to log on to your machine in the morning just aren't going to work.
For high security -- very high security -- environments, perhaps. But my personal feeling is that this isn't where we're going (thumbprint scanners on iPaq's and Thinkpads leap to mind) and I bet a hashing technique so you can't reverse engineer (easily) the original has advantages even if it is less secure.
I have to admit that I'm just not a big IDS/IPS fan. FAR too few people have the time (at least in my experience) to use them well. It doesn't matter what the product is.
/that/. And then seeing if an IDS is of any additional use.
What is generally lacking is a policy (which, sadly, security is mostly about) and a concrete idea of what to do when an 'attack' is detected.
And people then buy an expensive new IDS, or spend time to implement one, or whatever. Think it's exciting for a while. And then I come back 3 months later and it's turned off in the corner.
And in the meantime people aren't exploiting the information they already have. Not just the bandwidth graphs but firewall logs, system logs, etc. I personally would recommend finding an event correlation system (anyone know of a good open source one?) along the lines of Netforensics or the former Protego and implementing
IPS -- I haven't had enough personal experience with an in-line IDS to make even a remotely intelligent comment. I like the idea of such a platform but it (as MJR frequently points out) falls foul of being an 'allow everything not specifically denied' platform and thus limited. This is not an outright condemnation, since otherwise you run into best being the enemy of good, but it's something to be considered...
Well....
:)
Grip safetys are a feature of 1911's (and, admittedly, others -- but primarily 1911s). And while John Moses Browning's design is still extremely popular (I own two and am getting, I think, a third) it's not exactly modern. Even the Browning High Power (P35) doesn't have a grip safety.
Many modern guns are 'slick slides', as an earlier poster said. My Sig P229 (relatively modern) has no 'active' safety -- it has a firing pin block and a decocker but if you pull at the trigger with a round in the chamber it will go BANG.
I think almost all the handguns I can think of are at least 3 button, though. Even the Colt Single Action Army, though the hammer is one hell of a big 'button'
No ... all NAT traversal does is to wrap the ESP packet in a UDP packet (to the best of my understanding, at any rate).
So if you have the integrity trailer turned on -- which, as the original poster said, is good practice -- it should make no difference if it's a raw ESP packet or an ESP packet in the payload of a UDP packet.
There also look to be some fairly large technical difficulties with implementing the attack, not the least of which is that you have to bit flip arbitrarily to recover the data and depending on your SA lifetime that might not be terribly productive.
Yes, it's a flaw in IPSec and that's bad, but I think it's technically a very difficult attack AND relatively easy to work around.
... and in a WWW based format, as opposed to the executable from an AV company. I think it was two of their researchers -- Colleen Shannon and David Moore. The animation for Code Red is here .
Sadly, 'the web' appears to be slowly mutating into 'the internet'. I've seen it on technical documents and even the somewhat mocking 'interweb' used.
It's like DMZ or hacker. Not worth fighting, since I'm sure that 90% of the people who use the term automatically include mail and other applications in that term.
(Hey. Mail is web, right? Just look at Yahoo!, Hotmail or even Outlook Web Access!)
I think it's still easier to find an acceptably competent Windows admin in most markets that an acceptably competent Linux/UNIX admin, especially given the salaries that most mid-sized organisations are willing to pay.
Add that to the inherent resistance to change, the cost of retraining users to work on a Linux system at the desktop (or at the mail server, since Exchange/Outlook is a large component of many organisations, together with the tightly integrated AD) and it is an uphill struggle.
I use Linux at the desktop; we have a couple of linux servers doing some tight applications. The majority of our 'core' applications (Mail/Calendaring and accounting, as well as AAA services) are all Windows based and will remain so for the forseeable future because I don't have a viable alternative that I can give to my management that justifies the change and retraining.
I couldn't agree with the above more: respect is not something you're ever given, it something you earn by the way you behave.
I tend to think there's more than competence and confidence; it's a manner of bearing and of how you treat people that'll affect their attitude as well, and confidence can too easily pleaed into 'percieved arrogance'.
Treat people as you'd want to be treated. Be polite, ESPECIALLY to people you don't like. Admit to what you don't know, and come up with a plan to learn it IF you need to.
This doesn't surprise me in the least; depending on the organisation he could well have been asked to leave.
Many of the Universities I work with have Acceptable Use Policies that dictate that you WILL NOT attempt to do things like this without 'appropriate permission', which I gather your friend did not have. In doing so, while he might have thought he was contributing to security (and may in fact have been) he was, to all legal intents and purposes, a cracker attempting to compromise this system -- a stance that has been supported in a (US) Court of Law.
The second part of this is that there are issues with limiting passwords -- there is a point where the limitations actually reduce the search space rather than increase it (an issue, I believe, with one of the FIPS standards).
And finally -- passwords, in general, are soft. One factor authentication is pretty much weak by definition and the combination of rapidly increasing processor power, distributed cracking tools such as this and the various RC projects and tools such as Rainbowcrack are rapidly decreasing their utility. Even Bill Gates has said that the password will have to become a passphrase of 30-40 characters if it survives at all.
It is. However. The only sane tool for most organisations today. And so I come back to a point I made elsewhere; security is a human issue. Choice of weak passwords is a human issue.
Well....
I think it's not entirely that they don't care but that you have to find appropriate ways to pass on that information, and appropriate alternatives that'll work for the masses.
(Yes; there will always be some people who just won't care. Then they can get scammed and it'll keep the various law enforcement agencies busy with useless work, etc, etc. And they probably deserve it, since I believe that deliberate ignorance should be punished. But that's my grumpy cynical Monday morning full of meetings side getting control of my outside voice)
The real moral is that security is, at root, a human issue and one that is extremely hard to address via machines and technology only.
The answer is training for users, in a fashion that is understandable explaining at least some of the details of security and concepts. And it must be repeated, and done in different fashions to have as wide an exposure as possible and as wide an impact as possible ('loose lips sink ships', anyone?)
But this is
a) Hard
b) expensive
c) hard to measure the impact of
This means that most organisations who are truthfully more concerned about the appearance of security than the actual impact will NOT take these steps and thus people are vulnerable to identity theft and companies are more vulnerable to social engineering.
Also, in all honesty, I fear that the 4 billion number is low, not high and NAT/PAT are only stopgap measures. (Especially with the relatively wide range of protocols that require application level awareness to actually translate, including such staples as H.323 and the rest of the multimedia stable).
Add to that the large blocks that are allocated AS large blocks and only fractionally used (or not at all; at one stage one of my former customers had a registered Class B for 200 or so employees. And that entire network space was NAT'd to someone else's space prior to reaching the Internet) and the traction will have to happen, regardless of if your ISP understands it now.
Personally, I like being able to remember IP addresses, and not having to totally rely on DNS. But that's not going to be feasible forever.
You know ... the first two questions and the answers are excellent.
/.)
I'm not sure that having it FIPS-140 certified buys a vast amount from a technical perspective above and beyond the first two. It's a necessary step for getting the Federal government to use it, but I'd trust the external peer review prior to that.
However -- there's the two points addressed: open standard and accepted for review. Given some time to analyse and review it, this sounds like a decent addition to the arsenal, IF it passes said review.
(I'm no cryptographer. I don't even play one on
It's the standard crypto algorithm; I, personally, would be happy if they turn the algorithm over to open peer review. Anything else smacks of security by obscurity to me.
If the algorithm is openly available and openly reviewed it may well be a viable alternative, though my understanding was that one of the reasons Rijndael was selected as the AES algorithm was it's ease of implementation in hardware and low memory footprint as compared to several of the other contenders.
If it's not? Snake oil, or at least possibly. And I hate 'possibly'.
The ILECs (Incumbant Local Exchange Carriers) were required by the 1996 Telecom Act to open up their copper plants to other carriers (CLECs, or competitive local exchange carriers) for a certain period of time, in order to be allowed to provide long distance services. I believe this was to further limit the monopoly that each baby bell had in their area since they'd already got the most expensive side of the arena, the physical wiring.
...well. Will many people read them, on-line? Even working in the IT industry; even with good LCD monitors, laptops, eBooks and whatever I've still noticed a strong tendency (and one that I'm very guilty of) to destroy great swathes of forest to generate the paper to print out the on-line doc so I can digest it better.
I do; I have the awesome Codeweaver's Crossover Office installed on my laptop so I /can/ use MS apps if and when I have to, but I try and do most of my word processing and spreadsheet functionality in OO. This is mainly since I've become increasingly irritated with the Office suite, not just for bloat but for the automated sidebars and whatever the HELL they did to styles in XP and 2K3. Mind you -- final versions of almost everything are in MS Office format so my cow-orkers can deal with them.
I've found that Writer is, in general, solider that Word for large documents; it's style support is definitely superior and the outline numbering for headers and integration into ToC's is better. It took adjustment, but I'm happier producing documentation and deliverables with it than I ever was in word.
Math seems a little quirkier to me; I use it less and tend to fall back to Excel more. However, for the basic accounting, budgeting and proposal type spreadsheets that are all I need in my job role, I find I can do 90% of my work in it.
Impress? Sorry. Still got to be Powerpoint for those pre-sales presos and post-sales trainings. Again, that could be a familiarity issue on my part, but the difficulties I've found in handling dedicated title slides and section breaks plus the lack of some of the auto-scaling geatures made me unhappy. (I'd love someone to tell me I'm being dumb, since I'd rather use it over PPT...)
Uhm....
/good/ to have packet loss. And, yes, it can be a syllable.
From what I've seen, yes -- it's not
But not always, and people are adept at filling in the blanks in that sort of thing; analagous to talking to someone with a radically different accent to what you're used to.
Actually, the point about games is well made. Most of those other protocols (especially SMTP) are FAR less sensitive to latency, though they generate far more aggregrate traffic than voice.
In fact, I suspect that you could simply do this on packet size and actually accelerate the performance of 'traditional' apps while still negatively impacting VoIP. Just shove a few of those big packets on the wire first.
Mind you, this wouldn't be exactly foolproof, but it'd be an interesting approach. I'm not a lawyer, so I've no idea if it's actually defendable in court, either.
You know. I just read what I posted. The above poster is totally correct; voice can stand limited packet loss, absolutely, thanks to the small payload per packet.
What it cannot take is the latency or jitter.
It's obviously time to shut up and stop posting when I'm making that blatant of an error.
It's not on the last mile that they care about. They'll continue to provide that.
It's the backbone where this has an impact, where it's not just your traffic, but everyone elses too.
Just serialise your VoIP traffic first. You will have better quality calls.
Conslutant. Cow-orker. You know...
:)
I'm just an intellectual whore these days.
On cell phones: that can be unacceptable. In a VoIP environment, from the testing I've done, above 250ms things start getting seriously strange thanks to the packet switched stuff.
/can/ interleave; many of the frame QoS techniques do similar things to their layer 2 transport frames).
And I think QoS is an answer (not the answer) even when there is sufficient bandwidth -- for the reason above. Latency and avoiding inappropriate delays. I want to shove my (usually small) voice packets on the wire in a reasonable time frame. I want to interleave them with larger packets; I may even want to deliberately fragment those larger packets to make for a more efficient interleaving model (ATM QoS on a Cisco relies on multilink PPPoA just so I
In an IP Telephony network we, as an organisation, do QoS on gig links. And no, those gig links aren't heavily utilised. But we'd like to ensure that even at a bad time the phone works; people REALLY REALLY like the phone to work.
Packet loss? Video is less sensitive than voice to packet loss. I can lose a packet, yes. But I'd like to avoid it since people know what a phone sounds like and people know what voice is, and since I want to use UDP to avoid overhead on my traffic (small data per packet; don't oversubscribe. In fact, it's common to use compressed headers to further reduce the VoIP overhead).
And on bandwdith; that's all codec and header compression dependent, now, isn't it?