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

12 thoughts on “TECH 581 W Computer Network Operations: Laboratory 2, Team 5”

1. Team five has presented a complete and concise lab that details the procedure as was expected by the lab design document. A lab that meets almost all of the requirements as per the syllabus and lab design document. The abstract meets the requirements of the syllabus as for length, and does give an overview of what will be accomplished in the lab. The literature review is more cohesive then any of the other labs presented, including team two’s literature review. The literature review does more than just list articles with an explanation of the article. There is a high level of synthesis between the articles, but even though this is the case, it still reads slightly like a list of categories instead of just articles. The methods section lists all of the tasks that will be completed in the lab, and is rather long and complete, but I still question it as showing a scholarly strategy and technique for completing the lab. The methods section appears to include information that might somewhat be better served in the findings section. Team five appears to assume the five-layer TCP/IP model over the four-layer without any reason over that Comer and Stalling say that the TCP/IP model might be five layers instead of four. I disagree with this as before, until the DoD changes the model, the TCP/IP model is four layers. This team also does seem to not give a reference to source anonymity other than in their conclusion, and even than that reference is just two sentences long, they also do not provide any reference to professor Liles blog as a source for those two sentences which calls the completeness of their lab. Team five shows an active recon table that while seemingly balanced does not agree with other teams at layers other than 3, 4, and 7. This might be an omission on the part of team five, and it might also suggest a deeper understanding than the other teams on active recon. The SCADA tables shown by team five are very easy to read, and are broken into separate tables for each SCADA protocol making them easy to get information from, and form possible attack vectors. Team fives tables on MODBUS and RP750 agree with team two’s tables on the same. As I stated before I disagree with their almost assumption of the five-layer TCP/IP model, however I do agree with their SCADA tables in their entirety. Team five’s approach is different than team one’s approach, as well as team fours approach. It does appear to align with team two and team three’s approach to this lab. I do not believe team five could provide much improvement over that which has been already stated. Team five’s methods do not however require improvement. All in all team five has presented an answer to lab two that is efficient, mostly complete, and represents an understanding of the requirements of the class and lab that is well developed. However it was not without its room for improvement.

2. Once item I noticed right away was that this group had a much more cohesive literature review. It did not sound like a list like the majority of the other group’s la reports did. Even though the literature review was more cohesive, not all of the questions that a literature should have were answered. The second methodology paragraph was long. I feel that it should have been broken up into more paragraphs to properly convey the different models that were being compared to each other as well as the OSI 7 layer model and the TCP/IP model. The group did not put the tables created into the findings section. I feel that the table belongs there more than at the end for a more cohesive paper. In addition to that, I think that the discussion of the SCADA models as well as a lot of the methodology section should be put into the results section since it is a result of research. If the group had done this, I feel the lab report would have more cohesive. It seemed to go from place to place and one could tell that different people wrote different parts of the lab report.
   The group’s table was well structured except that the kinetic layer had no tools in it. Does the team think that there are no tools for this layer, or is the table incomplete? Like the last lab report from this group had a fantastic layout for the table, making it much easier to read than most of the other groups’. I like having one layer with all of the tools in it. It is much easier on the eyes because there are fewer words. The group discussed the why the TCP/IP model could have 4 or 5 layers. There was not a real clear answer as to what side of the debate the group was on. They did include all 5 layers in their comparison tables, but never stated why they chose what they did. Overall the group wrote a much better lab report than they did for the first lab report. I would just like to see more cohesiveness in future lab reports and maybe sectioning out tables and then discuss them right after in the results section.

3. Team 5’s abstract was well written and gave a solid definition of what active reconnaissance is and it can be used by hackers. It also met the requirements detailed in the syllabus. They explained how the tools used for active reconnaissance will fit into the OSI and TCP/IP module and their McCumber cube hierarchy. There lit review was well organized and encompassed what the authors were trying to express in their writings. I thought the way team 5 put the tables together by grouping all the tools that share the same OSI layer and McCumber cube was good. This made the table easy to follow. I didn’t see any tools in layer 0; where as some of the other groups did indentify at least a few tools. The method section was very detailed but maybe a bit too long. I agree with their findings issues and conclusions. Overall the paper and lab was well done.

