Network Security Lab (NetSecLab) ‏ 2016

1. COMMUNICATIONS SYSTEMS CENTER Network Security Lab (NetSecLab)‏2016 Network Security Lab (NetSecLab)‏ by Communications Systems Center (CSC)

2. Outline • History • Components of NetSecLab • Team Boxes, Victim Boxes, Traffic Generator • Competition rules • General Rules, Scoring Rules • Logistics • Reports, Internet Access, Lab Access, HDs, Team Captains • Suggestions • Summary • References

3. History • Developed by • Chris Lee (CSC alumnus - ShadowServer) • Dr. Selcuk Uluagac (CSC alumnus – Fla. Int. U.) • Held each semester of 6612 since Fall 2003 • A friendly in-class competition • 2016: • Where: KACB 2446 • Preparation (lab available): April 6 • Competition Day1: Apr 6, 9-10 a.m. • Competition Day 2: Apr 8, 9-10 a.m.

4. Teams • A list of team members, and the initial team leader will be posted on the class Web site. • Each team has a secure T-square site: • “NetSecLab - Team X” where X in the Team number. • All team communications should be on the T-square site, in the “Chat Room”. Files should be posted in Resources. These documents are only accessible by the team members, professor, and TA.

5. Lab Architecture • Competition in a private network • No outside connection allowed (!!!)‏ [except DL's]. • Any data you want should be brought other means .. • Primary subnet 192.168.100.0/24 CDL Remote Team

6. Teams Boxes-General • O/S Choice • Install Linux OS from provided CD or Flash Drive. Required services will be preinstalled. Do not install another or later operating system. • The supplied system has backdoors installed. Find them, disable them, use them. • Assign any IP address during the preparations • Configure to use the 192.168.100.0/24 network. • We will give your IP address before C-Day 1 and 2. Know how to change it. • Create a user account called “customer” • Used primarily by the traffic generator • Give the password to us and don't change during the competition day. • You should have logins for each team member as well. Let them choose a password. • Patch and harden your box (i.e., with the team's hard drive)

7. Team Boxes-Services • Services needed:Port #: • SSH 22 • Telnet 23 • SMTP (*) 25 • HTTP 80, 443 • MulticastZoo (Java provided) 446 • XMPP/Jabber (Open source) 5222 • MySql (**) 3306 • PhpMyadmin/pma Notes: (**) MySQL does not have to be available via the network, but the contents should be accessible via the webpage interface, phpMyAdmin. (*) SMTP should not relay, but should deliver email from anywhere to users on the box. The referee's "Traffic Generator" must be able to continually access these services. The same username ("customer") and password must be usable for these services, including MulicastZoo.

8. Team Boxes - Cont. • All services must: • be on the common ports • allow a valid login (correct username, “customer”, and password) from any computer on the network • The Traffic Generator will test this continuously. • be maintained during the competitions • "customer" must be able to upload and download files (using scp, sftp, or ftp), edit them with ed, vi, pico, sed, awk), access the bash command shell, and execute programs (as "customer"). • You must protect your host by limiting permissions and "chrooting". Creating VM's is not allowed (except can be used to install offensive applications). • No firewall may be used.

9. Victim Boxes • Vulnerable prey machines • With different old O/Ss and different old services running • They have no active defence mechanism • Points for exploiting (getting the password file). • They will be up during the Contest Day 1 & 2 • Be prepared for older, unpatched, versions of Windows and Linux.

10. Traffic Generator • Collection of traffic generating scripts. • Randomly connecting to team and victim boxes as the “customer” account. • Login, create files, read files, delete files, ssh or telnet from your box to other boxes ;)‏ • Do not attack the Traffic Generator. It may strike back. • IP's higher than 192.168.100.200 should not be scanned or attacked.

11. Competition Rules • Attackers should not change victims' passwords unless needed for a compromise, and then it should be reset back to the original password. • No denial of service attacks, rate throttle your nmaps (no -T4 or higher)). • Services on the team and victim should remain up and active throughout the competition. Services should not be turned off by the defender or the attacker (unless momentarily necessary for a compromise or defence). The service should still be available for legitimate use. • Absolutely no deleting of logs (yours or others). They are needed when writing the report, and for umpires to verify claims. • No arp poisoning. It is not needed since we will use an Ethernet hub. Since we have many teams on one hub, we cannot toleratre teams doing arp poisoning. • No DoS attacks. .

12. More Rules Do not break any GT rules. For example do not steal GT passwords, GT email, T-square passwords, etc. Do not interfere with the Remote Teams box or hard drive. It may be necessary to leave their box running unattended. In the lab overnight. Other teams are fair game. Use “nmap” sensibly: “nmap” will take weeks to scan 65,535 ports on 255 IP addresses, on a congested HUB network. Scan first the IP range, using one port that you know should be open (-p 21). Turn off pings (-Pn), like: nmap -p 21 –Pn -sS –T3 192.168.100.1-199 Once you know the active IP addresses (e.g., 19, 25, 67, 92), scan only them and ports where you have a possible exploit: nmap -p 21,22,23,25,80,110 -P0 -sS -T3 192.168.100.19,25,67,92 NMAP does not always give perfect results, especially on a congested hub network where many packets are being lost. Sometimes you learn more and faster with a passive sniffer (e.g., dsniff). Do not run NMAP at a higher speed than normal . This is against the rules, and you will DOS yourself more than anyone else.

