TECH 581 W Computer Network Operations: Laboratory 2, Team 1


The first part of the lab is to research active reconnaissance tools and their relationship with anonymity.  Once the relationships are established, the tools will be added to the OSI 7 layer model.  The purpose of this step is to determine where the active reconnaissance tools attack different part of a network and what techniques may exist for anti-forensics.  A comparison could be made to see what of the past laboratory assignment table and the active reconnaissance tools.

The next part of the lab will include the research of SCADA protocols in comparison of the OSI 7 layer model.  The protocols will also be compared to the TCP/IP model.  The TCP/IP model will be set next to the OSI 7 layer model to determine where the layers of it compare to the OSI 7 layer model.  Once everything is aligned, the group will be able to see where the active reconnaissance tools can go into the SCADA protocol layers.

Literature Review

In the previous laboratory experiment, the group found attack tools and fit them into the OSI 7 layer model as well as found their McCumber cube coordinate.  This was only the first lab which leads into this second lab, which involves finding active reconnaissance tools and doing the same process with them.  These labs have all tied into researching and learning about penetration testing and how to properly utilize it for our needs.  Hopefully one day in the future this will give us the ability to provide this service to others.  For those that do not know about penetration testing there are articles explaining what it is, how to determine whether you need to do it, and how one should go about starting the process.  Matt Bishop wrote a short article called About Penetration Testing, putting penetration testing into an analogy.  This is analogy is about when someone buys a new car and wants to see how they can protect it from getting stolen, so to find out the person asks their friend who is a cop(Bishop, 2007).  Before the cop can properly test the car, they need to know some information about it, such as the make and model, as well as what the person determines to be a violation of protecting the car (Bishop, 2007).  This article ties into our lab because before the group can even start performing some penetration tests, we need to figure out what tools can attack what part of a system or network, which is just like having the cop learn about the car and what tools are available before doing their own penetration testing.  This article provides a nice analogy for anyone who does not fully understand penetration testing and would like to learn a little about it, although this article does not fully explain how to start the actually process.

In 2001, J.P. McDermott wrote an article called Attack Net Penetration Testing. This paper like Matt Bishop About Penetration Testing helps determine what needs to be done before starting the actual process of penetration testing.  The main steps that McDermott wrote about the beginning process of penetration testing are (McDermott, pg15, 2001).

  • Define penetration testing goals.
  • Perform background study.

Just like Matt Bishop wrote about what steps to be taken before the process of penetration testing need can begin, McDermott has a more technical side of explain the process.  These are the only two first steps of his process, but that is exactly what the group has been doing in this lab and the previous lab.  The research is performing the background study, while putting the tools found into different models to see where they fit into different protocols is considered to be a goal of penetration testing, as in where we want to attack and what tools to succeed with.

Matt Bishop also wrote another article called Security Plan for Red Teaming. Bishop conveys the message that before anyone starts to perform any king of penetration testing or “red teaming” a plan needs to be formulated.  This idea of a plan fits with this lab exercise because that is basically exactly what we are doing.  The research that the group is performing is the foundation of the plan because the group will have lists that show attack tools and what OSI 7 layer model, what TCP/IP layer model, and what SCADA protocols can be attacked using different tools.  Bishop’s article discusses the security plan for the process of penetration testing the Secretary of State’s system (Bishop, pg1, 2007).  The group can use this information to make procedures and policies to be used for when the group starts to do their own penetration testing.  The only problem with this article is that it seems to be all opinion; the author seemed to use his own knowledge as the reference.

Matt Bishop is not the only article that describes a method or framework for setting the process of penetration testing.  In 2007, Choo et al setup a framework for penetration testing military applications. The article is called Automated Red Teaming: A Proposed Framework for Military Application and the authors main objective is to “design key components and techniques to develop an automated red teaming framework (Choo, pg1936, 2007).  This is also what the group is setting up in this lab experiment.  The group has done research in finding tools to attack different layers of different models.  This is essentially setting the group up for future penetration testing or red teaming of our own systems.  The model used by Choo et al describes a way to have the tools automatically run using algorithms (Choo, pg1937, 2007).  Godefroid et al also devise a way to have an automated system for penetration testing in the article Grammar-based Whitebox Fuzzing. Godefroid et al have some code that can be used to automate the tools to perform some penetration testing (Godefroid, pg209, 2008).  From the looks of some of these algorithms, some are complex formulas and codes.  Some of the tools found by the group have the capability to be automated.  Michael Gegick and Laurie Williams wrote a paper called Matching Attack Patterns to Security Vulnerabilities in Software-Intensive System Designs. This article deals with this lab by the fact that the group is putting the tools into different layers and determining what can be attacked with them.  Once the group begins to do some actual penetration testing we will be able to see some patterns on what tools attack the layers and protocols researched in this lab.

In 2004, a conference was held and Sankalp Singh,James Lyons and David M. Nicol wrote the conference proceedings called FAST MODEL-BASED PENETRATION TESTING. This describes another method for making a model and how to perform the task as well as what to test.  Their approach is to “which take detailed information of the host configurations, attacks, vulnerabilities, critical assets, and connectivity to build complex models of the system that allow for automatic generation of repeated, independent attack paths” (Singh et al, pg1, 2004).  Other had made models such as Matt Bishop and Choo et al.  This article seems to most closely represent what the rest of the lab exercises will be.  We will use the information that we already have, plus what our research has found, and perform the penetration based on that.  This all comes down to what is ethical and what is not.

