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

161–170 of 298 posts

Re: My First 10 Minutes on a Server

#161

Post by MichaelGG »

tjohns wrote: post #106

> I check our logwatch email every morning and thoroughly enjoy watching several hundreds (sometimes 1000s) of attempts at gaining access with little prevail. This is something that actually bugs me a bit. These attacks are so common, getting emails like this every day contributes to alarm fatigue. ( https://en.wikipedia.org/wiki/Alarm_fatigue ) I'd love to see the Linux nightly security scripts replaced with somethi…

Yep and this doesn't demonstrate anything about security. Showing brute force scanners trying out "root/letmein123" doesn't teach anyone the importance of good security, just the importance of not using super-common user/passes.

I cannot figure out why anyone would care or find anything useful in these logs. Change the port, call it a day. Getting worked up about random SSH attempts (or random HTTP "exploit" attempts) seems to be for admins with too much free time.

Re: My First 10 Minutes on a Server

#162

Post by nnutter »

brobinson wrote: post #160
brokenwren wrote: post #7

This one is pretty decent but if you want the ultimate guide check out this one: https://www.inversoft.com/guides/2016-guide-to-user-data-sec... It covers 10x what all the other guides cover in terms of server and application security. It was posted a few weeks ago on HN but didn't make the front-page.

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

Why must they be PULLED?

Re: My First 10 Minutes on a Server

#163

Post by [deleted] »

nnutter wrote: post #162
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…

Why must they be PULLED?

[deleted]

Re: My First 10 Minutes on a Server

#164

Post by carlisle_ »

treerunner wrote: post #115
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.

I always change the ssh port to something other than 22. It has always seemed to work well for me for most automated attacks. Perhaps this is not advisable for some reason?

There is a slight security concern to binding it to a port above 1024 in that a non-privileged user can bind to that port and MITM.

Here is a good summary of the different options you have with ssh and choosing a port:

http://serverfault.com/questions/619898/should-i-change-the-...

Re: My First 10 Minutes on a Server

#165

Post by mastorrent »

nnutter wrote: post #162
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…

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.

Re: My First 10 Minutes on a Server

#166

Post by ryanlol »

windsurfer wrote: post #140
ryanlol wrote: post #135

Earlier quoted context omitted.

If you've got a good password on your key, then nobody will be able to use it in years. It most certainly helps.

Years? How long a password would you need to make GPU cracking take years?

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.

Re: My First 10 Minutes on a Server

#167

Post by abglassman »

mkagenius wrote: post #86
brokenwren wrote: post #7

This one is pretty decent but if you want the ultimate guide check out this one: https://www.inversoft.com/guides/2016-guide-to-user-data-sec... It covers 10x what all the other guides cover in terms of server and application security. It was posted a few weeks ago on HN but didn't make the front-page.

We are preparing one focussing on application development: https://github.com/FallibleInc/security-guide-for-developers... (work in progress)

Great checklist.

Re: My First 10 Minutes on a Server

#168

Post by bch »

mwpmaybe wrote: post #98
codelitt wrote: post #97

Earlier quoted context omitted.

It depends on your VPS, but many give a root password by default. I do make sure later in the article that `/etc/ssh/sshd_config` does not allow root login: PermitRootLogin no But you make a good point that a simple solution is just having no root password at all. If your VPS does have a root login by default, then I believe you can get rid of it with: sudo usermod -p '!' root The best part about sharing things like…

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.

Re: My First 10 Minutes on a Server

#169

Post by chrisseaton »

windsurfer wrote: post #140
ryanlol wrote: post #135

Earlier quoted context omitted.

If you've got a good password on your key, then nobody will be able to use it in years. It most certainly helps.

Years? How long a password would you need to make GPU cracking take years?

You're already given your own concrete time estimate - 'hours' - how did you work that out?

Re: My First 10 Minutes on a Server

#170

Post by hueving »

brobinson wrote: post #160
brokenwren wrote: post #7

This one is pretty decent but if you want the ultimate guide check out this one: https://www.inversoft.com/guides/2016-guide-to-user-data-sec... It covers 10x what all the other guides cover in terms of server and application security. It was posted a few weeks ago on HN but didn't make the front-page.

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

>This is a really bad idea and a good way to get owned. Database backups must be PULLED

Just make sure your database server doesn't have permission to delete backups (e.g. Have it POST a backup via HTTPS). There is nothing wrong with db server initiated backups.

Post reply on HN