CentOS 8 crond not sending email

This took a while to work out, since I was wrongly assuming it would work by default as in previous versions, but in order for crond to send email on CentOS 8, I had to change /etc/sysconfig/crond to:

$ cat /etc/sysconfig/crond
# Settings for the CRON daemon.
# CRONDARGS= :  any extra command-line startup arguments for crond
CRONDARGS=-m "/usr/sbin/sendmail -t"

as root.  Once the file is changed, restart crond:

# systemctl restart crond

which leads to the following

$ ps -ef |grep cron
root     21528     1  0 23:06 ?        00:00:00 /usr/sbin/crond -n -m /usr/sbin/sendmail -t
rfifarek 21812 20404  0 23:14 pts/1    00:00:00 grep --color=auto cron

This was from a minimal install, fully patched as of 2020-02-28

Linux Mint on Dell XPS 9560

For the most part, Linux Mint 18.3 worked on my new Dell XPS 9560.

That said, what I did have to change:

• the 4k display was impossible to read, so I had to switch to Auto or Double (Hi-DPI) for the User interface scaling
• Menu (lower left) -> Settings -> General -> User interface scaling: 
• prevent lockups by disabling Nouveau video driver and using the commercial Nvidia driver. Maybe I'm just unlucky, but this isn't the first time the Nouveau driver has caused serious issues. 
• Menu (lower left) -> Settings -> Driver Manager (under Administration) -> NVIDIA binary driver 
• another oddity was that the kernel logs (dmesg) were getting spammed with AER logs. This was more of an annoyance than impacting the usability of the system, but I disabled them anyway. In a terminal window: 
• sudo su - 
• Enter password as requested 
• vi /etc/default/grub 
• Change the line GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" to GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pci=noaer" 

 Hope that helps.

Pulling Raw Data from Alienvault's OSSIM MySQL database

I've been playing with OSSIM from alienvault.com (great product), and found myself needing to get automated access to some of the raw asset data that OSSIM was collecting for import into another tool.  What I found was that it was stored in a MySQL database backend, which allowed me to query the data and export it.

To access the MySQL database, you have to first login via SSH to the OSSIM host, and "jailbreak" to the shell.  Once there, you can get the MySQL root password by examining the contents of

/etc/ossim/server/config.xml

Then connect to the database:

mysql -p alienvault

Once there, I worked out that the IP was stored in hexadecimal, and the data that I needed was spread across a couple of tables.  A little SQL magic, and I could get all the data into the string format I wanted.  Here's an example of getting the IP and MAC address:

mysql> select inet_ntoa(conv(HEX(ip),16,10)) as ip,
    -> CONCAT_WS(':',SUBSTR(HEX(mac),1,2),
    -> SUBSTR(HEX(mac),3,2), SUBSTR(HEX(mac),5,2),
    -> SUBSTR(HEX(mac),7,2), SUBSTR(HEX(mac),9,2),
    -> SUBSTR(HEX(mac),11,2)) as mac
    -> from host_ip;
+----------------+-------------------+
| ip             | mac               |
+----------------+-------------------+
| 10.1.1.1       |                   |
| 192.168.56.102 | 08:00:27:D9:81:0E |
| 192.168.56.1   | 0A:00:27:00:00:00 |
+----------------+-------------------+
3 rows in set (0.00 sec)

May not be the most efficient way, but it worked. There is plenty of other data you could grab within these tables.

OpenVAS 5.0 Appliance Fixes

Spent some time today getting the OpenVAS downloadable appliance working today.  The first piece that is missing is the necessary step of fixing the timezone.  If the timezone of the client (most likely your host OS) and the server VM doesn't match, you will run into an issue where when you try to login to GSAD with a browser, you will receive the error "Session has expired, Please login again".  A quick Google search lead me to this post:

http://lists.wald.intevation.org/pipermail/openvas-discuss/2011-June/003128.html