Godefroid et al start to describe the different types of what they can “fuzzing”.  In 2004, David Hafele wrote an article called Three Different Shades of Ethical Hacking:Black, White and Gray. This article goes into the different areas of penetration testing.  While all that the group will be learning in can be used for “evil” it can also be used for good.  The entire purpose is to learn how to properly test our systems and how to protect them.  From what the group members have learned, this topic has always been a heavily debated item.  Hafele wrote “Ultimately, the ideal for the Ethical Hacker is to be a contributor to the body of knowledge of network security” (Hafele, pg4, 2004).


The first part of the lab was to research active reconnaissance tools.  Once the tools were found, the group then put the tools into the OSI 7 layer model.  In addition to attaching the tools to the proper OSI 7 layer model, the group also determined which dimension of the McCumber cube that the tool also fit into.  The group also researched the anonymization techniques for anti-forensics.

In the next part of the lab, the group researched SCADA protocols.  In addition to looking into the SCADA protocols, the TCP/IP protocols were aligned with OSI 7 layer model to see how they compare to each other.  The research that the group did looking at how the TCP/IP model fits with the OSI 7 layer model was able to help the group find out why there is a debate on how many layers the TCP/IP model has.


Part 1

OSI Layer Model

Recon Tools

McCumber Cube Heirarchy

Layer 8/ People

Confidentiality, processing, policy
Dumpster diving, Social Engineering,

Shoulder Surfing, Manipulation,

Confidentiality, transmission, human
Phishing, Integrity, processing, human
Layer 7/ Application Mbenum, netenum, netmask, psinfo, psfile,smtp-vrfy, whoami, amap, p0f, psk-crack, sinfp, unicornscan, xprobe2, pbnj, zenmap, cisco torch, curl, smb bruteforcer, smb client, stompy, Confidentiality, storage, technology
Getsids, http put, halberd, httprint, httprint gui, metoscan, mezcal https, mibble mib browser, onesixtyone, openssl-scanner, paros proxy, peach, rpcdump, smb serverscan,  smb-nat, tnscmd, taof, vnc_bypauth Confidentiality, processing, technology
0trace, relay scanner, sqlquery, Dsniff Confidentiality, transmission, technology
Gfi languard, sqlupload, openssl to open SQL inject Integrity, processing, technology
Goog mail enum, google-search Integrity, transmission, technology
Pstools Availability, storage, technology
Fuzzer, sqldict, sqldumplogins, medusa Availability, processing, technology
Layer 6/ Penetration Finger google, googrape, gooscan, maltego, metagoofil, checkpwd, cicso auditing tool, cisco enable , bruteforcer, cisco global expoiter, isr-form, jbrofuzz, list-urls, metacoretex, mistress, nikto, OAT, sidguess, smb4k, Confidentiality, storage, technology
Pslist, psgetsid, psloggedin, psloglist, pstoreview, Confidentiality, processing, technology
Sql scanner, sqllibf Confidentiality, transmission, technology
Absinthe Integrity, storage, technology
Cowpatty Integrity, transmission, technology
Bed, cirt fuzzer, Availability, storage, technology
Layer 5/ Session NBTscan Confidentiality, storage, technology
Dnstracer, Scapy, Send IP, tcptraceroute, tctrace, ike-scan, ikeprobe, superscan, Confidentiality, transmission, technology
Thc pptp, tcpick, urlsnarf, hotspotter, karma, kismet, btcrack, pcapsipdump Integrity, storage, technology
Afrag, asleap, bluebugger, blueprint, btscanner, carwhisperer, minicom Integrity, processing, technology
Hsrp spoofer, wifitap, wicrawl, wifizoo, Integrity, transmission, technology
Sipsak, sipcrack, sipdump, sip Availability, processing, technology
Layer 4/ Transport Dnswalk, Confidentiality, storage, technology
Nessus, Snmp walk, snmp scanner, smb get serverinfo, snmpcheck, snmp enum, Confidentiality, transmission, technology
wireshark, wireshark wifi, Integrity, processing, technology
Firewalk, Fport 2.0 Integrity, transmission, technology
Smb dumpusers Availability, processing, technology
Layer 3/ Network Advanced Port scanner, Advanced Net Tool, ARIN, AW Security Port Scanner, Cheops, DNS-Ptr, dnstracer 1.5, dns-bruteforce, dnsenum,  dnsmap, dnspredict, IP Tools, NScan, NEWT,subdomainer, angry ip scanner, Confidentiality, storage, technology
Dig, protos, Libvsk Confidentiality, processing, technology
AcePing, Ass, Autoscan, fierce, fping, Friendly pinger, genlist, hping, hping2, hping3 , Lanspy, netcat, netdiscover, Nmap, NSLookup ping, protos, scanline, scanrand, dsniff, etherape, nemesis spoofer, netenum, netmask, Sam Spade tracert,Whois,7th port scan, Confidentiality, transmission, technology
Fport, intrace, itrace, yersinia, Packit Integrity, transmission, technology
Spike Availability, processing, technology
Layer 2/ Data Link Dmitry, host, nmbscan, Confidentiality, storage, technology
Layer 1/ Physical Rcrack, john 1.6.34,


Confidentiality, processing, technology
Ettercap Aircrack, NetStumbler, djohn Confidentiality, transmission, technology
Fakeap, wiassistant, hstest, pwl9x Integrity, transmission, technology
Layer 0/ Kinetic Human Machine Interface (HMI) Integrity, storage, technology
Remote Terminal Units (RTU), Programmable Logic controller (PLC) Integrity, transmission, technology

Part 2

OSI Layer


Layer 8/ People

Layer 7/ Application


Layer 6/ Presentation


Layer 5/ Session

Application/H2H Transport

Layer 4/ Transport

H2H Transport

Layer 3/ Network

Internet/ Network Access (Subnet)

