Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My First 10 Minutes on a Server

codelitt.com

Post reply on HN
Print view View original

221–230 of 298 posts

Re: My First 10 Minutes on a Server

#221

Post by foodstances »

pfg wrote: post #190
mastorrent wrote: post #165

Earlier quoted context omitted.

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 t…

It's also easy to do this with Tarsnap. You can split out your host keys with tarsnap-keymgmt into separate read, write, and delete keys. Just take your delete key off of the host and store it somewhere secure.

Re: My First 10 Minutes on a Server

#222

Post by gog »

tobltobs wrote: post #17

Can somebody help me out with this question: The default config for unattended-upgrades seems to not enable reboot even if a reboot would be required to activate the upgrades. Wouldn't that had made quite a few important upgrades in the last years effectless if they server did never get rebooted?

If you turn on email reporting you get an email tagged with [reboot required].

Re: My First 10 Minutes on a Server

#223

Post by justinhj »

Someone1234 wrote: post #61

Why do people install fail2ban then disable password based authentication entirely? I legitimately don't understand the purpose. Also, they complain about log spam (from failed SSH attempts) this is one reason to move SSH to a different port. It does NOT increase security, but it DOES reduce log spam from bots trying for easy targets.

Have you tried it both ways? some scripted attacks will try 22 find that it is open then spam it with attacks. If it's not open they will have to scan your ports then spam you with attacks

Re: My First 10 Minutes on a Server

#224

Post by moosingin3space »

JoshTriplett wrote: post #210
moosingin3space wrote: post #199

Earlier quoted context omitted.

Have you measured how long typical terminals take to respond? Regarding the third point, it might be a good idea to just feed it to XParseColor and process it from there.

> Have you measured how long typical terminals take to respond? Arbitrarily long. Consider that a user might run your application over SSH via a high-latency network connection. Better to just handle it asynchronously. Your input loop needs to watch for escape sequences anyway, so watch for that one and process it when or if you see it. Sadly, that only works for interactive screen-oriented applications, not run-and-…

I assume XParseColor would therefore limit portability to OS X or Wayland Linux. I stand corrected.

I was speaking of this regarding screen-oriented termbox/curses applications, not run-and-exit applications.

Re: My First 10 Minutes on a Server

#225

Post by walrus01 »

mastorrent wrote: post #165
nnutter wrote: post #162

Earlier 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.

Doesn't entirely fix the problem, but using public/private key auth and a private key created just for the backup cron job, the server can push a backup via scp/ssh to its own user account which on the destination end is chrooted into a particular backup destination directory.

Re: My First 10 Minutes on a Server

#226

Post by brobinson »

brokenwren wrote: post #178
brobinson wrote: post #160

Earlier quoted context omitted.

>2048 bit RSA keys Github recommends 4096 now, for what it's worth. [1] >Pushing database backups offsite This is a really bad idea and a good way to get owned. Database backups must be PULLED from the server, not pushed from it. Separately, you also need to test that you can restore from your backups periodically. There were a couple other things I disagree with, but they're in the realm of personal preference. It's…

I agree that pulling does appear to be more secure, but if someone breaches any of your servers undetected, you're pretty much hosed regardless. Plus, the Inversoft guide specifically states that backups must be encrypted. I could put my backup ZIPs on a public Github repository and no one would be able to access the user data stored inside it. Therefore, it really doesn't matted if they are pushed or pulled.

If a script or cronjob or whatever on the server has write access to the repo, so does the hypothetical attacker.

I remember seeing a "hacking" website get wiped along with all of its backups about 15 years ago and it left a very strong impression on me regarding this issue.

Re: My First 10 Minutes on a Server

#227

Post by devishard »

larrywright wrote: post #101
ryanmarsh wrote: post #48

I 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?

Hardening (along with any other server setup/configuration) should be implemented using some idempotent configuration management software (Chef, Puppet, Ansible, etc). It's 2016, there's no need to configure servers manually.

It depends.

I'm a security guy, so it would be embarrassing and possibly bad for my career if any of my servers got hacked, but I actually don't set up servers that often--it's not part of my job. These Web 2.0 configuration management solutions change pretty fast and don't care about reverse compatibility. So between my infrequent setups my configuration scripts pretty much always break.

Contrast this with bash, which cares a whole lot about reverse compatibility, and it's a no brainer. I've got scripts where the only modifications I've made since 2005 were to add functionality or increase security, never to fix existing functionality that was broken by a change to the system. I'll take that over Chef or Ansible (both tools I've used) any day.

Re: My First 10 Minutes on a Server

#228

Post by eranation »

adrianmsmith wrote: post #95

What's the reason for using a firewall? Assuming that services which shouldn't be accessible to the outside only listen to localhost not the network (e.g. MySQL on a LAMP stack), isn't that sufficient? (Honest question, I don't have much experience with syadmin.)

Layered security. You always add redundant security so in case another layer fails you have a fallback. It's the better be safe than sorry version of infosec.

Re: My First 10 Minutes on a Server

#229

Post by walrus01 »

For those saying "why fail2ban?", fail2ban can be used for a great deal more than just watching the sshd log. You can activate fail2ban rules for apache and nginx which help significantly with small DDoS, turning spurious traffic/login attempts into iptables DROP rules. And a lot of other daemons.

Re: My First 10 Minutes on a Server

#230

Post by walrus01 »

raimue wrote: post #76
ryanmarsh wrote: post #48

I 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?

You are supposed to understand the implications of all of these steps. If by accident you ever lock yourself out, you will need to know how you set it up. If you just recommend running a script, most people will not learn what they are doing.

Yes. Doing this 'manually' step by step lets you choose which things are really necessary, your configuration might be different, and forces you to learn WHAT it's doing rather than just running a script. I am not a huge fan of Arch Linux (prefer debian unstable), but this is the same principle as the Arch Linux installation process which doesn't have a monolithic installer but forces you to do the process manually step-by-step.
Post reply on HN