Category: Tech

Anything and everything I write that has something to do with tech. Maybe it’s a post about the time I blew up that server in 2003 because I didn’t know what bridged networking really meant. Sorry Roger!

Connecting a Wazuh 4.x agent to SecurityOnion 2.3x

Security Onion is a fantastic and continually impressive suite of SOC tools that work very well for small organizations. Most of the time at least. The installation is not user-friendly, and it is clearly expected that you know why or why not to chose a particular option.

For all my love of SecurityOnion 2.x, I am continually wishing it natively had more up-to-date wazuh agent support. There were significant changes in Wazuh 3.x to 4.x, including the change to TCP as the default communications protocol for the agents.

 

2022/10/13 21:52:06 wazuh-agent: ERROR: (1216): Unable to connect to '10.X.X.X:1514/tcp': 'No connection could be made because the target machine actively refused it.'.

 

*sigh*

Manipulating the SO firewall wasn’t sufficient. I thought that perhaps just adding tcp as a valid protocol:

sudo so-firewall addportgroup wazuh_4_agents
sudo so-firewall addport wazuh_4_agents tcp 1514
sudo so-firewall apply

 

Sadly, that was insufficient. I gave up and went back to 3.13 which was released years ago.

 

Fully disabling remote access to root on MariaDB

An OpenVAS vulnerability scan helped me recently identify a DB that had a 9.0 rating and was allowing remote access to the root account. Thankfully the DB was not accessible to the Internet, but the ease of lateral movement inside a server network couldn’t be allowed. So I went about responsibly mitigating this vulnerability, which I did not expect to have taken as long as it did. Turning off remote access should be easy, even thought I’m not a DBA, I felt confident this would not be that difficult. I read the free manual and didn’t not see any major challenges.

 

First off, I’m not a DBA, second this was the first install of mariaDB that I knowing was getting involved with. I don’t think the differences between MySQL are that significant, but I had to keep it in mind.

First step was to change the root password. At least make sure it wasn’t using the default password of password to log in. Seriously. I don’t know if this is set this way by mariaDB during installation, or was set by the application using the DB.

Changing the root password was insufficient. The scan still returned the vulnerability existed. Turns out I had only changed it for the localhost version of root. I was interested to learn and understand that different DB users can share the same login name, so long as their hosts are different.

So then I changed the password for 127.0.0.1, and and ::1 to account for the IPV6 change. This was still insufficient to stop the vulnerability from showing up.

I modified the my.cnf and still had no success.

I had to manually verify this existed, something I should have done earlier. It’s always possible for a vulnerability scan to show a false-positive, and every finding should be checked out before reporting it. All the verification necessary came from a different host with a simple command:

mysql -u root -h 10.20.30.xx -p

And I had root access to the DB application running on this host. And of course with MySQL access and root DB permissions, it wouldn’t be difficult or long for someone to take control of that server. This was getting frustrating. If the hashes in the mysql.user table were clearly showing that the password was changed, then what was I missing?

At this time I need to remember that I am not a DBA, and I had no clue that there was a “ghost” user in the system. I say ghost because the username actually had no value, but they could access the system from any IP address.

Thankfully I found this post https://dba.stackexchange.com/questions/4614/cannot-drop-anonymous-user-from-mysql-user. Suddenly I realized that this wasn’t as much of an issue with being able to log in as root, rather it was blocking anonymous access to the DB. Semantics? Part of me is curious if I could have logged in with a username of PapaJohn and had it work.

Quickly removing that user from the mysql.user table was all it took to mitigate that vulnerability.

DELETE FROM mysql.user WHERE user='' AND host='%';
FLUSH PRIVILEGES;

 

I did learn today that anonymous access exists on a default MySQL or MariaDB installation. I learned that there is a test DB created by default that needs removing also. An excellent writeup on how to clean a default installation can be found here: https://www.loginradius.com/blog/engineering/is-your-database-secured-think-again/.

I am grateful that this is solved, and I’m thankful I don’t have to scold the application developer for having done this. I am troubled however at a new installation being left open to the wild by default. This is a solid reminder that the need for highly trained engineers is greater than ever, for this inexcusable default configuration for MySQL will not be caught in many of the SMBs that I have traditionally supported. Only due to a vulnerability scan did this even get flagged for the customer, and only through persistence did it get mitigated. A highly trained DBA should have known this in-advance, and known to delete these items immediately after a fresh install. Sadly I think the MySQL and MariaDB communities are doing a disservice to SMBs that lack dedicated DBAs and trust in the communities to provide software that is secure enough to use.

 