Layer 2/ Data Link

Network Access (Subnet)

Layer 1/ Physical

Network Access (Subnet)

Layer 0/ Kinetic

OSI Layer

SCADA Modbus Over Serial

SCADA Modbus

Layer 8/ People

Layer 7/ Application



Layer 6/ Presentation

Layer 5/ Session

Layer 4/ Transport

Layer 3/ Network

Layer 2/ Data Link

Modbus Serial Line Protocol


Layer 1/ Physical



Layer 0/ Kinetic

OSI Layer

SCADA Modbus+


Layer 8/ People

Layer 7/ Application


Modbus Application Layer (MBAP)

Layer 6/ Presentation

Layer 5/ Session

Layer 4/ Transport

Transmission Control Protocol/ ModbusTCP

Layer 3/ Network

Internet Protocol

Layer 2/ Data Link


Data Link Ethernet 802.2/802.3

Layer 1/ Physical


Physical Ethernet

Layer 0/ Kinetic

OSI Layer


SCADA DeviceNet

Layer 8/ People

Layer 7/ Application


Application CIP App Object Library

Layer 6/ Presentation

Presentation CIP Data Management I/O Messages

Layer 5/ Session

CIP Message Routing, Connection Management

Layer 4/ Transport

DeviceNet Transport

Layer 3/ Network

DeviceNet Transport

Layer 2/ Data Link

Data Link DNPS/ Pseudo Transport Layer


Layer 1/ Physical

EIA-232/ EIA-485

DeviceNet Physical Layer

Layer 0/ Kinetic

Figure 1.1

TCP/IP Model

While there are several versions of the TCP/IP model, the most common is the Department of Defense model, which is separated into four layers: the Process/Application layer, Host-to-Host (H2H) layer, Internet Layer and Network Access layer (Groth, 2002, p. 110).

This model has been accepted by many affiliations and organizations such as, of course, the U.S. Department of Defense and Cisco Academy (Dye, Antoon, & McDonald, 2007). Stallings indicated that he felt the reason that the TCP/IP protocol follows the DoD model rather than the widely known and accepted OSI model because “the OSI model is unnecessarily complex, with seven layers to accomplish what TCP/IP does with fewer layers” (Stallings, 2007).

Application Layer

The top layers of the OSI model, Application layer, Presentation layer and Session layer, are all satisfied by the DoD model’s Application layer. For instance, in the session layer of the OSI model, ongoing communications between two entities is considered a session. In the DoD model, the Appication layer satisfies this functionality with protocols such as HTTP and FTP. However, the OSI model’s Session layer is argued to be more complex than this. “In TCP/IP, its [the session layer] characteristics are provided by the TCP protocol” (Hong, Meng, Wai, Chuan, & Ming, 2000). The TCP protocol lies, of course, in the H2H Transport layer, which is the reason Stallings argues that the Application and H2H Transport layers of the TCP/IP model both fall within the OSI models Session layer.

H2H Transport Layer

Figure 1.3 indicates that the TCP/IP H2H Transport layer satisfies the characteristics of the OSI Transport layer. Also, Figure 1.3 includes the debatable inclusion of OSI session layer characteristics.

Internet Layer

The Internet layer of the DoD model corresponds with the OSI model’s Network layer very directly. The difference between the layers is that the Internet layer is specifically connectionless, while the Network layer includes both connection-oriented and connectionless-oriented communications.

Network Access / Subnet Layer

Considering the way that the Network Access/ Subnet Layer matches up to the Network, Data Link and Physical layers of the OSI model in figure 1.3 and how it matches with the Data Link and Physical layers in figure 1.2, this is where the layers become difficult to match. To support Stallings’ view of the inclusion of the Network layer in the Network Access layer, in the electronic document Comparison and Contrast between the OSI and TCP/IP Model, the authors go on to say that “after much deliberation by organizations, it was decided that the Network Interface Layer in the TCP/IP model corresponds to a combination of the OSI Data Link Layer and network specific functions of the OSI network layer” (Hong, Meng, Wai, Chuan, & Ming, 2000).

Physical Layer (Debated)

While Stallings and others, such as Kurose and Forouzan, stress that the TCP/IP model should include a Physical layer due to the need for physical medium to carry the signal, the most common TCP/IP model, the DoD model, does not include a Physical layer. This is because physical medium is assumed in the Network Access layer of the DoD model and encapsulation methods, such as VPN technologies, render the Network Access layer to be the last layer, while a physical medium is assumed further down the stack.

To answer the question “are there four or five layers to TCP/IP?” it seems that the majority of professionals have embraced the four-layer model, but the need for a separate physical layer is still debated. Also, to say that the DoD model matches up with the OSI model as it does in Figure 1.2 appears to be more complex. As found in Stallings’ comparison, I think that some layers of the TCP/IP model share characteristics of the Session and Network layers of the OSI model. As shown in Figure 1.1, I think that the layers match as shown while sustaining a four-layer model.


SCADA stands for Supervisory Control And Data Acquisition. This technology is typically used for steel making, power generation and distribution, chemistry, but also in some experimental facilities such as nuclear fusion (Daneels & Salters, 1999). SCADA systems can operate using several different proprietary protocols, although some operate over underlying open protocols, such as TCP/IP. These protocols include MODBUS, MODBUS+, MODBUS TCP, DNP3 and DeviceNet.


MODBUS is an application layer messaging protocol for client/server communication between devices connected on different types of buses or networks (Modbus, 2006, p. 2). It can run over several types of hardware that correspond to the Physical layer on the OSI model. These hardware types include: serial, EIA/TIA-485/232 and Ethernet.

