Lab 4.5 -- Simulated Chinese Firewall (Part Deux)

For the second part of lab 4, (lab 4.5), we are once again thwarting the simulated Chinese-firewall IDS, but this time the professor configured the IDS to detect small packets sizes. We will no longer be able to just break the offending words into very small packets and send the text file to Ta.

The first thing I did on this lab was to put myself in the sudoer’s file on Tha; we are still going to send our messages to Ta, but we will be using Tha as the staging server to send our packets. We received an e-mail from the professor that the performance on Tha was very poor, and that we should use a root shell. I decided to log-in to Tha with the root user:

# ssh root@Tha

In the second part of this lab we will be using libpcap and scapy in order to forge raw packets to Tha. I’ve never used libpcap, (a package capture program), or scapy, (used to manipulate and forge network packets), before, so I’m not completely sure of what I’m doing just yet…I‘m starting to notice a pattern with the labs at this point… ;)

I started by running sniff.py, (a tool given to us by Jong), to sniff on port 8092. (the port of my student number):

# python sniff.py eth0 tcp port 8092

I receive a message stating:

“…sniffing eth0 starting…”

…and it just hangs after that. I’m not sure if it’s actually doing anything, or if I’m using the .py file incorrectly. My SSH session would literally time-out before I would receive any feedback from the command above. I hope I’m not seriously degrading the performance of the server for everyone! Although it wouldn’t be the first time I’ve done this… :)

I’m going to e-mail the professor and make sure I’m using the tool correctly. There was another e-mail sent out that suggested we merge the sniff.py and lab4.py files in order to get the correct output from the “out.txt” file. This was also due to the degraded performance of Tha. I'm going to have to look at the code and determine how to merge the programs together.

As you can see, I really don’t have much to report on this week concerning the lab, but I hope to have it completed and have received another “Success!” response by the next blog post. I’m also still reading-up on both scapy and libpcap; that should definitely keep me busy the rest of this week.

Passing the "simulated" string filter censorship IDS

As stated in my last post, lab 4 simulates computer censorship by filtering certain strings from client requests, sending reset commands to both the client and the server being requested.

After Jong’s lecture, I downloaded the lab4files.tar.gz and extracted the file to access the serverv3.c code. I put the .c file on ‘Ba’ so I could test whether my python code would work before I tried it against ‘Ta’. I compiled and ran the server code with the ‘&’ switch in order to make the server run in the background so I could test my lab4.py code:

./a.out 9082 &

The ‘9082’string is the port the server will be listening on.

The code I wrote was basically the same code Jong gave us in lecture, but I broke the strings up with the ‘.replace()’ function in python:

**********************************
for l in lines:
l = l.replace("antithesis", "anti\nthesis")
l = l.replace("fundamentally", "funda\nmentally")
l = l.replace("consequence", "conse\nquence")
l = l.replace("illuminated", "illu\nminated")
l = l.replace("viewpoint", "view\npoint")
**********************************

I would search for a keyword in the string, and then replace it with a newline character in the middle of the word: “anti\nthesis” would become:

‘Anti’
‘Thesis’

Once the keyword was broken-up, I would use the ‘split()’ function and send the current string, up until the split, to the server:

L2 = l.split(‘n’)
For x in l2:
s.send(x.strip())
time.sleep(1)

This was allowing the keyword to pass to the server, and the string was re-configured on the server side in its entirety.

I ran this code on Ba, configuring my lab4.py code to connect via the local host:

s.connect(("127.0.0.1", 9082))

After running my lab4.py code I received a ‘success’ response from the server; this tells me the strings are being broken-up and re-configured correctly...but would it work on ‘Ta’ ???

I ran my code from Alef to the server running the simulated censorship and received another ‘success’ response from the server:

[tjcdeba@Alef ~]$ python lab4_code.py
"What is Prof. Crandall (a.k.a. Jed, a.k.a. J-Dub, whatever you prefer)'s favorite Von Clausewitz quote?\nSuccess!\n"

Looks like lab 4 is done…on to lab 4.5!

Lab 4 beginnings -- and a test coming up...

With labs 2 and 3 done,

** I probably could have done more with lab 3; I could have explored NMAP more thoroughly and maybe discovered other ports/exploits using different scans and techniques, but I’m happy I found the four machines on the sub-net configured by the professor.

I’m now concentrating on lab 4 and the test coming up this Friday (4/17). The test is going to be pretty hard, I think, with a lot of references to information from Homework #2. Thankfully it’s open-book/open-notes so I’ll be able to bring a lot of information and references from the web and from the book. I’ve re-done Homework #2 and I’m still a little shaky on filling out a transitive closure matrix. I’m going to re-read chapters 16 and 17, and I’m also going to read chapter 32 (It’s only 5 pages so it shouldn’t take too long).

For lab #4 we’re trying to overcome a simulated Chinese fire-wall scenario: the professor has configured a router that is simulating the way the Chinese government is, (sort of), censoring internet traffic into and out of the country by filtering words or phrases, and then sending reset packets to both the sender and the destination.

We had a very good lecture today, (4/15), on the technology of the Chinese firewall scenario by Jong Chun Park. He laid-out the scenario we would be facing in lab 4, and he gave pretty good instructions on how to over-come the censorship by “sending a sequence of packets which split the keywords.” He even gave us some python code in order to accomplish this:

import socket # client
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((“10.0.0.3”, 8080))
s.send(“hello”)
d=s.recv(1024)
print repr(d)
s.close()

He also stated that the censorship algorithm that’s employed here is not an actual Intrusion Detection System, but rather an iptable filter. I’m going to be working on lab 4 this weekend, and I don’t believe it should be too hard (I think Jong and the professor have pretty much done most of the heavy lifting on this one).

