VPS Open Ports - Thoughts?

Obsolesce

My VPS was online and not very secured right out of the box. For example, the default SSH settings were loose, allowing password and root login. When I would SSH in, I would typically see tens of thousands of failed login attempts, though nothing pointing towards anything being successful besides me.

But that doesn't mean nothing got in another way.

NOTE: I do plan on trashing the server and starting over from minimal install (rather than server install) on F26. But I don't want to do that until I have all of my Salt States set up and tested so I can do minimal install, add my Salt stuff, then let it configure itself according to my GitLab setup.

Here's what I'm looking at, and have some questions about:

0_1512245374716_291c26b4-2595-4fc6-b50e-e72ddb0d18f6-image.png

My questions:

That 52.167.219.168 address is registered (supposedly) to Microsoft. I don't know why anything would be connecting to that IP address on my VPS, so I'm asking if there's anything legit that makes sense.
Other than that, everything looks legit... I see Salt listening on 4505-4506, Cockpit on 9090, SSH on 22. But wtf is that foreign IP?

Obsolesce

Was just thinking, could that be GitLab?

Obsolesce

Okay, I feel better now. I confirmed it is GitLab: https://twitter.com/gitlabstatus/status/834770479076487168?lang=en

Obsolesce

I've been deep-diving into Linux VPS hardening via SaltStack, creating a few States to dramatically improve the security of the server and minions.

stacksofplates

https://gitlab.com/hooksie1/ansible-hardening

You can grab some of those rules if you want. It's for Ansible, but shouldn't be too hard to use in Salt.

Obsolesce

@stacksofplates said in VPS Open Ports - Thoughts?:

https://gitlab.com/hooksie1/ansible-hardening

You can grab some of those rules if you want. It's for Ansible, but shouldn't be too hard to use in Salt.

Thanks, I'll pick those apart. The more to go through the better!

scottalanmiller

That looks like you have done SSH TO that address, not from that address.

Obsolesce

@scottalanmiller said in VPS Open Ports - Thoughts?:

That looks like you have done SSH TO that address, not from that address.

That's correct isn't it? Salt connects to the SSH address on GitLab.

scottalanmiller

@tim_g said in VPS Open Ports - Thoughts?:

@scottalanmiller said in VPS Open Ports - Thoughts?:

That looks like you have done SSH TO that address, not from that address.

That's correct isn't it? Salt connects to the SSH address on GitLab.

Yes.

What you likely want to use it netstat -tulpn to see what is listening (open) rather than what is connected (which includes connections you have established.) For example, using your netstat flags, my desktop shows my MangoLassi web connection. Which is interesting, but not useful in this case.

stacksofplates

@tim_g said in VPS Open Ports - Thoughts?:

@stacksofplates said in VPS Open Ports - Thoughts?:

https://gitlab.com/hooksie1/ansible-hardening

You can grab some of those rules if you want. It's for Ansible, but shouldn't be too hard to use in Salt.

Thanks, I'll pick those apart. The more to go through the better!

I just threw a molecule test in and found out auditd doesn't seem to want to work in LXC (haven't tried to figure out why) so that's why it's failing the CI/CD tests. The Vagrantfile does work correctly if you want to see what all it does.

Obsolesce

@scottalanmiller said in VPS Open Ports - Thoughts?:

@tim_g said in VPS Open Ports - Thoughts?:

@scottalanmiller said in VPS Open Ports - Thoughts?:

That looks like you have done SSH TO that address, not from that address.

That's correct isn't it? Salt connects to the SSH address on GitLab.

Yes.

What you likely want to use it netstat -tulpn to see what is listening (open) rather than what is connected (which includes connections you have established.) For example, using your netstat flags, my desktop shows my MangoLassi web connection. Which is interesting, but not useful in this case.

I see, here's what that shows:

0_1512249515615_93379f64-3ef0-4d60-9de8-984c16e3628a-image.png

A little more interesting, but both are helpful.

So, port 68 and 323... are those supposed to be listening like that?

stacksofplates

@tim_g said in VPS Open Ports - Thoughts?:

@scottalanmiller said in VPS Open Ports - Thoughts?:

@tim_g said in VPS Open Ports - Thoughts?:

@scottalanmiller said in VPS Open Ports - Thoughts?:

That looks like you have done SSH TO that address, not from that address.

That's correct isn't it? Salt connects to the SSH address on GitLab.