When using this protocol over serial, MODBUS uses the MODBUS Serial Line Protocol, which is a Master-slave protocol that corresponds with the Data Link layer of the OSI model (Modbus, 2006, p. 5). Running MODBUS over serial requires either an EIA/TIA-485 or EIA/TIA-232 serial interface. The only other layer above the previously mentioned is the above layer 2 is the MODBUS Application layer, which corresponds to the Application layer of the OSI model.

Typically, the MODBUS protocol used with a Remote Terminal Unit (RTU). In this case, the protocol model follows a similar model to that of MODBUS over serial; however, layer 2 is replaced with an RTU instead of the MODBUS Serial Line Protocol.

MODBUS+ is a SCADA protocol that allows for high-speed transmission over a token-passing network. The physical layer (which corresponds to layer 1 of the OSI model) does not specify a specific technology. Layer 2 of MODBUS+ specifies a High-level Data Link Control (HDLC), which corresponds with the layer 2 of the OSI model. The final layer of the MODBUS+ protocol is the MODBUS Application layer, which corresponds to the Application layer of the OSI model.

MODBUS TCP is an implementation that allows the MODBUS Application Protocol to run on top of the TCP/IP protocol over Ethernet. Layer 1 is, of course, Ethernet and corresponds to the Physical of the OSI model. Layer 2 is Ethernet 802.3, which corresponds to the Data Link layer of the OSI model. Layer 3 is the Internet Protocol, which directly corresponds to the Network Layer of the OSI model. Above IP is, of course, TCP. TCP is the fourth layer in the MODBUS TCP protocol model and directly corresponds with the Transport layer of the OSI model. Finally, the top-most layer in the MODBUS TCP protocol is the MODBUS Application Protocol, which corresponds to the Application layer of the OSI model.

All of these protocols follow a similar pattern, as you can see from Figure 2.2. With MODBUS TCP being the only significantly different protocol, and assuming some sort of physical layer, layer 2 is the only thing unique in each MODBUS protocol. When looking at these protocols from a security standpoint, they leave much to be desired. There are no authentication mechanisms in any layer of the protocols. When considering MODBUS TCP, Byres, Franz, & Miller indicate that it “consists of short-lived transactions where the master initiates an request to the slave that results in a single action. When combined with the lack of authentication and poor TCP initial sequence number (ISN) generation in many embedded devices, it becomes possible for attackers to inject commands with no knowledge of the existing session” (Byres, Franz, & Miller, 2004).


DNP3 is an open SCADA protocol, which follows a 3-layer model. This model includes the Physical, Data Link and Application layers. It does not adhere to the OSI model, but rather a model proposed by the IEC (International Electrotechnical Commission) for more basic implementations (Triangle MicroWorks, Inc., 2002). While this protocol follows a 3-layer model, it does include a fourth Pseudo-Transport Layer. This Pseudo-Transport Layer segments application layer data into data link frames. This assumes that the Pseudo-Transport Layer must lie below the Application layer. While this model does not follow the OSI model, the Pseudo-Transport Layer was added as a sub-layer to the Data Link layer to match it as close as possible.

DeviceNet is an open standard managed by ODVA that has become a popular SCADA protocol and is widely accepted around the globe (OpenDeviceNetVendor Association, Inc., 2004). Figure 2.3 shows how the DeviceNet protocol adheres to the OSI model. The DeviceNet protocol contains a Physical layer, which uses proprietary hardware. Layer 2 of the DeviceNet protocol use the Controller Area Network (CAN), which corresponds to the Data Link layer of the OSI model. Layer 3 in the DeviceNet protocol contains the DeviceNet transport layer, which corresponds to the Network and Transport layers of the OSI model. For DeviceNet’s upper layers, the Common Industrial Protocol (CIP) is used, which adheres to the Session, Presentation and Application of the OSI model (see figure 1.1 and figure 2.3).  This model also adheres to layer 0 of the OSI model in relation to the transfer of network communication to kinetic energy; however, the layer appears as the highest layer of the model, whereas the Kinetic layer appears as Layer 0 on the OSI model.

DeviceNet appears to follow the OSI model the most closely out of all of the SCADA protocols. This model follows all of the same layers, with an exception of layers 3 and 4 being merged as the DeviceNet Transport layer and the wrong placement of Layer 0. However, this makes an interesting point because it seems that Layer 0 should be at the top of the OSI model, just under people. Considering that data starts with people OR by gaining telemetry from industrial hardware via an RTU or PLC (Programmable Logic Controller), it should travel down the OSI model from Application to the Physical layer regardless of whether this is a 7, 5,4 or 3-layer protocol. After passing the Physical layer on the sender’s side, it would seem ridiculous for low voltage communication signal to be converted to high voltage power to run industrial equipment and generate kinetic energy. Therefore, communication data must travel back up the protocol model on the recipient’s side and pass the Application layer for it to be processed by an RTU or PLC in order to generate the correct electrical current and, ultimately, kinetic energy


One of the biggest issues with this lab was finding the active reconnaissance tools.  In addition to finding all of the reconnaissance tools, another issue was trying to figure out which OSI 7 layer model and McCumber cube dimension they fit into.  Another issue was picking a side of the debate of how many layers the TCP/IP model has.  The last issue that the group has was aligning the SCADA protocols as well has the TCP/IP model with the OSI 7 layer model.  Once that was taken care of, the group got a better understanding of what tools can attack what SCADA protocols.


The group realizes that this lab exercise shows the importance of researching attack tools and how they apply to different models and protocols.  The group took the side of the TCP/IP debate that the model has 4 layers and not 5.  This is because the group believes that the physical layer is covered by the data link layer as seen in our research. The group does understand the other side of the argument, but thinks that the TCP/IP model is different that the OSI 7 layer model, but the 5 layers were discussed in the findings.    This lab will be very useful in the rest of the labs for doing penetration testing.


