The messages in the log file indicate that they used some command
injection in a script to call wget and download the files into /tmp.
I'm fairly sure it was via a bad script, and I'm trying to locate
which script was used, so far with no success.
Common PHP scripts in wide use (Nukes, phpbb
On Thu, Jan 05, 2006 at 09:34:08AM +, Dylan Smith wrote:
Secondly, if the box is mainly a web server, use 'pf' to egress filter. If
the machine should not be making outgoing connections to the Internet, block
all outgoing traffic.
Amen. Default deny both in and out works wonders
On Wed, Jan 04, 2006 at 09:08:35PM +, Gaby vanhegan wrote:
On 4 Feb 2006, at 20:38, veins wrote:
I would think php, but this doesn't explain it unless you turned the
chroot off.
Due to historical reasons, we're not running apache chrooted.
This is why they're in /tmp rather
On Wednesday 04 January 2006 18:25, you wrote:
It's just a bit frustrating. Am I right in thinking if the wget
output is in /var/www/logs/error_log then it comes from a site that
has no defined ErrorLog. This is a limited number of sites, but I've
found no log entries from the transfer logs
To begin, I'm running OpenBSD trim.chrispyfur.net 3.6 GENERIC.MP#173
i386.
I have some suspect files in /tmp, and I'm fairly sure that they
shouldn't be there. Only thing I can't twig is what method the
attackers used to get the files into that directory. The files are:
Looks like you've made some new friends in Manaus, Brazil :-)
-p.
On Wed, Jan 04, 2006 at 02:50:01PM +, Gaby vanhegan wrote:
To begin, I'm running OpenBSD trim.chrispyfur.net 3.6 GENERIC.MP#173
i386.
I have some suspect files in /tmp, and I'm fairly sure that they
shouldn't be
Hi,
Standard advise is to reinstall the o/s (3.8 ? ;-) and then _data_
only from know good backup. You could use a boot cdrom dd off an
image of the disk for later analysis if you want first.
Is there some attack vector like php or such available on the
machine ? maybe they used that
On Wed, 2006-01-04 at 14:50:01 +, Gaby vanhegan proclaimed...
To begin, I'm running OpenBSD trim.chrispyfur.net 3.6 GENERIC.MP#173
i386.
I have some suspect files in /tmp, and I'm fairly sure that they
shouldn't be there. Only thing I can't twig is what method the
attackers used
On 4 Jan 2006, at 15:51, Pete Vickers wrote:
Standard advise is to reinstall the o/s (3.8 ? ;-) and then _data_
only from know good backup. You could use a boot cdrom dd off an
image of the disk for later analysis if you want first.
It seems that the files have been uploaded, but they
On 4 Jan 2006, at 16:05, eric wrote:
I have some suspect files in /tmp, and I'm fairly sure that they
shouldn't be there. Only thing I can't twig is what method the
attackers used to get the files into that directory. The files are:
Is this doing any A/V scanning? You have told us nothign
On Wed, Jan 04, 2006 at 04:07:21PM +, Gaby vanhegan wrote:
On 4 Jan 2006, at 15:51, Pete Vickers wrote:
Is there some attack vector like php or such available on the
machine ? maybe they used that to retrieve write the file?
The messages in the log file indicate that they used some
To begin, I'm running OpenBSD trim.chrispyfur.net 3.6 GENERIC.MP#173
i386.
I have some suspect files in /tmp, and I'm fairly sure that they
shouldn't be there. Only thing I can't twig is what method the
attackers used to get the files into that directory. The files are:
Is this
On Wed, Jan 04, 2006 at 05:28:38PM +0100, Joachim Schipper wrote:
There was a phpBB2 in one of the paths used. If you have phpBB enabled
somewhere, that's a likely attack vector.
I noticed that too. phpBB has been used for many sorts of tricks.
The ISP that I work for scans for it and
On 4 Jan 2006, at 16:28, Joachim Schipper wrote:
The messages in the log file indicate that they used some command
injection in a script to call wget and download the files into /tmp.
I'm fairly sure it was via a bad script, and I'm trying to locate
which script was used, so far with no
On 4 Jan 2006, at 16:10, knitti wrote:
I would think php, but this doesn't explain it unless you turned the
chroot off.
Due to historical reasons, we're not running apache chrooted. This
is why they're in /tmp rather than /var/www/tmp, or any other place.
Gaby
--
Junkets for bunterish
From: Gaby vanhegan [mailto:[EMAIL PROTECTED]
I would think php, but this doesn't explain it unless you turned the
chroot off.
Due to historical reasons, we're not running apache chrooted. This
is why they're in /tmp rather than /var/www/tmp, or any other place.
Given the security
Gaby vanhegan wrote:
On 4 Jan 2006, at 16:10, knitti wrote:
I would think php, but this doesn't explain it unless you turned the
chroot off.
Due to historical reasons, we're not running apache chrooted. This
is why they're in /tmp rather than /var/www/tmp, or any other place.
On 4 Feb 2006, at 20:38, veins wrote:
I would think php, but this doesn't explain it unless you turned the
chroot off.
Due to historical reasons, we're not running apache chrooted.
This is why they're in /tmp rather than /var/www/tmp, or any
other place.
historical ?
There are
18 matches
Mail list logo