Yes.

What you likely want to use it netstat -tulpn to see what is listening (open) rather than what is connected (which includes connections you have established.) For example, using your netstat flags, my desktop shows my MangoLassi web connection. Which is interesting, but not useful in this case.

I see, here's what that shows:

A little more interesting, but both are helpful.

So, port 68 and 323... are those supposed to be listening like that?

Chrony does by default, in case you want to monitor/control it remotely. Dhclient needs to so you can get an address but since it's layer 2 it can get the address without the port open.

scottalanmiller

@tim_g said in VPS Open Ports - Thoughts?:

@scottalanmiller said in VPS Open Ports - Thoughts?:

@tim_g said in VPS Open Ports - Thoughts?:

@scottalanmiller said in VPS Open Ports - Thoughts?:

That looks like you have done SSH TO that address, not from that address.

That's correct isn't it? Salt connects to the SSH address on GitLab.

Yes.

What you likely want to use it netstat -tulpn to see what is listening (open) rather than what is connected (which includes connections you have established.) For example, using your netstat flags, my desktop shows my MangoLassi web connection. Which is interesting, but not useful in this case.

I see, here's what that shows:

A little more interesting, but both are helpful.

So, port 68 and 323... are those supposed to be listening like that?

323 is listening on the loopback. Definitely nothing to worry about.

stacksofplates

@scottalanmiller said in VPS Open Ports - Thoughts?:

@tim_g said in VPS Open Ports - Thoughts?:

@scottalanmiller said in VPS Open Ports - Thoughts?:

@tim_g said in VPS Open Ports - Thoughts?:

@scottalanmiller said in VPS Open Ports - Thoughts?:

That looks like you have done SSH TO that address, not from that address.

That's correct isn't it? Salt connects to the SSH address on GitLab.

Yes.

What you likely want to use it netstat -tulpn to see what is listening (open) rather than what is connected (which includes connections you have established.) For example, using your netstat flags, my desktop shows my MangoLassi web connection. Which is interesting, but not useful in this case.

I see, here's what that shows:

A little more interesting, but both are helpful.

So, port 68 and 323... are those supposed to be listening like that?

323 is listening on the loopback. Definitely nothing to worry about.

Oh ya I'm dumb. I didn't even look at that. I know you can monitor and control it remotely so that's all I was thinking of. By default chronyc does only accept local commands.

Obsolesce

@stacksofplates said in VPS Open Ports - Thoughts?:

@scottalanmiller said in VPS Open Ports - Thoughts?:

@tim_g said in VPS Open Ports - Thoughts?:

@scottalanmiller said in VPS Open Ports - Thoughts?:

@tim_g said in VPS Open Ports - Thoughts?:

@scottalanmiller said in VPS Open Ports - Thoughts?:

That looks like you have done SSH TO that address, not from that address.

That's correct isn't it? Salt connects to the SSH address on GitLab.

Yes.

What you likely want to use it netstat -tulpn to see what is listening (open) rather than what is connected (which includes connections you have established.) For example, using your netstat flags, my desktop shows my MangoLassi web connection. Which is interesting, but not useful in this case.

I see, here's what that shows:

A little more interesting, but both are helpful.

So, port 68 and 323... are those supposed to be listening like that?

323 is listening on the loopback. Definitely nothing to worry about.

Oh ya I'm dumb. I didn't even look at that. I know you can monitor and control it remotely so that's all I was thinking of. By default chronyc only accepts local commands.

Lol yeah I didn't look at that either. 0.0.0.0 is the one to look out for (all interfaces) in my screenshot.

scottalanmiller

@tim_g said in VPS Open Ports - Thoughts?:

@stacksofplates said in VPS Open Ports - Thoughts?:

@scottalanmiller said in VPS Open Ports - Thoughts?:

@tim_g said in VPS Open Ports - Thoughts?:

@scottalanmiller said in VPS Open Ports - Thoughts?:

@tim_g said in VPS Open Ports - Thoughts?:

@scottalanmiller said in VPS Open Ports - Thoughts?:

That looks like you have done SSH TO that address, not from that address.

That's correct isn't it? Salt connects to the SSH address on GitLab.

Yes.

What you likely want to use it netstat -tulpn to see what is listening (open) rather than what is connected (which includes connections you have established.) For example, using your netstat flags, my desktop shows my MangoLassi web connection. Which is interesting, but not useful in this case.

