PHP 5.2.8
Nothing worked...
Still have three that I need to pass.
TCP Port 8443 - OpenSSL which is older than 0.9.6m or 0.9.7d
TCP Port 8443 - The remote service accepts connections encrypted using SSL 2.0
TCP Port 80 - Apache Tomcat (prior to 3.3.1a) is prone to a directory listing
Port blocking / changing didn't work, 8443 still responds as a Plesk panel.
Any suggestions?
Still have three that I need to pass.
TCP Port 8443 - OpenSSL which is older than 0.9.6m or 0.9.7d
TCP Port 8443 - The remote service accepts connections encrypted using SSL 2.0
TCP Port 80 - Apache Tomcat (prior to 3.3.1a) is prone to a directory listing
Port blocking / changing didn't work, 8443 still responds as a Plesk panel.
Any suggestions?
I'm using the art channel. Stat's that everything is up-to-date.
I think I'm down to one issue now, the so called tomcat one that got added when I ran the yum update using the art channel.
We believe we figured out disabling plesk and keeping everything online that is needed during the scan. (Can no longer access the control panel via 8443 / 8800, load's as page cannot be found when I issue the "service psa stop" command!!!)
I think I'm down to one issue now, the so called tomcat one that got added when I ran the yum update using the art channel.
We believe we figured out disabling plesk and keeping everything online that is needed during the scan. (Can no longer access the control panel via 8443 / 8800, load's as page cannot be found when I issue the "service psa stop" command!!!)
-
- Atomicorp Staff - Site Admin
- Posts: 8355
- Joined: Wed Dec 31, 1969 8:00 pm
- Location: earth
- Contact:
Thats the one I used, and it had at least 2 separate memory leak issues. One was resolved in the -dev (pre-5.2.9) tree. The latter takes a few days to manifest on my systems here and is not related to the strtotime() leak.
The following is some test code to show the strtotime leak.
The following is some test code to show the strtotime leak.
Code: Select all
<?php
// Run with the PHP CLI on the Linux shell...
// WARNING: If this bug affects you as well, your machine
// might start swapping within just a few seconds!
while (true)
strtotime('2008-12-16 19:48:27');
?>
Hello,
This memory leak is killing me, once a day! Server freezes and can be resolved only by a Reboot from the serial console.
Scot, what would be the best approach until it has been eradicated? Could I downgrade to 5.2.7? Are the packages still available somewhere in your repositories for CentOS 5.2?
Regards,
Adrian
This memory leak is killing me, once a day! Server freezes and can be resolved only by a Reboot from the serial console.
Scot, what would be the best approach until it has been eradicated? Could I downgrade to 5.2.7? Are the packages still available somewhere in your repositories for CentOS 5.2?
Regards,
Adrian
-
- Forum Regular
- Posts: 661
- Joined: Mon Oct 29, 2007 6:51 pm
I think I "might" have it figured out.I think I'm down to one issue now, the so called tomcat one that got added when I ran the yum update using the art channel.
When I just ran the httpd -M command I noticed that it was running the module " proxy_ajp_module (shared)" so I went into the conf.d folder and found a module load file for it and commented out every line. Now when I run httpd -M it does not display this module.
I hope this is the issue, it's running a PCI compliance scan now.
-
- Atomicorp Staff - Site Admin
- Posts: 8355
- Joined: Wed Dec 31, 1969 8:00 pm
- Location: earth
- Contact:
Thanks for following up at least! I actually make more notes on the things that don't work for me when I'm debugging than the things that do. Have you looked for all the installed tomcat packages (rpm -qa) and tried removing them?
In regard to PCI compliance testers... if they're not doing local checks you're always going to have high rates of false positives like that. It has to do with the limited way they use their (otherwise fantastic) vulnerability scanners.
In regard to PCI compliance testers... if they're not doing local checks you're always going to have high rates of false positives like that. It has to do with the limited way they use their (otherwise fantastic) vulnerability scanners.
-
- Forum Regular
- Posts: 661
- Joined: Mon Oct 29, 2007 6:51 pm
-bash-3.2# locate tomcscott wrote:Thanks for following up at least! I actually make more notes on the things that don't work for me when I'm debugging than the things that do. Have you looked for all the installed tomcat packages (rpm -qa) and tried removing them?
In regard to PCI compliance testers... if they're not doing local checks you're always going to have high rates of false positives like that. It has to do with the limited way they use their (otherwise fantastic) vulnerability scanners.
/usr/local/psa/admin/bin/tomcatmng
/usr/local/psa/admin/plib/tomcatmng.php
/usr/local/psa/admin/plib/api-cli/tomcat.php
/usr/local/psa/admin/sbin/tomcatmng
/usr/local/psa/bin/tomcat
/usr/local/psa/bin/tomcat.sh
/usr/local/psa/etc/logrotate.d/tomcat
/usr/local/psa/etc/service/tomcat.xml
/usr/local/psa/etc/service/stdmode/tomcat.xml
/usr/local/psa/etc/service/vzmode/tomcat.xml
-bash-3.2# rpm -qa | grep tomc
-bash-3.2#