TechGuySG

"rhsecapi"

rhsecapi makes it easy to interface with the Red Hat Security Data API.

From the RPM info in the rhsecapi package:

Leverage Red Hat's Security Data API to find CVEs by various attributes (date, severity, scores, package, IAVA, etc). Retrieve customizable details about found CVEs or about specific CVE ids input on cmdline. Parse arbitrary stdin for CVE ids and generate a customized report, optionally sending it straight to pastebin. Searches are done via a single instantaneous http request and CVE retrieval is parallelized, utilizing multiple threads at once. Python requests is used for all remote communication, so proxy support is baked right in. BASH intelligent tab-completion is supported via optional Python argcomplete module. Python2 tested on RHEL6, RHEL7, & Fedora but since it doesn't integrate with RHN/RHSM/yum/Satellite, it can be used on any internet-connected machine. Feedback, feature requests, and code contributions welcome.

This tool make it easy to make a query regarding a CVE against RH suite of products and check how are they affected.

A simple query on a CVE

$rhsecapi CVE-2024-3094

 [NOTICE ] rhsda: Found 1 CVEs on cmdline
 [NOTICE ] rhsda: Valid Red Hat CVE results retrieved: 1 of 1

 CVE-2024-3094
  SEVERITY : Critical Impact
  DATE     : 2024-03-29
  BUGZILLA : 2272210
  FIX_STATES :
  Not affected: Red Hat Enterprise Linux 6 [xz]
  Not affected: Red Hat Enterprise Linux 7 [xz]
  Not affected: Red Hat Enterprise Linux 8 [xz]
  Not affected: Red Hat Enterprise Linux 9 [xz]
  Not affected: Red Hat JBoss Enterprise Application Platform 8 [xz]

Another query that also shows the relevant RHSA

rhsecapi CVE-2023-4911 [NOTICE ] rhsda: Found 1 CVEs on cmdline [NOTICE ] rhsda: Valid Red Hat CVE results retrieved: 1 of 1

CVE-2023-4911

 SEVERITY : Important Impact
 DATE     : 2023-10-03
 BUGZILLA : 2238352

 FIXED_RELEASES :
  Red Hat Enterprise Linux 8: [glibc-0:2.28-225.el8_8.6] via RHSA-2023:5455 (2023-10-05)
  Red Hat Enterprise Linux 8: [glibc-0:2.28-225.el8_8.6] via RHSA-2023:5455 (2023-10-05)
  Red Hat Enterprise Linux 8.6 Extended Update Support: [glibc-0:2.28-189.6.el8_6] via RHSA-2023:5476 (2023-10-05)
  Red Hat Enterprise Linux 9: [glibc-0:2.34-60.el9_2.7] via RHSA-2023:5453 (2023-10-05)
  Red Hat Enterprise Linux 9: [glibc-0:2.34-60.el9_2.7] via RHSA-2023:5453 (2023-10-05)
  Red Hat Enterprise Linux 9.0 Extended Update Support: [glibc-0:2.34-28.el9_0.4] via RHSA-2023:5454 (2023-10-05)
  Red Hat Virtualization 4 for Red Hat Enterprise Linux 8: [glibc-0:2.28-189.6.el8_6] via RHSA-2023:5476 (2023-10-05)
  Red Hat Virtualization 4 for Red Hat Enterprise Linux 8: [redhat-release-virtualization-host-0:4.5.3-10.el8ev] via RHSA-2024:0033 (2024-01-03)
  Red Hat Virtualization 4 for Red Hat Enterprise Linux 8: [redhat-virtualization-host-0:4.5.3-202312060823_8.6] via RHSA-2024:0033 (2024-01-03)

FIX_STATES :

 Not affected: Red Hat Enterprise Linux 6 [glibc]
 Not affected: Red Hat Enterprise Linux 7 [compat-glibc]
 Not affected: Red Hat Enterprise Linux 7 [glibc]

UPDATE : There is a version that supports python3 used in RHEL8/9. You can get it here

Download-RPM

One problem is that rhsecapi needs python2 so it is problem getting it to run on anything newer than RHEL7. There is an option to run it in a docker container.

This is the method I ended up using to run rhsecapi.

distrobox which used podman to create a Centos 7 container then install the rhsecapi rpm.

[bogus@myhost ~]$ distrobox enter --root centos7

[bogus@centos7 ~]$ rhsecapi -h

usage: rhsecapi [--q-before YYYY-MM-DD] [--q-after YYYY-MM-DD] [--q-bug BZID] [--q-advisory RHSA] [--q-severity IMPACT] [--q-product PRODUCT] [--q-package PKG] [--q-cwe CWEID] [--q-cvss SCORE] [--q-cvss3 SCORE] [--q-empty] [--q-pagesize PAGESZ] [--q-pagenum PAGENUM] [--q-raw RAWQUERY] [-i YYYY-?-NNNN] [-x] [-0] [-f FIELDS | -a | -m] [-p PRODUCT] [-j] [-u] [-w [WIDTH]] [-c] [-l {debug,info,notice,warning}] [-t THREDS] [-P] [-E [DAYS]] [--dryrun] [-h] [--help] [CVE-YYYY-NNNN [CVE-YYYY-NNNN ...]]