4. In this group’s abstract they introduced the idea of active reconnaissance but did not define what it was. They also introduced anti-forensics and how it can help in hiding the attacker but also at the same time can be unreliable. They also talk about making the active recon tool table and aligning it to the OSI model and McCumber’s cube. The last part of the abstract talks about the comparison of the TCP/IP model and SCADA models. They mention that there is a risk when SCADA networks are merged with TCP/IP networks. This also leads into the ability to study ways to probe TCP/IP networks to also probe SCADA networks for information. Next the group goes into their literature review. The team goes about literature different from the rest of the groups. They do not talk about each individual article, but incorporate each article into an explanation of active reconnaissance in red teaming. The team does a good job in intertwining how each of the articles in this lab with each step in the lab. They do a great job in how they both relate. The review also gives a brief explanation of what each article’s theme is about in a circuitous way. The team did not though talk about the methodology, research question, supporting data, or errors or omissions of each article. Next the group discusses their methodology for this lab. They begin by explaining how they will use various active recon tools to gather information about a network. They also explain how they will use Tor to cover their tracks. They do a nice job of explaining the tools that they will use to do the attacks and how they will use them, but it almost sounds like they are going to be limited on the number of tools they are going have at their exposal. They also only very briefly talked about the table that they built for the active recon tools. Next in the methodology the group talks about the second part of the lab. I think that they went into too much information about the protocols at this point in the paper. The team starts explaining the MODBUS protocol and how it can be compromised and they also start talking about other SCADA protocols in detail also. This part does not define the methodology of that section of the lab. The description of the SCADA protocols should have been in a part of its own and should have gone on describing the different layers of each of the SCADA protocols. The group also forgot to talk about the other SCADA protocols they give in the table at the end of the lab paper. Next the group talks about their findings. The group mentions that the active recon tools focus on layers seven, four, and three of the OSI model. They also mentioned how they did scans to gain information on the MAC addresses of the computers and that they had troubles running their scans through the Tor network. As for the findings in the second part of the lab, the group talked about the SCADA protocols fall within the OSI model and how creating the tables for the SCADA protocols gave the team a better insight on how to attack SCADA networks. Next the team explains that they had some problems with Backtrack working properly in VMware and how they solved the problem. Last the team concludes the paper by explaining how active reconnaissance can very risky. They mention that it is better to use compromised machines to do the dirty work than trying to cover up your tracks. The team also mentions how the articles were very insightful in giving them a better understanding of how each tool fits into the OSI model and McCumber’s cube. In the last part of the conclusion the team talks about how SCADA networks are becoming more incorporated into the TCP/IP network and the dangers of this. They mention that more security analysis needs to be done on SCADA hardware and software to prevent these security risks.

