My notes, things I have learned, and documentation I have created.

OS: CentOS7

You should have your TXT record set in your DNS prior to implementing this on your server:
“v=spf1 mx ip4:aaa.bbb.ccc.ddd ip4:eee.fff.ggg.hhh -all”

Here is link I found useful to understand the options for the DNS record:
https://support.dnsimple.com/articles/spf-record/

You need to have the EPEL repository enabled to install the pypolicyd-spf package using the methodology I have outlined here.

To install and enable the EPEL repository:

# yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

Install the package Python package:

# yum install pypolicyd-spf

Modify the main.cf to add SPF verifcation to postix:
The master.cf and main.cf need to modified:

# cd /etc/postfix/
# cp -p master.cf master.cf.20190716
# vi master.cf
…
policy unix – n n – 0 spawn user=nobody argv=/bin/python /usr/libexec/postfix/policyd-spf
…

# cp -p main.cf main.cf.20190716
# vi main.cf
…
smtpd_recipient_restrictions =
permit_sasl_authenticated,
reject_unauth_destination
check_policy_service unix:private/policy
…

Note: the policy defined in the master.cf does not need to be named “policy”. However, if you change that, you need to also change it in your “check_policy_service” statement in the main.cf.

Restart postfix to implement changes:
# systemctl restart postfix

Let me just preface this post by saying “This is not a persistent configuration. If you boot the system, these settings will be lost unless you save them via the /etc/sysconfig/network-scripts files or through NetworkManager.

Here is how you can manually configure the IP address and gateway in CentOS/RHEL7:

Configure the IP address and subnet mask:

# ip addr add aaa.bbb.ccc.ddd/ss dev interface

For example:

# ip addr add 123.123.123.123/24 dev eno1

Likewise, to remove the IP address:

# ip addr del 123.123.123.123/24 dev eno1

To configure the default gateway:

# ip route add default via ddd.ccc.bbb.aaa dev interface

For example:

# ip route add default via 123.123.123.254 dev eno1

Same kind of thing to remove the currently configured gateway:

# ip route del default via 123.123.123.254 dev eno1

Once you have the interface configure, bring it up:

# if link set eno1 up

And to take it down:

# if link set eno1 down

I used the following procedure to disable the weak ciphers enabled in openssh on CentOS 7:

You could probably guess where you this should be configured, but one of the challenges can be getting of complete list of what is supported.

Get a list of supported ciphers:

# ssh -Q cipher
3des-cbc
blowfish-cbc
cast128-cbc
arcfour
arcfour128
arcfour256
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc@lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com

To disable one or more, you need to explicitly specify the ciphers you do want to use. For example, arcfour:

# vi /etc/ssh/sshd_config
…
Ciphers 3des-cbc,blowfish-cbc,cast128-cbc,aes128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

…

And then, restart sshd:

# systemctl restart sshd

And check:

$ ssh -c arcfour localhost
no matching cipher found: client arcfour server 3des-cbc,blowfish-cbc,cast128-cbc,aes128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

CentOS 7
VMware ESXi

I used the following method to remove a disk from a system. Note: In this case the volume group only had one volume on it.

Disk: /dev/sde
Volume Name: /dev/vg_name/lv_name
Volume Group Name: vg_name

Remove all volumes in a group:

# lvremove vg_name
Do you really want to remove active logical volume lv_name? [y/n]: y
Logical volume “lv_name” successfully removed

Remove the group:

# vgremove vg_name
Volume group “vg_name” successfully removed

Remove the volume:

# pvremove -v /dev/sde
Wiping cache of LVM-capable devices
Labels on physical volume “/dev/sde” successfully wiped

I deleted the disk from vSphere, and then rescan for the changes:

# echo “- – -” > /sys/class/scsi_host/host0/scan

Verify that the disk is no longer there:

# fdisk -l /dev/sde

I decided to give OpenVAS as an alternative to Nessus thinking it would be pretty comparable since it is Nessus fork and the Nessus cost was too much for a small company. I used the following to install it on CentOS7.