At this point I don’t really have that much to report on lab 4, I’m just trying to get everything together for the test and then I’ll be able to concentrate on the lab. I added myself as a sudoer on Tha, and I've downloaded the lab4 files from the class website. Other than that, I haven't really accomplished much on this lab. Oh, and I guess I should learn a little bit about python as well… =)

Come out, come out wherever you are....

For this week’s post I’m continuing to focus on my NMAP scans on the University’s virtual environment set up by the professor.

As stated last week I found a machine on IP: 192.168.33.2 with port 22 open using:

sudo nmap -n --scan-delay 1s -vvv -PN -p22 192.168.33.2-100

Wanting to investigate this machine further, I performed an OS scan using:

sudo nmap -PN -A 192.168.33.2

This revealed:
Running (JUST GUESSING) : FreeBSD 5.x|6.X (90%)
Aggressive OS guesses: FreeBSD 5.4 or 5.5 (x86) (90%), FreeBSD 6.1-RELEASE through 6.2-BETA3 (x86) (88%), FreeNAS 0.671 (runs FreeBSD 6.1-STABLE) (87%)

Earlier in the week I found a machine with port 80 open using:

sudo nmap -n --scan-delay 1s -vvv -PN -p80 192.168.33.2-100

But, another scan this evening, (at around 7:56pm), did not reveal any machines with port 80 open. This may be due to packet loss though we’ve been informed that the web server is not very stable so it may be down at the moment. I'm not completely convinced this is due to packet loss because a ‘w’ command reveals only about 8 other scans being performed at the moment.

We were informed that there is “probably” at least one windows machine on the network, so I decided to search for it with the command:

sudo nmap -n --scan-delay 1s -vvv -PN -p135,139,445 192.168.33.2-100

NMAP returned with:
Host: 192.168.33.40 () Ports: 135/open/tcp//msrpc///, 139/open/tcp//netbios-ss\
n///, 445/open/tcp//microsoft-ds///

The 135 open TCP port tells me this is *probably* a windows machine.

After running:
Sudo nmap –n –PN –A 192.168.33.40

NMAP returned with:
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn
445/tcp open microsoft-ds Microsoft Windows XP microsoft-ds
Device type: general purpose
Running (JUST GUESSING) : Microsoft Windows 2000|2003|XP (98%)
Aggressive OS guesses: Microsoft Windows 2000 SP4 (98%), Microsoft Windows Server 2003 Enterprise Edition 64-Bit SP1 (95%), Microsoft Windows 2000 Server SP4 (94%), Microsoft Windows XP SP2 (94%), Microsoft Windows XP SP2 (firewall disabled) (94%), Microsoft Windows 2000 SP3 (92%), Microsoft Windows 2000, SP0, SP1, or SP2 (92%), Microsoft Windows 2003 Server SP1 (91%)
Service Info: OS: Windows

After learning from other students in the class, (and from the professor), that there are 4 machines on the subnet, I decided to perform additional scans to try and locate the 4th machine. Another student in the class tipped me off that I should try scans other than SYN scans…so, after performing FIN,Xmas tree and Null scans, I found:

Host 192.168.33.22 appears to be up ... good.
Interesting ports on 192.168.33.22:
Not shown: 1694 closed ports
PORT STATE SERVICE
22/tcp open|filtered ssh
80/tcp open|filtered http
111/tcp open|filtered rpcbind

At this point I *believe* I’ve located everything on the subnet, though I’m going to continue scanning with different switches to see if anything else pops up. I’m also really enjoying using nmap, I think I’ll use it at work just to see what I can find….just kidding, of course =)

Who? What? Where? -NMAP- it is then….

For lab this week we are to use NMAP to discover machines, ports, and services on a subnet configured by the professor. The professor has put several machines running different services on a number of ports and we are to find out all we can about the machines on the subnet. This lab can only be done if the previous lab, (lab 2, the buffer-overflow attack), was completed because you needed to have root privileges on Ba. This is the first time I’ve ever used NMAP, and at this point there are so many things you can do with it that I haven’t even really scratched the surface yet. I began by reading a few of the MAN pages on NMAP, as well as some Google searching to begin understanding the tools I would need in order to complete this lab.

In the beginning things have been kind of slow because there are so many people doing scans that I would imagine there is a high probability of major packet loss. I ran the ‘w’ command from the terminal on Ba and noticed that there were 17 people on the server, and they were most likely scanning the subnet as well:



I found that port 22 (SSH) was open on IP: 192.168.33.2, so I directed an OS scan on that machine with the command:

‘Sudo nmap –n –PN –A 192.168.33.2’

I put the results of this scan into a log file, and it determined that machine was running FreeBSD 5.4 or 5.5 (x86) , though the scan was (89%) sure that this was the correct OS and version number. I’m still doing some scans on the subnet, but it’s taking quite a while and I need to have this blog post up by 12:00a.m. (it’s 10:00p.m. now, so I’ll probably have a few more scans complete in the next couple of hours).

I did notice something kind of funny when I was attempting to scan for ALL OS’s on the subnet, (Yea, I know, not a smart thing to do with so much traffic on the server); I got kicked off the server for “exceeding my allowed time on the server.”



I’m not sure what this really means because the scan was only running for about 30 minutes. Maybe the professor has some kind of time-elapse method that will stop your scan after a set time period; this is just a guess, I have no idea if it’s correct. This also taught me that I need to do more directed scans and not have such a broad view of the task.

At this point I haven’t been able to answer all of the questions for the lab just yet, but I hope to by the next blog post. It’s taking a while to actually filter through the data and mine it for the information I’m looking for. As I stated before, I haven’t had very much experience with NMAP, so I’m still wading my way through the process.

…and the battle continues….