General > General Technical Chat
Server Error Reports
gnif:
We are aware, debugging an issue with the main website is having an impact on services.
wilfred:
--- Quote from: gnif on September 17, 2023, 10:29:09 am ---
--- Quote from: Karel on September 17, 2023, 06:16:55 am ---Security through obscurity... hmmm...
--- End quote ---
You are misusing the term, the software in use is open source and available to the public as such, public scrutiny. How we have decided to make use of this software and build the EEVBlog infrastructure is kept private as this knowledge makes it easier to infiltrate the system if someone does get a foothold in some software/service. This is called "operational security" and is very different to "security through obscurity".
--- End quote ---
According to my dictionary the use of obscurity was spot on. Your desire to keep knowledge of the infrastructure private and not well known is pretty much the dictionary's definition.
gnif:
--- Quote from: wilfred on October 04, 2023, 02:30:43 pm ---
--- Quote from: gnif on September 17, 2023, 10:29:09 am ---
--- Quote from: Karel on September 17, 2023, 06:16:55 am ---Security through obscurity... hmmm...
--- End quote ---
You are misusing the term, the software in use is open source and available to the public as such, public scrutiny. How we have decided to make use of this software and build the EEVBlog infrastructure is kept private as this knowledge makes it easier to infiltrate the system if someone does get a foothold in some software/service. This is called "operational security" and is very different to "security through obscurity".
--- End quote ---
According to my dictionary the use of obscurity was spot on. Your desire to keep knowledge of the infrastructure private and not well known is pretty much the dictionary's definition.
--- End quote ---
Say whatever you like, we do not rely on the server being kept secure by omitting information as such this is not "security through obscurity". Limiting operational information to the general public is a no brainier as it gives administrators more time to combat attacks in progress that are trying to probe for such information to progress the attack. Sure the attacker may not be able to break in at all due to the security layers in place, but why risk it? Why hand out a map to the treasure even though the treasure box is padlocked?
Again, we are using open software with industry standard well known and reviewed security implementations. We are not relying on security though some custom logic that is closed and has not been peer reviewed. We are not "secure" because we rely on the fact that people don't know the specifics of how things are configured.
If we are to apply your definition of "security by obscurity" one could argue that the authentication credentials used to access the servers are kept secret and as such is "security by obscurity".
Nominal Animal:
--- Quote from: wilfred on October 04, 2023, 02:30:43 pm ---According to my dictionary the use of obscurity was spot on. Your desire to keep knowledge of the infrastructure private and not well known is pretty much the dictionary's definition.
--- End quote ---
Bullshit. By that definition, not keeping your password on a post-it note stuck to your monitor would be security-through-obscurity also.
In the industry, "security through obscurity" is used to describe the situation when knowing the technical and implementation details of the system is sufficient to break the security scheme. "Operational security" is used to describe the situation when the technical details of the system are kept private to limit the attack surface: knowing them does not break the security scheme, but it may help an attacker trying to break the security scheme by providing useful targeting information.
For example, if one accepts incoming SSH connections on a nonstandard port, and keeps that port number private (only telling those who do use those SSH connections), one applies operational security, not security through obscurity. Revealing the port does not compromise security per se, but it can help attackers. As security measures go, it is a very weak one, but if combined with diverting incoming connections from addresses that have recently tried to connect to other ports (especially the standard SSH port) to a designated honey pot, it can be a powerful tool for early automated attack detection. Essentially, it does not provide any added security per se, but it definitely can help in detecting intrusion attempts, and focusing human security monitoring to where it is most likely needed. Also, it does nothing at all against directed attacks.
Gnif uses the simplest operational security approach there is, one that is literal millenia old: minimize the attack surface by only providing information to those who actually need it.
The reason this is done, is that it makes attacks and intrusion attempts harder and more costly. Before anyone can attack, they need to know what they are attacking, where, and how. Even if an attacker uncovers this information, the security is not yet compromised; they still need to do the attack itself. If an attacker cannot uncover that information, they need to guess what kind of an attack might work, and usually try several ones to have any kind of chance at success, and failed attack attemps tend to be easy to detect.
What benefit would there be for gnif or Dave or other gnif's clients, if they revealed the system security scheme details publicly? Here, absolutely nothing; it would just make it easier for attackers to design and plan intrusion attempts to these systems.
There are certain forums where specific details and their application and usefulness are discussed, but to reduce the possibility of attackers exploiting the information discussed, they tend to be closed/insular, invitation-only, with real-world identity verification. Me, I prefer physical meetings and face-to-face discussions, because of body language.
bd139:
Sort of.
To be fair it doesn't necessarily increase the attack risk but that depends on who you are. Most of the attack IVs are drive by i.e. from network scans etc. No one is going to read something in this forum and go "yay lets tear eevblog a new asshole". No joking but in the scale of things no one really gives a fuck about EEVblog because the end game has no financial advantage. I mean you might have pissed off an adversary by banning them for being a prick when posting but that's about the only major risk vector. Realistically defending against automated network attacks is probably the only major worry, followed by casual idiots attacking problems with the forum software. Fundamentally the profile depends if you are an interesting target i.e. you have a lot of PII, financial data and/or information to leverage to generate money in some way. Not all endpoints are equal.
But at no point should you make anyone's life easier for them if they are an adversary and that means keeping schtum on configuration, location, versions, everything. A dumbass could work that out. Do you pin a sign on your door with "I have a nice TV and the window is over there?". Nope!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version