Live data from Hacker News

My First 10 Minutes on a Server

codelitt.com

191–200 of 298 posts

Re: My First 10 Minutes on a Server

#191
post #133

Not sure if others feel this way but adding this line to sudo never felt right to me... deploy ALL=(ALL) ALL I usually instead limit the deploy user to a smaller subset of commands e.g. the init.d script to control a service. obviously if someone gained access to deploy user we're probably sol anyway... but it just makes it seem safer... we have a to login as an ops user to install or update things on the boxes.

I prefer to grant my person-user access to run any command as deploy, so I can kick off deployments from a remote machine using Ansible:

  - include: deploy.yml
    become: yes
    become_user: deploy
And grant separate access for my person-user to restart services as root. And use sudo groups.

Re: My First 10 Minutes on a Server

#192
post #9

Earlier quoted context omitted.

My worry here is that, in posting what seems to be a book, people just won't even do it because we don't have time to do it, unless this is a primary part of their jobs. If a 10 minute guide gets users 90% of the way, then they're more likely to do it. And that's good enough to cover a majority of automated attacks. Update: I take it back – they've provided scripts to run this stuff. I will explore these. Thanks for…

Back in the day, The Linux Documentation Project had a trove of hundreds of HOWTOs covering every facet of using Linux. By today's standards they seem like "books", but in reality they were step-by-step instructions for anything you could ever want to do in Linux. No digging through forums, no combing through man pages, no following broken outdated blog posts that didn't explain what you were doing. I find it sad tha…

So are they outdated now?

Re: My First 10 Minutes on a Server

#193

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

Something like Ansible can help with this a ton. My playbooks are littered with tasks such as:

  - ufw: rule=allow direction=in port={{ redis_port }} src={{ hostvars[item]['ansible_ssh_host'] }}
    with_items: "{{ groups['jobservers'] }}"

Re: My First 10 Minutes on a Server

#194

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. =)

Re: My First 10 Minutes on a Server

#195
post #72

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.

Fail2ban can be used to block IPs based on any log file, not just SSH - I believe the author uses an Apache log in the example.

It also has rules for mailers, and other utilities, which I often use just because they're nice and simple to work with.

Re: My First 10 Minutes on a Server

#196

Earlier quoted context omitted.

Right, I was thinking myself... why not have a chef recipe do this, and walk through the systems as you do that. Ideally the server comes up and applies chef, doing the needful to secure it. Hand-cooking a server is extremely painful.

I mention Ansible and other tools in the article. The idea, as others have mentioned, is to teach a man to fish. You're much better off with having an automated way to perform this, but you shouldn't ever run anything automated that you don't understand. We'll release an Ansible Playbook over the next week or so that follows these steps.

See related (as inspiration, or an upstream):

  - https://github.com/openstack/openstack-ansible-security
  - https://github.com/geerlingguy/ansible-role-security

Re: My First 10 Minutes on a Server

#197
post #22

For protecting against brute-force login attempts, I use sshguard [1] I really think this should be installed by default on distros like Ubuntu. [1] http://www.sshguard.net/

I can't see any benefit, what am I missing? Put SSH on a port that's not 22 and done, no more mass scanning. The only thing SSHGuard has ever done for me is to lock me out when I was accidentally using the wrong key.

If SSH is on a non-standard port, it is still possible to brute-force access to the server. You will see fewer automated attempts but you are still vulnerable to a motivated attacker who port scans you and finds the SSH port. Such an attacker is less common than automated scans but is more of a threat. With Sshguard, you are no longer vulnerable to this type of attack at all, no matter which port you run SSH on.

Re: My First 10 Minutes on a Server

#199

Earlier quoted context omitted.

I didn't know about this, but from now on, when writing CLIs that use color, I'm going to take this into account!

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.

Re: My First 10 Minutes on a Server

#200
post #69

Earlier quoted context omitted.

I agree that fail2ban for ssh seems unnecessary. But, it also provides monitoring for other services like http and common exploits. I'd be interested in learning from the community if fail2ban adds much value. As I've looked into the service, it seems like simply running the latest security patches obviates the need for fail2ban.

I too am curious to know what the consensus is. People seem to fall into one of two camps: 1. it's unnecessary if you disable password login or 2. it's an easy thing to add as yet another safety net on top of sane service configuration and firewall rules. I've taken some flak here for being in the #2 camp so I'm loathe to expose myself once again, but my thinking is that even with password authentication disabled, ss…

Useful or not, it opens an extra attack vector on the server. Parsing logs is always a dangerous area from security perspective.
Post reply on HN