It is usually high packets per second that brings a machine to its knees, as opposed to bits or bytes per second.
If you had a given amount of sustained data coming into a machine, it would typically be much less taxing if those packets where large, as opposed to the same bandwidth being used up with very small packets.
Packets are variable length and a single packet will be much larger than a single byte.
Without a firewall, a fresh Windows 2000 installation will have a worm within a minute of connecting to the internet. And that's without ever opening a single application. No other operating system EVER MADE can compare to that.
Viruses don't care if you got a little sticker. They're too stupid to notice. And that makes up 99% of hack attempts
This is really a non-point. Patched or properly-configured systems were never vulnerable to Code Red or most other network worms (except in that window where someone is downloading patches to a new box).
Agreed. However...
There's no point in feeling safe because there's so many ineffective hack attempts -- its the 0-day and unpublished stuff you need to worry about.
A firewall can allow local traffic and block public for example. Regardless of whether a service is patched or not, an attack to a blocked port from the internet should not succeed.
For the typical XP user, that is what matters. Since they don't go fixing something (or having it fixed) until it is very obviously broken (exploited).
Well then please do fuck off and build your own internet with your own broken protocols, because the rest of us here would like to interoperate.
And sending replies to requests on ports a server does not serve on (or does not want to serve on for that packet), is so high on the interoperability list.
There's nothing wrong with security through obscurity unless that's all you've got.
In other words, it is okay, but if it is all you have it is terrible overall.
I think the AC ment to say that if security through obscurity is all you can achive then it should be used; but otherwise real security is preferred.
What are you smoking? This (what you were replying to), "AC explicitly says that you need more than security through obscurity", says it just as anyone who comprehends English would take it. The original poster did after all, use the word unless.
It is fine, as long as it is not all you have.
99.8% security is good. 99.8% + 0.1% is better. 0.1% on it's own is terrible.
The 0.1% helps, but should not be relied on to be anything other than 0.1% security.
I wonder that the AC is hiding...
Huh!?!? He is using English. You interpret it badly and assume he is hiding something?
While adding obscurity to a secure system is not necessarily a bad thing. (Why not make it harder, especially if the costs in time and aggravation are low.) It isn't something that should be counted on.
I agree one hundred percent! And said it too.
But the above isn't really security through obscurity. It is really a two tiered access control. At the first tier you must have the appropriate clearance level or above to access data at that classification level. The second tier is more amibigous, but you must have a reason to actually access the information. Access control is generally a good thing.
One meaning of obscurity, is that something is hidden or unknown.
Obscurity, would be more like having a single room for all confidential, secret and top secret files which are in turn stored in unlocked filing cobinets. The files are randomly ordered and numbered. Anyone can access the room, but you have to know the number on the file your looking for to find it easily out of alll the files in the room. It's obscure. It's a lot more difficult to find specific information. It's not secure.
Yes, that fits well with the commonly said "security through obscurity" phrase. I just beleive that obscurity does not have to be that simple, since the word has more meaning than that.
"Security through obscurity" does not always have to be extremely trivial. It can add too, but should never be relied on, for security.
In computer security groups the term obscurity goes furthen than just implify matter that is not directly visible.
That's my point, although it is not common.
The term obscurity is used to define a method which seemingly hides the data but does so in a trivial and often extremely ineffective manner.
Yes I know. Yet the word obscurity means so much more.
You bring up encryption as a method of obscurity but I'd disagree with this in the general case.
I agree that the "security through obscurity" phrase has come to mean "secret mechanism", amongst computer security people.
I am merely stating that obscurity does get used outside of that commonly used phrase and does actually help outside of it.
If you use a Ceasar chiffer or simple XOR (basically the same thing) to encode data then you have obscurity. It may seem like the data is encrypted but it is merely done so in the most trivial manner, this is obscurity. Breaking such an encryption takes on the order of milliseconds for a computer and would be in a code breakers standard set of tools which do the job automatically.
Caesar.
Obscurity typically implies that while the user believe that he is safe that is not really the case. A user using XOR encryption is using security by obscurity.
Specifically "simple XOR". Yes. Combine XOR with strong random data and plain text.... ; )
A user using 256 bit AES encryption may have obscured their data, but are not using security by obscurity (because that data is genuinly safe).
Not if their password was not obscure enough. If Bill is using good crypto with a password of Bill, then he is rooted.
Reading and replying to most of these posts, is really quite frustrating. Because my bookshelf and career, has been dominated by these issues for more than ten years. People are force feeding me facts that I mostly don't disagree with, because I am willing to use the word "obscurity" outside of the commonly used meaning to computer security people.
Odd that your understanding of security is flawed then.
You perceive my understanding of security to be flawed, because I view "obscurity" to be something beyond it's use in the typical "security through obscurity" usage?
This is called compartmentalisation
Obscurity: "hidden", "out of sight", "unknown".
and is a function of risk management not security per se.
The risk we are specifically talking about here, is security risk.
Functionally, security by obscurity relies on the mechanism being unknown.
The common use of that phrase, is regarding mechanisms. But I do not accept that limited view of the usage of "obscurity" within security. I made that clear. Are we going to allow the true meaning of such a general word to become so limited when used within a given field? I don't accept it. But since I am well aware of the "security through obscurity" term, I felt the need to elaborate, to avoid these types of replies! (Applied Cryptography has been my favourite book for many years. I was also very pleased to find something I discovered for myself, to be documented within it. LFSR's)
By contrast, security without obscurity allows the mechanism to be public and tested, and relies on the secrecy of something easily-changed (password, padlock).
Knowing the control codes, means that an attacker can focus more easily on finding what obscures them (almost like known headers in files). The "character" frequencies of what would be obscured under the noise can help to eventually remove that noise and find how to re-create that noise, etc.
With specific reference to stealthing ports, not only is it false security (as noted,
It can cause a host to be overlooked. It can prevent a DoS (I have seen reports of firewalls crashing under DDoS due to replying, but then the same system staying up with dropping). But most importantly...
If you are dropping packets to a particular port, then you probably are not providing a service on that port. Packets you do receive to it, you should not be. It is not your problem, it differs little to there not even being a host at that IP and it is a very cheap way to block the traffic (for you, not the other end). It is their mistake or malicious intent, so they can bear the brunt of the small inconvenience.
it is possible to determine the existence of a stealthed node)
I am well aware of this, as I have posted elsewhere here that nmap is able to determine a WinXP SP2 machine as being alive, even though it's firewall was on with no exceptions.
but it can lead to difficulty in diagnosing network faults.
If you are dropping packets to a port that has no service, then the difficulty is just having to wait for timeouts. Big deal. I would like to hope that the person diagnosing network faults, knows the network well enough to know what that host should and should not be serving.
At best, you will achieve a negligible reduction in risk.
I try to live my life by this...
What do I have to gain and/or loose by doing one thing, and what do I have to gain and/or loose by doing the other thing?
Politely block packets I don't expect? Gain: Standard compliance, quicker response when someone else makes a mistake or attempts malicious activities. Loose: Possibly host production time if answering a deluge causes a crash.
Drop packets I don't expect? Gain: Bandwidth and possibly availability. Loose: *I* loose nothing (I know my network right?).
So, do I choose to retain standards compliance (for the malicious and mistaken) at the risk of host uptime? Or do I choose to selectively bend standards to improve bandwidth and uptime at the risk of putting some malicious or mistaken people out a little bit?
At worst you will open new avenues of risk (bad network design).
Yeah, because dropping packets to a port that has no service (or should have no service for that packet in particular, depending on the rules), is really bad network design. As opposed to good network design, which politely blocks packets to ports that have no service. Come on!
The problem with this statement is that it assumes that the people who have made certain that the system is a good one has not made any errors. Typically this is the stage where you get weak links in your defences.
The military tends to buy 3rd party security hardware and implement their own security policies.
Just look at CSS for DVD players. I'm sure they were pretty sure that "this is really safe" and that "if we publish our method it will just make it more vulnerable".
You are comparing a badly designed and managed consumer system, against an entity which typically takes years to rigorously trial and audit multiple systems that finally made it through a culling process.
They are pretty far apart as far as importance goes.
If they had in fact published the method for peer review there would have been a lot of real crypto experts who laughed at them instead of the entire world after their precious system was hacked by a bunch of amateurs.
I agree. But the military does consult and hire top experts. Going further and publishing to the public should be of little value if their process was right to begin with. Sometimes it isn't, but that is not the fault of not being open.
Except where they NEEDED to know, but the people who made the choice weren't good enough to make that determination. In that case you have yet another fuckup.
It is a necessary evil. Nothing is perfect and unfortunately humans are an integral part of that.
Yes, because its more likely that its not just the bad guys who find the holes, but also some good solid citizens.
I wasn't talking about source code. I was talking about control protocols (control codes). The public does not need to know it and if the military needs to make the details of secret systems available to the public, to get their help, there is a big problem.
The general open source community does a great job, but how good are they going to be at such specific and uncommon problems, such as those associated with satelite comms (over well paid experts)?
Pay a team of very tightly knit experts and they can take Mach and BSD and build OSX on it. I love Linux and the BSD's, but as far as the desktop goes, they can't hold their own against WinXP and OSX as far as cleanliness and integration goes.
The military have too little to gain and too much to loose by making those types of things public.
; ) That's the thing. Malicious people don't always adhere to RFC's and they are quite happy to break them if it helps their activities. So people who are required to protect networks, need to make the most appropriate decisions to do so, which might include breaking standards.
If it mostly only hurts the malicious, then that should be an acceptable and appropriate decision.
Encryption is obscurity? News to me, I thought the data was altered...:P
Idiot.
\Ob*scu"ri*ty\, n. [L. obscuritas: cf. F. obscurit['e].] The quality or state of being obscure; darkness; privacy; inconspicuousness; unintelligibleness; uncertainty.
It is altered, however it retains a correlation between the original, the encryption algorithm and the key(s) used.
You are correct, but the bad behavior is encouraged everywhere, not just for Windows users.
I'm an OpenBSD and pf user. I don't see it as bad behaviour, since you should typically only be "breaking standards" on packets you should not be receiving anyway.
If you should not receive a particular packet, then why honour it with a polite reply? It is either a mistaken or malicious packet. Unless of course, it is a legitimate tech who should quickly be able to figure out what is going on and be empowered to fix it. If he is not empowered to fix it, then that is a problem with policy (or lack of) or configuration at a more fine grained level. Certainly not the fault of DROP overall.
Your statement that there's _nothing_ wrong with security through obscurity (whether it's all you got or not) is a very dangerous statement to stand behind, which is why I suspect you posted as an AC.
I have worked for military, top tier financial and law enforcement entities (I am not the AC poster, BTW). In the military, no matter how high your security clearance is, if you don't "need to know" something to carry out the job at hand, then you will not get to know it. If you do need to know it and have a high enough clearance, then you will get to know it. That is a security through obscurity policy that helps to make a nation safer.
If a military satelite communications system uses some hypothetically perfect authentication and encryption, then would there be any good reason to publish to the World the specifications of the control codes? No, there would be no good reason, so it should not be made public, regardless of the fact that the crypto is supposed to be perfect. "More eyes looking at the code" would not be good enough in this instance.
Obscurity techniques that lead to higher security, does get used and should get used. Because they usually add a layer of security.
The problem here, is that YOU, along with a lot of others around here, think of "security through obscurity" in the same weak light.
Security through weak obscurity is bad. Relying on it, is unforgivable.
As I said in another post, passwords and encryption are obscurity methods that can be strong.
If they are scanning a subnet for fun, they aren't a real security concern, the people whom you SHOULD worry about do not need a ping reply, as they know there are other ways to see if a host is alove or not, in which case blocking pings does nothing.
pf does not just drop ping packets, it can drop any connection that was not statefully initiated from the trusted side.
Security by obscurity is a bad practice to pass on.
pf dropping packets that it does not expect to get, by no means falls under the typical "security through obscurity" rant that people go on about.
Not all security by obscurity is bad. You probably use it and rely on it every day. The usage of passwords is a form. Your password should be obscure in complexity and privacy. Encryption obscures data.
People have taken the whole "security through obscurity" saying too far and run with it blindly. Relying on weak obscurity is bad, of course. But not all obscurity is weak.
I bet most of that can be chalked up to simple carelessness in installation.
Would not surprise me.
I am no MS fan, however I went ahead with installing SP2 onto my XP Home install, which had Kerio Personal Firewall running, Norton Antivirus 2003 running and Spybot S&D Resident running. I keep Ghost images and have been meaning to move back to my latest clean image, which is why I was so reckless (I wanted to preview it first).
I had to click a gazillion times to appease Kerio and S&D but it eventually finished, seemingly without any issues once it was all done.
Exactly. RAID should never be used in place of backups. How often could you have potentially lost data to human error in software usage/config? And how often to hardware failure?
If you suffer from human error with the software while relying on RAID, you lost your data and get a rude lesson in RAID and backups addressing mutually exclusive problems.
Real RAID, buys production systems time to keep going while a (hopefully) hotspare rebuilds or a replacement disk gets delivered for rebuilding.
RAID saves productivity during what should be only a brief period of vulnerability. Backups prevent complete loss. People who use RAID as a backup, don't understand the limits of RAID or the value of real backups.
So many times, I have had to order tapes from a data bank because some user deleted an "important" file from RAID protected storage.
Hell, I am a sole trader, who legally must keep business records for tax purposes, etc. I rsync my records, email, web site, server configs, site documentation, etc across 5 different machines, spanning 3 different architectures and 5 different OSes. On top of that I keep rotating weekly (CDRW) and permanent monthly (CDR) backups.
This might seem like paranoia, but I do it because I easily can and CDR's are cheap. I can also move to any of those machines and resume my emailing, invoicing, doco, etc. Take one of them on the road (Thinkpad or iBook) if business or disaster dictates and not worry that a worm is going to prevent me from earning my living or answering to the tax man.
Such is life. I'm quite happy with FreeBSD now. Such is life.
Are you avoiding OpenBSD because of Theo?
Seems like such a waste. Love him or hate him, OpenBSD is put together pretty damn well. I started with OpenBSD around when you did (2.5), years before that it was Debian Linux and since then I've played with Net and FreeBSD. I like them all, but there's a lot to love about OpenBSD and it's what I enjoy each day where I have a choice.
I'm glad you're happy with FreeBSD, it just seems a pitty to avoid OpenBSD because the leader may have been rude to you. What matters is that he gets great things done for the project, which you can freely reap.
Well.. I DID RTFM at the time. I saw nothing either saying "We don't do ISO images" or "We do ISO images". That was added after my initial inquiries. Had it been there when I asked, I wouldn't have said anything.
It may well be, that your post substantially helped to get the mention in the FAQ shortly thereafter. On 25th Oct 1999.
I am sure being 6'2" and 260 lbs dosent add to the aerodynamics.
Your weight takes power when you accelerate and your frame takes more and more power the faster you go. It's your frame that contributes to the aerodynamic drag, not your weight.
The soluion to that problem is to put a sufficiently large capacitor in parallel with the voltage source.
Practically speaking, how large a capacitor are you going to get!? I have some massive 50,000uF 50V caps, that wouldn't last so much as a second if I tried to draw a constant amp from it.
You would be better off with a similar sized battery.
For the bush above the house, the highest bush is shaded in different tone (darker vs lighter) on the left outline.
For the bridge, the "dots" on the bridge are not exactly the same. For example, in pic 3 and 5, the dot on the bridge along the highest row to the right side, differ from the rest.
Okay. I picked out lots of very small differences that seemed to be the cause of dither-dots that did not have the same grouping or alignment as each other.
Looking at the PDF, it seems that this is coming down to my laser printers dithering of the PDF's bitmaps, as the outlines, as-viewed, appear anti-aliased and thus have a deal of grey around the edges that needs to be dithered on a B&W printer.
Since I was a child, I could always solve these puzzles within seconds.
How? I cross my eyes so that the two images form an overlapped image to my perception. So I see three images, but concentrate on the "middle" image. This takes some concentration to retain focus and alignment, to begin with, but it does not take long to master doing it quickly.
All the differences appear to flash and really jump out in an instant. That's about the best I could describe the effect. The hard part is trying to circle the differences with a pen whilst holding this state, because the pen comes into just one eyes view and causes loss of alignment.
Slashdot Mirror
Nice throughput- so how long before MS implements it in Longhorn or XP ? :D
As long as OpenBSD and OSX get it, I'll be happy.
The BSD's look pretty lively to me (he says, sitting in his OpenBSD shirt).
Packets Per Second.
It is usually high packets per second that brings a machine to its knees, as opposed to bits or bytes per second.
If you had a given amount of sustained data coming into a machine, it would typically be much less taxing if those packets where large, as opposed to the same bandwidth being used up with very small packets.
Packets are variable length and a single packet will be much larger than a single byte.
Without a firewall, a fresh Windows 2000 installation will have a worm within a minute of connecting to the internet. And that's without ever opening a single application. No other operating system EVER MADE can compare to that.
Except for Windows XP. ; )
Viruses don't care if you got a little sticker. They're too stupid to notice. And that makes up 99% of hack attempts
This is really a non-point. Patched or properly-configured systems were never vulnerable to Code Red or most other network worms (except in that window where someone is downloading patches to a new box).
Agreed. However...
There's no point in feeling safe because there's so many ineffective hack attempts -- its the 0-day and unpublished stuff you need to worry about.
A firewall can allow local traffic and block public for example. Regardless of whether a service is patched or not, an attack to a blocked port from the internet should not succeed.
For the typical XP user, that is what matters. Since they don't go fixing something (or having it fixed) until it is very obviously broken (exploited).
Well then please do fuck off and build your own internet with your own broken protocols, because the rest of us here would like to interoperate.
And sending replies to requests on ports a server does not serve on (or does not want to serve on for that packet), is so high on the interoperability list.
There's nothing wrong with security through obscurity unless that's all you've got.
In other words, it is okay, but if it is all you have it is terrible overall.
I think the AC ment to say that if security through obscurity is all you can achive then it should be used; but otherwise real security is preferred.
What are you smoking? This (what you were replying to), "AC explicitly says that you need more than security through obscurity", says it just as anyone who comprehends English would take it. The original poster did after all, use the word unless.
It is fine, as long as it is not all you have.
99.8% security is good. 99.8% + 0.1% is better. 0.1% on it's own is terrible.
The 0.1% helps, but should not be relied on to be anything other than 0.1% security.
I wonder that the AC is hiding...
Huh!?!? He is using English. You interpret it badly and assume he is hiding something?
While adding obscurity to a secure system is not necessarily a bad thing. (Why not make it harder, especially if the costs in time and aggravation are low.) It isn't something that should be counted on.
I agree one hundred percent! And said it too.
But the above isn't really security through obscurity. It is really a two tiered access control. At the first tier you must have the appropriate clearance level or above to access data at that classification level. The second tier is more amibigous, but you must have a reason to actually access the information. Access control is generally a good thing.
One meaning of obscurity, is that something is hidden or unknown.
Obscurity, would be more like having a single room for all confidential, secret and top secret files which are in turn stored in unlocked filing cobinets. The files are randomly ordered and numbered. Anyone can access the room, but you have to know the number on the file your looking for to find it easily out of alll the files in the room. It's obscure. It's a lot more difficult to find specific information. It's not secure.
Yes, that fits well with the commonly said "security through obscurity" phrase. I just beleive that obscurity does not have to be that simple, since the word has more meaning than that.
"Security through obscurity" does not always have to be extremely trivial. It can add too, but should never be relied on, for security.
In computer security groups the term obscurity goes furthen than just implify matter that is not directly visible.
That's my point, although it is not common.
The term obscurity is used to define a method which seemingly hides the data but does so in a trivial and often extremely ineffective manner.
Yes I know. Yet the word obscurity means so much more.
You bring up encryption as a method of obscurity but I'd disagree with this in the general case.
I agree that the "security through obscurity" phrase has come to mean "secret mechanism", amongst computer security people.
I am merely stating that obscurity does get used outside of that commonly used phrase and does actually help outside of it.
If you use a Ceasar chiffer or simple XOR (basically the same thing) to encode data then you have obscurity. It may seem like the data is encrypted but it is merely done so in the most trivial manner, this is obscurity. Breaking such an encryption takes on the order of milliseconds for a computer and would be in a code breakers standard set of tools which do the job automatically.
Caesar.
Obscurity typically implies that while the user believe that he is safe that is not really the case. A user using XOR encryption is using security by obscurity.
Specifically "simple XOR". Yes. Combine XOR with strong random data and plain text.... ; )
A user using 256 bit AES encryption may have obscured their data, but are not using security by obscurity (because that data is genuinly safe).
Not if their password was not obscure enough. If Bill is using good crypto with a password of Bill, then he is rooted.
Reading and replying to most of these posts, is really quite frustrating. Because my bookshelf and career, has been dominated by these issues for more than ten years. People are force feeding me facts that I mostly don't disagree with, because I am willing to use the word "obscurity" outside of the commonly used meaning to computer security people.
Odd that your understanding of security is flawed then.
You perceive my understanding of security to be flawed, because I view "obscurity" to be something beyond it's use in the typical "security through obscurity" usage?
This is called compartmentalisation
Obscurity: "hidden", "out of sight", "unknown".
and is a function of risk management not security per se.
The risk we are specifically talking about here, is security risk.
Functionally, security by obscurity relies on the mechanism being unknown.
The common use of that phrase, is regarding mechanisms. But I do not accept that limited view of the usage of "obscurity" within security. I made that clear. Are we going to allow the true meaning of such a general word to become so limited when used within a given field? I don't accept it. But since I am well aware of the "security through obscurity" term, I felt the need to elaborate, to avoid these types of replies! (Applied Cryptography has been my favourite book for many years. I was also very pleased to find something I discovered for myself, to be documented within it. LFSR's)
By contrast, security without obscurity allows the mechanism to be public and tested, and relies on the secrecy of something easily-changed (password, padlock).
Knowing the control codes, means that an attacker can focus more easily on finding what obscures them (almost like known headers in files). The "character" frequencies of what would be obscured under the noise can help to eventually remove that noise and find how to re-create that noise, etc.
With specific reference to stealthing ports, not only is it false security (as noted,
It can cause a host to be overlooked. It can prevent a DoS (I have seen reports of firewalls crashing under DDoS due to replying, but then the same system staying up with dropping). But most importantly...
If you are dropping packets to a particular port, then you probably are not providing a service on that port. Packets you do receive to it, you should not be. It is not your problem, it differs little to there not even being a host at that IP and it is a very cheap way to block the traffic (for you, not the other end). It is their mistake or malicious intent, so they can bear the brunt of the small inconvenience.
it is possible to determine the existence of a stealthed node)
I am well aware of this, as I have posted elsewhere here that nmap is able to determine a WinXP SP2 machine as being alive, even though it's firewall was on with no exceptions.
but it can lead to difficulty in diagnosing network faults.
If you are dropping packets to a port that has no service, then the difficulty is just having to wait for timeouts. Big deal. I would like to hope that the person diagnosing network faults, knows the network well enough to know what that host should and should not be serving.
At best, you will achieve a negligible reduction in risk.
I try to live my life by this...
What do I have to gain and/or loose by doing one thing, and what do I have to gain and/or loose by doing the other thing?
Politely block packets I don't expect? Gain: Standard compliance, quicker response when someone else makes a mistake or attempts malicious activities. Loose: Possibly host production time if answering a deluge causes a crash.
Drop packets I don't expect? Gain: Bandwidth and possibly availability. Loose: *I* loose nothing (I know my network right?).
So, do I choose to retain standards compliance (for the malicious and mistaken) at the risk of host uptime? Or do I choose to selectively bend standards to improve bandwidth and uptime at the risk of putting some malicious or mistaken people out a little bit?
At worst you will open new avenues of risk (bad network design).
Yeah, because dropping packets to a port that has no service (or should have no service for that packet in particular, depending on the rules), is really bad network design. As opposed to good network design, which politely blocks packets to ports that have no service. Come on!
The problem with this statement is that it assumes that the people who have made certain that the system is a good one has not made any errors. Typically this is the stage where you get weak links in your defences.
The military tends to buy 3rd party security hardware and implement their own security policies.
Just look at CSS for DVD players. I'm sure they were pretty sure that "this is really safe" and that "if we publish our method it will just make it more vulnerable".
You are comparing a badly designed and managed consumer system, against an entity which typically takes years to rigorously trial and audit multiple systems that finally made it through a culling process.
They are pretty far apart as far as importance goes.
If they had in fact published the method for peer review there would have been a lot of real crypto experts who laughed at them instead of the entire world after their precious system was hacked by a bunch of amateurs.
I agree. But the military does consult and hire top experts. Going further and publishing to the public should be of little value if their process was right to begin with. Sometimes it isn't, but that is not the fault of not being open.
Not everything should be open.
Except where they NEEDED to know, but the people who made the choice weren't good enough to make that determination. In that case you have yet another fuckup.
It is a necessary evil. Nothing is perfect and unfortunately humans are an integral part of that.
Yes, because its more likely that its not just the bad guys who find the holes, but also some good solid citizens.
I wasn't talking about source code. I was talking about control protocols (control codes). The public does not need to know it and if the military needs to make the details of secret systems available to the public, to get their help, there is a big problem.
The general open source community does a great job, but how good are they going to be at such specific and uncommon problems, such as those associated with satelite comms (over well paid experts)?
Pay a team of very tightly knit experts and they can take Mach and BSD and build OSX on it. I love Linux and the BSD's, but as far as the desktop goes, they can't hold their own against WinXP and OSX as far as cleanliness and integration goes.
The military have too little to gain and too much to loose by making those types of things public.
Good point. Is there an RFC for virus behavior?
; ) That's the thing. Malicious people don't always adhere to RFC's and they are quite happy to break them if it helps their activities. So people who are required to protect networks, need to make the most appropriate decisions to do so, which might include breaking standards.
If it mostly only hurts the malicious, then that should be an acceptable and appropriate decision.
Encryption is obscurity? News to me, I thought the data was altered... :P
Idiot.
\Ob*scu"ri*ty\, n. [L. obscuritas: cf. F. obscurit['e].] The quality or state of being obscure; darkness; privacy; inconspicuousness; unintelligibleness; uncertainty.
It is altered, however it retains a correlation between the original, the encryption algorithm and the key(s) used.
If it did not, then it could not be decrypted.
Moron.
You are correct, but the bad behavior is encouraged everywhere, not just for Windows users.
I'm an OpenBSD and pf user. I don't see it as bad behaviour, since you should typically only be "breaking standards" on packets you should not be receiving anyway.
If you should not receive a particular packet, then why honour it with a polite reply? It is either a mistaken or malicious packet. Unless of course, it is a legitimate tech who should quickly be able to figure out what is going on and be empowered to fix it. If he is not empowered to fix it, then that is a problem with policy (or lack of) or configuration at a more fine grained level. Certainly not the fault of DROP overall.
Your statement that there's _nothing_ wrong with security through obscurity (whether it's all you got or not) is a very dangerous statement to stand behind, which is why I suspect you posted as an AC.
I have worked for military, top tier financial and law enforcement entities (I am not the AC poster, BTW). In the military, no matter how high your security clearance is, if you don't "need to know" something to carry out the job at hand, then you will not get to know it. If you do need to know it and have a high enough clearance, then you will get to know it. That is a security through obscurity policy that helps to make a nation safer.
If a military satelite communications system uses some hypothetically perfect authentication and encryption, then would there be any good reason to publish to the World the specifications of the control codes? No, there would be no good reason, so it should not be made public, regardless of the fact that the crypto is supposed to be perfect. "More eyes looking at the code" would not be good enough in this instance.
Obscurity techniques that lead to higher security, does get used and should get used. Because they usually add a layer of security.
The problem here, is that YOU, along with a lot of others around here, think of "security through obscurity" in the same weak light.
Security through weak obscurity is bad. Relying on it, is unforgivable.
As I said in another post, passwords and encryption are obscurity methods that can be strong.
If they are scanning a subnet for fun, they aren't a real security concern, the people whom you SHOULD worry about do not need a ping reply, as they know there are other ways to see if a host is alove or not, in which case blocking pings does nothing.
pf does not just drop ping packets, it can drop any connection that was not statefully initiated from the trusted side.
Security by obscurity is a bad practice to pass on.
pf dropping packets that it does not expect to get, by no means falls under the typical "security through obscurity" rant that people go on about.
Not all security by obscurity is bad. You probably use it and rely on it every day. The usage of passwords is a form. Your password should be obscure in complexity and privacy. Encryption obscures data.
People have taken the whole "security through obscurity" saying too far and run with it blindly. Relying on weak obscurity is bad, of course. But not all obscurity is weak.
I bet most of that can be chalked up to simple carelessness in installation.
Would not surprise me.
I am no MS fan, however I went ahead with installing SP2 onto my XP Home install, which had Kerio Personal Firewall running, Norton Antivirus 2003 running and Spybot S&D Resident running. I keep Ghost images and have been meaning to move back to my latest clean image, which is why I was so reckless (I wanted to preview it first).
I had to click a gazillion times to appease Kerio and S&D but it eventually finished, seemingly without any issues once it was all done.
The same arguement goes for mirrored as well.
Exactly. RAID should never be used in place of backups. How often could you have potentially lost data to human error in software usage/config? And how often to hardware failure?
If you suffer from human error with the software while relying on RAID, you lost your data and get a rude lesson in RAID and backups addressing mutually exclusive problems.
Real RAID, buys production systems time to keep going while a (hopefully) hotspare rebuilds or a replacement disk gets delivered for rebuilding.
RAID saves productivity during what should be only a brief period of vulnerability. Backups prevent complete loss. People who use RAID as a backup, don't understand the limits of RAID or the value of real backups.
So many times, I have had to order tapes from a data bank because some user deleted an "important" file from RAID protected storage.
Hell, I am a sole trader, who legally must keep business records for tax purposes, etc. I rsync my records, email, web site, server configs, site documentation, etc across 5 different machines, spanning 3 different architectures and 5 different OSes. On top of that I keep rotating weekly (CDRW) and permanent monthly (CDR) backups.
This might seem like paranoia, but I do it because I easily can and CDR's are cheap. I can also move to any of those machines and resume my emailing, invoicing, doco, etc. Take one of them on the road (Thinkpad or iBook) if business or disaster dictates and not worry that a worm is going to prevent me from earning my living or answering to the tax man.
Such is life. I'm quite happy with FreeBSD now. Such is life.
Are you avoiding OpenBSD because of Theo?
Seems like such a waste. Love him or hate him, OpenBSD is put together pretty damn well. I started with OpenBSD around when you did (2.5), years before that it was Debian Linux and since then I've played with Net and FreeBSD. I like them all, but there's a lot to love about OpenBSD and it's what I enjoy each day where I have a choice.
I'm glad you're happy with FreeBSD, it just seems a pitty to avoid OpenBSD because the leader may have been rude to you. What matters is that he gets great things done for the project, which you can freely reap.
Well.. I DID RTFM at the time. I saw nothing either saying "We don't do ISO images" or "We do ISO images". That was added after my initial inquiries. Had it been there when I asked, I wouldn't have said anything.
It may well be, that your post substantially helped to get the mention in the FAQ shortly thereafter. On 25th Oct 1999.
I am sure being 6'2" and 260 lbs dosent add to the aerodynamics.
Your weight takes power when you accelerate and your frame takes more and more power the faster you go. It's your frame that contributes to the aerodynamic drag, not your weight.
The soluion to that problem is to put a sufficiently large capacitor in parallel with the voltage source.
Practically speaking, how large a capacitor are you going to get!? I have some massive 50,000uF 50V caps, that wouldn't last so much as a second if I tried to draw a constant amp from it.
You would be better off with a similar sized battery.
For the bush above the house, the highest bush is shaded in different tone (darker vs lighter) on the left outline.
For the bridge, the "dots" on the bridge are not exactly the same. For example, in pic 3 and 5, the dot on the bridge along the highest row to the right side, differ from the rest.
Okay. I picked out lots of very small differences that seemed to be the cause of dither-dots that did not have the same grouping or alignment as each other.
Looking at the PDF, it seems that this is coming down to my laser printers dithering of the PDF's bitmaps, as the outlines, as-viewed, appear anti-aliased and thus have a deal of grey around the edges that needs to be dithered on a B&W printer.
Did you print them?
Cows pocket in 5.
The bridge? They all look the same to me.
The bush above the house? Again, all look the same to me.
By river, you mean the extra riple around the bridge in 2?
The diffs I see are:
1. COAT AIR
2. Extra ripple around bridge.
3. Extra sun ray.
4. No difference here.
5. Cows right pocket (on our left) has moved.
Since I was a child, I could always solve these puzzles within seconds.
How? I cross my eyes so that the two images form an overlapped image to my perception. So I see three images, but concentrate on the "middle" image. This takes some concentration to retain focus and alignment, to begin with, but it does not take long to master doing it quickly.
All the differences appear to flash and really jump out in an instant. That's about the best I could describe the effect. The hard part is trying to circle the differences with a pen whilst holding this state, because the pen comes into just one eyes view and causes loss of alignment.
Anyone else do this?