The solution listed there used the ntpdate command to get the clock back in sync, however, it didn't entirely address my issue.  The other issue for me was that the timezone was EST, not MST like my client system, or UTC like my servers.  To fix that, run the following commands as root:

apt-get install ntp
cp /usr/share/zoneinfo/[country/city or timezone] /etc/localtime
reboot

where country/city for me was America/Denver, for example.

From there, it works "out of the box".  Well, sorta.  If you follow the advice on the download page:

"You should upgrade the base system immediately to install all security updates published meanwhile. The base system is Debian Squeeze, so you need to run "apt-get dist-upgrade" or other managament tools you might prefer."

it stops working again.

Two issues that arose with this.

First, the VM that was created for me by opening the OVA appliance image in VMware Workstation created a disk of 8GBs, which is fine until you decide to update it.  Upon running "apt-get dist-upgrade", the partition fills up before the update finishes.  Once I realized that was happening, I paused the "apt-get dist-upgrade" run with ctrl-z, and removed the filesystem reservation from the ext3 filesystem with the command "tune2fs -m0 /dev/sda1".  That freed up enough disk space to allow the process to finish.  Keep in mind, this is a quick fix, and may not be enough to get around this in the future.  In that case, you'll need to extend the disk size in the VM settings, and then resize the partition within the VM - no small task.

Update: Had some time to do some more digging, and found that the majority of the disk space is used by the /root/source directory, and one file in particular /root/source/dummy at 2.4GBs.  It's not clear if this file is important, or even what it is.  bzip2'd the file, and the resulting size was 1.8KB, so obviously not much real data in it.  If you need even more disk space, /root/source/debian has a lot of source tarballs that can probably be removed.

Second issue I ran into was that upon logging into gsad via a browser, the gsad process would max out the CPU, and nothing would happen.  Ran strace on the process, and it would just sit and spin in an infinite loop.  Back to Google, which turned up a string of mailing list posts, but the first response lead me down the right path:

http://lists.wald.intevation.org/pipermail/openvas-discuss/2012-November/004652.html

(Related to that email thread: People, stop whining about free services/software.  They are free.  Either help fix the problem, or shut up and go buy something.  Then complain to the folks you just paid.)

The issue is with the newer libmicrohttpd that was installed by "apt-get dist-upgrade" breaking gsad.  To fix this, run the following as root:

cd /root/libmicrohttpd/libmicrohttpd-0.9.15/

./configure && make && make check
cp ./src/daemon/.libs/libmicrohttpd.so.10.13.0 /usr/local/lib/
ln -s /usr/local/lib/libmicrohttpd.so.10.13.0 /usr/local/lib/libmicrohttpd.so.10
ldconfig -v

In the ldconfig output, you should see libmicrohttpd.so.10 listed in /usr/local/lib BEFORE the system installed libmicrohttpd.so.10 in /usr/lib. Reboot, and now gsad will use the new (older) version of libmicrohttpd, which works.

Enjoy.
-R

Register now for Cyber Defense Initiative 2012, December 7-16, Washington DC. Choose from 20+ courses; event includes dedicated digital forensics campus, NetWars Tournament of Champions, evening bonus sessions, and full vendor expo! http://www.sans.org/info/112329

CentOS/RHEL Shrink Partitions

Increasing LVM partition sizes in CentOS/RHEL 5.X is infinitely easier than shrinking them, but in the rare instance where you might have to, here's a quick guide on a couple of gotchas. If you need to shrink the / partition (probably the rarest occurrence), you're stuck booting off a LiveCD and hoping for the best.

Now I bet you're saying something along the lines of "but all the other partitions should be easy, right?" Uh, no, particularly /usr. Why? Well, someone decided that the LVM utilities should reside under /usr. Not a big deal, they provide a static /sbin/lvm.static, which, while the syntax is slightly different, provides most (all?) of the functionality you are used to from the LVM utils.

