Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API

From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "security by obscurity"
-
We got DDoS attacked by some spam bot crawler thing.
Higher ups called a meeting so that one of our seniors could present ways to mitigate these attacks.
- If a custom, "obscure" header is missing (from api endpoints), send back a basic HTTP challenge. Deny all credentials.
- Some basic implementation of rate limiting on the web server
We can't implement DDoS protection at the network level because "we don't even have the new load balancer yet and we've been waiting on that for what... Two years now?" (See: spineless managers don't make the lazy network guys do anything)
So now we implement security through obscurity and DDoS protection... Using the very same machines that are supposed to be protected from DDoS attacks.16 -
When you spend 6 hours figuring out how to best encrypt/decrypt your unimportant website cookies just because you don't want people to see how bad you are at naming stuff :x
-
Public REST (-inspired) API. Should I skip numeric IDs because it's easy for consumers to snoop around?
Example:
POST api/foo
201 Created api/foo/69
Uh, I'll get 68 just because I can. Hopefully it returns Unauthorized, unless we some kind of bug.
Is it just security by obscurity if I use, like, guids or something instead of sequental IDs?17 -
A thing that I am annoyed that people are getting wrong is security by obscurity.
You have heard of it and being told it is bad. It is so bad that it alone is a counter argument. Let me set you straight:
>>>Security by obscurity is the best security you will ever have<<<
There is an asterisk: It is probably not right for your business. But that is for the end.
Security by obscurity means to hide something away. Most security is based on hiding. You hide your private key or your password or whatever other secret there is. If you had a 2048 long sequence of port knocking, that would be fine, too.. Or it would be fine if it wasn't observable. You could write this down in your documentation and it wouldn't be security by obscurity. It would just be security. Weird, but fine.
The real meat of obscurity is: No one knows that there is someone. The server you port knock looks like a harmless server, but suddenly has an open port to a bad application for an IP, but only if that IP went to 25 other ports first.
In the animal kingdom, there are different survival strategies. One of them is being an apex predator or at least so big and lumbering that no predator wants a piece of you. That's our security. It is upstream security. It is the state.
But what is the rest of the animal kingdom going to do? Well, run away. That works. Not being caught. And those not fast enough? Hide! Just be invisible to the predators. They cannot triple check every leaf and expect to be done with the tree before starving. That's security by obscurity. Or hide in the group. Zebras. Easy to see, hard to track in the group. Look like everyone else.
There is a reason why drug smugglers don't have vaults in the carry-on. Arrive at the customs and just refuse to open the vault. If the vault is good enough. Nope, they lack the upstream security by the state. The state is there enemy, so they need obscurity rather than cryptographic safety.
And so, for a private person, having a port knocking solution or disguising a service as another service is a great idea.
Every cryptography course happily admits that the moment they can catch you physically, cryptography is useless. They also teach you about steganography. But they omit to tell you that obscurity is the second best solution to having a stronger army when you cannot rely on your state as upstream security.
Why did I say, not a good idea for companies?
1. It is self-defeating, since you have to tell it to all employees using it. A shared secret is no secret. And therefore it cannot be documented.
2. It makes working with different servers so much harder if there is a special procedure for all of them to access them. Even if it were documented. (See 1.)
3. You're a company, you are advertising your services. How to hide that you run them?
Do you see how those are not security relevant questions? Those are implementation relevant questions.
Here is an example:
Should you have your admins log into servers as normal users before elevating to root or is that just obscurity? Well, not for security purposes. Because that foothold is so bad, if compromised, it makes little difference. It is for logging purposes, so we have a better server log who logged in. Not only always root. But if our log could differentiate by the used private key, there is no issue with that.
If it is your private stuff, be creative. Hide it. Important skill. And it is not either, or. Encrypt it your backup, then hide it. Port knock, then required an elliptic curve private key to authenticate.
It is a lot of fun, if nothing else. Don't do it with your company. Downsides are too big. Cheaper to hire lawyers if needed.2 -
FUCK you "WP iThemes Security Pro".
First of all, your FUCKing services isn't really secure, more like security by obscurity.
Don't get me started on how you probably don't have a dedicated team of security experts.
But oh well, the customer insisted I must install you, despite my advise.
Second of all, Don't FUCKing send me emails regarding "Scheduled malware scan failed" without it containing the FUCKing error message, not some generic "http_request_failed" error, why did it FUCKing fail?
Last but not least: Don't FUCKing clutter is with with your giant ass logo that takes up half my screen or FUCKing spam such as your upcoming events, newly published books/articles, incorrect "documentation"2 -
I've been wondering about renting a new VPS to get all my websites sorted out again. I am tired of shared hosting and I am able to manage it as I've been in the past.
With so many great people here, I was trying to put together some of the best practices and resources on how to handle the setup and configuration of a new machine, and I hope this post may help someone while trying to gather the best know-how in the comments. Don't be scared by the lengthy post, please.
The following tips are mainly from @Condor, @Noob, @Linuxxx and some other were gathered in the webz. Thanks for @Linux for recommending me Vultr VPS. I would appreciate further feedback from the community on how to improve this and/or change anything that may seem incorrect or should be done in better way.
1. Clean install CentOS 7 or Ubuntu (I am used to both, do you recommend more? Why?)
2. Install existing updates
3. Disable root login
4. Disable password for ssh
5. RSA key login with strong passwords/passphrases
6. Set correct locale and correct timezone (if different from default)
7. Close all ports
8. Disable and delete unneeded services
9. Install CSF
10. Install knockd (is it worth it at all? Isn't it security through obscurity?)
11. Install Fail2Ban (worth to install side by side with CSF? If not, why?)
12. Install ufw firewall (or keep with CSF/Fail2Ban? Why?)
13. Install rkhunter
14. Install anti-rootkit software (side by side with rkhunter?) (SELinux or AppArmor? Why?)
15. Enable Nginx/CSF rate limiting against SYN attacks
16. For a server to be public, is an IDS / IPS recommended? If so, which and why?
17. Log Injection Attacks in Application Layer - I should keep an eye on them. Is there any tool to help scanning?
If I want to have a server that serves multiple websites, would you add/change anything to the following?
18. Install Docker and manage separate instances with a Dockerfile powered base image with the following? Or should I keep all the servers in one main installation?
19. Install Nginx
20. Install PHP-FPM
21. Install PHP7
22. Install Memcached
23. Install MariaDB
24. Install phpMyAdmin (On specific port? Any recommendations here?)
I am sorry if this is somewhat lengthy, but I hope it may get better and be a good starting guide for a new server setup (eventually become a repo). Feel free to contribute in the comments.24 -
Today, I found out that the webmaster for the organization I volunteer at is using a security-by-obscurity PHP implemented design for the private data of our members. I've talked with him about it, but for a variety of reasons to do with organization and workload, it won't be changing.
Fml.3