Disable file uploads

Is there any way to stop / disable random file uploads… for example,
I’m having ‘fun’ with mail relays being uploaded to the cache area of a
wordpress site?

Can’t think of anything off the top of my head that would do it.

Cheers,

Steve

Steve H. BSc(Hons) MIITP

Linkedin: http://www.linkedin.com/in/steveholdoway
Skype: sholdowa

On Tue, Mar 24, 2015 at 09:13:50AM +1300, Steve H. wrote:

Hi there,

Is there any way to stop / disable random file uploads… for example,
I’m having ‘fun’ with mail relays being uploaded to the cache area of a
wordpress site?

What the difference between a request that is a file upload and a
request
that is not a file upload, on your system?

Are there some specific urls you want to block? Do you want to block
all POST requests?

Can’t think of anything off the top of my head that would do it.

Would it be simpler for you to configure your wordpress to disallow
file uploads?

f

Francis D. [email protected]

On Mon, 2015-03-23 at 22:52 +0000, Francis D. wrote:

Are there some specific urls you want to block? Do you want to block
all POST requests?

Can’t think of anything off the top of my head that would do it.

Would it be simpler for you to configure your wordpress to disallow
file uploads?

f

I would like to block at web server level if possible, seems the most
sensible to me. This is what I currently use for wordpress ( after this
morning lol )

    # set the static ones first, then the catchall
    # Directives to send expires headers and turn off 404 error

logging.
location ~* ^/(?:uploads|files|cache|plugins)/.*.(png|gif|jpg|
jpeg|css|js|swf|ico|txt|xml|bmp|pdf|doc|docx|ppt|pptx|zip|woff|ttf|otf|
xls|myo|qbb|pst|dat|qbx|bc7|cf7)$ {
expires 24h;
log_not_found off;
}

    location ~* ^/wp-content/(files|uploads|cache|plugins)/.*.(|php|

js|swf)$ {
types { }
default_type text/plain;
}

I think I should be able to simplify it by having the block before a
straight catchall with no extensions listed, which would help ( although
a zero expiry on .html would probably be beneficial ).

Cheers,

Steve


Steve H. BSc(Hons) MIITP

Linkedin: http://www.linkedin.com/in/steveholdoway
Skype: sholdowa

On Tue, Mar 24, 2015 at 12:47:38PM +1300, Steve H. wrote:

On Mon, 2015-03-23 at 22:52 +0000, Francis D. wrote:

On Tue, Mar 24, 2015 at 09:13:50AM +1300, Steve H. wrote:

Hi there,

Is there any way to stop / disable random file uploads… for example,
I’m having ‘fun’ with mail relays being uploaded to the cache area of a
wordpress site?

What the difference between a request that is a file upload and a request
that is not a file upload, on your system?

    # set the static ones first, then the catchall
    # Directives to send expires headers and turn off 404 error

logging.
location ~* ^/(?:uploads|files|cache|plugins)/.*.(png|gif|jpg|
jpeg|css|js|swf|ico|txt|xml|bmp|pdf|doc|docx|ppt|pptx|zip|woff|ttf|otf|
xls|myo|qbb|pst|dat|qbx|bc7|cf7)$ {
expires 24h;
log_not_found off;
}

For requests that match this location block, serve from the filesystem.

    location ~* ^/wp-content/(files|uploads|cache|plugins)/.*.(|php|

js|swf)$ {
types { }
default_type text/plain;
}

For requests that match this location block, serve from the filesystem.

None of that seems to say “handle file uploads”.

I confess I’m somewhat confused about what your question is.

What request do you make of nginx, that does not give you the response
that you want?

f

Francis D. [email protected]

On Tue, 2015-03-24 at 00:00 +0000, Francis D. wrote:

What the difference between a request that is a file upload and a request
}

None of that seems to say “handle file uploads”.

I confess I’m somewhat confused about what your question is.

What request do you make of nginx, that does not give you the response
that you want?

f
Sorry,

