Assignment

Environment

Sources

Everything done in this post is based on our previous class (see course homepage above).

Varnish

Varnish is a very useful reverse proxy, which can greatly improve web server performance. We make Varnish listen to TCP port 80, so that it will serve the requested websites instead of Apache. (Varnish does get them from Apache but greately reduces load.) Pages are essentially served as static websites thanks to this, which makes everything *very* fast.

Installing Varnish

The metapackage ‘varnish’ installs libvarnishapi1 and varnish, which are exactly the things I need.

sudo apt-get install varnish

I need to edit /etc/default/varnish. One of the configurations therein is uncommented by default, which is what I’ll use. DAEMON_OPTS has numerous flags and values. The only one which needs to be changed is -a, since we don’t want varnish to listen to port 6081 but port 80.

sudo nano /etc/default/varnish

See above for the changes. After that, I need to restart varnish.

sudo service varnish restart

Varnish is now set up and WordPress works once more. We’ll get to actual performance tests later, but first…

Firebug

Time to install Firebug, the Firefox addon. I open Firefox and go to Tools -> Add-ons. (Or just press Shift-Ctrl-A). There’s a search field in the upper right corner:

Typing ‘firebug’ finds the addon I’m after.

Once the addon is installed, I go to my WordPress’ “Hello world” post while having Firebug open, and take a look at how fast various parts of the page load.

HTML generally seems to load quite fast:

Images take a bit longer: (Also, what’s 0.gravatar.com?)

AB

Apache Bench is a tool for testing web server performance. It can create huge amounts of traffic, so be sure to try it out on your localhost only, unless you want to appear like you’re attempting to ddos attack a website.

Varnish was consistently faster, but moreso when it comes to PHP. Static pages are rather light to begin with, but still provides a considerable boost in performance.

Best for last: AB meets Varnish meets a WordPress post

I thought it’d be interesting to see a proper, conclusive result, so I tried benchmarking my WordPress’ performance with and without Varnish. I modify /etc/default/varnish and change its listening port, and temporarily switch off Varnish off.

(Changing the listening port might not be necessary, now that I think of it, seeing as it won’t be listening to anything anyway.)

sudo service varnish stop

And modify /etc/apache2/ports.conf to its original state, so that WordPress works normally with port 80, and restart Apache:

sudo service apache2 restart

To clarify: If one doesn’t stop Varnish first, port 80 won’t be available for apache2 to listen.

Assignment

Environment

I’m using Ubuntu 12.04 @ Virtualbox. I loaded an old snapshop in order to emulate a clean installation from a live CD. (I opted for Virtualbox to get a shared clipboard between Ubuntu and Windows.) Username is ‘antero’ during the whole exercise, seeing as how I didn’t create a separate user for WordPress.

Prerequisite steps

Time to install LAMP. Install apache2 (with mods userdir, php5 and rewrite), mysql-server and php5 and phpmyadmin. For this week’s report, I’m going to omit the usual installation logs for better readability, and concentrate on essential steps. Also, I decided to drop the “let’s/we” narrative. Also, I enable ufw before installing any servers.

Time to log in to phpmyadmin with root and the password given during install. Then, Privileges -> Add new user. I enter the information shown in the following screenshot, and make sure that “Create database with same name and grant all privileges” is checked. After clicking “Create user” I close phpmyadmin.

Provided I haven’t made a mistake somewhere, I should be all set for installing WordPress.

Installing WordPress

I extract the downloaded file with the built-in archive manager, File Roller, in the graphical file manager. It extracts to public_html/wordpress, which I deem satisfactory. If I recall correctly, the tar.gz includes proper permissions, so I won’t have to modify those. We’ll see.

I’ll be creating their DocumentRoots to /home/antero/banshee, haunter and marrow. However, if we want php to work there, we’ll need to comment out some lines in /etc/apache2/mods-available/php5.conf, after which it’ll look like this:

I’ll create an index.html (which might later be renamed to index.php) into each directory, with the site’s name as the content. Then we’ll create the sites’ files in /etc/apache2/sites-available. Result:

HTTP Status codes

Let’s see if we can generate the called-for errors 200, 403, 404 and 500. We just did 404, so that leaves 200, 403 and 500. Let’s wikipedia up what those status codes mean:

200 OKStandard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request the response will contain an entity describing or containing the result of the action

403 ForbiddenThe request was a valid request, but the server is refusing to respond to it.[2] Unlike a 401 Unauthorized response, authenticating will make no difference.[2] On servers where authentication is required, this commonly means that the provided credentials were successfully authenticated but that the credentials still do not grant the client permission to access the resource (e.g. a recognized user attempting to access restricted content).

500 Internal Server ErrorA generic error message, given when no more specific message is suitable.

The line tells the host, port and ip, time of access, method (GET), status code, browser info and OS info. That’s another one down. 403 and 500 remain. Let’s see if we get 403 if we remove all permissions for marrow’s index.html, restart apache2 (and empty Firefox’s cache):

Yes. That leaves us with code 500. Code 500 seems to be more of a “something’s wrong” type of error code. So, let’s break something. How about inserting a mishmash of garbled data into haunt.er’s .htaccess file? Source: http://httpstatus500.com/

The package will contain two roguelike games, namely nethack and dungeon crawl, so I’ll make a working directory to keep organized. In the directory, we create a skeleton file for the package with equivs-control:

The file is now created. Next we edit it, but first a screenshot of the contents:

Notice the highlighted line about reasonable defaults. I love reasonable defaults. Anyway, time to edit the file a bit. We changed the package name, version number (to 0.1), depends (to include the games) and the description:

Time to build the deb package, then:

antero@VirtualBox:~/mymeta-games$ equivs-build mymeta-games.cfg
dh_testdir
dh_testroot
dh_prep
dh_testdir
dh_testroot
dh_install
dh_installdocs
dh_installchangelogs
dh_compress
dh_fixperms
dh_installdeb
dh_gencontrol
dh_md5sums
dh_builddeb
dpkg-deb: building package `mymeta-games' in `../mymeta-games_0.1_all.deb'.
The package has been created.
Attention, the package has been created in the current directory,
not in ".." as indicated by the message above!
antero@VirtualBox:~/mymeta-games$

It was. Now to see whether it works, with gdebi. Which, it seems, we have to install first:

The program 'gdebi' is currently not installed. You can install it by typing:
sudo apt-get install gdebi-core
antero@VirtualBox:~/mymeta-games$ sudo apt-get install gdebi-core
...
Processing triggers for man-db ...
Setting up gdebi-core (0.8.5build1) ...
antero@VirtualBox:~/mymeta-games$

Doing ‘man gdebi’ describes it as a “Simple tool to install deb files”, which sounds apt (as in fitting).

Success! Although the lines “long description and info” and “second paragraph” look ugly. Now, to see if it passes lintian (a static analysis tool for Debian packages). We install lintian with sudo apt-get install lintian, and then:

Looks like we have some tinkering to do. I’ll edit the cfg file to contain Erkki Esimerkki <erkki@esimerkki.com> and change the version number to 0.2 to prevent future errors. Actually, let’s add the long description as well, as its lack bothers me to no end:

Let’s see if we can sign it. Remember how we set the maintainer to Erkki Esimerkki <erkki@esimerkki.com>? We need to remember that now, as we generate keys with gpg –gen-key. We insert Erkki’s info when asked, and set the key to expire in 1 week, and otherwise just press enter whenever asked something. I wouldn’t usually include all sensitive data on a report, but since this is a temporary environment with fake info, I’ll let it slip.

Looks like it did. Next stop is to rebuild the package once again, this time with the –full parameter. Also, I’ll change to description a bit and increase the version number. (Latter steps not specifically reported anymore.) –full makes it use Erkki’s key. Quote from man equivs-build:

–full | -f

Do a complete build. debuild will be called, that is, a full package will be built and signed, suitable for upload to the Debian servers.The ID used to signed is taken from, in that order, the user from the last entry of a supplied changelog, the Maintainer: field in the equivs control file, or the local username.

It is now a signed package, unless I’ve misunderstood something along the way.

Repository

Next up, setting up a repository. We’re going to need to install Apache web server and enable userdir, so let’s get that out of the way.

antero@VirtualBox:~/mymeta-games$ sudo apt-get install apache2
...

We use a handy tool called a2enmod to enable userdir, and then restart the server:

