Things are back on track and am looking forward to talking about security, from the front line.

I’ve noticed in my logs numerous attempts using web applications scanners, the latest one run on the 21st June using acunetix. . As you know this adds quite a bit of unnecessary traffic to your site, especially when you turn all the options on in the scanner and it basically runs all the web tests against each file and directory on your server. The following is a snapshot of the difference in traffic from the scan.

As you can see jumping from under 1000 requests to over 130,000 is quite a big jump.

Also got some recon using Google “site:gilbertverdian.com php”.

By the way that IP is the transparent proxy from http://www.tpg.com.au, an Australian ISP. Seems users from that ISP have been a little naughty lately.

My setup is quite standard, hosted by dreamhost, running wordpress, with mysql db and a couple of wordpress plugins. If someone wants to really break in, all you have to do is easily set up a vmware LAMP server using linux and install wordress… emulate this environment and have a go against your virtual host. You might even gain some 0day credits if you find some bugs.

I know in the past of other security professionals having their own server broken into (not mentioning any names johnny because they didn’t patch ssh about 4 years ago), but he admitted in getting lazy and not patching an old version and moved on…

So the question stands, what do we do about it? Should we follow this up with the ISP? Or just let it go? What do you guys do?

- Good security practice recommends separating and segregating different functions, especially in a web environment, to different systems
- Being on different systems, access can be controlled on what is allowed to pass through to each system through firewalls.
- for example, the application server running middleware only needs to talk to the database server on sql ports to run queries
- therefore controls can be put in place on each of the systems which should be separated by firewalls on how and what is accessed.
- Assumptions should be made that each server should be sacrificed in a worse case scenario. Meaning it should be assumed that a server will be compromised. If this is taken into consideration, then we have to limit the damage of the impact of the server. If set up correctly as described above, then if one server is compromised, then attackers will only have access to the one server. But in the case of all the web functions being put on the same server, if there is a vulnerability in just one of those functions, then they have access to all the data in each of the functions. This is also the same for servers that are physically or logically placed on the same network without any controls to restrict their access.
- The final risk is that of the underlying operating system. If there is a vulnerability in the OS of the server, then again attackers will be able to access the data stored in each of the functions of the web systems.