Network Security and Forensics

1. Network Securityand Forensics Professor James L. Antonakos Computer Science Department Broome Community College

2. 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

3. 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.

4. The Networking Lab We Use

5. 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.

6. 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

7. 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

8. Scenario #1: Switched LANs

9. 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?

10. Scenario #1: Switched LANs

11. 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?

12. Scenario #1: Switched LANs

13. 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)?

14. Scenario #1: Switched LANs

15. Scenario #1: Switched LANs

16. 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?

17. Scenario #1: Switched LANs

18. 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.

19. 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.

20. 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.

21. 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.

22. Scenario #2: DHCP Not Working

23. 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.

24. 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.

25. Scenario #3: Baselining Your Network

26. Scenario #3: Baselining Your Network

27. Scenario #3: Baselining Your Network

28. Scenario #3: Baselining Your Network

29. 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.

30. Scenario #4: Logs, Logs, Logs

31. Scenario #4: Logs, Logs, Logs

32. 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.

33. 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.

34. Scenario #5: Watch the Traffic • Here we have ICMP messages flooding the network from a computer infected with Nachi.

35. Scenario #5: Watch the Traffic • Here we have ARP traffic using some interesting Destination addresses.

36. 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).

37. 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.

38. Scenario #6: Wireless Freedom? • There are plenty of tools available that will locate and identify wireless networks.

39. Scenario #6: Wireless Freedom? • Finding wireless networks is now a built-in tool.

40. 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.

41. 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.

42. Scenario #7: Mystery Traffic

43. 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?

44. Scenario #7: Mystery Traffic • Taking a closer look at the destination port numbers, we have:

45. 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

46. 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?

47. 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.

48. 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.

49. 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.

50. Scenario #9: Exploring Steganography • Do you see anything?