(The example I’m following used codename and suite ‘lucid’, but I suppose ‘precise’ is appropriate for Ubuntu 12.04.) Then we add our previously created deb package into the repository, with reprepro, which we’ll also have to install.

antero@VirtualBox:~/public_html/repository$ reprepro
The program 'reprepro' is currently not installed. You can install it by typing:
sudo apt-get install reprepro
antero@VirtualBox:~/public_html/repository$ sudo apt-get install reprepro
Reading package lists... Done
Building dependency tree
...

“Is x a roguelike?”

On the term ‘roguelike’

The term roguelike is used very loosely today. To each their own, but this might not make sense, because:

If everything’s called a roguelike, the term loses its meaning.

We already have the terms hack and slash and dungeon crawler. They are perfectly good, descriptive terms, and don’t refer to a overly specific thing.

The term roguelike refers to a certain type of game, such as NetHack, ADOM, Dungeon Crawl or Angband, to name but a few. These games have a lot in common with each other, and their core gameplay and appearance are reminiscent of Rogue.

If a game shares merely one or two features with these, it might not be a roguelike itself, but a game with some features found in roguelikes. Which, incidentally, is completely okay.

Still, this is an important distinction. Bad analogy:

An ornithologist might get quite annoyed if people started calling fish birds, because both have two eyes and require oxygen to survive, and are commonly eaten by humans.

What separates a roguelike from any old hack and slash, then?

A roguelike typically has most of the following high value factors.The factors are paraphrased from the Berlin Interpretation:

Random environment generation

Permanent death

Turn-based

Grid-based

Non-modal (Every action available at any point, ie. no separate exploration and fight modes etc.)

Complexity (Plenty of possible item/player/monster/world interactions at any given time)

Exploration and discovery (Random environment and unidentified items for every new player character)

It would likely have some of the other factors as well:

Enemies are similar to players (ie. have inventory, equipment, use items and cast spells)

Tactical challenge (learning curve, trial and error, accumulated knowledge of the game world)

ASCII display (traditional, but many roguelikes also have tile graphics available)

Dungeons (rooms connected by corridors)

Numbers (used to describe character etc, and are deliberately shown)

So?

It’s good to remember that for many people a roguelike is a specific type of game, one still relevant today. When Binding of Isaac is called one on the basis that it has a degree of randomity and permanent death, it might well cause the occasional frown, even if both sides enjoy the game.

On the other hand, dismissing the previous generation of gamers as “butthurt dwellers” because they refuse to call a real-time 3D shooter a roguelike is just ignorant.

Note that appearance alone isn’t the key; Dungeons of Dredmor is blatantly graphical, and yet fulfills a large amount of the aforementioned factors, whereas Dwarf Fortress boasts nice ASCII graphics, but its gameplay is fulfills a precious few. (Save for the adventure mode, reportedly – haven’t tried it myself yet.)

Assignment

Additional tasks:
– Can you find additional information on the attacker (using legal means)?
– Analyze the rootkit line by line

Examine the partition to your heart’s content. Use nothing but legal methods, ie. don’t portscan remote addresses. Be careful with the image.

Notes

I’ll use Virtualbox for this assignment. I’ve had my eye on Lubuntu for a while, so the guest OS image I’ll be using is lubuntu-12.04-desktop-i386.iso. After downloading the Scan of the month 15 image and installing autopsy, I’ll disable networking functionality from the guest, and use the host for searches and writing this report.

In Virtual Lubuntu:

Computer name: luba
Username is: mrf

Also, I’ve been advised to include information on my system for compatibility reference.
Hardware:

Oracle Virtualbox (VT-x disabled, as I only ever use one core for VMs and Virtualbox’s own virtualization seems to work better)

Every piece of kit seems to work well in Xubuntu 12.04. Nvidia’s restricted driver provides the occasional headache, though.

Autopsy install and setup

We’ve covered the basic apt-get install routine in earlier posts, so from here on out I will just include the commands without the output, unless there is something exceptional worth reporting. (Provided our teacher agrees.) Let’s start by installing autopsy, a forensic browser.

That’s done. We can now access it if need be. We close the timeline view with the Close button and return to autopsy’s gallery. Time to take a look at the contents of the image. We press the Analyze button and enter the File Analysis view.

Analysis