First the requirements. They are not clearly defined on the OpenVAS page for downloading the binary packages, which I did. You need to disable SElinux. I had mine in permissive mode and it caused some problems. The rest was pretty straight forward. This uses the Atomicorp repository.

To install and perform initial configuration:

# wget -q -O – http://www.atomicorp.com/installers/atomic |sh
# yum upgrade
# yum install openvas
# openvas-setup

To stop, start and check OpenVAS services:

# systemctl stop openvas-manager
# systemctl status openvas-manager
# systemctl start openvas-manager
# systemctl status openvas-scanner
# systemctl stop openvas-scanner
# systemctl start openvas-scanner

Location of the logs:

# cd /var/log/openvas/
# tail gsad.log
# tail openvassd.log
# tail openvasmd.log

This is a very useful command to very the status of you installation. It was helpful in determining that I needed to disable SElinux:

# openvas-check-setup

This command rebuilds the database information:

# openvasmd –rebuild

As a result of not having SElinux disabled, I found that the redis (an advanced key-value store) service was not running so the OpenVAS scanner would not work properly after I rebooted. With SElinux disabled, I restarted redis.
# systemctl stop redis
# systemctl start redis
# systemctl status redis

And then to check the status:

# openvas-check-setup
openvas-check-setup 2.3.7
Test completeness and readiness of OpenVAS-8
(add ‘–v6’ or ‘–v7’ or ‘–v9’
if you want to check for another OpenVAS version)

Please report us any non-detected problems and
help us to improve this check routine:
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Send us the log-file (/tmp/openvas-check-setup.log) to help analyze the problem.

Use the parameter –server to skip checks for client tools
like GSD and OpenVAS-CLI.

