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 through obscurity"
-
!security
(Less a rant; more just annoyance)
The codebase at work has a public-facing admin login page. It isn't linked anywhere, so you must know the url to log in. It doesn't rate-limit you, or prevent attempts after `n` failures.
The passwords aren't stored in cleartext, thankfully. But reality isn't too much better: they're salted with an arbitrary string and MD5'd. The salt is pretty easy to guess. It's literally the company name + "Admin" 🙄
Admin passwords are also stored (hashed) in the seeds.rb file; fortunately on a private repo. (Depressingly, the database creds are stored in plain text in their own config file, but that's another project for another day.)
I'm going to rip out all of the authentication cruft and replace it with a proper bcrypt approach, temporary lockouts, rate limiting, and maybe with some clientside hashing, too, for added transport security.
But it's friday, so I must unfortunately wait. :<13 -
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.17 -
Does anyone else get that surreal feeling where you actually realise you're paid to sit and write a language which most of the world doesnt understand, no one can speak it, and the those who may have the capability to write it don't really want to understand?
I mean, I'm pretty sure that a book written in Latin wouldn't sell well enough to pay the author year-on-year.
Pretty much job security through obscurity.
Surreal.3 -
Just as an extension of last rant to explain how much fun it is to keep up with Apple's security through obscurity bullshit.
AFAIK this full disk access (FDA) feature was touted to protect a user's data on macOS. Programs that want to access those files need to request the user's permissions to do so. Now to the fun part: Apple is not providing any API. A staff member suggested, that you should only try to access the files your app needs and if you can't as for the user's allowance. One should not use some fixed files and try to access them, because their locations might change, as well as their (UNIX file) access rights (ACL), or if they fall under FDA. Not to speak about the other security features that might hinder you accessing files (you might be sandboxed, or the files might be subject to SIP/rootless).
Honestly, you should be starting to take drugs, if you want to stay sane. I mean UNIX ACL are weird enough: e.g. you can make a directory only readable for root such that a user cannot list the files inside, but you can place files inside that the user can read (if she knows about their existence). On macOS you'll never know. You may have all the rights to access a file,.. but Apple will only give you the finger.
As they always do to us developers.2 -
What the FUCK Synology! Why the fuck would you change the sshd source and manually hardcode specific shells that the users are allowed to use! https://serverfault.com/a/470919
I'm trying to test a new sshd configuration here, and this motherfucker is not letting me log in because it keeps receiving SIGCHLD and failing to handle it (because of course chsh is missing!) and it won't let me in.
THEN HOW THE FUCK AM I LOGGED IN IN THE FIRST PLACE???6 -
We should rename our "users" table to "losers".
It would be more accurate, plus the added benefit of security through obscurity - we'd be immune to little Bobby Tables.6 -
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