I made some progress in class earlier, so I’ll be picking up where I left off, informationwise.

First off, there’s a deleted file that doesn’t seem to belong: /1/lk.tgz. Let’s click it and use the Export feature and see what it contains.

The archive certainly contains interesting stuff. I extracted the file to /home/mrf/Downloads/last. Let’s take a look at ‘cleaner’ with the strings-command:

mrf@luba:~/Downloads/last$ strings cleaner |less

This thing seems to be a bash script that cleans log files, and contains odd stuff in german. How about ‘install’?

mrf@luba:~/Downloads/last$ strings install |less

The strange boasting in the beginning of the file is pretty incriminating. I’d say that lk.tgz contains the rootkit.

Further analysis

File ‘ssh’ contains a lot of lines relating to man-in-the-middle attacks and other warnings. It reads like a logfile.

File sshd_config mentions PidFile /dev/ida/.drag-on/pidfile. There are also keys present (ssh_host_key and ssh_host_key.pub)

I’ll take a closer look a bit later on. Let’s check out the other directories on the partition now.

…they seem to be mostly empty. For future reference: /etc and $OrphanFiles are interesting. /etc because it contains system settings in human readable form, although the attacker did have the cleaner script, and $OrphanFiles because it might contain interesting loose files.

Notes on orphanfiles

OrphanFile-2041 is the previously mentioned install script. Based on this, it has been deployed on the server. Its last line “rm -rf last lk.tgz computer lk.tar.gz” removes lk.tar.gz, last, computer and lk.tgz, which, incidentally, is the archive we extracted earlier. There’s some romanian in there as well.

The file mentions two e-mail addresses: last@linuxmail.org and bidi_damm@yahoo.com, which might be forensically useful in the future.

OrphanFile-2043 is the logfile cleaner script. The script’s called sauber, which is german for clean.
OrphanFile-2044 is inetd.conf, which mentions a user called ‘cyrus’.
OrphanFile-2045 is bash script that mentions mkxfs and linsniffer (remember to write more about this later)
OrphanFile-2047 is a perl script that sorts the output from LinSniffer.
OrphanFile-2050 contains a long string of numbers and an e-mail address: root@dil2.datainfosys.net
OrphanFile-2059 kills linsniffer and removes tcp.log

I had to export most of the orphanfiles for closer inspection with the strings-command.

2039: Similar content with the previously mentioned ssh-file
2049: Mentions root@dil2.datainfosys.net again

Conclusions so far

The Scan 15 challenge asks:

Show step by step how you identify and recover the deleted rootkit from the / partition.What files make up the deleted rootkit?

We have located lk.tgz and recovered it. Its contents seem to make up the deleted rootkit.

Let’s start it up from the Applications menu. Here’s a screenshot of the eventual result:

top

man top: “top – display Linux tasks”

Spotify is now playing random tracks until forever. Time to see what top has to say about that. Let’s run it:

antero@xub12:~$ top

Pressing shift-m shows running processes organized by memory use, from most hungry to least. Shift-p does the same for processor time. Affixed here are screenshots of the system’s CPU and memory usage while Spotify is playing music:

It appears to using 5% of cpu resources. What a hog. Next up is the RAM usage view:

For future reference, just add -n with the other flags, resulting in “netstat -pena –inet”. As far as mnemonics go, “penan internet” is quite dumb, but still helpful.

ps

man ps: “ps – report a snapshot of the current processes”

Next up is ps, started with the waux parameters. Note how there’s no ‘-‘ before the flags – the command is from the days of yore, when hyphens were nowhere to be seen. (As taught in class.) To avoid a wall of output, we pipe ‘grep spotify’.

Odd. I would have expected Spotify’s disk cache to show up. Gazing upon iotop’s manpage I found a flag that makes it only show processes with actual I/O activity. However, with just -o the window was mostly blank, with the occasional process briefly flashing up and disappearing. I added -b, which is batch mode, with which iotop outputs a feed of activity, which eliminates the flashing. Here’s the output:

Well, that was unimpressive. The laptop became slightly noisier for a while, though.

The assignment told us to measure the stress imposed on the system, but man stress doesn’t really shed light into this. I assume munin will take care of that. In order to get a clearer reading, I’ll just run a 25 second test.