Is there a similar guide for Windows servers out there?
My First 10 Minutes on a Server
181–190 of 298 posts
Re: My First 10 Minutes on a Server
#182Earlier quoted context omitted.
A very short one. Reasonable 10+ character passwords should remain out of reach for years. Also, AFAIK there doesn't currently exist any very effective GPU cracking software for SSH passphrases.
I went to lookup the algorithm GPG uses to encrypt private keys, to help answer the original question, but couldn't seem to find that information anywhere. Do you know what it is?
According to a quick stack exchange search, OpenSSL uses 3DES for encryption of private keys.
Re: My First 10 Minutes on a Server
#183> We don't even have a password for our root user. We'll want to select something random and complex. So you're taking something secure by default -- no password means no login allowed, and making it less secure. And if you have hundreds of these servers, you'll need to rotate them whenever someone on the team leaves. This is painful. Simple solution: leave root password blank, don't forget your sudo password. If you…
The last company I was at was more like this and had admins who were really anti LDAP...because...I have no clue.
You should have centralized auth whenever possible. LDAP servers with fallback, Shibboleth for SSO on web apps (or to implement ADFS integration or SSO with Slack or whatever),
I'd also recommend these steps being combined with Vagrant + your configuration management tools (Ansible, Chef, Puppet).
There are Vagrant + Linode, Vagrant + KVM/libvrt, Vagrant + Digital Ocean, etc. If you combine the two, you can get pretty close between local virtualbox instances and production (you'll run into some issues with each providers base box being a little different, but you can usually accommodate for both your own box and your provider's)
This makes it a little easier to move your architecture from one provider to another.
Re: My First 10 Minutes on a Server
#184I think 2FA is generally bad practice and quite sad it is ubiquitous in e.g. banking and people try to shove it everywhere. It is analogous to password rules, 8-14 characters, numbers, capital letters and other signs. Yet it is very rare you can use a 40+ character passphrase. It gives a false sense of added security, while being annoying at the same time imo. It is very common, for me at least, not to have access to my phone all the time, because I left it at home, in the car etc. Not to mention if you lose it (or someone steals it) you have a huge pita to deal with.
Re: My First 10 Minutes on a Server
#185I think 2FA is generally bad practice and quite sad it is ubiquitous in e.g. banking and people try to shove it everywhere. It is analogous to password rules, 8-14 characters, numbers, capital letters and other signs. Yet it is very rare you can use a 40+ character passphrase. It gives a false sense of added security, while being annoying at the same time imo. It is very common, for me at least, not to have access to…
2FA doesn't have to be annoying. Take a look at Yubikey devices as an example of how to do this right. The reality is that it is actually really useful at preventing some common attack vectors: password reuse, keyloggers, etc.
It's even better if you're using a hardware dongle that supports U2F (or can be used as a smartcard for SSH), because that can even prevent active MITM attacks.
Re: My First 10 Minutes on a Server
#186I don't mean to sound flippant but why can't these "lock down your new box" tutorials just be a bash script? Shouldn't they be?
The Inversoft guide posted does have a corresponding GitHub repo. https://github.com/inversoft/2016-security-scripts
I think scripting all of this is great - but also agree that it is important to understand what is being performed.
Re: My First 10 Minutes on a Server
#187My biggest concern with being on a VPS like Linode, once you're all done securing yourself and binding services to the local LAN IP, is an attack from within the network. The VPS you own is also accessible by others on the same subnet, contrary to what you might assume. I'd love to see a ufw guide for whitelisting only your own internal IPs to be allowed access to any services for ultimate security.
Not sure what you mean but ufw by default blocks everything on your interface so other machines in the local subnet shouldn't have access.
If you want to have more security and no (or just a single) outgoing service configure OpenVPN with TLS and put all your local services in a local subnet for your machine. So not even a portscan can find something.
Re: My First 10 Minutes on a Server
#188Earlier quoted context omitted.
sudo passwd -l
Not on (eg) BSD. I don't know if this is Linux-only, or more pervasive, but certainly not entirely standard. On Net, Free, Dragon Fly and OpenBSD "-l" mean "update only the local database", versus Kerberos.
Well, sure, but the usermod method I was remarking on isn't standard either, and it established a Linux context for this thread. I'm not sure there's a truly portable way to lock a password across SysV, Linux, and BSD systems.
Re: My First 10 Minutes on a Server
#189Forgot to check if the server isn't backdoored. You will be surprised how many providers add many backdoors and monitoring systems you don't need (m looking at you AWS guys).
Re: My First 10 Minutes on a Server
#190Earlier quoted context omitted.
Why must they be PULLED?
If a server can push backups, it must necessarily have credentials for and write access to that backup repository. If the server is compromised, that write access could be used to attack the backup repository as well. Pulling backups from a server removes the need for credentials or access to the backup repository.
That is one valid way of solving this problem. Another option is to have a permission system that allows you specify that the server can only append new data, but not delete or overwrite existing files. This is useful if you don't want the added complexity of having a separate "backup management" service, which could easily become a bottleneck if you are backing up a lot of data from multiple servers.
One way to do this is with S3, for example, is to use an IAM role with only the "PutObject" permission, and enable object versioning for the bucket to prevent a compromised server from being able to delete data by overwriting existing files.