Great, problem solved, right?! Nope, not quite. While /bin/bash (default root shell) doesn't depend on libraries under /usr, it does hold open files from the /usr tree. That prevents you from un-mounting /usr.

To shrink "system" partitions (except /, see above), you will likely need to be in single user mode, but before you do that, run chsh:

[root@centos5 ~]# chsh
Changing shell for root.
New shell [/bin/bash]: /bin/sh
Shell changed.
[root@centos5 ~]#

to change the login shell for the root user. After you are done, you can switch it back. Now reboot into single user mode.

Once in single user mode, you'll notice the prompt has now changed to:

sh-3.2#

or similar. Even though /bin/sh is just a symlink to /bin/bash, bash detects that it's being run as sh, runs with a reduced feature set, which doesn't require it to open files on /usr.

To shrink the /usr partition:

• umount /usr 
• e2fsck -f /dev/path/to/lvm/partition 
• resize2fs /dev/path/to/lvm/partition  [new size slightly smaller than desired final result]
• lvm.static lvmreduce -L [new size] /dev/path/to/lvm/partition
• resize2fs /dev/path/to/lvm/partition
• e2fsck -f /dev/path/to/lvm/partition
• mount /usr  

Wash, rinse, repeat for other partitions.

Enjoy. -R

Don't miss SANS Network Security 2012, September 16-24 in Las Vegas, your annual mega-networking opportunity. Choose from over 35 courses, huge vendor expo, riveting bonus sessions, and a thrilling NetWars competition. Sign up today! http://www.sans.org/info/107529

Community SANS Security 401: Security Essentials Bootcamp Style in Boulder, Colorado - Discount Code!

http://www.sans.org/boulder09_cs/description.php?tid=672

I will be teaching (!) SANS Security 401 in Boulder, Colorado this Oct. 19 - 24th, 2009. This is a great "intro" class for folks starting out in computer and network security. The course covers the most common issues facing computer security professionals today. It's both broad and deep in it's scope of information. The course is broken out into the following daily topics:

Day 1: Networking Concepts
Day 2: Defense In-Depth
Day 3: Internet Security Technologies
Day 4: Secure Communications
Day 5: Windows Security
Day 6: Linux Security

Follow the links above for more detail on the topics covered for each day.

I'm working on getting some guest speakers for the lunch breaks covering more advanced topics. If you know of any folks local to the Boulder area that would be interesting to hear from, let me know!

Discount Code: If you use the discount code COINS-RF when registering, you'll get a 10% discount off the price of the course. Need a bigger discount? Contact me at rfifarek at sans DOT org for more information.

Department of Defense employees and contractors: Please note that the Security 401 SANS Security Essentials course prepares you to pass the GSEC and S+ certifications. These are two of the certifications which meet the requirements listed in DoD directive 8570.1 for IAT Level II employees and contractors. For details, click on http://www.giac.org/info/41124.

-R

WIP: Steps to Grow Physical Volume on LVM on Virtual Machine

This is a work in progress, expect the post to change, perhaps drastically. This isn't the "simplest" way to do this, you could do this all online, but this allowed us to maintain consistency in setup across multiple physical and virtual machines.

Skeleton outline:

- Snapshot and shutdown the VM (bummer)
- Within VMware Infrastructure Client, extend the disk allocation for the VM
- Power on the VM
- Check that the disk size change is seen by the VM: run dmesg or fdisk -l
- fdisk the disk
- within fdisk, delete the physical partition that you wish to extend, then recreate the physical partition with the same options except extend the size to use the newly added free disk space
- write out the changes to disk and exit
- reboot the VM
- run pvdisplay
- run pvresize on the newly extended partition
- verify that the resize worked by comparing pvdisplay output
- verify that the new "Free PE" has increased with vgdisplay
- use lvcreate (-n LVNAME -L SIZE VolumeGroup) or lvextend to allocate new space

Voila!