So for anyone that needs to search why they can log into a MySQL DB server remotely using the root account and the default password, consider that it may have nothing to do with root at all. Disable anonymous access to the DB, and then worry about changing the password for root.

Making a plan to reduce Digital Hoarding

I’ve been working in IT for more than 20 years now. There are many reasons why I have maintained a digital hoard of outdated executables and installers, but the time has come to make an effective plan for clearing out some debris. In this post I want to look at some of the various reasons maintaining a library has been helpful and necessary. I want to then identify a path forward to clear out all this digital rubbish. Creating a file management plan like this has applicability to all of us as individuals, as the digital debris we leave behind may become more overwhelming for our loved ones than physical possessions.  This topic has serious relevance to businesses, as clearly defined and documented retention policies are more likely to be followed. These retention policies are recommended as one method to reduce several different risks to businesses.

 

How this impacts me

As seen in this screenshot, keeping various versions of files is an easy activity to get carried away with.

List of outdated files

 

Some of the reasons I have kept files is very important to note, and there can be legitimate reasons to keep multiple versions handy. And this isn’t an issue when we are talking about small(ish) files like these nmap installers:

List of nmap installers with size and dates

But… this becomes a huge space consumer when we start looking into entire operating systems backed up as .ISOs, .IMGs, and .DMGs. Windows 7 became end of life on January 14, 2020 and Windows 8.1 will be EOL less than 5 months from this post on January 10, 2023. If I was to have to reinstall an OS on an old computer, I will never install Windows 7. The only reason I have kept these old .ISOs was to become nostalgic and take them for a spin in a VM. This is ridiculous, who has time for that? This size issue has become a huge burden since I started working with CyanogenMod and LineageOS for Androids. It is also a pain due to offline versions of iOS that I needed to maintain for some work functions a few years back.

List of Windows 7 installers with size details. More than 12GB of files

  • Often times developers will deprecate entire programs and do everything they can to pull access to this code. (Microsoft does this often!)
    • This leads to a situation where they only place to download a very useful program is some shady random website. And anyone with a bit of security knowledge understands that it’s trivial to wrap some malware around another executable.
      • For a while I was hosting an online and freely accessible “Toolbox” with installers in this same way. And then I realized I am really not helping this problem. If someone downloads something from my site and it’s clean, that same individual may think that it’s also OK to download something else from another random site. This is proliferating bad behavior, and I don’t want to be part of this any longer.
  • Some times a new version comes out and is incompatible with my current OS. Or a feature is deprecated or broken in a new version.
  • If work is going to be done offline and far away from an Internet connection, then having a giant toolbox is very helpful.
    • This was essential when I was a Peace Corps volunteer, and common practice before people started tethering phones as hotspots.
  • The irrational fear that the Internet would be disrupted severely enough that I needed to hoard access as a means to fix computers in a world that was permanently offline.
    • As I’ve grown older, I realize that if this ever happened I have fear that society as a whole would suffer heavily. This means there is significant incentive and momentum in our country for this situation to not occur.
      • And therefore if it really did occur, fixing computers will not be a high priority for me.
        • It is this same argument that a lot of people, including myself, still own their physical CDs and DVDs, but subscribe to streaming services.

 

With some of those easy reasons out of the way, it’s not hard to imagine the proliferation of executables over the last several years.

My plan to excise some of this waste:

  1. Identify the two most recent versions of an executable or .ISO I have.
    1. In the case of an Operating System, if it is EOL it should be deleted.
  2. Delete everything older.
  3. When I download an updated version of something, delete the older version.

 

I have no reasonable way to guess the amount of time this will take. Also, I am not entirely sure whether as my colleague Jeff would say “is the juice worth the squeeze?” I am aware that my hoarding has now caused a sufficient lack of disk space on a rather expensive SSD, and it’s absurd for me to keep this junk any longer.

 

I wish you all luck. Digital hoarding may be both easier to start and clean up than physical hoarding. I am finding it is just as important to clean out your digital space as it is the physical. Buying a new hard drive just because you run out of space is the digital equivalent of people getting storage lockers because they run out of space in their house.

 

Closing

I want to come back and address this topic separately for its impact to YOU my reader, as well as to IT leaders that may find this relevant to their businesses.