This is the best block I can find, where the intention is that php files
are just served as text, not processed, which should be good and
annoying for the users as well.

As I said, I can’t work out how on earth to stop them being uploaded in
the first place.

Steve


Steve H. BSc(Hons) MIITP

Linkedin: http://www.linkedin.com/in/steveholdoway
Skype: sholdowa

Sounds like you either have a vulnerable web application or hole in your
systems security. If the root of your problem is that your having
content uploaded to your server without your consent, you’re asking the
wrong question.

If your app does allow for arbitrary file upload, you can disallow
certain file extensions, but that should be handled in whatever
Wordpress plugin you’re using.

On Mon, 2015-03-23 at 19:57 -0700, Robert P. wrote:

Sounds like you either have a vulnerable web application or hole in your systems
security. If the root of your problem is that your having content uploaded to your
server without your consent, you’re asking the wrong question.

If your app does allow for arbitrary file upload, you can disallow certain file
extensions, but that should be handled in whatever Wordpress plugin you’re using.

Well, I’m going for the multiple levels of protection approach, but am
trying to mate that with a ‘simple to maintain’ methodology.

So, yes I’d like to do both, but without being heavy-handed on the
website owners.

Steve

Steve H. BSc(Hons) MIITP

Linkedin: http://www.linkedin.com/in/steveholdoway
Skype: sholdowa

On Tue, 2015-03-24 at 16:15 +1300, Steve H. wrote:

Steve
Just had another attack on a drupal site. Should I resort to weird
ownership / permissions at a system level? That just makes it really
difficult for the client to keep their site current, which is pretty
counter-productive. I did work out a couple of scripts for Magento to
chown nobody / chattr +i to lock a site down when in ‘production mode’
and vv, but it is still an imposition.

Steve

Steve H. BSc(Hons) MIITP

Linkedin: http://www.linkedin.com/in/steveholdoway
Skype: sholdowa

On Wed, Mar 25, 2015 at 09:04:18AM +1300, Steve H. wrote:

Hi there,

Just had another attack on a drupal site. Should I resort to weird
ownership / permissions at a system level?

From what I’ve read in the thread, you seem to have two possible
approaches.

One is “stop the unwanted files from being uploaded”. To do that, you
will need to know how the unwanted files are uploaded – if they don’t
go through nginx, no nginx config will block them.

(If they do go through nginx, then there may be some correlation
between file modification times and nginx request logs which indicates
what request leads to the files being uploaded.)

Are there ftp or scp or other logs indicating how these files are put
onto your server?

The other is “stop the unwanted files from being served”; but I think
you also indicated that the unwanted files were being actively executed
on your server.

That just makes it really
difficult for the client to keep their site current, which is pretty
counter-productive.

More counter-productive than the reputation damage to running an
exploited server?

You’re in damage-control mode. Turn everything off, or make everything
read-only, until you can find out what has happened and can make it
right.

Good luck identifying the cause,

f

Francis D. [email protected]

On Mar 23, 2015, at 11:15 PM, Steve H. wrote:

Well, I’m going for the multiple levels of protection approach, but am
trying to mate that with a ‘simple to maintain’ methodology.

So, yes I’d like to do both, but without being heavy-handed on the
website owners.

I understand the frustration of this. You don’t need to have
compromised software to be affected by it. Once someone finds out you
have wordpress installed, you become subject to a lot of attacks and
random POSTs – as scripters try to exploit known issues.

If you can do this – one of the simplest things to do is to put as much
of the wordpress “dashboard” behind a httpauth block in nginx, and
disable POST everywhere but there. I’ve seen some large properties
heavily configure wordpress to run on “admin.example.com” behind heavy
auth, and then have “public.domain.com” simply handle GET requests.

That may not work on your setup though. If you’re using the internal
wordpress comments tool or any of their api/web hooks, you’d need to
open up those urls to POST – but you can limit it to something
arbitrarily small (e.g. 1k or less)

There are also a few integration how-tos for using nginx with fail2ban.