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

201–210 of 298 posts

Re: My First 10 Minutes on a Server

#201

Post by feld »

dave2000 wrote: post #128
feld wrote: post #42

Earlier quoted context omitted.

google-authenticator is a fancy name for an algorithm described in RFC 6238. It does not talk to servers or require any network access. Google is not involved in any way; they just made the algorithm popular and branded it.

I didn't read the question as "what if Google discontinues authenticator" but more as "what if I use Google authenticator on my phone and it gets stolen and i can't log in any more"

it provides you with backup codes that you print and put somewhere safe

Re: My First 10 Minutes on a Server

#202

Post by rodolphoarruda »

Shorel wrote: post #194
rodolphoarruda wrote: post #31

I'd be more curious to see a "My first 10 minutes on an Ubuntu desktop" version of the article.

Or alternatively: "My first 10 minutes on an Ubuntu desktop (for users who don't hate Unity, which includes myself)". In my case: Change the Switch workspace keys from Ctrl+Alt+Arrow keys to Super+ Arrow keys. Remove LibreOffice, install WPS Office. Remove Transmission, install Deluge. Install indicator-multiload, indicator-sound-switcher. Install Kodi. Install Steam. A lot more stuff, but I have not written it down.…

Yes, I see a lot of reaction around Unity. To be honest, I had to google it to find out what it was. I have always used Ubuntu Gnome, so I had no clue about Unity nor its issues.

Back to the topic here, I thought someone could outline a security checking for an ubuntu desktop to assess how secure the system is -- or maybe making it secure from a clean install.

Edit: grammar

Re: My First 10 Minutes on a Server

#203

Post by a_imho »

tjohns wrote: post #185
a_imho wrote: post #184

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

no, my point is exactly that the 2 in 2FA is inherently annoying, because you need to have physical access to 2 different devices at the same time.

How does it prevent password reuse? You can use the same (weak) password to lock your phone and login to your banking account (which is again, a false security). However it could be easily circumvented by random generating secure passwords for users (which needs clever advertising like 2FA, because they prefer convenience otherwise). In this case your phone is a single point of failure. You could even argue it increases the attack surface.

Re: My First 10 Minutes on a Server

#205

Post by jacquesm »

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.

That may be true but with a pulled db backup and a good recovery strategy you'll be back up relatively quickly, without you'll be DOA.

Re: My First 10 Minutes on a Server

#206

Post by merurr »

jeremyt wrote: post #156
stonogo wrote: post #154

No production server should ever be manually configured.

How should this be done by, say, a small team of three with no SysAdmin?

Take a day off and get familiar with ansible, it will save you tons of time in the long run and simplify your dev/staging/prod environment for years to come

Re: My First 10 Minutes on a Server

#207

Post by merurr »

molecule wrote: post #138
mmgutz wrote: post #14

Hmmm ... why does root need a password? `sudo su`

> You'll only need this root password if you lose your sudo password. Also, good to have in case sudoers file is corrupted, e.g. via bad edit, typo, etc. .

    cd /etc
    git init
    git add *
    git commit -am "before i screwed up"

Re: My First 10 Minutes on a Server

#208

Post by pfg »

a_imho wrote: post #203
tjohns wrote: post #185

Earlier quoted context omitted.

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.

no, my point is exactly that the 2 in 2FA is inherently annoying, because you need to have physical access to 2 different devices at the same time. How does it prevent password reuse? You can use the same (weak) password to lock your phone and login to your banking account (which is again, a false security). However it could be easily circumvented by random generating secure passwords for users (which needs clever ad…

> How does it prevent password reuse?

It does not prevent password reuse, it mitigates the risks of password reuse in that it adds the requirement of having physical access to a device, which is a show-stopper for most attackers.

If you're using a password manager with sufficiently complex passphrases, the biggest remaining risk factor are targeted malware attacks (something like a keylogger), which is something that typical SMS- or TOTP-App-based 2FA implementions won't help you with, fair enough. Implementations where certain security-sensitive activities require separate confirmation and where the details are transmitted through a separate channel would mitigate this attack to a certain degree as well. As an example, some banks in Europe provide their customers with card readers with a PIN pad that shows transaction details on a separate display. Banks routinely include transaction details in SMS-based TAN mechanisms, which works as well, but is obviously not quite as good.

> You could even argue it increases the attack surface.

How?

Re: My First 10 Minutes on a Server

#209

Post by bch »

mwpmaybe wrote: post #188
bch wrote: post #168

Earlier quoted context omitted.

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.

The _effect_ of what you do (make an "impossible hash") is the way, as far as I know -- whether its vipw, passwd -l, whatever...

Regardless -- I'm not trying to diminish your solution, nor Linux; I elided over the usermod example in the grandparent (didn't recognize it at all), but interestingly, as I look on my NetBSD system,there is a usermod(8), with a -p for already hashed passwords. As I test it though, it rejects '!' as an argument:

  # usermod -p ! jnk
  usermod: Can't modify user `jnk': invalid password: `!'

Re: My First 10 Minutes on a Server

#210

Post by JoshTriplett »

moosingin3space wrote: post #199
JoshTriplett wrote: post #153

Earlier quoted context omitted.

Awesome; more tools should do that. Some caveats, though: * You might not get a response from every terminal, so limit how long you wait. * If you don't already have echo turned off, turn if off before sending the sequence, because otherwise it'll be visible as though the user typed it. * You don't know that the color will use the "rgb:RRRR/GGGG/BBBB" format (a terminal can return anything XParseColor can understand)…

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-exit command-line applications that want to use color.

> Regarding the third point, it might be a good idea to just feed it to XParseColor and process it from there.

That assumes you have libX11 and an X Display available. The former is a heavy dependency for a CLI application, and the latter requires you to connect to the X server.

I'd suggest just manually handling the common case of "rgb:R/G/B" (where each component may use 1-4 digits and requires scaling accordingly), and then deal with anything else if your users actually encounter it in the wild.

Post reply on HN