Bishop, M. (2007). About Penetration Testing. IEEE Security & Privacy, 84-87.

Bishop, M. (2007). Security Plan for Red Team Testing (pp. 1-3).

Byres, E. J., Franz, M., & Miller, D. (2004). The Use of Attack Trees in Assessing Vulnerabilities in SCADA Systems. Retrieved June 20, 2009, from Proceedings of the International Infrastructure Survivability Workshop:

Choo, C. C., C; Tay, S. (2007). Automated Red Teaming: A Proposed Framework

for Military Application. Singapore.

Daneels, A., & Salters, W. (1999). What is SCADA? Retrieved 6 20, 2009, from

Dye, M. A., Antoon, R., & McDonald, R. (2007). Network Fundamentals: CCNA Exploration Companion Guide. Cisco Press.

Gegick, M. W., L. (2005). Matching Attack Patterns to Security Vulnerabilities in Software-Intensive System Designs.

Godefroid, P. K., A; Levin, M. (2008). Grammar-based Whitebox Fuzzing.

Groth, D. (2002). Network+ Study Guide. Alameda, CA, USA: Sybex Inc. .

Hafele, D. (2004). Three Different Shades of Ethical Hacking:Black, White and Gray.

Hong, T. T., Meng, M. C., Wai, C. Y., Chuan, T. Y., & Ming, C. K. (2000, June 11). Comparison and Contrast between the OSI and TCP/IP Model. Retrieved 2009, from

McDermott, J. P. (2001). Attack Net Penetration Testing.

Modbus. (2006, December 28). MODBUS APPLICATION PROTOCOL SPECIFICATION V1.1b . Retrieved June 20, 2009, from

Modbus. (2006, December 30). MODBUS over Serial Line Specification and Implementation Guide V1.02. Retrieved June 20, 2009, from

OpenDeviceNetVendor Association, Inc. (2004). DeviceNet Technical Overview. Retrieved June 20, 2009, from

Singh, S. L., J; Nicol, D. (2004). Fast Model Based Pentration Testing.

Stallings, W. (2007). Data and Computer Communications (8 ed.). Prentice Hall.

Triangle MicroWorks, Inc. (2002, February 22). DNP3 Overview. Retrieved June 20, 2009, from

