li...@32... wrote:
> I just had an attempt made on my server to exploit it. The user was able to
> upload a folder call .sgurz into the tmp folder, this folder had 2 files,
> boink and .boink2.
>
> I do not think it did anything except use up all the apache processes.
>
> What would the filer need to be in order to block this type of attack in the
> future?
You need to search through the apache logs and find the query which
resulted in the compromise. That will tell you which software is
allowing the upload to /tmp, and it will give you some insight into how
to block that query. For instance, I know that AWStats does not do
proper sanitizing of some input because it once lead to a worm
compromising my machine. I then created a rule that prevents queries
which involve "awstats" and several of its optional variables which I
don't personally use:
SecFilterSelective THE_REQUEST "awstats" chain
SecFilterSelective ARGS
"(pluginmode|loadplugin|debug|configdir|perl|cgi|chmod
|exec|print)"
The exploit ran perl code through one of these variables, which I found
in my apache access log. Grep'ing for "perl" might make your search
easier. However, your case might have involved a different tack. In
fact, it's possible a low-priviledge account was brute-force hacked
through ssh, not through apache. I've had that happen too. Are the
files in /tmp owned by the apache user?
Either way, run "ps ax" and search for running processes (perhaps
masquerading as "init" or some other system program) which don't look
like they belong, either because of the user that started it, the time
it started, or the resources it's using. That's probably your zombie.
Note the name and owner, and kill that process. Grep your ssh log for
the username that launched it (or that own the files in /tmp), if not
apache, to see if a brute-force attack was launched against it.
Hope that helps.
Tom
|