I see, here's what that shows:

A little more interesting, but both are helpful.

So, port 68 and 323... are those supposed to be listening like that?

323 is listening on the loopback. Definitely nothing to worry about.

Oh ya I'm dumb. I didn't even look at that. I know you can monitor and control it remotely so that's all I was thinking of. By default chronyc only accepts local commands.

Lol yeah I didn't look at that either. 0.0.0.0 is the one to look out for (all interfaces) in my screenshot.

Yeah, that's the biggest one.

Obsolesce

@stacksofplates said in VPS Open Ports - Thoughts?:

@tim_g said in VPS Open Ports - Thoughts?:

@stacksofplates said in VPS Open Ports - Thoughts?:

https://gitlab.com/hooksie1/ansible-hardening

You can grab some of those rules if you want. It's for Ansible, but shouldn't be too hard to use in Salt.

Thanks, I'll pick those apart. The more to go through the better!

I just threw a molecule test in and found out auditd doesn't seem to want to work in LXC (haven't tried to figure out why) so that's why it's failing the CI/CD tests. The Vagrantfile does work correctly if you want to see what all it does.

I looked through things a bit...

I see the similarities between Ansible and SaltStack... Salt seems easier. But that may be because I have never looked at Ansible before, and because I'm familiar with Salt.

How do you like it?

stacksofplates

@tim_g said in VPS Open Ports - Thoughts?:

@stacksofplates said in VPS Open Ports - Thoughts?:

@tim_g said in VPS Open Ports - Thoughts?:

@stacksofplates said in VPS Open Ports - Thoughts?:

https://gitlab.com/hooksie1/ansible-hardening

You can grab some of those rules if you want. It's for Ansible, but shouldn't be too hard to use in Salt.

Thanks, I'll pick those apart. The more to go through the better!

I just threw a molecule test in and found out auditd doesn't seem to want to work in LXC (haven't tried to figure out why) so that's why it's failing the CI/CD tests. The Vagrantfile does work correctly if you want to see what all it does.

I looked through things a bit...

I see the similarities between Ansible and SaltStack... Salt seems easier. But that may be because I have never looked at Ansible before, and because I'm familiar with Salt.

Well that's just a role. It's funny because I feel the opposite. I can't follow Salt stuff because I don't see the organization to it. With Ansible you can do everything in a playbook like:

- name: playbook
  hosts: vps
  user: cm_user
  become: true

  tasks:
    - name: task for firewalld
      dostuff:

    - name: task for something else
      domorestuff:

    - name: task for another thing
      domorestuffagain:

But once you get out of doing simple things, it's hard to manage that. Roles really should do one thing well so that hardening one is a bad example. I have others that do specific things like only set up firewalld. Then to call a role you just do:

- name: playbook
  hosts: vps
  user: cm_user
  become: true

  roles:
    - { role: firewalld, firewall_services: [http, https] }

Then that firewall_services list is passed to the firewalld role and it sets those values. I guess roles can be looked at like a function in a programming language. It's a way to abstract stuff and reuse it over and over again without hard coding values.

stacksofplates

So all of your playbooks can go in one ore more repos just for the playbooks. Then have a requirements.yml file that tells ansible which roles to install at runtime.

stacksofplates

There are definitely use cases for everything being in a playbook. This playbook updates my DNS servers and sends a completed or failed message to Slack. It didn't make much sense to create a role for any of this.

---
- name: Update playbook
  hosts: dns_servers
  user: centos
  become: true
  gather_facts: true
  serial: 1   

  tasks:
    - block:
      - name: update packages
        package:
          name: '*'
          state: latest
      - name: reboot servers
        shell: sleep 2 && /sbin/shutdown -r now "Ansible system upgraded"
        async: 1
        poll: 0
        ignore_errors: true

      - name: wait for server to come back
        wait_for:
          host: "{{ openstack.networks.private[1] }}"
          port: 22
          delay: 10
        delegate_to: localhost

      - name: Send Slack notification
        slack:
          token: "{{ slack_token }}"
          channel: #ansible
          msg: "Updates completed on {{ openstack.name }} successfully"
        delegate_to: localhost

      rescue:
        - name: fail
          slack:
            token: "{{ slack_token }}"
            channel: #ansible
            msg: "Updates on {{ openstack.name }} failed"
          delegate_to: localhost