10 replies to this topic

[TheFunk]

This March is the annual CCDC (Collegiate Cyber Defense Competition). If my school makes it past the preliminaries next week we'll be competing in the regionals, meaning we'll be up against schools from a big chunk of the East Coast. I've heard that the competition involves securing several different servers, running different services (e.g. a mail server, a DNS server, an FTP server, supposedly we'll be dealing with a Splunk and a Hadoop server). The catch is, teams are only given a very tiny window of time to secure the machines, before a team of trained network pentesters/ethical hackers begins to attempt exploiting vulnerabilities with their systems. My team has come up with some good ideas about what to do, and when to do it, but if anyone has any input, it would be greatly appreciated. Also, our team is allowed to use resources from a publicly available site during the competition. That means that any information provided here can be used, even during the competition.

To the best of my knowledge the main OSes we'll be dealing with are:
-Ubuntu Server
-Fedora
-Windows Server 2008 (or 2003)
-Windows 7
-and perhaps a lonely Windows XP machine sitting in the corner somewhere, crying out for attention and asking for an upgrade from the horrific state that is: "Service Pack 2". (I shudder at the thought)

[tekio]

Before the competition figure out the exact versions of the servers to be installed. Get very familiar with them, and any known security flaws. Practice running drills till you guys get it down, and could do it in your sleep in under 5 minutes.

[TheFunk]

Before the competition figure out the exact versions of the servers to be installed. Get very familiar with them, and any known security flaws. Practice running drills till you guys get it down, and could do it in your sleep in under 5 minutes.

I wish we could, but we were told we won't know details like that until the day before the competition. I'd like to say what we already have planned but I don't want our agenda to be public, so I might wait until tomorrow and mention our plans on the IRC channel, or I could PM anyone interested.

[Powermaniac7]

PM some info sounds interesting. At first for some reason thought you meant you were given a blank computer with all the hardware necessary and you had to install a secure operating system onto it that you programmed xD...Was thinking that would be easy program some useless piece of shit that is basically passworded and the password only gives you access to a terminal with possibly another password to enter that which requires a particular formula to be known to know the password...Hmm a infinite loop of passwords that are generated by a formula hmm...Geometric or Arithmetic Sequences or maybe something like the Fibonacci Sequence would be good and even harder to work out...

Anyway...

[army_of_one]

I'd cheat. There are advanced technologies developed for Linux (heck, even Windows) that can greatly reduce exploitation possibilities. I'm big on risk mitigation b/c I spend most time researching "high assurance/robustness" systems: systems that can resist prolonged attack by sophisticated, well-funded entities (NSA definition). Turns out, there plenty you learn studying these systems that can be applied in COTS. Examples include minimized TCB, control of dataflow, carefully mapping requirements to design to implementation, minimizing implementation complexity, pen testing, etc. So, what comes to mind when we discuss this example? Quick 5 min brainstorming follows.

For Linux, could try to get a copy of SecVisor. It's mathematically verified to prevent kernel-level injections. Then, add to the kernel executing only signed code, comparing existing processes against whitelist, detecting file modifications, and MAC (could use SMACK or Tomoyo to avoid SELinux-style complexities). Do the regular checklist steps for the system and specific server. Hackers will have a hard time exploiting this box. For Windows, might use application level virtualization so you can do the above with a precreated (or quickly created) Linux VM, depending on the rules. Technology like TILT can run with an application to detect illegal dataflows with minimal overhead. You might also use virtualization to run the WIndows box in a deprivileged way next to a privileged box (Linux or BSD) that monitors it.

Quite a few options. They aren't simple. But protecting inherently insecure legacy software from a whole arsenal of attacks, including zero days, never is easy or simple. It's why I hate monolithic OS's and promote better designs like INTEGRITY, QNX, or MINIX 3 (work in progress). Google LOCK, GEMSOS and XTS-400 for very secure designs from the old days. (I think Schell has a "lessons learned" GEMSOS paper on the net, too.) Bernstein's Qmail Lessons Learned paper is also instructive.

[_ThEcRoW]

I think that pulling the plug is still the most quick way to "secure a server"

[serrath]

Try ReL1K's Artillery.
https://www.secmaniac.com/download/

[army_of_one]

I think that pulling the plug is still the most quick way to "secure a server"

http://en.wikipedia.org/wiki/Cold_boot_attack

That was funny.

[phasma]

Disable unnecessary services (if you'r not using it then it shouldn't be running), uninstall unnecessary software (same goes), make sure EVERYTHING is up to date, implement HIDS and iptables/firewalls (default rule to deny all traffic then allow as you go), utilize SELinux in Fedora environments and anywhere else you can. Also look into securing the services/daemons running on the box from SSH/FTP to DNS. (Disallowing root and anon login for SSH/FTP etc.)

Edited by phasma, 16 April 2012 - 11:04 AM.

[serrath]

Oh... Contest was in March. We might be a little late here.

[TheFunk]

Oh... Contest was in March. We might be a little late here.

Haha! Yeah, it's okay though, I worked out a few things. In the end I decided to go for a quick configuration of iptables, changed all default passwords and disabled unnecessary services, and lastly I found that the system was using AppArmor, so I made some adjustments to that and called it a day. The way everything was set up was rather annoying, and we apparently lost points because iptables was blocking the scorebot for a while (woops). I'll upload some scripts later.