Started off by

  1. Enabling unattended updates
  2. Enable only ssh login with key
  3. Create user with sudo privileges
  4. Disable root login
  5. Enable ufw with necessary ports
  6. Disable ping
  7. Change ssh default port 21 to something else.

Got the ideas from networkchuck

Did this on the proxmox host as well as all VMs.

Any suggestions?

  • Zerafiall@alien.topB
    link
    fedilink
    English
    arrow-up
    3
    ·
    10 months ago
    1. Don’t bother with disabling icmp. You’ll use it way more then it’s worth disabling, and something like nmap -Pn -p- X.X.X.0/24 will find all your servers anyways (same can be said for ssh and port 22. But moving that does stop some bots)

    2. As long as i go out not exposing anything the the global internet, you really don’t need a lot. The fire wall should already deny all inbound traffic.

    The next step is monitoring. It’s one thing to think your stuff is safe and locked down. It’s another thing to know your stuff is safe. Something like Observium, Nagios, Zabbix, or otherwise is a great way to make sure everything stays up, as well as having insights into what everything it doing. Even Uptime Kuma is a good test. Then something like Wazuh to watch for security events and OpenVAS or Nessus, to look holes. I’d even though in CrowdSec for host based virus detection. (Warning, this will quickly send you down the rabbit hole of being a SOC analyst for your own home)

    • Internet-of-cruft@alien.topB
      link
      fedilink
      English
      arrow-up
      2
      ·
      10 months ago

      Block outbound traffic too.

      Open up just what you need.

      Segment internally and restrict access. You don’t need more than SSH to a Linux Server, or perhaps to it’s web interface for an application running on it.

    • NevarroGuildsman@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      10 months ago

      I just set up Wazuh at work and pointed it at a non-domain, vanilla Windows 11 machine to test and it came back with over 300 events immediately. Not trying to scare anyone off as I think it’s a great tool, more just a heads up that the rabbit hole runs very deep.

  • EugeneBelford1995@alien.topB
    link
    fedilink
    English
    arrow-up
    2
    ·
    10 months ago

    Honestly, between the home lab being behind a RTR, NATed, patched & updated, and given the lack of users clicking on random crap and plugging in thumb drives from God Only Knows Where … I’d go out on a limb and say it’s already more secure than most PCs.

    There’s also no data besides what I already put on Medium and GitHub, so it’s not a very attractive target.

  • jmartin72@alien.topB
    link
    fedilink
    English
    arrow-up
    2
    ·
    10 months ago

    Don’t expose anything to the outside world. If you do, use something like Cloudflare tunnels or Tailscale.

    • umbrella@lemmy.ml
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      10 months ago

      Or host a VPN on it and get in through that. Many of these microservices are insecure, and the real risk comes from opening them up to the Internet. This is important.

      Also set permissions properly if applicable

  • tabortsenare@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    Internet > Firewall, IP Whitelist, IPS/IDS yada yada> DMZ / VLAN > > Proxmox /w FW:$true (rule only for game ports) > GameServer > Deny all traffic from GameServer to go anywhere but internet

    Proxmox server has firewall, all the hosts on proxmox have firewall enabled (in proxmox). Only allow my main device to access. No VLAN crosstalk permitted.

    I don’t bother with anything else internally, if they’re inside they deserve to SSH with my default root / password credentials

  • murdaBot@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    Don’t expose unnecessary things to the internet, keep any client PCs patched, use some sort of malware protection … and that’s all you need to do.

    All these VLANs are such are just overkill unless you’re actively exposing things to the internet. They wind up breaking really useful stuff, especially stuff that relies on multicast.

    Besides, that Chinese IoT device can’t get hacked if it’s not open to the 'net in the first place.

  • Emotional_Orange8378@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    from the internet side, I lock down ssh or administrative stuff to local network, and specific IPs, like work. inside my network, everything has a password to access, no defaults. vlans for specific use servers, etc.

  • LAKnerd@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    Air gapped, no Internet access. I don’t use Internet services for any of my stuff though so I can get away without direct Internet access

  • theniwo@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    Enabling unattended updates -> Hell no. Regular Patchdays
    Enable only ssh login with key -> yes
    Create user with sudo privileges -> yes
    Disable root login -> no
    Enable ufw with necessary ports -> Basic iptables, but not on all hosts. But fail2ban
    Disable ping -> nope
    Change ssh default port 21 to something else. -> nope

      • theniwo@alien.topB
        link
        fedilink
        English
        arrow-up
        1
        ·
        10 months ago

        Can you give me ressources on how to configure f2b?

        I usually leave the defaults, or maybe tweak the times a bit.

        One could only enter my network thru vpn or nginx on 443 anyway, so I am not that worried

        • lack_of_reserves@alien.topB
          link
          fedilink
          English
          arrow-up
          1
          ·
          10 months ago

          The majority of the default fail2ban installations only bans an IP for 10 minutes and uses a 10 minute findtime, e.g. slow brute forcing is not at all banned.

          Before I switched to crowdsec (which I really recommend you do, its quite easy) I changed my bantime and findtime in /etc/fail2ban/jail.conf (I think I made a local file… read the file it should say) to something like 8 hours (e.g. change 10m to 640m for both those variables).

          • theniwo@alien.topB
            link
            fedilink
            English
            arrow-up
            1
            ·
            10 months ago

            Well if you are using strong passwords or no passwords from outside at all, but key auth only, i think you are pretty in the safe side. As i said, i have no ssh port open to the internet. Raising the ban time could only lead to banning myself. 😀

            But for ports open to the outside, yes. I ppbly would do that too. Plus hardening the ssh config a bit

            • lack_of_reserves@alien.topB
              link
              fedilink
              English
              arrow-up
              1
              ·
              10 months ago

              I have an open ssh port and I use key auth with password as well as crowdsec. Even if people get my ssh key they would still need to know the password.

  • RedSquirrelFtw@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    Anything that faces the internet I have on a separate vlan. Each system on that vlan is treated as if it was facing the internet directly, that way if one of them gets compromised the hacker will not get far trying to get into any other machines.

    Rest of my network is a little more tame just for ease of access since it’s only me on here.

    Although at some point I do want to revisit my security protocol even locally, just in case. Hitting some kind of drive by trojan script or something within the browser is always a possibility, it could work in reverse where it connects to an external server and then accesses the rest of the network that way. I’m not aware of such trojans but I’m sure it’s possible.

    I do block all outbound ports except for base internet ports but a properly written malicious script would probably take that into account and use a common port like 443.

    At some point I might setup a honeypot. Just need to name the VM “cryptowallet” or something like that and it would be a very fast target. If access to it is detected it would alert me and shut off the internet.

  • Impressive-Cap1140@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    Is there really any security benefit to not using default ports? Especially if the service is not open externally? I cannot find any official documentation that states you should be doing that.

  • Daniel15@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    If it’s a Debian system, “Create user with sudo privileges” and “Disable root login” can be done during initial setup. Just leave the root password blank and it’ll disable the root user and grant sudo permission to the regular user you create.

    Create a separate management VLAN and use it for all your infra (web UIs of all your networking hardware, Proxmox, SSH for servers, etc).

    For unattended upgrades, ensure the auto updaters are properly configured so they’re used ONLY for bug and security fixes, nor for minor or major releases! Debian unattended-upgrades has good settings out-of-the-box but you may want to add any custom repos you’re using. Make sure you have an email relay server configured in the Exim config, as it uses apt-listchanges to email the changelogs to you.

    But above all, press the power button to turn it off and then never turn it on again. 100% unhackable.

  • radiantxero@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago
    1. Snort on perimeter inbound and outbound.
    2. ntopng on perimeter.
    3. Heavy VLAN segmentation. Like with like.
    4. Inter-VLAN ACLs on core switch. This is a stateless firewall. Some VLANs with certain device types have inbound and outbound. Trusted devices only have inbound.
    5. SPAN to Security Onion for all internal traffic.
    6. SNMPv3 monitoring on all devices.
    7. MAC Sticky on all camera ports because the cabling extends outside of the physical structure of the house. I am going to implement Dot1X at some point.
    8. VRFs for sensitive infrastructure to prevent outbound routing completely.
    9. A VRF for devices to be forced through an external VPN (Mullvad). Used for devices that do not support a VPN agent.
    10. No antivirus. All antivirus is a botnet.
    11. All server infrastructure is Devuan using OpenRC instead of systemd.
    12. Gaming PC is Artix.
    13. DNS blackhole.
    14. Public DNS is a Swiss no-logging provider which I use DoT to send my queries to.
    15. LibreWolf or Brave Browser on everything.
    16. Only hole into the network is a 4096 bit encrypted Wireguard instance operating in a container using an uncommon port. I wrote a custom script that can reach into the container and pull from the API in order to show active sessions, GeoIP, browser fingerprints, length of time the socket has been open, etc.
    17. I use geofencing for inbound connections to the Wireguard instance. I only allow my immediate area cellular ISPs IANA address spaces to touch my network. Same goes for the geographic area surrounding my parents house.
    18. Unattended updates using custom scripting for my servers, including rebuilding the Wireguard container every single night, updating the server, and I also fire Nessus at it every night. If in the morning there is a CVE of note on that server, the NAT rule allowing traffic to the VPN is disabled at the perimeter until a sufficient patch is released.
    19. I run STIGs on everything, within reason and where infrastructure allows, in my suite.
    20. LibreSSL over OpenSSL.