Transcript Slide 1
Network Security and Forensics Professor James L. Antonakos Computer Science Department Broome Community College Topics • • • • • • • • • • • • • My Teaching Goals The Networking Lab We Use Why Bother? Scenario #1: Switched LANs Scenario #2: DHCP Not Working Scenario #3: Baselining Your Network Scenario #4: Logs, Logs, Logs Scenario #5: Watch the Traffic Scenario #6: Wireless Freedom? Scenario #7: Mystery Traffic Scenario #8: Telnet DoS Attack Scenario #9: Exploring Steganography Final Comments My Teaching Goals • Get students interested, excited, and curious about security and forensics. • Show students how to use different hardware and software tools. • Reinforce knowledge from other courses. • Show students how to learn. • Increase my own knowledge by learning from students. The Networking Lab We Use Internet Cable Modem Router Managed Switch Router Located in Network Closet 192.168.1.1 192.168.1.253 COMP4 Router ` 192.168.1.251 192.168.1.98 COMP1 ` 192.168.1.108 COMP7 ` 192.168.1.107 192.168.1.150 192.168.1.245 COMP2 COMP3 COMP15 COMP5 ` ` ` ` 192.168.1.105 192.168.1.109 192.168.1.102 COMP8 COMP9 COMP10 ` ` ` 192.168.1.113 192.168.1.111 192.168.1.101 192.168.1.115 192.168.1.104 COMP6 ` 192.168.1.117 192.168.1.112 COMP11 COMP12 ` ` 192.168.1.103 192.168.1.100 Networking Lab Details • Lab is fed from a Cisco ASA firewall in network closet. • Managed Asante switch is fed from Linksys router. • Thirteen desktop PCs running Windows XP (with Linux and Windows Server partitions also). • Networked Axis video camera. • Linksys wireless access point. • Local file server. • HP network printer. • Additional Linksys router feeds small test network. Network Lab Details, Part 2 • Internet connection for lab is through Time Warner RoadRunner. • This allows us to do things that are not possible on the campus network: Capture traffic Add devices Use Administrator privileges on the lab computers Install / remove / test software Why Bother? • What are we looking for? Network policy violations Compliance violations Access violations Security violations Performance issues • Why Bother? Justify IT existence and budget Keep network running smoothly and in compliance Better informed future planning Scenario #1: Switched LANs Scenario #1: Switched LANs • What has the SwitchSniffer application found? IP and MAC addresses Machine names Operating systems Network vendors • Questions to students: How did SwitchSniffer do all this? Are we safe on a switched LAN? Scenario #1: Switched LANs Scenario #1: Switched LANs • Wireshark ran on the machine whose IP address was 192.168.1.104. • SwitchSniffer was run on the same machine so that Wireshark could capture all traffic associated with the program. • Questions to students: Why is SwitchSniffer using ARP? Where is the ARP for 192.168.1.1? Scenario #1: Switched LANs Scenario #1: Switched LANs • An ARP reply shows that an IP address is active and also returns the MAC address of the device. • Question to students: Does the time difference between the ARP request and ARP reply tell us something about the device (fast response means dedicated hardware, slow means operating system)? Scenario #1: Switched LANs Scenario #1: Switched LANs Scenario #1: Switched LANs • SwitchSniffer has used SMBs with some discovered devices to learn more about them. • The “Follow TCP Stream” feature of Wireshark shows what SwitchSniffer learns via the SMB session. • Question to students: Why does SwitchSniffer use SMBs with some devices but not all? Scenario #1: Switched LANs Scenario #1: Switched LANs • We examined the SwitchSniffer program using the Strings utility. • We found a large list of NIC Vendor names and their associated 24-bit MAC address ID. • SwitchSniffer used the MAC address from the ARP reply to search its internal database. Flagged vendor IDs caused a SMB session to follow. Scenario #1: Switched LANs • What did the students learn? Not really safe even on a switched LAN. How to use Wireshark. The power of the ARP protocol. How to use the Strings utility. Overall, one way to investigate the operation of a network-based program. Scenario #2: DHCP Not Working • A student in the lab indicated he could not get to the Internet. • I used IPCONFIG to examine the IP address of the student’s computer. It was 169.12.75.4. • Seeing the 169, I assumed there was a connection problem and checked the network cable, and restarted the laboratory switch and router. No luck. Scenario #2: DHCP Not Working • Then the student told me something interesting. • He said “We did a router lab in Advanced Networking today.” • Being familiar with the router lab experiment, I immediately checked the TCP/IP Properties of the network connection. Scenario #2: DHCP Not Working Scenario #2: DHCP Not Working • The “router lab” instructor used a static IP address similar to the auto-IP address assigned when DHCP is not working. • The student forgot to re-enable DHCP at the end of the lab experiment. • What the students learned: Users will make changes to their system if they are able. Do not make assumptions about system properties. Check settings whenever possible. Scenario #3: Baselining Your Network • A baseline provides a “picture” of your network under normal conditions. • Depending on your network, the baseline may need to be established over a long period of time. • Deviations from the baseline indicate incidents that may require further attention. Scenario #3: Baselining Your Network Scenario #3: Baselining Your Network Scenario #3: Baselining Your Network Scenario #3: Baselining Your Network Scenario #4: Logs, Logs, Logs • Logging should be enabled on firewalls, routers, computers, and other loggable network devices. • Logs must also be examined or reviewed on a timely basis. • Depending on the log, it may not be easy to locate suspicious information. Scenario #4: Logs, Logs, Logs Scenario #4: Logs, Logs, Logs Scenario #4: Logs, Logs, Logs • What the students learned: The right software makes log analysis easier. Even with the right software, reviewing the log results requires time and patience. Scenario #5: Watch the Traffic • Here is captured Skype traffic even with no phone conversation taking place. • Once the conversation begins, there will be 25 messages/second in each direction carrying 320 bytes of digital voice information. • Adding Skype video to the call increases the required bandwidth. • Multiple users engaging in Skype can quickly eat up a significant portion of available network bandwidth. Scenario #5: Watch the Traffic • Here we have ICMP messages flooding the network from a computer infected with Nachi. Scenario #5: Watch the Traffic • Here we have ARP traffic using some interesting Destination addresses. Scenario #5: Watch the Traffic • These strange Destination MAC addresses are designed to locate computers whose network adapters are running in Promiscuous mode (ie: they are sniffing traffic). Scenario #5: Watch the Traffic • What the students learned: Network traffic needs to be examined. Even legal traffic can cause problems on the network. ARP traffic can be used for malicious purposes. Malicious code may use simple messages (ICMP, ARP) to locate victims. It is possible to discover network adapters running in Promiscuous mode. Scenario #6: Wireless Freedom? • There are plenty of tools available that will locate and identify wireless networks. Scenario #6: Wireless Freedom? • Finding wireless networks is now a built-in tool. Scenario #6: Wireless Freedom? • I take my students on a war driving exercise each year. We take note of the number of wireless networks discovered and how many are secured. • We compare the results with the previous year’s results to gain appreciation for the yearly growth. • We also “war-walk” around campus, looking for rouge access points to report to the Computer Center. Scenario #6: Wireless Freedom? • At the same time, we take note of the signal strength as we move from room to room and building to building to gain an understanding of how the building’s construction affects signal strength. • Our campus provides unsecured wireless access in all buildings. • All wireless traffic is pushed onto “VLAN-10” where it is connected directly to the Internet with no access to college servers or other networked devices or services. Scenario #7: Mystery Traffic Scenario #7: Mystery Traffic • Things the students picked up on: The source port number keeps increasing by 1. The destination port number bounces around seemingly at random, but all in the 7000 range. The data area of the UDP datagrams contain an increasing integer sequence ([100], [101], [102], etc). Why all the ICMP messages? Scenario #7: Mystery Traffic • Taking a closer look at the destination port numbers, we have: 7099 7100 7032 7047 7117 7115 7114 7047 7098 7105 7110 7013 Scenario #7: Mystery Traffic • First we remove the 7000 bias on the port numbers. • The Value numbers are actually decimal values for ASCII codes. • The network traffic represents the command cd /usr/bin Port Value ASCII 7099 99 c 7100 100 d 7032 32 7047 47 / 7117 117 u 7115 115 s 7114 114 r 7047 47 / 7098 98 b 7105 105 i 7110 110 n 7013 13 <cr> Scenario #7: Mystery Traffic • I explain to the students that this is one way to hide commands sent from one computer to another. • Question to students: What is required on the destination computer in order to be able to receive commands in this way? Scenario #8: Telnet DoS Attack • During registration week, faculty were not able to Telnet to the registration server, or were disconnected during a session, or experienced slow response from the server. • The cause of the trouble was an external DoS attack against the Telnet server. • The short term solution involved turning off access to the Telnet port from the outside. • The long term solution involved switching to secure Telnet and FTP from off campus. Scenario #9: Exploring Steganography • Steganography is a way of hiding one form of information inside another. • In Greek, the word stegos means “covered writing.” • It is not obvious that anything is hidden. Scenario #9: Exploring Steganography • What can you hide? Practically any type of digital file can be hidden inside another digital file. Example 1: A Word document can be hidden inside a JPG image. The image looks normal to the naked eye. Example 2: A text file is hidden inside a WAV file. The WAV file sounds fine when it is played. Scenario #9: Exploring Steganography • Do you see anything? Scenario #9: Exploring Steganography • Where is the information? Scenario #9: Exploring Steganography • Here are the results after adjusting the pixel color. • This is not a very difficult process to crack. Scenario #9: Exploring Steganography • Do you see any differences? The JPG image on the right contains a hidden file which was put there using a program called JPHS (JPG Hide and Seek). Scenario #9: Exploring Steganography • If every pixel was the same the result of subtracting the images would be an all-black image. Scenario #9: Exploring Steganography • The second image actually contains a 1400-line C program for a video game. Scenario #9: Exploring Steganography • What the students have seen: You must know where to look in a file to find hidden information. You must know the process used to hide the information. You must know some strange math to understand how some steganography techniques work. You need to know a lot about computers and file types to be able to investigate steganography techniques. Final Comments • To perform true incident response and network forensics, it may be necessary to have access to all network traffic, or at least all traffic concentrated in the problem area. • The amount of traffic exchanged on a business or educational network may be difficult to store due to lack of resources (ie: several TB each day). Final Comments • Some intrusions are not discovered until days, weeks, or even months after they have taken place. • Some questions to answer: Where do you tap into the network to capture traffic? How long do you store the captured traffic? How often do you review the captured traffic? What changes should be made to prevent future problems? Thank you! Professor James L. Antonakos [email protected] (607) 778-5122