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?

  • WillingLimit3552@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 years ago

    Disable root login covers 99.9999 percent of it, as long as your box has only one or two obscure login accounts.

  • Zerafiall@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 years 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)

    • NevarroGuildsman@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 years 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.

    • Internet-of-cruft@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 years 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.

  • reviewmynotes@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 years ago

    You have a good list to start with. Consider adding sshguard or fail2ban in the short term and crowdsec in the long term. Also use lynis on Unix systems and PingCastle on AD systems and see what suggestions those make. Just a few suggestions off the top of my head.

  • radiantxero@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 years 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.
  • wallacebrf@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 years ago
    1. strict 3-2-1 backup policy
    2. VLANs. all VLANs are controlled by my Fortigate FWF-61E (soon to be replaced by a FG-91G). the VLANs have strict access permissions on a per-device basis on what they can and cannot access.
      1. CORE network where the NAS live
        1. only specific devices can access this VLAN, and most only have access to the SMB ports for data access. even fewer devices have access to the NAS management ports
        2. this network has restrictions on how is accesses the internet
        3. I have strict IPS, web-filtering, DNS filtering, network level fortigate AV, deep SSL inspection, and intrusion protection activities
        4. everything is logged, any and all incoming and outgoing connections both to/from the internet but also any LAN based local communications.
      2. Guest wifi
        1. can ONLY access the internet
        2. has very restrictive web and DNS filtering
        3. I have strict IPS, web-filtering, DNS filtering, network level fortigate AV, basic SSL inspection, and intrusion protection activities
      3. APC Network Management Cards
        1. can ONLY access my SMTP2GO email client so it can send email notifications
        2. it does have some access to the CORE network (NTP, SYSLOG, SNMP)
        3. very select few devices can access the management ports of these cards
        4. I have strict IPS, web-filtering, DNS filtering, network level fortigate AV, basic SSL inspection, and intrusion protection activities
      4. Ethernet Switch / WIFI-AP management
          1. very select few devices can access the management ports of the switches
        1. ZERO internet access allowed
      5. ROKUs
        1. restrictive web and DNS filtering to prevent ads and tracking. Love seeing the space where ads SHOULD be and seeing a blank box.
        2. can access ONLY the IP of my PLEX server on the CORE network, on ONLY the PLEX port for the services PLEX requires.
      6. IoT devices
        1. Internet access ONLY except for a few devices like my IoTaWatt that needs CORE network access to my NAS on ONLY the port required for InfluxDB logging.
      7. Wife’s computer
        1. because of HIPPA due to her job, i have ZERO logging, and no SSL inspection, but do have some web and DNS filtering.
      8. print server
        1. zero internet access, and only the machines that need to print can access.
    3. as already indicated i have a fortigate router which has next generation firewall abilities to protect my network
    4. while i do not have automatic updates i am notified when updates are available for my router, my NAS, the switches, and APC network cards. i always like to look at the release notes and ensure there are no known issues that can negatively impact my operations. I do have most of my docker containers auto-update using watchtower.
    5. i keep SSH disabled and only enable when i ACTUALLY need it, and when i do, i use certificate based authentication
    6. i have disabled the default admin account on ALL devices and made custom admin/root users but also have “normal” users and use those normal users for everything UNLESS i need to perform some kind of activity that requires root/admin rights.
    7. on all devices that have their own internal firewall, i have enabled it to only allow access from VLAN subnets that i allow, and go even further by restricting which IPs on those VLANS can access the device
    8. changing default ports is fairly useless in my opinion as once someone is on your network it is trivial to perform a port scan and find the new ports.
    9. all windows based endpoint machines
      1. have a strict endpoint control using fortigate’s fortiguard software with EMS server. this allows me to enforce that machines have minimum specifications,
      2. i use group policy to enforce restrictive user environments to prevent installation of programs, making system changes, accessing the C: drive etc as this prevents a decent amount of malware from executing
      3. antivirus must be enabled and active or the endpoint becomes quarantined.
      4. if the system has unusual behavior it is automatically quarantined and i am notified to take a look
      5. even though the fortigate router blocks all ads and trackers i also use a combination of UBlock Origin to prevent ads and trackers from running in the browser as ADs are now one of the most common points of entry for malware
      6. i use ESET antivirus which also performs and ties into the fortiguard endpoint protection to ensure everything on the machines is OK
    10. for all phones/tablets i have Adguard installed which blocks all ads and malicious web sites and tracking at the phones level

    this is not even all of it.

    the big take away is i try to layer things. the endpoint devices are most important to protect and monitor as those are the foot hold something needs to then move through the network.

    i then use network level protections to secure the remaining portions of the network from other portions of the network.

    • radiantxero@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 years ago

      Anything that has internet access like your IoT can be C&C utilizing stateful connections. An outbound socket is built, and reflected traffic can come back in. Your IoT devices especially should not be exposed to the internet. They can’t even have an antivirus agent installed on them.

  • murdaBot@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 years 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.

  • Comfortable-Cause-81@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 years ago

    ssh default port is 22.

    Really, unless I’m trying to learn security (valid), or have something to protect. I do the basic best practices.

    Real security is an offline backup.

    • PreppyAndrew@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 years ago

      SSH port really doesnt matter. If it is an exposed SSH port, it will probably get picked up if its 69 or 22.

  • mss-cyclist@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 years ago

    Unattended updates can be tricky.

    Think of config changes which need manual adjustment, or a broken update. This is something you would probably not like to happen at night without notice. Could easily break your vital systems (e.g. homeassistant, authentication, vaults…)

    • Daniel15@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 years ago

      +1

      Use unattended updates ONLY for bug and security fixes, nor for minor or major releases. Ensure you configure your auto-updaters properly!

      Debian unattended-upgrades only upgrades packages from the main and security repos by default, so it should be fine since no major updates are performed within a particular Debian version.

  • jjaAK3eG@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 years ago

    Hosted reverse proxy and VPN servers. I have no open ports on my home network.