VPS Open Ports - Thoughts?

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

Obsolesce

Ansible looks confusing at first. It'd take me some getting used to.

With Salt, there's basically two parts:

A top file to say which hosts, groups, pillars, grains, etc get what (state files).
States that are applied according to the top file.

And you can include / chain other state files.

stacksofplates

@tim_g said in VPS Open Ports - Thoughts?:

Ansible looks confusing at first. It'd take me some getting used to.

With Salt, there's basically two parts:

A top file to say which hosts, groups, pillars, grains, etc get what (state files).

States that are applied according to the top file.

If I'm reading that right, that sounds similar. Ansible lets you assign different levels per variable as well. So the default directory in a role has the least priority. They are used as sane defaults. They can be overridden with the vars directory in a role. And those can be overridden in a playbook. And those can be overridden by the command line (or Tower/AWX).

Roles also have the test directory to allow you to test the role. If you look at that hardening role, there's a playbook in the test directory that tells Vagrant how to build everything.

Obsolesce

I'm thinking about a SaltStack certification path to help me really, really learn it. I feel like I've barely touched it and I already feel this (and similar like Ansible) are so insanely powerful and are the future of systems management.

scottalanmiller

@tim_g said in VPS Open Ports - Thoughts?:

I'm thinking about a SaltStack certification path to help me really, really learn it. I feel like I've barely touched it and I already feel this (and similar like Ansible) are so insanely powerful and are the future of systems management.

And they are! That's what I presented at MangoCon

And that's Sodium's idea... take what Salt and Ansible do and build on top of that for even more power.

Obsolesce

@scottalanmiller said in VPS Open Ports - Thoughts?:

And they are! That's what I presented at MangoCon

Still waiting on those videos!

scottalanmiller

@tim_g said in VPS Open Ports - Thoughts?:

@scottalanmiller said in VPS Open Ports - Thoughts?:

And they are! That's what I presented at MangoCon

Still waiting on those videos!

Yeah @Minion-Queen

Obsolesce

@scottalanmiller said in VPS Open Ports - Thoughts?:

And that's Sodium's idea... take what Salt and Ansible do and build on top of that for even more power.

Yeah, once I got into SaltStack, and realized Sodium is building on that, I threw myself on board and am waiting and watching Sodium.