Run rhsecapi --help for full help page

VERSION: rhsecapi v1.0.1 last mod 2017/06/27 See http://github.com/ryran/rhsecapi to report bugs or RFEs

"TCP_WRAPPERS"

In ALMALinux/Centos/RHEL 8, tcp_wrappers support was removed from the openssh daemon. This was already done sometime back in Fedora 28 release. Reasons given were as follows:

This was very useful 20 years ago, when there were no firewalls in Linux. This is not the case for today and connection filtering should be done in network level or completely in application scope if it makes sense.

While firewall rules can provide similar functionality but tcp_wrappers is still handy in some situations.

TCP Wrappers (also known as tcp_wrappers) is a host-based networking ACL system, used to filter network access to Internet Protocol servers on (Unix-like) operating systems such as Linux or BSD. It allows host or subnetwork IP addresses, names and/or ident query replies, to be used as tokens on which to filter for access control purposes. Let's do a bit of history first on the origins of tcp_wrappers.

The story begins in 1990 at Eindhoven University of Technology where Wietse Venama was administrator of the computer system network. Wietse is also the creator of the Postfix SMTP server. The university system was coming under increasingly heavy attacks from a Dutch computer cracker who was consistently able to gain root privilege. The cracker was skilled at typing the following command sequence:

rm -rf /

One night, Wietse noticed the cracker was watching him over the network, making contact with the finger network service. Since finger does not require a password, he was finally able to explain why much of the crackers activities had gone unnoticed. Wietse’s first reaction was to shutdown the finger network service. Instead, he decided it would prove more beneficial to maintain the service and determine where the finger requests were coming from. The solution he found was to make a swap by moving the vendor provided network server programs to another location, and install a trivial (TCP Wrapper) program in their place. Whenever a connection was made, the trivial program would just record the name of the remote host and then run the original network server program. The first TCP Wrapper version was just a few lines of code that Wietse carefully copied from an old network daemon source. Because it did not exchange any information with the client or server processes, the same TCP Wrapper version could be used for many types of network services. He made several improvement to the software and used to monitor the cracker activities. However the cracker was never caught. He maintained it until 1995, and on June 1, 2001, released it under its own BSD-style license.

The following attributes of TCP Wrappers are of prime importance:

• Wrappers can be installed without any changes to existing software, or to existing configuration files.
• The wrapper programs have no interaction with the client user.
• The wrappers have no interaction with the server application.
• Once the wrappers have established interaction between client and server, the wrapper disappears. Consequently, there is no overhead on either end.

In the previous version of Centos/RHEL before release 8, the openssh daemon, sshd had the libwrap library compiled in. This means the tcp_wrapper feature was supported and it worked in the following manner.

tcp_wrapper looks at the content of two files to determine access to network services:

/etc/hosts.allow

/etc/hosts.deny

rules in /etc/hosts.allow is processed first.

If you want to explicitly allow localhost full access and block 192.178.0.114 from accessing sshd, the contents of the two files are as follows

/etc/hosts.allow ALL: 127.0.0.0/8

/etc/hosts.deny sshd: 192.168.0.114

sshd because of the libwrap library will honor the hosts.deny entry and refuse ssh connection from the host 192.168.0.114. Any modification to the files will take immediate effect.

I have been using tcp_wrapper to block ssh brute force attacks. A background program watches the /var/log/secure for failed attempts to login via ssh. After 3 failed tries, the IP address of the attacker is entered into /etc/hosts.deny file and that attacking host is blocked instantly.

While this can also be done by creating a firewall rule to DROP/REJECT connection from this attacker. I find the tcp_wrapper approach to be simpler and I have a list of the offending IPs in one file.

This approached had work very well for many years until Centos release 8. The openssh no longer has the libwrap library. So I used Fail2Ban to block ssh brute force attacks instead. It will block the attacking IPs by creating firewall rules via firewalld.

Recently I wanted to try to find a way to use tcp_wrapper like mechanism to block ssh brute force attacks. After review some options I reread this link and it provided a way to incorporate tcp_wrapper support to sshd. In fact, the methodology is very similar to the approach used in the 1990s when Wietse implement tcp_wrappers.

The implementation is as follows:

Install tcp_wrappers

yum install tcp_wrappers

cd /etc/systemd/system/

cp /usr/lib/systemd/system/sshd@.service .

edit sshd@.service

CHANGE THIS LINE ExecStart=-/usr/sbin/sshd -i $OPTIONS $CRYPTO_POLICY

TO ExecStart=@-/usr/sbin/tcpd /usr/sbin/sshd -i $OPTIONS $CRYPTO_POLICY

IF SELINUX is enforced, this seboolean needs to be turn on

setsebool ssh_use_tcpd on getsebool ssh_use_tcpd ssh_use_tcpd --> on

Stop the current ssh service and start the sshd socket systemctl stop sshd; systemctl start sshd.socket

To make it permanent remember to disable sshd.service and enable sshd.socket

the tcpd program will checks on the /etc/hosts.allow and /etc/hosts.deny (create them first) files before running the sshd program. Essentially the same tcp_wrapper functionality is back in place. I can now run my ssh brute force blocking program again.