Step 1: Checking OpenVAS Scanner …
OK: OpenVAS Scanner is present in version 5.0.7.
OK: OpenVAS Scanner CA Certificate is present as /var/lib/openvas/CA/cacert.pem.
OK: redis-server is present in version v=3.0.7.
OK: scanner (kb_location setting) is configured properly using the redis-server socket: /tmp/redis.sock
OK: redis-server is running and listening on socket: /tmp/redis.sock.
OK: redis-server configuration is OK and redis-server is running.
OK: NVT collection in /var/lib/openvas/plugins contains 51943 NVTs.
WARNING: Signature checking of NVTs is not enabled in OpenVAS Scanner.
SUGGEST: Enable signature checking (see http://www.openvas.org/trusted-nvts.html).
OK: The NVT cache in /var/cache/openvas contains 51943 files for 51943 NVTs.
Step 2: Checking OpenVAS Manager …
OK: OpenVAS Manager is present in version 6.0.9.
OK: OpenVAS Manager client certificate is present as /var/lib/openvas/CA/clientcert.pem.
OK: OpenVAS Manager database found in /var/lib/openvas/mgr/tasks.db.
OK: Access rights for the OpenVAS Manager database are correct.
OK: sqlite3 found, extended checks of the OpenVAS Manager installation enabled.
OK: OpenVAS Manager database is at revision 146.
OK: OpenVAS Manager expects database at revision 146.
OK: Database schema is up to date.
OK: OpenVAS Manager database contains information about 51943 NVTs.
OK: At least one user exists.
OK: OpenVAS SCAP database found in /var/lib/openvas/scap-data/scap.db.
OK: OpenVAS CERT database found in /var/lib/openvas/cert-data/cert.db.
OK: xsltproc found.
Step 3: Checking user configuration …
WARNING: Your password policy is empty.
SUGGEST: Edit the /etc/openvas/pwpolicy.conf file to set a password policy.
Step 4: Checking Greenbone Security Assistant (GSA) …
OK: Greenbone Security Assistant is present in version 6.0.11.
Step 5: Checking OpenVAS CLI …
OK: OpenVAS CLI version 1.4.5.
Step 6: Checking Greenbone Security Desktop (GSD) …
SKIP: Skipping check for Greenbone Security Desktop.
Step 7: Checking if OpenVAS services are up and running …
OK: netstat found, extended checks of the OpenVAS services enabled.
OK: OpenVAS Scanner is running and listening on all interfaces.
OK: OpenVAS Scanner is listening on port 9391, which is the default port.
OK: OpenVAS Manager is running and listening on all interfaces.
OK: OpenVAS Manager is listening on port 9390, which is the default port.
OK: Greenbone Security Assistant is listening on port 80, which is the default port.
Step 8: Checking nmap installation …
WARNING: Your version of nmap is not fully supported: 6.47
SUGGEST: You should install nmap 5.51 if you plan to use the nmap NSE NVTs.
Step 10: Checking presence of optional tools …
OK: pdflatex found.
WARNING: PDF generation failed, most likely due to missing LaTeX packages. The PDF report format will not work.
SUGGEST: Install required LaTeX packages.
OK: ssh-keygen found, LSC credential generation for GNU/Linux targets is likely to work.
OK: rpm found, LSC credential package generation for RPM based targets is likely to work.
WARNING: Could not find alien binary, LSC credential package generation for DEB based targets will not work.
SUGGEST: Install alien.
OK: nsis found, LSC credential package generation for Microsoft Windows targets is likely to work.
OK: SELinux is disabled.

It seems like your OpenVAS-8 installation is OK.

If you think it is not OK, please report your observation
and help us to improve this check routine:
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
Please attach the log-file (/tmp/openvas-check-setup.log) to help us analyze the problem.

To update the rules or tests (Network Vulnerability Tests – NVTs), you can use the following command which is run by the setup when you run it. I believe this is the one that very clearly says that you should at most run this once a day, otherwise they will block you IP address. It looks like they usually updated once a week anyway. If so, you will get something like the following:

# openvas-nvt-sync
[i] This script synchronizes an NVT collection with the ‘OpenVAS NVT Feed’.
[i] The ‘OpenVAS NVT Feed’ is provided by ‘The OpenVAS Project’.
[i] Online information about this feed: ‘http://www.openvas.org/openvas-nvt-feed.html’.
[i] NVT dir: /var/lib/openvas/plugins
OpenVAS community feed server – http://www.openvas.org/
This service is hosted by Greenbone Networks – http://www.greenbone.net/

All transactions are logged.

If you have any questions, please use the OpenVAS mailing lists
or the OpenVAS IRC chat. See http://www.openvas.org/ for details.

By using this service you agree to our terms and conditions.

Only one sync per time, otherwise the source ip will be blocked.

[i] Feed is already current, no synchronization necessary.

I wanted to log as much useful information as I could from a Avaya phone system to my CentOS 7.x syslog server running rsyslogd.

That was easy, as I may noted before here:

# vi /etc/rsyslog.conf
…
if $fromhost-ip startswith ‘aaa.bbb.ccc.ddd‘ then /var/log/mylog.log
& ~

…

# systemctl restart rsyslog

However, I found my log flooded with the same unneeded messages over and over. To prevent those message from being logged into any of the log files, I made the following configuration changes:

# vi /etc/rsyslog.conf
…
:msg, contains, “what I want to filter out” ~
…

# systemctl restart rsyslog

To List all timezones:

# timedatectl list-timezones

To set to the new timezone:

# timedatectl set-timezone newtimezone

Sample output:

# timedatectl list-timezones | grep Angeles
# timedatectl set-timezone America/Los_Angeles
# date
Thu Mar 5 11:56:43 PST 2015
# ls -l /etc/localtime
lrwxrwxrwx. 1 root root 41 Mar 5 11:56 /etc/localtime -> ../usr/share/zoneinfo/America/Los_Angeles

To view your current timezone configuration:

# timedatectl status

CentOS: 6.6

When setting an SFTP server, you may want to restrict or jail the SFTP users to only one location without restricting all aspects of openssh. This is how I restricted SFTP without impacting all of openssh:

Create the group you will match to and therefore add users to to grant SFTP access:

# groupadd sftp

Create a user:

# useradd -G sftp -d /into -s /sbin/nologin testuser

Notice the home directory. This is the logical root location for the user. Also, note that the shell is nologin to prevent ssh access.

Set the password:

# passwd testuser

Make a backup copy of the sshd_config file and make the following changes to the existing file:

# cp -rp sshd_config sshd_config.orig
# vi sshd_config
…
# JGZ – Force to use openssh in-process sftp server
#Subsystem sftp /usr/libexec/openssh/sftp-server
Subsystem sftp internal-sftp
…
# JGZ – Match to group to chroot
Match Group sftp
ChrootDirectory /sftpdir/%u
AllowTCPForwarding no
X11Forwarding no
ForceCommand internal-sftp
…

Restart the service:

# service sshd restart

It is very important that the directory permissions are correct. Create directories and set permissions:

# mkdir /sftpdir
# chmod 755 /sftpdir
# ls -ld /sftpdir
drwxr-xr-x. 3 root root 4096 Feb 27 05:53 /sftpdir
# mkdir /sftpdir/testuser
# chmod 755 /sftpdir/testuser
# ls -ld /sftpdir/testuser/
drwxr-xr-x. 3 root root 4096 Feb 27 14:57 /sftpdir/testuser/
# mkdir /sftpdir/testuser/into
# chown testuser.sftp /sftpdir/testuser/into
# chmod 755 /sftpdir/testuser/into
# ls -ld /sftpdir/testuser/into
drwxr-xr-x. 2 testuser sftp 4096 Feb 27 15:07 /sftpdir/testuser/into/

It should be simple enough to create a script to create new users. Basically, this what you need:
# useradd -G sftp -d /intocbb -s /sbin/nologin testuser1
# mkdir -p /home/testuser1/incoming
# chown testuser1.sftp incoming/
# passwd testuser1

OS: CentOS6

I was getting a bunch of duplicate package messages when I tried to update one of my servers. It had been a while and I didn’t remember what I might have done, but I suspect that I stopped a yum update in the middle to cause all the duplicates.

Here are a list of commands that I used in the past to get yum working again:

Complete any unfinished transactions, if it was stopped in the middle at some point:

# yum-complete-transaction

Will clean all cached data:

# yum clean all

List duplicate packages:

# package-cleanup –dupes

Remove duplicate packages:

# package-cleanup –cleandupes

I needed to add more storage to my CentOS6 machine for my remote system backups. I decided to allocate a completely new volume group and volume to facilitate this need. Here are the steps I used to create the volume:

The new disk was added via vSphere, since this a VM. I determined the correct device file by looking to the dmesg output.

Initialize the whole disk using pvcreate.
# pvcreate /dev/sde

For partitions, use pvcreate /dev/sde[x].

Create a volume group
# vgcreate vg_vmlinux01_backup /dev/sde

To add multiple disks or partions, use vgcreate volume_group_name /dev/sdx /dev/sdy …

Activate the volume group:
# vgchange -a y vg_vmlinux01_backup

Create logical volume
This will allocate all remaining available space to the volume. You can use -L to specify a particular size. Not needed in my case.
# lvcreate -l 100%FREE -n lv_rmbackup vg_vmlinux01_backup

Write the filesystem with the desired label.
# mkfs -t ext4 -j -L /rmbackup /dev/vg_vmlinux01_backup/lv_rmbackup

If you need to create the filesystem with more than the default number of inodes:
# mkfs -t ext4 -j -N 20000000 -L /rmbackup /dev/vg_vmlinux01_backup/lv_rmbackup

Modify the /etc/fstab:
# vi /etc/fstab
…
LABEL=/rmbackup /rmbackup ext4 defaults 1 0
…

Mount it:
# mount /rmbackup