I try to find out if haproxy and keepalived are or can be affected by CVE-2022-37434
I've tried to grep source code of both applications to find method inflateGetHeader which is the cause of the problem. Didn't find anything
Related
I am facing an extremely rare and peculiar problem.
We use Magento 2 in many websites, which uses Varnish almost out of the box. We face problems problems, but they are rare and easily fixable.
Yesterday, we noticed something really strange.
The file /lib/systemd/system/varnish.service is reverting to its default form somehow, without us updating or changing it. By reverting, Varnish stops working (because on its default installation, Varnish is configured on port 6081, but usually everybody changes this to port 80). So the fix is really easy, but it's really frustrating. I saw that on different versions too, both 5 & 6.
Does anybody know if Varnish is autoupdating these files somehow?
Many thanks, I am at your disposal for further explanations.
The fact that /lib/systemd/system/varnish.service is reverted shouldn't really be a problem, because you should have a copy of that file in /etc/systemd/sytem that contains the appropriate values.
If you perform sudo systemctl edit varnish and perform changes, a new file called /etc/systemd/system/varnish.service.d/override.conf will be created.
If you call sudo systemctl edit --full varnish a file called /etc/systemd/sytem/varnish.service will be created.
It's also possible to do this manually by running sudo cp /lib/systemd/system/varnish.service /etc/systemd/system/, but this also requires calling sudo systemctl daemon-reload.
Have a look at the following tutorial, which explains the systemd configuration of Varnish for Ubuntu: https://www.varnish-software.com/developers/tutorials/installing-varnish-ubuntu/#systemd-configuration.
If you're using another distribution you can find the right tutorial on https://www.varnish-software.com/developers/tutorials/#installations.
I have a problem when launching any instance (from and AMI) within a particular VPC. Everytime I type a "sudo" command, I get the following:
sudo: unable to resolve host ip-xxx-xx-x-xxx
I have seen many posts on the internet about this and they all mention the following two solutions:
Manually edit the /etc/hosts file on every server... This is not practical (especially when using AutoScaling to generate new instances) and I shouldn't have to do this as I don't have to do this for any instances on other VPCs
Turn on "DNS hostnames" on the VPC... I have done this and it hasn't made a difference. I have gone through all the settings on the VPC (and route tables, subnets etc) and I have it set exactly the same way as a "working" VPC on my account. Still no luck
Any help here?
It seems as if this is an AWS specific problem that has been run into before, it stems from not enabling enableDnsHostnames in your VPC configuration.
Here is a link to the AWS documentation that talks about this.
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dns.html#vpc-dns-updating
This is a really late answer, and I'm not sure if it's still relevant for newer EC2 instances, but I've just taken over an account running Ubuntu 16, and I solved this annoyance by just adding the dns hostname to the hosts file. Presumably this could be automated for any auto-scaling if desired. As simple as:
echo 127.0.0.1 ip-10.x.x.x >> /etc/hosts
Or any variant using tee or sed or your other Unix tool of choice. You could include ipv6 version as well, if you really want to be thorough, but ipv4 was enough to stop the warning in my case.
Im having trouble configuring shorewall on my linode instance.
just thought maybe you know of an issue, perhaps related to your Xen virtualization and running shorewall on it...
when attempting to start shorewall I get the following error:
"ERROR: UNTRACKED state requires Raw Table in your kernel and iptables"
any ideas would be appreciated
thanks
Ideally the kernel should have CONFIG_IP_NF_RAW (and CONFIG_IP6_NF_RAW for IPv6) enabled, which provides support for the missing "Raw Table" mentioned in the error.
A link to an (unmaintained) page for kernel configuration options with Shorewall can be found here:
http://shorewall.net/kernel.htm
However, if you are unable to update the kernel, you may be able to work around the issue by editing the shorewall.conf (or shorewall6.conf) file, and changing the following line:
BLACKLIST="NEW,INVALID,UNTRACKED"
to:
BLACKLIST="NEW,INVALID"
This would, obviously, reduce some of the effectiveness of the firewall, hence ideally the kernel should be updated instead.
I have a slight problem bit of the back story. recently ive been trying to test out univention which is a linux distribution with the goal of being able to replace Microsoft active directory.
I tested it locally and all went reasonably well after a few minor issues i then decided to test it remotely as the company wants to allow remote users to access this so i used myhyve.com to host it and its now been setup successfully and works reasonably well.
however
my main problem is DNS based as when trying to connect to the domain the only way windows will recognize it is by editing the network adapter and setting ip v4 dns server address to the ip address of the server hosting the univention active directory replacement. although this does allow every thing to work its not ideal and dns look up on the internet are considerably longer. i was wondering if any one had any ideas or have done something similar and encountered this problems before and know a work around. i want to avoid setting up a vpn if possible.
after initially registering the computer on the domain i am able to remove the dns server address and just use a couple of amendments to the HOST file to keep it running but this still leads to having issues connecting to the domain controller sometimes and is not ideal. any ideas and suggestions would be greatly received.
.Michael
For the HOST entries, the most likely issue is, that there are several service records a computer in the domain needs. I'm not sure, whether these can be provided via the HOST file or not but you'll definitely have authentication issues if they are missing. To see the records your domain is using issue the following commands on the UCS system.
/usr/share/univention-samba4/scripts/check_essential_samba4_dns_records.sh
For the slow resolution of the DNS records there are several points where you could start looking. My first test would be whether or not you are using a forwarder for the web DNS requests and whether or not the forwarder is having a decent speed. To check if you are using one, type
ucr search dns/forwarder
If you get a valid IP for either of the UCR Variables, dns/forwarder1, dns/forwarder2 or dns/forwarder3, you are forwarding your DNS requests to a different Server. If all of them are empty or not valid IPs then your server is doing the resolution itself.
Not using a forwarder is often slow, as the DNS servers caching is optimized for the AD operations, like the round robin load balancing. Likewise a number of ISPs require you to use a forwarder to minimize the DNS traffic. You can simply define a forwarder using ucr, I use Google on IPv4 for the example
ucr set dns/forwarder1='8.8.8.8'
The other scenario might be a slow forwarder. To check it try to query the forwarder directly using the following command
dig univention.com #(ucr get dns/forwarder1)
If it takes long, then there is nothing the UCS server can do, you'll simply have to choose a different forwarder from the ucr command above.
If neither of the above helps, the next step would be to check whether there are error messages for the named daemon in the syslog file. Normally these come when you are trying to manually remove software or if the firewall configuration got changed.
Kevin
Sponsored post, as I work for Univention North America, Inc.
Preliminaries:
+ CentOS 5
+ Plesk 10.4.4 Update #35
Problem: During the addition/alteration of a new domain/host in plesk, it will normally write new or update apache vhost config files and then restart the apache service. The updating rewriting seems to go fine, there are no errors in the files, however lately apache fails to restart after shutting down due to the unavailability of port 80, further examination via "netstat -tulpn..." shows the following...
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 :::80 :::* LISTEN 25794/PDFLUSH
tcp 0 0 :::443 :::* LISTEN 25794/PDFLUSH
You can see that PDFLUSH is occupying a high process ID but is sitting on both 80 and 443 which prevents apache from coming back up. I'm having to manually get the PID and issue a kill before I can run "service httpd start" again to get apache up.
In my searching, I've seen an old reference to someone being hacked but I can find any similar symptoms, and honestly I don't know what to look for in the logs or which log file to look at specifically. I've also heard that this could be a symptom of failing memory but I don't know how to test memory on a production server.
Please, any help would be greatly appreciated, my heart sinks every time I get an SMS that the servers down again!
EDIT
It's happened again by simply adding a subdomain, however this time I was able to run a ps -aux quickly prior to killing the PDFLUSH instance and bringing back up apache...
apache ... ./PDFLUSH -b service.config
Trying to search out the location of that now...
The good news is I found the culprit, the bad news is that it is "c99", just do a google on it and you'll find a long history. Now the real fun begins, has the server been rooted?
For those that have similar issues and think it might be the same even if it's using a name other than "PDFLUSH", just do a
find /var/www/vhosts -name PDFLUSH
To figure out where the little bastard is hiding. I found mine in one of my shared hosting clients sites buried deep in a dir tree inside the webroot.
The netstat output that you have included is highly suspect:
The program that you are seeing is called PDFLUSH with all characters in upper case. This seems like an attempt to evade detection; pdflush (all lower case) is the name of a legitimate kernel thread that handles writing dirty memory pages back to the disk. It highly unlikely that any legitimate program would be using such a name.
The legitimate pdflush does not have any networking capabilities - it has nothing to do with networking at all. This one seems to be acting as a web server, yet no web server with such a name exists. Unless you explicitly installed a custom web server with that unfortunate name, you have a problem.
Have you tried connecting to those two ports with netcat or a Telnet client? That might give you a clue on what is going on.
As far as testing the memory of your system goes, memtest86 is the de facto standard tool these days. Failing memory, though, usually appears in the form of random crashes - what you are seeing seems way too specific.