5. I find this lab write up to be very well assembled and researched. Not only is the literature review remarkably clear and concise, it is written very ‘smoothly’ in that issues directly related the lab are integrated and discussed without any discernable change of tone or topic-very nice. I also found the description of the ‘experiments’ done with the tools very interesting. I would judge the tool listing to be nearly impeccable, with perhaps one small contention which I shall discuss later. The discussion of SCADA protocols was generally well done: I thought the concise and to-the-point discussion of the different aspects of SCADA to be appropriate. I feel both the ‘Findings’ and ‘Conclusions’ section to be well considered. I also appreciated the brief discussion of problems and issues encountered in the lab.

   A small number of minor flaws were present in this write up which must be mentioned. I thought the second paragraph of the ‘Methodology’ section, the one which discussed SCADA, to be poorly formatted. This large chunk of information would have been greatly improved in presentation by breaking it up into smaller, internally consistent paragraphs. As it is now, it ‘reads’ roughly, and has all the characteristics of the classic ‘run-on’ paragraph denounced by composition instructors. This is an issue easily corrected: something to consider for the next lab write up.

   Additionally, I must discuss the inclusion of ‘Solarwinds DNS/Whois Resolver’ among the ‘active’ reconnaissance list. According to the description (via the link helpfully provided) I think the tool to have ‘extremely’ limited active reconnaissance capabilities ( the ability to ‘ping’ a host to verify that it is up) with the much greater emphasis on what I would judge to be ‘passive’ data gathering via DNS queries. I cannot fault this group technically for including this tool, as it does in some regard engage the target network, put if the only ‘active’ functionality is a ‘ping’ variant, does it really belong in OSI layer seven? I suggest, ‘despite’ this tools name, it probably belongs in layer three or four. This is a relatively minor criticism, but I think it serves well in demonstrating the ambiguities present in classifying some of these tools.

   Finally, I wish to discuss some of the more interesting findings presented. I found the experiment with Tor a very thorough touch, though I noticed that the ‘Conclusions’ section asserted “using proxies or Tor provide[d] unreliable results,” yet any recounting of using a ‘straight proxy’ (which is certainly different than Tor) is not present. Did you try a simple proxy, or are ‘Tor’ and ‘proxy’ being considered the same thing in this statement? In my opinion, Tor only serves the purpose of providing privacy to the public at large, to those who have no other recourse: a truly malicious attacker will not worry about the legal consequences of creating privately controlled proxies by nefarious means. These illegally controlled private proxies are ‘much’ more desirable to a malicious attacker due to the fact that they are effectively under his complete control. It is also true that these illegal (and unwilling) proxies can be expendable in an attack, so complicated encryption and routing techniques need not be used-almost certainly assuring greater reliability than the Tor network. A nice experimental touch, though, and I would be curious to see further results in this area of inquiry.

6. Team five starts with a concise abstract. Unfortunately it goes down hill from there. The team’s Literature review says very little in spite of being verbose. You relate the articles back to the lab, but you really don’t review them in depth, and you don’t evaluate. Did you cover all the articles? It feels like something is missing. There are two really nice paragraphs at the end of the literature review that don’t fit with the rest of the section. They might make a nice introduction, or beginning to the methods section. Likely they should have been part of the methods section, since this is the only place the group ever discusses TCP/IP. I don’t follow the discussion of SCADA at all. You talk about upper and lower layers, but don’t really go into detail. It doesn’t make much sense. Tell me about each protocol and how the layers work together. Compare it in detail to TCP/IP or OSI. It would have been nice to see all the SCADA protocols in one table. Did you look at any other protocols? Did you ever decide how many layers are in the TCP/IP stack? What is the evidence? The results section as well as the conclusion is also thin. The only thing I got out of reading the lab is that TOR and proxies didn’t work well with active scanning. Did you try slowing the scan? Give me more detail about everything.

7. I believe this was overall a well-written lab report. I found it interesting that they discussed using an IP reflector as part of their surreptitious active reconnaissance. I also think that their explanation for the need to include SCADA in their network testing is very good.
   Unfortunately, due to my work schedule the past few days I was unable to furnish a more thorough review.

8. I reviewed the lab report for Team 4 and found that I agree with most of it. I do think that needed to take the time to proofread the document before submitting it. They would have also done well to run spell check grammar check.
   Unfortunately, due to my work schedule the past few days I was unable to furnish a more thorough review.

9. I think that group 5’s write-up for lab 2 was adequate. The abstract for this lab was very good. The literary review was adequate. Group 5 chose to write the literature review as one big comprehensive review, which is good. However, the group really did not discuss how the reading related to the lab, and did not discuss whether or not they agreed with each reading. It seemed as if the literary review was mostly a summary of all of the readings. All of the citing for the literary review was done well. The table containing the penetration testing tools was adequate. More depth could have been put into how these tools are actually installed. What if you needed to make your own Live CD or install these on a computer that BackTrack is not compatible with? I think the group could have gone into more depth about why they chose the 5-layer TCP/IP model. When I say “more depth” I mean they should have indicated what which model they chose and why. They simply used the 5-layer model in the chart and did not discuss any of the possibilities for a 4-layer model. What about the DoD model or the 5-layer model? How are these not correct? Also, do these layers match up exactly with the OSI model? Or is it fuzzy where layers like the session and transport layers meet? When dealing with SCADA, what about the Kinetic layer? When dealing with the DeviceNet protocol, what about the Pseudo Transport Layer? Is it really its own layer or does it exist in another layer? The conclusion was very comprehensive and well done. However the paper over was difficult to read because of the large paragraphs with no spacing to indicate different topics.

