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?
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.
-
@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.
-
@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.
-
@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.
-
@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.
-
@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?
-
@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.
-
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.
-
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 -
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.
-
@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.
-
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.
-
@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.
-
@scottalanmiller said in VPS Open Ports - Thoughts?:
And they are! That's what I presented at MangoCon
Still waiting on those videos!
-
@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
-
@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.
-
I really think if we could get a Kubernetes (or an ELB type thing) for systems management that would be the best case. It's such an awesome tool for it's use. I mean just being able to say I want 3 copies running and it makes sure that's what happens even when things die is awesome.
-
I think if SodiumSuite plays their cards right, it has the potential to completely replace Microsoft's system management (like Group Policy and SCCM and others in the suite) as well as the major alternatives, such as Dell's KACE, etc.
-
@tim_g said in VPS Open Ports - Thoughts?:
I think if SodiumSuite plays their cards right, it has the potential to completely replace Microsoft's system management (like Group Policy and SCCM and others in the suite) as well as the major alternatives, such as Dell's KACE, etc.
Quest bought KACE and it's gone downhill a bit.
-
@tim_g said in VPS Open Ports - Thoughts?:
I think if SodiumSuite plays their cards right, it has the potential to completely replace Microsoft's system management (like Group Policy and SCCM and others in the suite) as well as the major alternatives, such as Dell's KACE, etc.
That's our thoughts!
