Based on this post, haproxy has provided mitigation acls rules that can be used to help fight against log4j attack requests getting proxied to the affected log4j apps.
In reading some of the users comments, It came to my attention that many Enterprise Linux Haproxy system out there might be running an older haproxy version 1.5 which doesn't have the option http-buffer-request directive. This directive is critical to any CVE you are trying to mitigate, even more so if this is your only option until you can upgrade the affected applications.
what is the easiest way to upgrade and to what version?
Answering my own question...
Haproxy 1.6 is needed, however RH provides haproxy 1.8 from the RHSCL repo
Make sure these repos are active on the system and install haproxy1.8
subscription-manager repos --enable=rhel-7-server-optional-rpms --enable=rhel-7-server-rpms --enable=rhel-server-rhscl-7-rpms
yum install -y rh-haproxy18.x86_64
cat the current config into the 1.8 cfg file and run a quick test config
cat /etc/haproxy/haproxy.cfg > /etc/opt/rh/rh-haproxy18/haproxy/haproxy.cfg
/opt/rh/rh-haproxy18/root/usr/sbin/haproxy -c -V -f /etc/opt/rh/rh-haproxy18/haproxy/haproxy.cfg
^ correct any warns or alert errors, In my experience, its mainly directive order or check port strings on your backend services. this is relatively simple to search the net for and correct
nano /etc/opt/rh/rh-haproxy18/haproxy/haproxy.cfg
Add the ACLS Rules, use unique names if using more than one listener/frontend in the cfg so they don't overlap
systemctl disable --now haproxy && systemctl enable --now rh-haproxy18-haproxy
yum remove -y haproxy && yum install -y rh-haproxy18-haproxy-syspaths.x86_64
^ the rh-haproxy18-haproxy-syspaths.x86_64 package replaced the haproxy service name so you do not have to update the systemctl scripts or even keepalived if you are using it to monitor haproxy service
I use this within keepalived which works before and after
killall -0 haproxy
HAProxy have blogged about this topic.
December/2021 – CVE-2021-44228: Log4Shell Remote Code Execution Mitigation
Related
I want to connect my poller to start monitoring. Unfortunately when exporting the configuration, the poller does not start running
View no executed poller (NON)
I tried to change the IP of the poller, restart the gorgon services of the two machines, nothing worked.
Anyone have an idea of the solution?
One common oversight on fresh installs is to not disable the firewall and the selinux. From personal experience, it may help to restart all processes in the command line after the first config export attempt from the web interface (Configuration > Pollers > Export Configurations).
On pollers:
systemctl enable centreon centengine
On Central:
systemctl restart php-fpm httpd24-httpd centreon cbd centengine gorgoned
Otherwise, I might need more information. If your issue hasn't been resolved yet, mind sharing:
Your centreon version (from the capture I'd guess Centreon 22.04)
You install medium (from source, packages, OVA/VM)
Your distro
You may find some more clues in the logs:
PHP error logs
For version using PHP 7.2 or 7.3 on centOs 8 or PHP 8
tail -f /var/log/php-fpm/centreon-error.log
For version using PHP 7.3 on centOs 7
tail -f /var/opt/rh/rh-php73/log/php-fpm/centreon-error.log
For version using PHP 7.2 on centOs 7
tail -f /var/opt/rh/rh-php72/log/php-fpm/centreon-error.log
centreon-engine logs (On Central and on Poller)
tail -f /var/log/centreon-engine/centengine.log
centreon-broker logs (On Central)
tail -f /var/log/centreon-broker/central-broker-master.log
centreon gorgone logs (On Central and on Poller)
tail -f /var/log/centreon-gorgone/gorgoned.log
I follow the first steps to install Flink.
I can start the cluster without any problem
$ start-cluster.sh
Starting cluster.
Starting standalonesession daemon on host DESKTOP-....
Starting taskexecutor daemon on host DESKTOP-....
But I don't get any status from
$ ps aux | grep flink
I can also not access the dashboard via localhost:8081.
There is an older post having these issues, but the solution didn't work for me, since the described conf files do no longer exist, apparently.
My JAVA_HOME is set as C:\Progra~1\Java\jdk1.8.0_311 to avoid issues with the space in Program Files.
Can you check the logs in the /logs folder? I'm suspecting that C:\Program Files\ could still cause issues because of the space there.
go to download Flink folder and try bash command
$./bin/start-cluster.sh --daemon bootstrap-server localhost:8081
and run code one more
$ ./bin/flink run examples/streaming/WordCount.jar
if you finished run above code which not issue, go to localhost:8081
This still seems to be problematic. I tried to run from Windows Subsystem for Linux (WSL).
I have the following versions: java 11.0.16 and flink 1.15.2.
sudo apt-get update
sudo apt install openjdk-11-jre-headless
export FLINK_HOME=/mnt/c/Projects/Apache/flink-1.15.2
I set the following in flink-conf.yaml
rest.port: 8081
rest.address: localhost
rest.bind-adress: 0.0.0.0
Whereby I changed the bind address for localhost to 0.0.0.0 this seems to have fixed the problem.
$FLINK_HOME/bin/start-cluster.sh
Now I can access the Flink Web Dashboard.
I need to bring up the following service and configure recovery options as below using ansible,
rem Register windows services
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\installutil.exe" "C:\myservice.exe"
rem Configure windows services recovery options
%SystemRoot%\System32\sc.exe failure myservice reset= 600 actions= restart/300000
%SystemRoot%\System32\sc.exe failureflag myservice 1
I can use win_service module to install service.
- name: Install Windows service
win_service:
name: myservice
path: 'C:\myservice.exe'
How do I set recovery options in ansible ? I don't see any free-form text in below given link,
https://docs.ansible.com/ansible/2.3/win_service_module.html
The link you have shared points out to the win_service module in ansible version 2.3 which is quite old.
Meanwhile, I just checked and there is nothing about recovery options either in the latest version of win_service (2.8 at time of writing)
However, there seems to be an ongoing pretty advanced PR that would introduce changes meeting your requirements. There are still some issues to fix and it missed 2.9 code freeze. But hopefully it could come out for the next version.
If you really can't wait you can try to install ansible from the above PR branch. But if you want to keep it safe, you will have to launch commands through the win_command module after installing the service until this PR is released.
Installed Webmin successfully on a Debian system.
Created a virtual server, added some users and a domain.
Installed ProFTPD via Webmin's unused modules.
Added a new user with same named group via System -> Users and Groups.
Tried to connect via ftp using my server's external ip and my new user's credentials.
This should work according to most tutorials but it doesn't.
I'm suspecting some other service handles FTP requests before ProFTPD.
Is there a way to monitor protocol handlers? Could it be something else?
Thanks in advance.
because webmin try start it as deamon, but maybe (like me on archlinux) you need to start it as system service... on root:
systemctl start proftpd.service
If you want to look at the logs error (if there is errors, but if server is not start, it should ne have error...) then use:
journalctl -xe command (as root), or
systemctl --failed , or
systemctl status proftpd.service (all of these commands under root user or sudoers users).
So first of all, check that service is running:
systemctl status
then check the config file of webmin service for proftpd use the correct protocol for call service (systemd for example), and then use correct sentence code for start/stop it. Check also it goes to look at the correct config file of proftpd current install place (depend of your distribution or the way you install it).
proftpd is not installed by webmin, proftpd is installed, then from webmin, you install a module who has to communicate with allready installed application proftpd. If this module is well configured for point on actual proftpd installation and correct call of service, then all will have to works.
(please, if this answer help you, do up vote for my answer, without notation when i help, i can not help more because i'm locked by the system, hope you understand)
Have a look at the server's log, check le ProFTP daemon status, check the firewall
I see the following notices displayed on login:
__| __|_ )
_| ( / Amazon Linux AMI
___|\___|___|
See /usr/share/doc/system-release/ for latest release notes.
There are 30 security update(s) out of 39 total update(s) available
How do I install these updates on my machine?
As outlined in section Security Updates within Amazon Linux AMI Basics, Amazon Linux AMIs are configured to download and install security updates at launch time, i.e. If you do not need to preserve data or customizations on your running Amazon Linux AMI instances, you can simply relaunch new instances with the latest updated Amazon Linux AMI (see section Product Life Cycle for details).
This currently includes only Critical or Important security updates though, see the AWS team's response to Best practices for Amazon Linux image security updates:
The default on Amazon Linux AMI is to install any Critical or
Important security updates on launch. This is a function of cloud-init
and be modified in cloud.cfg on the box or by passing in user-data.
This is why you see some security updates still available at launch.
Consequently, if you want to install all security updates or indeed need to preserve data or customizations on your running Amazon Linux AMI instances, you can maintain those instances through the Amazon Linux AMI yum repositories, i.e. you need to facilitate the regular Yum update mechanism as outlined for the yum-security plugin:
# yum update --security
Please note: This does not work if only security updates are selected, due to the fact that security updates are not properly flagged in centos and amazon linux. This may be a matter of Redhat making security a paid feature which, if I'm being frank, is bullshit.
For this to work you must update the yum-cron config file to install all updates. This makes security updates less likely to run reliably which makes everyone less secure.
update_cmd = default
Amazon Linux runs updates when the host boots for the first time.
If you plan to have hosts up long-term you may also want to enable automatic security updates. I recommend using yum-cron:
sudo yum install yum-cron
The config file is here: (you probably want to just run security updates)
/etc/yum/yum-cron.conf
You can then enable yum-cron like so:
sudo service yum-cron start
edit from a useful comment below:
"If you're creating/destroying instances with an auto-scaling group, etc, the command should be something like "sudo yum update -y" in user data."
The answer above is correct, here are the 4 commands you can copy and paste to run:
# Install the package yum-cron
sudo yum install yum-cron -y
# Change the config file /etc/yum/yum-cron.conf and modify the line apply_updates from no to yes
sudo sed -i "s/apply_updates = no/apply_updates = yes/" /etc/yum/yum-cron.conf
# Enable the yum-cron service to start automatically upon system boot
sudo systemctl enable yum-cron
# Start the yum-cron service now
sudo systemctl start yum-cron
These commands also work on Red Hat 7, CentOS 7
If you are running as the root user you can simply run the commands without sudo:
yum install yum-cron -y
sed -i "s/apply_updates = no/apply_updates = yes/" /etc/yum/yum-cron.conf
systemctl enable yum-cron
systemctl start yum-cron
For more information see https://linuxize.com/post/configure-automatic-updates-with-yum-cron-on-centos-7/
https://www.howtoforge.com/tutorial/how-to-setup-automatic-security-updates-on-centos-7/