13. Scoring Rules • Points are assigned by the level of compromise that each team is able to perform to the network. • Efficiency and creativity are given bonuses (but it's impossible to outline them here). • We want people to think up and implement new ways of exploiting machines. • We will reward such efforts on a case by case basis.

14. Scoring Rules-2 • Gaining user access to a victim box (50 pts.)‏ • Gaining user access to a team box (50 pts.)‏ • Gaining root access to a victim box and retrieving the password hash file (250 pts.) • Gaining root access to a team box and retrieving the /etc/shadow password hash file (250 pts.) • Modifying a team's Web page (250 pts.) This must be verified by a TA. • Mapping services, ports 1-2000, (50 pts. per any box) • OS detection (100 pts. per victim box)‏

15. Scoring Rules-3 • Time bonus: 100 being fully operational by 9:10. • After bonus: successfully cracking a password (100 pts. per password). • You can continue to crack passwords up until the turn-in deadline (assuming you have captured a password file). Victim boxes will have a crackable password • Penalties: • Not having services up during competition (-100 pts. per service each day, except -500 pts for no MulticastZoo)‏ • Your box becomes compromised (rooted), (-100 pts,/team per team each day)‏. Either password file stolen or Web page modified.

16. Logistics - Klaus 2446 • Installation CDs or a Flash drive will be provided a week before the competition. • External HDs will be distributed to each team captain • Use the keys in KACB 2446 to lock the drive in place. • Look for the light to indicate they are locked in place, and usable. • Each team’s computer will be labelled. • Please remember there are other classes utilizing the same space. Team boxes will be labelled during the competition. • A laptop may be connected on 10.0.0.0/24 to eth1 • Do not connect the Team Computer or an attached laptop directly to the Internet (or GTwifi) during the exercise. Some Ethernet cable plugs in the lab have broken tabs and may slip partially out. Check the plug first if you lose the network.

17. Reports-General • The report is the main portion of the project (and the part that most affects the grade). • The reports are informal and do not need extensive polishing. • We basically want to know • how you hardened your box, • what scripts you developed or used for attacking, • what references (people, Websites, books, independent research, etc.) you used to learn about the exploits, • a description of the effectiveness of your defence and offence during the lab. There will also be a "Scoring Spreadsheet" to fill out.

18. Reports-Format • Please write briefly and clearly. A clear list with a few words of explanation are better than verbose rhetoric. • Introduction (list of team members)‏ • Hardening Techniques • Attacking Techniques • Technique Analysis (what worked and why, if known) • Game Point Justifications • Team Member Significant Contributions • References to useful Web sites, books, articles, etc. • Appendix (if necessary) • No class period is available for a face-to-face editing session. Use the Team Chat Room or Wiki for collaboration. Email the report before class on Monday. Build the report as things develop.

19. Reports-Technique Sections • In the technique analysis section, you should give • Give justifications for the points you earned in the lab • Discuss how you found an exploit, how you used it, • Present some proof that the exploit worked like the shadow password file or a screenshot. Or get a referee to verify during the exercise. • Give us reasons to assign as much partial credit as we can. • If something did not work, please give us your best guess why it did not work. We want to learn from your experiences!

20. Competition Days • The a representative from each competing team should be present by before 9:00 a.m. • Hopefully, by 9:05 we should have all the boxes up and the referees have had a chance to verify your setup and fix any problems. • At this point we will start the show and allow the attacking teams to start their scripts. • Each attacking team's representative should be give the announcer constant updates, preferably by passing a note. • When an exploit is successful, the representative should alert a referee immediately so that it can be verified. • The competition will end at 9:55. • The teams are then expected to stop all their attacks, clean up, and save their logs.

21. Turn-ins • Reports • Please send them via email to us before Monday April 20. • Should not have any large sections of source code or log files or anything else that would belong in an appendix. • Hard Disks due in class on Monday April 20. • Create a gzipped tarball under /root home directory: • called: netsec-09spring-teamnumber.tar.gz where team name is your team number. • Include a README file describing the contents of the tarball • (this should be about the same as the 'appendix' that you will add to the report)‏ • The tarball should contain files of interest to the lab including: • log files, exploit source code (no binaries please), tcpdump files, and anything that you would like to reference from your report for proof. • Change the root password to “rootme”.

22. Final Suggestions • Start early • Time is limited! • Automation • Scripts • Have attack and defence strategies for your team • Nice delegation of responsibilities • Communicate with team members. Use the Team T-square site (Chat Room, Resources, Wiki, Email (sign email sent from site) • Build the report before and during the exercise.

23. Important Dates • Preparation Interval • April 4 - April 17, 2016 • Competition Day 1 • April 18, 9-10 a.m. EDT, KACB 2446 (DL by VNC) • Competition Day 2 • April 20, 9-10 a.m. EDT, KACB 2446 (DL by VNC) • Reports Due: Friday April 22 midnight EDT • In-class Presentation of Results by Prof. – Monday April 25. Team Representative should be prepared to discuss highlights of the experience.

24. References.. • http://users.ece.gatech.edu/~copeland/jac/6612/netseclab (link) • Start with Google, Wikipedia • Chris P. Lee, A. Selcuk Uluagac, K. Fairbanks, and J. A. Copeland, ”The Design of NetSecLab: A Small Competition-Based Network Security Lab”, IEEE Trans. on Education, vol 54, pp 149-155, 2011.

25. Questions ?