Saiweb

If you tie in your web application to automatically PURGE content when you modify it, thus keeping the content “fresh” while using Varnish you may notice if you made the jump from 2.x to 3.x that your PURGE VCL is no longer working, I refer you to: https://www.varnish-software.com/blog/bans-and-purges-varnish-30

In short replace your usual

with

Substituting “~ purge” with your ACL name, the above implement wild card purging aswell, if you do not want this and only want PURGE for the exact passed URL replace

“req.url ~ “+req.url

with

“req.url == “+req.url

Tweet

Ok, so following up on PHP & Caching with Varnish, let’s cut to the hard facts shall we?

Using the same tests as

ab -c 100 -n 500 -g ./saiweb-nocache-nogzip.bpl http://www.saiweb.co.uk/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.saiweb.co.uk (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Finished 500 requests

Server Software: Apache
Server Hostname: www.saiweb.co.uk
Server Port: 80

Document Path: /
Document Length: 92719 bytes

Concurrency Level: 100
Time taken for tests: 0.184 seconds
Complete requests: 500
Failed requests: 0
Write errors: 0
Total transferred: 47597095 bytes
HTML transferred: 47379409 bytes
Requests per second: 2716.92 [#/sec] (mean)
Time per request: 36.806 [ms] (mean)
Time per request: 0.368 [ms] (mean, across all concurrent requests)
Transfer rate: 252573.13 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 4 1.1 4 6
Processing: 9 31 7.0 32 47
Waiting: 2 7 5.7 4 26
Total: 15 35 6.8 36 53

Percentage of the requests served within a certain time (ms)
50% 36
66% 38
75% 39
80% 39
90% 41
95% 44
98% 48
99% 51
100% 53 (longest request)

2716.92 requests per second with a server load average of 0.1, and in this case varnish is serving cache from disk.

Caching using varnish (Or even nginx / mod_cache) means that PHP does not get executed at all, the cache system grabs the cache content and serves it.

This of course has the benefit of reducing the CPU and memory resources needed for the running of your application, but it does have some caveats.

• This only works for GET requests, and content not reliant on Cookies (Truely dynamic content will not cache)
• But on the “flipside” Varnish supports ESI, which when setup correctly you can target the dynamic sections of a pag for “passthrough” and have the rest cached

More details to come, as I have time to add them I have have a lot of posts to make on boxgrinder, KVM, libvirtd etc.
Tweet

Tags: caching, php, varnish

For those using netatalk for AFP shares in this case I am using CentOS, the EL5 compiles are missing the configure lines for the dhx2 extension, which is required by OSX Lion, if you are running x86_64 you can grab this file: netatalk-2.0.5-2.x86_64.rpm I have also emailed the Package maintainer @ EPEL with the changes I have made for this RPM so I would like to think that -2 will be available from EPEL soon.

Let me know if you have any issues with my RPM.

UPDATE: Official Rebuild in testing

Tweet

So I’ve decided to start some name and shame posts for “naughty” ip’s that trip an ids, turn up in my log audits etc … and who are woefully ill prepared …

Dear 82.98.131.66,

This post is for you, I’m not sure what you hope to gain by failing repeatedly to gain access to this blog (god knows I hardly have time to update it …) but doing it from a host with all your ports open probably not the best idea in the world, so here’s some information on you.

And for anyone else reading this, I usually end up ignoring the standard user enumeration and brute force attacks (As the offender get blacklisted very quickly), in this case however it was a targeted attempt …

Your ISP’s whois

Log of you attempting to get access to ftp

Can anyone say firewall?

You need to read this NOW!

Debian? seriously?

mySQL seems recent at least

For the moment I am assuming a compromised box quiet why you wanted to come after this blog is beyond me.

1. 12/06/2011 – This blog written and evidence sent to ISP
2. 12/07/2011 – The Scheduled publication for this post

Tweet

In theroy this: http://www.exploit-db.com/exploits/17423/ could be used to facilitate phishing,

To patch this update to 1.9.28, and apply this patch: https://raw.github.com/Oneiroi/PenTesting/master/patches/wptouch-edb17423.patch

UPDATE 07072011 .9.30 does not suffer from this exploit.

Tweet

In theory this: http://www.exploit-db.com/exploits/17423/ could be used to facilitate phishing,

To patch this update to 1.9.28, and apply this patch: https://raw.github.com/Oneiroi/PenTesting/master/patches/wptouch-edb17423.patch

update This: http://wordpress.org/news/2011/06/passwords-reset/ causes a 1.9.29 version to be rolled out.

1.9.29 is still vulnerable to this, the patch instructions above still work for 1.9.29

Tweet

Pre-req reading: Part 1

In this part we will cover setting up a backend. A backend is your application server, whether this be apache / nginx / iis (IIS – Is Inherently Stupid) you are telling varnish where it should sends it’s requests to.

Very basic configuration

For a quick start that’s it really you tell varnish a backend and the port to connect to it on … just make sure you use it in vcl_recv, but you’re not here for simple and quick start are you? lets add the following.

• timeout settings
• probe settings

Timeout settings

Your timeout settings deinf how long varnish should wait for a response from your backend

• connect_timeout wait 50ms for a tcp connection to take place
• first_byte_timeout wait 2s for the first byte of data to be sent from the backend
• between_bytes_timeout wait 2s if there is a pause mid data stream

Timeouts are a basic way of determining if a backend is down / miss behaving if you have multiple backends if timeouts occur then the backend is marked as sick and the other backends will be used.

probe settings – Trust me I’m a doctor

• url the URL to to query this must return a 200 OK response, you could use a php script to return a 500 on say a mySQL outage
• timeout how long to wait for a 200 OK response from the URL
• window keep the result of the last 5 probes in memory
• threshold how many of the window total must be OK for the backend to be “healthy”
• interval how often to run the probe

And that about wraps up this post.Tweet

Bad TMNT reference I know but with a reboot coming what do you expect realy?

Right so you have hidden your versions via The Hooded Apache so what now?

Well no matter what you do if your url’s contain .php / .asp / .cfm (Frankly if you are using coldfusion you deserve what you get … just saying …)

You are disclosing what your webapp is using as it’s server side language, now to be clear this hiding is only going to be effective if you are using a bespoke webapp, and not say Joomla / WordPress as they are easily identifiable via other means (for another post) …

mod_rewrite

Learn this, I mean seriously not only can it help cloak your server side language but you can do so using SEO urls.

BUT be careful if you think you’re being cleaver by having mod_rewrite change the extension alone …

it will be easy to enumerate the back end language this way … the first 404 that an attacker gets when enumerating your file names will reveal this rule i.e.

“The file /asfasdgasdg.php was not found on this server” … yeh …

Change the extension entirely

Security through obscurity? you bet your ass, just add your new extension onto your AddType declaration, because you are already avoiding the dual extension vulnerability right?

how about .wtf

Now just name your files .wtf instead of .php

So your using subversion good for you! you can use subversion as part of PCI 11.5 (iirc) to enforce file integrity assuming of course you have your subversion deploy setup securely just one tiny problem …

Seemingly innocent right? oh how wrong you are …

1. http://domain.com we know the version control server location, we can attack that later
2. http:// is not an encrypted protocol, easy to sniff for if you get access to the server / company lan
3. joe.blogs we have a known username we can attempt to access using dictionary / brute force / social engineering
4. http:// the server could be vulnerable to CVE-2011-1921
5. we know that config.php exists we can target that later for other crednetials

So assuming a worst case scenario,

1. Webapp is compromised and we managed to deploy a remote shell
2. Sniffing for http:// hiding silently in the background we find a site update / commit, and snag joe.blogs user credentials
3. Exploiting CVE-2011-1921 we enumerate all projects on the svn server (If we even have to … joe.blogs could have access to everything anyway …)
4. Inject backdoors into all projects committing changes as joe.blogs
5. Wait for co de to be deployed to production …
6. And now you have backdoors into multiple projects

You can prevent this by …

Or using mod_security

Ensure you use an ENCRYPTED protocol for your version control https:// / ssh+svn:// for example with subversion.

Tweet

Go ahead and run

You will get

As an attacker looking to hit a web app, one of the first things you’re going to want to look into is what version of web server is running, in this case you can see this blog in fact runs apache … but there is not much else to go on here is there.

That’s intentional, and by manual configuration changes I have put in place, this is not the case of a default LAMP install, take for instance, this snippet from another website,

This already has given me a wealth of information to go on and begin prepping an attack, I now know the site is running php version 5.2.14 Apache version 2.2.16 and that the underlying OS is Debian.

See the dilemma? your default roll outs are just declaring their running versions to anyone willing to listen, so lets make it a little more stealthy.

First and foremost if you are using php, edit your php.ini and set the following:

Now head into your httpd.conf and set the following

and

With these 3 simple steps all the headers will now return is Server: Apache this is the first step to shielding your app, I’ll be covering further steps as time allows.

Tweet

With work returning to “normal” levels I began digging through my backlog of seclist updates, errata updates and security related podcasts,

One particular attack method has me concerned as a typical Paranoid Systems Admin, namely the one covered by Darren @ Hak5.org,

Where combining jasager and airdrop-ng can allow you to easily set yourself up as a m.i.t.m transparently, so I began thinking how would you defend against such an attack, with most if not all wifi clients switching to jasager transparently without the user ever knowing, now remember this is all theory at this point it could be completely wrong, please leave feedback in the comments.

before I beging let’s make a couple of assumptions.

1. You are the admin for your network
2. You are in control of all AP’s on your network

If you can not confirm 1 & 2 then you can land yourself in a whole heap of trouble, so think before you do please …

That said onto a possible defense scenario, making airdrop-ng work as a “shield”.

The main premise of airdrop is to send DeAuth packets forcing a wifi client to reconnect, Darren’s jasager + airdrop  podcast (“Airport wifi challenge”) used this in conjunction with jasager to force clients to reconnect but to jasager instead, essentially denying access to the real AP’s and masquerading as them using jasager.

With me so far?

1. Client is connected to REAL Access Point
2. airdrop-ng sends DeAuth for all BSSIDs except jasager’s
3. Client Attempts to reconnect, jasager masquerades as the REAL AP
4. Client is now pwned.

To re purpose airdrop-ng as a “shield”, we change step 2 above .

1. Client is connected to REAL Access Point
2. airdrop-ng sends DeAuth for all BSSIDs except the REAL access point

Now this does cause a problem for any genuine “pop up” wifi, such as the share functionality on mac osx, and  mobile hotspots (wifi 3g), but it is one possible method of defense.

If you have some theories related to detecting and defeating WiFi m.i.t.m attacks please let me know, I’d love to hear them,

I’ll work on getting a screencast for this up as soon as possible.

• this will not protect against BSSID / MAC spoofing,
• this will only prevent against a rougue AP BSSID masquerading as your valid AP.
• this will only work within range of your wifi device generating the DeAuth packets.
• improper configuration could cause D.o.S of nearby REAL Ap’s and generaly piss people off.

Update 04/10/2011 Seems that this project wifijammer can do exactly what I outlined above. via: HackadayTweet