10. The formatting for the laboratory report for team five was somewhat hard to follow for the majority of the data was lumped underneath the methodology section. Consider putting more section heading and transition statements into the team’s reports.
    In the abstract, team five gave a definition of active reconnaissance, which they stated as” a method used by attackers to footprint a remote system by actively probing the network for information and getting results back. “The team also gave a general overview of the laboratory assignment.
    In the literature review section, team five appeared to be missing the supporting data for the articles or relate the articles to each other .The team appeared to tie the themes of the articles to red teaming and penetration testing. The team did relate the articles to the laboratory assignment. Within the literature section Team five also went into their discussion of the TCP/IP model. Team five sided with those who think the TCP/IP model should be comprised of five layers. The literature review section of team five differed from the other groups in that they described the relationship between penetration testing and SCADA devices. Team five stated” Because so many of the tools used in penetration testing and active reconnaissance operate in the network layers of the OSI model they can be applied to discovery and exploitation of SCADA networks as well. “The team went on to say that SCADA devices should be included in attack trees and test planning when conducting a penetration test.

    The methodology section gave an overview on what was to be done in the laboratory assignment and was a catch all for all of the team’s supporting data. Team five described what they planned to do in their virtualized test environment by using tools such as SolarWinds MAC Address Discovery, combined with Ping Sweeps and port scans using nmap to determine the number of hosts on a designated network, their IP addresses, and an approximation of why type they were based on the ports they had open.

    In the SCADA protocol section within the methodology section, team five described the layers of the MODBUS, DNP3, and DeviceNet SCADA protocols. The team did not describe the layers of the MODBUS+ and RP570 SCADA protocols, which were aligned later on in the laboratory report.

    In the findings section, group five somewhat described their test environment. Team five experimented with Tor for anonymity purposes, but the team concluded that the tool was proved slow and unreliable.
    In the issue section team five stated that they had problems with the BackTrack 3 VM image provided by the BackTrack team which had an older version of VMWare Tools loaded in it which prevented networking from functioning properly. However, team five did say they were able to overcome their problem via fixing an installation script.

    In the conclusion section, team five concluded that any attacker who used active reconnaissance would be better off running the attack from a compromised machine, which would somewhat solve the anonymity issues with active reconnaissance.

11. The team’s abstract is clear and they identify everything that is they are going to discuses in this lab. They do a good starting out with the originals of red teaming and the principle behind it. Agreed, that define goals are important part when conducting projects such as penetration testing. The team talks about different methods to obscuring your location using tools such as Tor and IP reflector. Another place which the team may want to check out is http://www.covermyass.com which will similar to Tor and IP reflector. The team then goes on to talk about SCADA. Overall the team does a good job covering the reading. They go into great detail under there methodology. They mention several tools such as Solar Winds MAC Address Discovery for actively examining network surroundings. They also mention combining tools such as with the Solo Winds with Ping Sweeps and port scans. This method could be dangerous because IDS systems could recognize several packets going through the network which can raise suspensions.
    The team mentions having problems with Backtrack 3 VM image they received from remote exploits is good information to know. They had an older version of VMware tools which simply is updated using VMware workstation. Perhaps another method of getting network tools to function is using the shell to assign the interface with a static IP address. Without more information on what they had problems with this may or may not be true.
    The groups charts were very clear and well put together.

12. I agree with the critiques of the SCADA section of the methodologies. After re-reading, I think a good portion of that belonged in the literature review.

    @mvanbode – The kinetic layer was intentionally left blank, it would’ve been better to fill it with “n/a” or something similar to convey this. We struggled to define what it truly meant to actively probe something that was kinetic.

    @gdekkerj – The DNS tool was included on the premise that DNS data ‘could’ be hosted on premise and subject to more stringent monitoring on the part of the target. Caching in the DNS system may limit the effectiveness of this defensive strategy and needs to be taken into account both by attacker and defender.

Comments are closed.