9 comments for “TECH 581 W Computer Network Operations: Laboratory 2, Team 1

  1. nbakker
    June 23, 2009 at 7:06 pm

    Team one did a very good job in their abstract explaining what was going to be done in the lab. The Abstract met the requirements of the syllabus in terms of length and explanation. The introduction to the lab, as found in the peer review section did at first appear to be some what redundant but concluded by explaining how lab two would fit into penetration testing seemingly for someone who had not first read their lab one exercise. The thought of an introduction is something team two has not considered, let alone one that allows the lab to stand its own, so I thought that was a good touch. The literature review itself while covering all of the topics of the syllabus, and being more cohesive then team one’s first literature review still did seem to read like more of a listing of the articles rather than a unified view of the literature in question. The methods section did leave much to the imagination, and was not a good overview of the strategy and technique to complete the lab. The two paragraphs simply listed the steps that were to be completed in a fifty thousand foot overview. While this does seem to be the general way methods are going to labs in the class that does not make scholarly in nature. There needs to be more. The first grid or taxonomy on active recon exploits does seem well balanced, containing multiple exploits per OSI layer. I do however question the inclusion of Google in layer 6 and kismet in layer 5. Does Google operate at the presentation layer? And is Google and ACTIVE recon tool? Also, Kismet is a 802.11 WiFi sniffer and cracking tool which would seem to run at layer 2. Team one’s second table, comparing OSI model to TCP/IP model, as well as 5 SCADA protocols is nothing more than confusing and very difficult to understand. Breaking each SCADA protocol into its own table combined with the OSI model would make much more sense and be much simpler to understand. IN fact I found it almost impossible to obtain any useful information from the table. Team one’s explanation of the TCP/IP model explains what Stallings views on the model are, less complex then OSI, but does not say anything about how the TCP/IP model is designed for TCP/IP and the OSI model is technically protocol agnostic at all layers instead of just the network access or physical. This was not required as part of the lab, but does seem to be a logical conclusion to draw. The explanation of the possibility of five layers in the TCP/IP model is complete and seems to agree with others in the class. Team one’s explanation of MODBUS does cover the many iterations of MODBUS, including MODBUS TCP, but doesn’t mention TCP port 502 anywhere. This seems like a large error in terms of the point of the lab. Team one’s explanation of DNP3 is complete, but they are missing a heading for DeviceNet which left me wondering if they missed it entirely at first glance. Once found, that explanation seemed complete as well. I agree with team one’s technical conclusions on the TCP/IP model, since until DoD changes the model it does officially have only four layers. The best way to enhance the next lab would be the inclusion of better methods. They do not however need to change their methods. Team presented a complete lab as per the syllabus.

  2. June 24, 2009 at 12:10 am

    The literature review was a little better than last lab but still reads like a list. Each paragraph, though it is taken in context of the lab any maybe the article before it, still is treated almost wholly individually. Each article’s paragraphs sounds more like a summary. The in-text citations are a little backwards, they’re supposed to be (Author, Year, Page). The handling of McDermott’s paper on penetration testing is a little light, his model of attack trees is important when assessing risk from a defensive perspective and planning an attack from an offensive perspective. Choo’s article on creating an automated red teaming framework describes a computer system for running simulated, automated attack, the literature review mentions that this is what is also being attempted in the lab assignment. Automation hasn’t yet been a part of the class, I believe that we’re instead working towards a model that emphasizes cognition and perception of results rather than an automated approach. This is what allows a penetration tester to test the parts of the McCumber cube that are not technology, that involve people and processes.
    The methodologies section is seriously weak. This lab was the first one that allowed us to begin using the tools found in the first lab. I was hoping to see a methodology about selecting various tools from the previous lab that fit in to the active reconnaissance role and pit them against the virtual lab environment that was created. The first paragraph of the methodologies only describes matching the active reconnaissance tools with the OSI layers that they exploit.
    The findings section also lacks depth. Instead of a description of the tools that were used and how they operated in the test environment, there is only the table with the tools and their corresponding OSI layers and McCumber cube positions. The list of tools contains a lot of tools that are well categorized, the only ones I would seriously question are the layer zero tools that are more objects that would be the targets of exploit tools rather than exploit tools themselves. Part two’s table is very confusing. According to the methodologies this table was going to align the OSI, TCP/IP, and SCADA protocols. The table looks like it was a few different SCADA protocols all combined into one big table which makes it difficult to figure out which protocol is being discussed. The descriptions of the various SCADA protocols were much more helpful than the table and added some good detail to the breakdown of each protocol’s components and why they were categorized that way.

    The issues section is interesting. Each “issue” that is mentioned was one of the parts of the assignment. I suppose that it’s good that parts of the assignment were difficult but more specific problems would’ve been more constructive for those attempting to recreate this lab. Finally, the conclusions are a little weak, simply restatements of some of the conclusions. One thing that’s missing from this lab report is any mention of anti-forensics methods or any tools to obscure the source of the reconnaissance traffic.

  3. jeikenbe
    June 24, 2009 at 11:54 am

    The group starts off with an abstract that describes both parts of the lab. The group did miss a couple of things in the abstract though. First they did not mention the literature that they had to read and review at the beginning of the lab. Second the group did not mention describing each of the layers of the SCADA protocols at the end of the lab. Next the group did a literature review on the eight articles that were assigned with this lab. The group recaps what was done in the first lab and how that lab ties into this lab. I do not think the group needed to do the recap in this part of the lab report. This part did not seem to fit. Then the group starts to talk about the eight articles given with this lab. They do a decent job at explaining what each article is talking about and how it pertains to the lab, but they lacked in other parts of the literature review. In the literature reviews the group did not mention the research question, the research method, the theme or topic of the article, any type of supporting data, and they mentioned only a couple errors and omissions. I believe that the group could have done a better job in the literature review but cutting back on the description of the article and more on the research and meaning behind the article. Next the group wrote up a methodology. They described what they did in each part of the lab and gave a very brief description of each part. Next were the tables that they had constructed in each part of the lab. The first table compared each of the active reconnaissance tools they had researched to the OSI 7 layer model and placed each one in McCumber’s cube. The table showed that there was a strong amount of tools in the application and network layer and a good amount of tools in the presentation and session layers. The other layers did not have that many tools in them. The next table showed the alignment of the TCP/IP model and the SCADA models aligned to the OSI 7 layer model. The table was a little difficult to follow because you could not compare all the protocols to each other that easily, because the protocols were on their own tables. Next the group talked about the TCP/IP model and described each of their layers. The group does a nice job of comparing the TCP/IP model and the OSI 7 layer model. They argue that the TCP/IP model should only have four layers using the argument that it is the most widely accepted of the models. Next the group discusses the SCADA protocols. They start off with a series of MODBUS protocols. The group does a good job at describing what the MODBUS protocols are used for and what they are, but they lack in the details. In the description of each of the layers of the protocols they only mention were the layer of that MODBUS protocol lines up to the OSI 7 layer model. The group does the same with the DNP3 set of protocols as they did with the MODBUS set. Next the group goes into issues they had with this lab. In this section they do not mention the issues that they had with the lab as much as what they did at each step of the lab. Last the group stated the conclusion. In the conclusion they briefly mentioned the researching of the active tools, then goes into explaining why they argued with keeping to the four layer TCP/IP model and not the five layers.

  4. gdekkerj
    June 24, 2009 at 3:25 pm

    There were a number of good things noted about this lab write-up. I thought the literature review to be fairly well done, with a nice synthesis of the important points, and a tie-in to the lab exercise attempted for the majority of the articles (although I think the term ‘cop’ to be poorly chosen). I also thought the active reconnaissance tool table to be of a nice format, with a large number of tools included (with caveats, noted later). The discussion on the TCP/IP was good, with some interesting discussion of the Department of Defense model versus the OSI approach. Also, for the most part, the SCADA protocols presented were discussed at length. In addition, a good number of external references were used to support the discussion on TCP/IP and SCADA.
    A number of flaws were noted, however, some fairly serious, others of less concern. Foremost, a discussion of anonymizaton techniques was conspicuously absent. While it was noted in the ‘abstract’ section that the team researched this topic, no information was presented on the results: if anonymization tools are present in the tool chart, there is no indication that specific tools are designated to this role. Closely related to the prior problem, the team did not mention any criteria used to classify a tool as an ‘active reconnaissance’ tool. Having researched this area also, I am fully aware of the problems with discerning if a tool falls within this particular domain. A definition of ‘what’ you consider an ‘active reconnaissance’ tool to be is not only helpful, it is absolutely necessary within the scope of this exercise.
    Since no definition of any of the criteria used to classify the tools into the chart is defined, it is even more perplexing to discover such tools as ‘googrape’ and ‘gooscan’ included in the ‘active’ tools chart. In reality, these tools do not engage the target network at all-they rely on public data indexed by the Google search engine. I would ask: if tools for digging up public data (equivalent to looking in a phone book or checking in the public library for periodical information) are considered ‘active’ reconnaissance tools, what would you consider to be passive? I also noticed such tools as ‘whois’ and a ‘John the Ripper’ variant included in this chart. The ‘whois’ addition suffers from the ‘absence of criteria’ also: it might be possible to justify this one (may engage the target network) but without any explanation as to why it is included, I believe it to be in error. Certainly, ‘John the Ripper’ is much harder to justify, as it works ‘offline’ to crack captured data files-to my knowledge there is no way to use ‘John’ to even connect to a network. This is most certainly an error caused by not being aware of the capabilities of a tool. There are many more inclusions that I would term ‘dubious;’ many of the Google based tools I would consider passive (therefore, categorically wrong), nearly all of the ‘*-crack’ variants I would consider misplaced, and many of the DNS tools I find extremely questionable without some justification presented. I would also consider a DNS tool in Layer 3 to be out of place (although exceptions exist; see team five’s review), as DNS is a layer seven protocol: it may ‘resolve’ a host to an IP address, but this comes back as payload information inside TCP/UDP encapsulation. I also was unaware that layer six of the OSI model is the ‘Penetration’ layer. Finally, I would question the inclusion of RTUs and PLCs as ‘active reconnaissance’ tools: how would you propose to use these devices in this role?
    A few more minor flaws proved distracting while reading the document. A number of the headings for the SCADA protocols appeared missing, which marred an otherwise easy to follow layout in the rest of the report. The general ‘MODBUS’ heading makes some sense, but the single ‘DNP3’ with DeviceNet falling under it confused me a bit: did you mean to imply DeviceNet as a subset of DNP3? If so, I am certain that this is wrong. I also notice that DeviceNet is not included in the SCADA stack charts. Finally, the SCADA charts were just downright confusing. It would have been better if the SCADA network stack tables were detached from each other; and, did empty areas in the charts imply continuous layers, or areas not addressed by the protocol? I could find no consistent pattern in this area (i.e. application listed multiple times under TCP/IP, but not under MODBUS TCP). Neglecting organizational details like these can render a reasonably complex report impossible to decipher meaning from.

  5. chaveza
    June 24, 2009 at 4:19 pm

    The abstract is strong they clearly identify everything that is going to happened in this lab. There are a few grammatical error right at the beginning such as, “This is analogy is about…” Bishop’s analogy for penetration testing is good for beginners and non-technical people to understand. However there is more to the article then just stealing a car. He does not have a research question but he does talk about penetration testing, not how to do it. McDermott on the other hand is more technical in his paper and does provides more detailed information about penetration testing. All six of steps of what McDermott talked about is important no just the first two which is defining goals and performing background study.
    Matt Bishop second article, Security Plan for Red Teaming is about planning, which is a great idea when doing just about anything. As with the other article, Bishop do not use supporting resources. He does seem to reference is own knowledge as if he were an expert in the field. If he is an expert then chances are others experts share his ideals and can reference each other for support.
    The team does a good job relating back to the lab from the reading. In the methods the group talked about gathering active reconnaissance tools and put them in a chart fitting the OSI 7 layer model and the McCumber Cube. They did this and was nicely charted which made it easy to read. This one is better then the previous chart from lab 1. The team then goes on to talk about the Department of Defense’s model of TCP/IP model, which is also accepted by Cisco. They break down the model’s layers, Application, Host-to-Host, Internet, and Network Accesses layer. The host-to-host description is a little slim. They mention figure 1.3 three times and 1.2 but did not locate in the paper any table or chart labed figure 1.3 or 1.2.
    The team goes on to talk about about the SCADA and SCADA protocols which are, MODBUS, MODBUS+, MODBUS TCP, DNP3, and DeviceNet.

  6. Borton
    June 24, 2009 at 4:26 pm

    Starting with the abstract, the group says “A comparison could be made…” but I’m uncertain what it is you’re comparing and whether you actually ever make the comparison. Do or do not. There is no could.
    In the literature review, the group tells us that the point of this lab is to see where active recon tools can be used against SCADA. Are you sure that’s the point? I got something slightly different. The group goes on to tell us that “the first lab leads into the second lab” and that “the labs teach penetration testing”. These are obvious points to the intended audience and should not be included. It makes the paper look like the group is more concerned about word count than substance. When discussing JP McDermott’s article, the group equates the lab assignments to the author’s penetration testing planning steps. I don’t think what we’re doing equates to defining goals and performing a background study. It’s a long reach to get there. The group criticizes Matt Bishop’s lack of source material for Security Plan for Red Teaming. Is this a scholarly article per se or something else? Is it ok for the Author to give his opinion? I thoroughly disagree with the group’s assessment of both Choo et al and Godefroid. The papers focused on automating very different things. They are not similar to what we are doing in the labs because of the automation aspect. Still discussing Godefroid, the group states that some of the algorithms “looks like complex formulas and codes”. Isn’t that an algorithm by definition?? I don’t understand what Hafle’s paper had to do with Godfroids. Is it that they both had colors in the title? Godfroid discusses an automation process for software testing. Hafle talks about different modes of testing. Neither actually talks about ethics. In general the literature review attempted to discuss the articles and (often erroneously) tie them to the labs but the evaluative process was missing. Is the article good? Why? I find it hard to believe that the group actually read all of the assigned material. I suggest having someone review for grammatical errors and awkward writing style. For example, Matt Bishop is a person, not an article. The group refers to him as an article repeatedly.
    In the methods section, the table format is very hard to read. I find some of the tool placement suspect. Ettercap for example. Can one tool be used attack more than one layer? One set of McCumber coordinates? You team mentions tools for anonymity in the abstract but never discusses them.
    Discussing the TCP/IP model, the group had a nice find with Stalling’s reasoning. Unfortunately I can’t verify it because no page number is listed. What do people other then Stallings think? Is there why do you think we did this exercise? Your answer about the physical layer is WEAK. The group agrees because most people say so?
    In discussing SCADA the group lists a very small set of applications. Is that all SCADA is used for? Where did you get your extensive knowledge of MODBUS? There wasn’t much sited for this section, and I had a different understanding of the data flow. In the section about DNP3, the group says that the model does not follow OSI at all but is based on an IEC standard. Where do you think the IEC got the idea for the protocol? As far as DeviceNet is concerned, does CIP exactly adhere to the top three layers of the OSI model? Are those the only three SCADA protocol stacks?
    The group’s issues section sounds like the lab objectives. Did you have a hard time with the lab in general, or are there specific issues you had in performing the given tasks?
    The group’s conclusion is painfully weak. What did you learn? Was the lab helpful at all? Were your findings in line with what you expected?

  7. shumpfer
    June 24, 2009 at 4:28 pm

    Team 1’s lab started with their abstract and describes what will be done within the lab. They then go onto the literature which they did a good job at leading from one article to the other but there was not a lot of confliction and conversation that argue different points. Such as this author believes this view and this other believes this view. How do we know which one is right, what facts are in place or are they just two different methods with one being preferred over the other? This will give the literature review more depth and raise questions by the reader. Getting people actively involved into a lab or paper will spark more thought and something may even come from those and continue a chain of new ideas. Then the team went into their methodologies and what they did within the virtual environment. This point was a little vague in the description of what and why did they use these certain tools to do the testing. It is important to let the readers know why something is being used and not another tool and for what reason. Some times it can be hard when the people working on the lab need to convey the information into a document explaining what they did. But being descriptive will help in the long run be used as evidence and create a backbone for the results given. They then go on and present their tables. The first table is good and can be followed well except for a minor error at the 8th layer of the table. The second table was hard to follow. It could have been broken down into separate tables making it easier to display across word press. Then the team explains the different protocols and does a good job breaking them apart and defining each of them some better than others. One thing that I would like to see is an example of what they are used for and what makes them a target. The team then goes on and explains their issues and the problems they had finding active reconnaissance tools to user. Overall this was the biggest issue out of all the groups is have tools that actively did reconnaissance. This asks the question is the more effective way to attack a system through a more passive approach collecting data and then attack the targeted system? They then go on to their conclusion and give their thoughts on where things lay and some of their findings. The conclusion needed to be worked on a little bit more and some of the information could have been put into the findings section.

  8. dkender
    June 24, 2009 at 4:36 pm

    I reviewed the lab report for team 1 and found a few errors. For example I believe “any king of penetration testing” was supposed to be “any kind of penetration testing”. In another sentence they wrote, “other had made models”. Should this be others have made models? There were some misspellings such as Appication instead of application. I do think they made a good point that the low voltage from the SCADA network would not likely power the device and therefore there must be a protocol stack on the receiving end to initiate the high voltage required to run the device.
    Unfortunately, due to my work schedule the past few days I was unable to furnish a more thorough review.

  9. tnovosel
    June 24, 2009 at 4:48 pm

    The abstract gave a good overview of what was to occur in the lab. The active reconnaissance tools though were not meant to provide anonymity, as this would be the job of anti-forensic tools. I was not sure what the group was getting at when the team stated “A comparison could be made to see what of the past laboratory assignment table and the active reconnaissance tools.” I assume it meant that some of the active reconnaissance tools could be extracted from the table from the previous lab.

    In the literature review section, the group did a nice job tying this lab to the previous lab and connecting both labs to the literature review for the lab via explaining the significance of penetration testing .For the literature review section, I had noticed a few discrepancies. The article Grammar-based Whitebox Fuzzing was almost completely left out of the literature review, for the supporting data only included an extreme overview distributed throughout the literature review section that briefly mentions the term fuzzing and they used codes for penetration testing. What relationship did this article on fuzzing have to some of the articles? How did fuzzing relate to the lab? The supporting information for the article, Three Different Shades of Ethical Hacking: Black, White and Gray seemed way too brief because besides covering ethics, the article explained different types of penetration testing techniques based on their coded color. I did not understand how the group associated good and evil with the different classifications of penetration testing when the team stated that “While all that the group will be learning in can be used for “evil” it can also be used for good.” When the group stated that “The entire purpose is to learn how to properly test our systems and how to protect them“, was this a reference to the article or to the lab, for there was not a transition statement to correlate the article to the lab.

    The method section gave an overview for the remainder of the lab, explained how the active reconnaissance tools were placed into the table, and explained the alignment of TCP/IP model. The method section did not mention the alignment of the SCADA protocols to the OSI and TCP/IP model.

    In the active reconnaissance table there were a few tools or methods that seemed more passive than active. Shoulder Surfing is more passive than active. Wireshark would also be more passive than active.

    In the H2H Transport layer sub section, group 1 stated “Figure 1.3 indicates that the TCP/IP H2H Transport layer satisfies the characteristics of the OSI Transport layer. Also, Figure 1.3 includes the debatable inclusion of OSI session layer characteristics.”Where is this figure 1.3 that the group mentions?

    For the second part of part 2, the SCADA table was somewhat hard to follow and appeared to have formatting issues.

    The group answered the question does the TCP/IP model have four or five layers? They concluded that the TCP/IP model should only have four layers because the Physical layer is implicitly there within the Network layer.

Leave a Reply