Monday, April 29, 2013
Labels:
CCDC
,
CTF
,
maccdc
This is the third part of a series of blog posts I'm writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is a "table of contents" which I'll update with relevant posts:
The team needs to have practice sessions where the systems are actually available to be utilized. Scenarios should be utilized for practices to provide a sense of what the competition will be like. During the practice sessions, each person should tackle the systems they're comfortable with first and then swap to something they are not comfortable with, such as starting on Windows and switching to Linux.
Any tools desired to be used for competition time need to be vetted first. Concerning tools, a quick note:
Toolsets - 1st party. Each system has its own built-in security tools that could be leveraged. Windows Server 2008 has an advanced firewall in which rulesets can be provisioned pretty granularly. Linux distros typically have IPTables. These types of basic built-in tool sets need to be learned through practices. Before the shiny, fancy tools can be downloaded from the internet station these built-in tools are all you have to work with.
Toolsets - 3rd party. Everyone loves finding research indicating a particular tool can do this or that, but unless you've actually used it and are comfortable implementing it, it's a waste of time and effort. Team members should prune the tool set at least a month before competition time to narrow down a definitive list. During that month or so prior to the competition, during practice sessions these tools need to be tested and tested from both a standalone and live-attack scenario (red-team sessions).
Scripting. Red teamers automate as much as possible, and so should the Blue team. Find simple scripts that can do some brute force defense while trying to lock down the system. These scripts can be kicked off immediately and just run in the background, without waiting to be attacked first. If they're already running from the start, at least they immediately kick off a Red team member, which prevents them from setting up persistence or at least slows them down.
Continue reading MACCDC 2013, Part 4
Read More
MACCDC 2013, A Blue Teamer's Lessons Learned: Part 3 - Practice
This is the third part of a series of blog posts I'm writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is a "table of contents" which I'll update with relevant posts:
#1 - Team selection
#3 - Preparation (PRACTICE!)
#4 - Game Time
Preparation (PRACTICE!)
The team needs to have practice sessions where the systems are actually available to be utilized. Scenarios should be utilized for practices to provide a sense of what the competition will be like. During the practice sessions, each person should tackle the systems they're comfortable with first and then swap to something they are not comfortable with, such as starting on Windows and switching to Linux.
Any tools desired to be used for competition time need to be vetted first. Concerning tools, a quick note:
Da Tools
Toolsets - 1st party. Each system has its own built-in security tools that could be leveraged. Windows Server 2008 has an advanced firewall in which rulesets can be provisioned pretty granularly. Linux distros typically have IPTables. These types of basic built-in tool sets need to be learned through practices. Before the shiny, fancy tools can be downloaded from the internet station these built-in tools are all you have to work with.
Toolsets - 3rd party. Everyone loves finding research indicating a particular tool can do this or that, but unless you've actually used it and are comfortable implementing it, it's a waste of time and effort. Team members should prune the tool set at least a month before competition time to narrow down a definitive list. During that month or so prior to the competition, during practice sessions these tools need to be tested and tested from both a standalone and live-attack scenario (red-team sessions).
Scripting. Red teamers automate as much as possible, and so should the Blue team. Find simple scripts that can do some brute force defense while trying to lock down the system. These scripts can be kicked off immediately and just run in the background, without waiting to be attacked first. If they're already running from the start, at least they immediately kick off a Red team member, which prevents them from setting up persistence or at least slows them down.
Continue reading MACCDC 2013, Part 4
Labels:
CCDC
,
CTF
,
maccdc
This is the second part of a series of blog posts I'm writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is a "table of contents" which I'll update with relevant posts:
If possible, teams should stage ESXi servers with VMs emulating the systems they can expect to see at MACCDC. These VMs are nothing more than basic installations including Windows 2000 (yes, really), Windows XP, Windows Server 2008, Ubuntu and more with web applications or other services. These systems can be staged and a scenario could be executed similar to that for MACCDC to get an idea of what's involved in securing each system.
Speaking from experience, if the centralized lab cannot be easily worked out or it turns out to be unreliable, team members should fall back on using VM Workstation and working with the VMs one at a time. The independent work can be performed between sessions where the main ESXi server is available or if there isn't an ESXi server at all.
Continue reading MACCDC 2013, Part 3
Read More
MACCDC 2013, A Blue Teamer's Lessons Learned: Part 2 - Staging a Lab
This is the second part of a series of blog posts I'm writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is a "table of contents" which I'll update with relevant posts:
#1 - Team selection
#2 - Preparation (staging a lab)
#4 - Game Time
Preparation: Staging a Lab
If possible, teams should stage ESXi servers with VMs emulating the systems they can expect to see at MACCDC. These VMs are nothing more than basic installations including Windows 2000 (yes, really), Windows XP, Windows Server 2008, Ubuntu and more with web applications or other services. These systems can be staged and a scenario could be executed similar to that for MACCDC to get an idea of what's involved in securing each system.
Speaking from experience, if the centralized lab cannot be easily worked out or it turns out to be unreliable, team members should fall back on using VM Workstation and working with the VMs one at a time. The independent work can be performed between sessions where the main ESXi server is available or if there isn't an ESXi server at all.
Continue reading MACCDC 2013, Part 3
Labels:
CCDC
,
Cyber (InfoSec) Competitions
,
cyber challenges
,
maccdc
MACCDC 2013, A Blue Teamer's Lessons Learned
This is the first part of a series of blog posts I'll be writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is a "table of contents" which I'll update with relevant posts:
For this year's competition, schools were allowed to have eight people to a Blue Team. The teams were organized by having a captain and co-captain oversee the other six. During the competition, the captain is responsible (among other things) for communicating business injects to the team members and is the team liaison with the white cell. Because the team captain can be asked to step away for interviews or captain-specific business injects, the co-captain should be capable of fulfilling those same duties.
The team members need to be comprised of people with a good mix of skills between Linux, Windows, Web Applications, and Firewalls. This means that every person on the team needs to be technically capable, or trained to be, by competition time. There were several instances at MACCDC 2013 where someone was pulled away to help another team member on something or complete an inject, leaving a laptop open. Ideally there should never be a time when someone's not working on a laptop (injects notwithstanding), which means that each person should be technically capable or comfortable with picking up where someone else left off.
Continue reading MACCDC 2013, Part 2
Read More
MACCDC 2013, A Blue Teamer's Lessons Learned: Part 1 - Team Selection
MACCDC 2013, A Blue Teamer's Lessons Learned
This is the first part of a series of blog posts I'll be writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is a "table of contents" which I'll update with relevant posts:
#1 - Team selection
#4 - Game Time
And so we begin number one...
Team Selection
For this year's competition, schools were allowed to have eight people to a Blue Team. The teams were organized by having a captain and co-captain oversee the other six. During the competition, the captain is responsible (among other things) for communicating business injects to the team members and is the team liaison with the white cell. Because the team captain can be asked to step away for interviews or captain-specific business injects, the co-captain should be capable of fulfilling those same duties.
The team members need to be comprised of people with a good mix of skills between Linux, Windows, Web Applications, and Firewalls. This means that every person on the team needs to be technically capable, or trained to be, by competition time. There were several instances at MACCDC 2013 where someone was pulled away to help another team member on something or complete an inject, leaving a laptop open. Ideally there should never be a time when someone's not working on a laptop (injects notwithstanding), which means that each person should be technically capable or comfortable with picking up where someone else left off.
Continue reading MACCDC 2013, Part 2
Friday, April 26, 2013
Labels:
Dell
,
noise reduction
,
PowerEdge 2950
Dell PowerEdge 2950: Silence the Noise, Part 2
First, a thank you to Neil for spurring my renewed energy into finding a solution to the 2950's noise level. For the background of this project, check out Silence the Noise, Part 1. In this post, I relate my research findings from my search for suitable fan replacements.
The Fans
To find a suitable replacement, we must first analyze the existing fans so we know the baseline for comparison. Dell PowerEdge 2950's come with Delta brushless, axial fans in a 60mm x 60mm x 38mm form factor. Dell appeared to utilize three variants, with Dell-approved replacement part numbers including JC972, PR272, YW880, and DC471. The ones in my 2950 are JC972, for which the corresponding Delta model number is PFC0612DE. It should be noted that some sites report the thickness as 35mm instead of 38mm, but according to the spec sheet, the proper thickness to keep in mind is 38mm.
Here's a recap and quick reference for the 2950 fans:
Now, if you've read my previous post, you know that I removed two fans leaving me a max of 120 CFM (~63 per fan). During that time, my CPU temp did not increase above 25 degrees. That means that across all four replacement candidates I can lower the CFM to 30 CFM max for each fan. Your mileage may vary.
On arnuschky's blog, in the comments someone reportedly fitted 60mm x 60mm x 25mm fans, so we don't have to stay with the 38mm thickness. A forum post at overclock.net provides insight into re-mapping the power pins from different fans into Dell's power connectors.
Keeping that mind, here is a list of potential replacements:
Read More
To find a suitable replacement, we must first analyze the existing fans so we know the baseline for comparison. Dell PowerEdge 2950's come with Delta brushless, axial fans in a 60mm x 60mm x 38mm form factor. Dell appeared to utilize three variants, with Dell-approved replacement part numbers including JC972, PR272, YW880, and DC471. The ones in my 2950 are JC972, for which the corresponding Delta model number is PFC0612DE. It should be noted that some sites report the thickness as 35mm instead of 38mm, but according to the spec sheet, the proper thickness to keep in mind is 38mm.
Here's a recap and quick reference for the 2950 fans:
- Dell Part Numbers: JC972, PR272, YW880, DC471
- Delta Part Number: PFC0612DE (I'm sure there are others)
- Form Factor: 60mm x 60mm x 38mm
- Air Flow: up to 67.8 CFM
- RPM: up to 12,000
- NOISE: 61.5 dB (one fan!!)
- Voltage: 12V
- Termination: 4 wire
- Features: PWM Control
The key elements we need to keep in mind for the replacement are the size (60mm x 60mm), air flow, noise, termination, and features.
To see like-manufacturer replacements, I checked Delta's website. Delta has a list of currently available fans in a similar form factor if you put in the correct search parameters. However, in the comments section of the hacking the BMI post, other PowerEdge 2950 owners reported that they swapped the 38mm thickness for thinner fans and they worked fine as long as the replacements had PWM control and a 4-wire termination. Here are some photos for reference:
Fan Label |
4-Pin Connector |
Now, if you've read my previous post, you know that I removed two fans leaving me a max of 120 CFM (~63 per fan). During that time, my CPU temp did not increase above 25 degrees. That means that across all four replacement candidates I can lower the CFM to 30 CFM max for each fan. Your mileage may vary.
On arnuschky's blog, in the comments someone reportedly fitted 60mm x 60mm x 25mm fans, so we don't have to stay with the 38mm thickness. A forum post at overclock.net provides insight into re-mapping the power pins from different fans into Dell's power connectors.
Keeping that mind, here is a list of potential replacements:
- Top Motor PWM Fan 60mm x 25mm ($4.75, max 48.8 dB, max 44.68 CFM)
- Cooljag Everflow 60mm x 25mm PWM Fan (F126025BU) ($9.99, max 33.5 dB, max 24.5 CFM)
- Evercool 60mm x 25mm High Speed PWM Fan (EC6025H12BP) ($9.99, max 36 dB, max 26.63 CFM)
- Nidec Ultraflo U60T12MUA7-57 60mm x 25mm 4-Pin PWM Fan ($4.99, max 32.5 dB, max 23 CFM)
- Dell Fan Assembly 12V DC 0.48A 60 X 25mm For Poweredge 2650 7K412 ($13.95, max 46.5 dB, max 38.35 CFM)
As you can see by visiting the links to these fans, all the power connectors are different with maybe the exception of the last one and would need to be re-pinned. Also, note that they're all thinner, coming in at a 25mm thickness instead of 38mm. Instead of trying to re-pin the power connector, I decided to check Delta's list of model numbers to see if they had a fan that I could use to more easily replace the JC972. To be posted in part 3...
Subscribe to:
Posts
(
Atom
)