what www perl script is running?

[Steve Bertrand]

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20090825/c003086d/smime.bin