As promised, here is my January 2014 presentation at Southern Oregon University. There was video of the event, which I hope to find and share later.
EDIT: The video, graciously provided by Sustainable Valley Technology Group, is now included below.
Though long delayed, below is the slideshare for my April 2013 talk at SOU, entitled “Getting Involved In Network Security”:
Expect another post with my January 2014 presentation soon.
I’m mentoring a highly-motivated high school student through a senior project, as he’s interested in network security and wants to do a penetration test of his high school. He’s got permission and I’ve got the spare cycles, so I agreed to mentor him.
What will hopefully follow is a series of blog posts of the compressed education I’ll give. I’m trying to constrain this to 40-ish hours, and also trying to pass enough education so he knows to a reasonable extent what he’s doing by the end, not just showing off a series of tools. With such a short time limitation, this will obviously be a whirlwind of topics, so advanced readers will have to forgive me glossing over some rather important details.
I’m a big believer in learning networking from a practical point of view, as it helps with many aspects of troubleshooting. Troubleshooting, as I use the word, is having a goal and working through or bypassing the obstacles encountered, often using many different approaches to the problem. It’s okay to have eleven failed solutions, as long as you have twelve different ways to solve the problem. Penetration testing is just troubleshooting your way to Domain Admin, so it relates well.
Though in a classroom environment I’d also teach the OSI model, for the defined purpose of this class the TCP/IP model fits better, so we’ll work with that. The one-sentence descriptions of each layer below are my own attempt to sum up the intent of each layer.
I’d be foolish not to link to Wikipedia’s page on the TCP/IP model, because it is very well fleshed out. Specifically, the section on encapsulation, which I’ll quote below, explains the concept very well:
The Internet protocol suite uses encapsulation to provide abstraction of protocols and services. Encapsulation is usually aligned with the division of the protocol suite into layers of general functionality. In general, an application (the highest level of the model) uses a set of protocols to send its data down the layers, being further encapsulated at each level.
The layers of the protocol suite near the top are logically closer to the user application, while those near the bottom are logically closer to the physical transmission of the data. Viewing layers as providing or consuming a service is a method of abstraction to isolate upper layer protocols from the details of transmitting bits over, for example, Ethernet and collision detection, while the lower layers avoid having to know the details of each and every application and its protocol.
The network access layer is scoped to just allowing hosts (or more precisely, their network interfaces) on the same network to communicate. This also includes the physical components (such as cabling and interfaces) and protocols for sending and receiving the physical signals. As an example protocol, an Ethernet address is assigned to the network card by the manufacturer and is supposed to be unique.
The link light on an Ethernet card, for example, is solely indicating whether the involved interface believes it is connected to another device speaking the same protocol. A laptop connected via Ethernet to a switch with no other hosts attached, for example, would still have an active link light, because both the switch and network interface speak Ethernet.
Moving packets from one interface to another at the link layer is called switching. A switch is a network device that connects hosts within the same subnet (or “switches packets”), and therefore operates at layer one.
As a building block above layer one, the Internet layer allows hosts in different subnets to communicate. Note that while network access layer addresses are hardware addresses assigned by the manufacturer, Internet layer addresses are assigned by the user to particular hosts. As such, a machine can have different Internet layer addresses while in different subnets (such as a laptop with a different IP address at home and at a coffee shop), whereas a network access layer device will always have the same address (assuming no MAC spoofing shenanigans).
Moving packets from one subnet to another is called routing. A router is a network device that connects multiple subnets (or “routes packets”), and therefore operates at layer two.
The transport layer builds upon the Internet layer (starting to get the theme, here?) by allowing multiple services on a single host. Look at the IPv4 header, for example. There’s a field for destination address, but how do you speak to a particular service on a host? Imagine a server that runs both HTTP and FTP. How do I, as a client, tell the server which service I want to talk to? Using solely IPv4, I can only send a packet to the host as a whole — there isn’t a field for which service I mean to talk to. The transport layer, at a minimum, provides this service through the concept of ports, of which there are 65,535 (or 2^32 – 1, since port zero is reserved).
Particular services are by convention found on particular ports, and vice versa (see IANA Assigned Port Numbers). If you see port 80 is open, for example, you’d expect a web server (HTTP) to be running on that port. However, there is no “Internet police” regulating this, so people can and do run services on non-standard ports, for a multitude of reasons. High ports are commonly used for a client to connect from (i.e., as an ephemeral port), so it’s very common to see a client connect from port 49,273 (for example) to port 80, in order to connect to a web server.
As for the two major protocols used at this layer, TCP (Transport Control Protocol) and UDP (User Datagram Protocol), there are some fundamental differences.
UDP is connectionless, meaning messages are sent directly, without any of the overhead that TCP has and as minimal as possible, barely providing anything beyond source and destination ports. For IPv4, even the checksum field is optional. In general, the protocols that emphasize low latency (Voice over IP, real-time video) or extremely high throughput with low overhead (DNS primarily) will tend to prefer UDP. However, since reliability isn’t guaranteed, protocols choosing UDP must be able to work despite occasional loss of packets. Voice over IP, for example, will just skip a few phonemes, where a missed DNS request will just result in sending the request again after a short timeout.
TCP is more complex, and provides reliable delivery of data in proper order. Even if some packets are dropped, if the overall connection *can* pass packets successfully, then eventually the two application-layer protocols above TCP will get their data. On a lossless network (which almost all local networks should be), the overhead is very minimal and high-speed communications are in no way hampered by TCP. As shown in the TCP header, all these features mean the protocol header itself has many more fields to track these options. We’ll skip going over the TCP fields at this level, for now.
As the top-most layer in the networking stack, the application layer is the one that carries traffic from a particular application. As such, there’s a ton of variation in this layer, and many, many protocols. I’ll touch on this concept in a further blog post, but application layer packets are, in blunt terms, the entire point of the communication. Though there’s a lot of scaffolding in lower layers to get an HTTP client connected to an HTTP server, the point of all of those connections it the HTTP (which is application layer) communication. The HTTP communication (in this example) is what the user requested, which is an exceedingly common theme.
UPDATE – if you’re looking for my article on “Building A Pen Test Lab”, it’s located on the SANS Pen Test blog, not here.
It’s not a debate that most IT professionals should have a lab environment in which they can practice their trade. Many don’t have one at work, though, and don’t make one at home. Those of us in network security (whether offense or defense) aren’t an exception, either. Ed Skoudis (of SANS and InGuardians fame) posted on this recently, and a DEFCON 20 talk from Trustwave featured their testing labs heavily.
The purpose of this design is to go into more detail than most security labs, to more closely simulate a standard small business network. You can learn some basics of Metasploit, for example, by using a BackTrack or Kali VM as well as Metasploitable, but more comprehensive attacks and defenses need a more realistic network.
The Active Directory domain controller, file server, and external blog in this lab all represent unique (and common) attack opportunities. Client desktops are almost always of multiple security levels and OS levels, which explains both the Windows XP and 7 workstations. The DMZ is slightly unusual for a small business, but is reasonable in simulating a larger environment. The larger environments, by the way, are the ones that have money for vulnerability assessments and penetration tests, so they’re certainly the networks worth studying.
Not included in the lab diagram is a Security Onion VM for intrusion detection capabilities, and a Splunk server (for now — Graylog2 might replace this) allowing all kinds of logs (syslogs and Windows event logs, to start) to be collected.
Though the hardware I used to put together this lab certainly wasn’t free, it was less expensive than you might think. I’ll put up another post about it shortly, but for now, know that it was based on this fine gentleman’s home lab. One awesome resource that I checked into heavily, by the way, can be found at www.reddit.com/r/homelab. If you have any quick questions, you can also reach some of those folk at #r_homelab on Freenode IRC.
In further posts, I’ll go into how and why I designed the lab this way, what licensing I used, and how I went about building it from a practical point of view.
Since the documentation was a bit sparse on my script in my previous post, I thought I’d post clearer instructions, for those not as familiar with Group Policy. This post is going live with my guest Tech Segment on PaulDotCom today.
For this implementation guide, I assume you have an Active Directory domain and several clients to manage. You’ll also need to do your work from a machine with Group Policy Editor, and either the correct delegated permissions or Domain Admin privileges. If there are any instructions that are unclear, leave a comment and I’ll update the post.
Please download the randomize-local-admin.vbs script from my GitHub (right-click, Save Link As…) and save it your Desktop or another accessible location. You’ll need this shortly.
Open up Group Policy Management Console, browse to the Group Policy Objects folder, then right-click on it and create a new Group Policy Object.
Name it something recognizable such as “Local Administrator Password Randomization”, then right-click and Edit it.
Now browse to Computer Configuration -> Policies -> Windows Settings and double-click on Startup. This is where we’ll set the script to run on boot.
Once the new window pops up, click Show Files to open the GPO’s directory and copy the VBScript (randomize-local-admin.vbs) inside. Make sure it has the right extension, or Windows won’t recognize it as a VBScript.
Now add the script to the Group Policy Object by clicking Add and selecting the script.
The intent of this script is to randomize local Administrator accounts on desktops and member servers, but domain controllers don’t have local accounts. So as to not randomize the builtin Domain Admin account, we’ll need to exclude DC’s, either via the Organization Units (OU’s) we target or by WMI Filters. If your Active Directory OU structure isn’t built with separate areas for Domain Controllers, or you want to link the entire domain, we can use a WMI Filter to exclude all machines classified as DC’s.
Under WMI Filters, right-click and click New. Right a name and description (“Exclude Domain Controllers” seems reasonable) and then click Add. You’ll need the following WMI Filter:
select * from Win32_OperatingSystem where ProductType <> “2”
Now that we’ve created the GPO and its WMI Filter, we can link it to an Organizational Unit. First, though, you’ll need to associate the WMI filter if you created one. After clicking on the Group Policy Object, select the WMI filter from the lower side of the right pane, under WMI Filtering.
Right-click an existing OU which has systems you’d like to target and click “Link an Existing GPO…”. Select the GPO you just created, and it will take effect on the next reboot on all Computer objects in that OU. You can select other OU’s in the same way.
To make an acceptable level of overkill, this script creates 120-character passwords using the full ASCII character set (1-255).
Again, if you have any issues feel free to leave a comment or send me an email.
In a former post I referred to Kon-Boot, but didn’t go into much detail. Here, I’ll expand on my use of Kon-Boot and how to set it up for your own network. Specifically, to keep things as easy as possible I add it to my PXE menu, so that you’re simply a reboot and a few keystrokes away from logging on to an otherwise locked machine.
Kon-Boot is a bootable shim which bypasses local account authentication on Windows machines. In other words, by booting into Kon-Boot (via floppy, CD, or over the network via PXE) you can bypass local passwords, such as for the built-in Administrator account.
As an aside, note that it cannot bypass domain authentication. This makes sense, as domain-joined machines contact domain controllers for domain user accounts, unless the client machine is offline and has cached credentials.
Kon-Boot is the reason I randomize the local Administrator password without disabling the account. For whatever reason, the author of Kon-Boot didn’t bypass enabled/disabled checks on local accounts, just their passwords.
I’ll assume you already have a DHCP server on your network. The FOG Project, which I heartily recommend for anyone looking for a free Ghost replacement, has a wonderful page on setting DHCP options for many types of DHCP servers. The same options will apply for us — option 066 (“Next Server”) will be the IP address of the PXE server, and option 067 (“Boot File”) will be “pxelinux.0”. In fact, if FOG itself is interesting, they have great setup guides that will get a FOG menu installed on Ubuntu, to which you can simply add Kon-Boot as an additional option.
Next, you’ll need a trivial file transfer protocol (TFTP) server. For this tutorial, I’ll go through the setup of tftpd-hpa and syslinux on Ubuntu 12.04 Server. I’d recommend making this machine a VM, as the resources required are laughably low. I won’t, however, go into the installation of Ubuntu Server, as there are plenty of fantastic guides for that piece already. If you use the previous link, keep track of the IP address you statically assigned, or make a static DHCP reservation for the PXE server.
Once you’re logged in, there’s a few pieces of software to install.
apt-get install tftpd-hpa syslinux vim-nox openssh-server
This will install the TFTP server, syslinux (think of it as GRUB for PXE), a minimal version of vim to edit text files, and an SSH server. We’ll also need to create the directory structure and copy over some of the syslinux files to the TFTP root directory.
cp /usr/lib/syslinux/memdisk /var/lib/tftpboot # used to boot a floppy image
cp /usr/lib/syslinux/pxelinux.0 /var/lib/tftpboot # the PXE boot file
cp /usr/lib/syslinux/vesamenu.c32 /var/lib/tftpboot # for the PXE menu
You’ll also have a choice between setting a root password and a fair number of sudo commands. For the purposes of this post, I’ll recommend setting a strong password (as an example, this password generator site is xkcd-approved!) for root.
sudo passwd # Enter your user password, then enter a strong password for root, twice
Next, we’ll install the free version of Kon-Boot. Earlier this year, the author came out with a new paid version, but maintained the original version for free download. The major restriction is the free version (v1.1) doesn’t support 64-bit Windows systems, while the paid version (v2.0) does. Go to the Kon-Boot download page, download from the first mirror, and save the zip locally. Inside kon-boot-all.zip you’ll find FD0-konboot-v1.1-2in1.zip (password is “kon-boot”), and in that you’ll find FD0-konboot-v1.1-2in1.img. Save it to another location locally, such as your desktop.
If you don’t already have it installed, you’ll also need a program to copy the Kon-Boot floppy image over to the PXE server. I recommend installing WinSCP (skip the “sponsored” version if you prefer) for those on a Windows platform.
Copy the FD0-konboot-v1.1-2in1.img file to the /var/lib/tftpboot directory.
Now you’ll need to write the pxelinux configuration file at /var/lib/tftpboot/pxelinux.cfg/default. You can either use the command below, or a text editor like vim or nano to write the text below:
echo -n ”
MENU LABEL Boot from hard disk
Boot from the local hard drive.
If you are unsure, select this option.
MENU LABEL Kon-Boot Floppy Image
Kon-Boot will bypass local authentication for
local administrative purposes.
” > /var/lib/tftpboot/pxelinux.cfg/default
If you’ve set up your DHCP server options as mentioned before, you should now be able to boot a client to the network and see the menu we’ve created. You may have to press a specific key during boot or change your BIOS options. For VMware virtual machines, pressing F12 during boot attempts a PXE boot.
Booting into Kon-Boot will take a few moments showing a fancy startup image, and then boot into Windows.
Now that you’re inside Windows, you can log in as the local Administrator account (or any other local account) without worrying about the password. You can leave the password field blank, or type in any particular password you want. It makes no difference, as the password check is more-or-less replaced with “return true”. Whereas before you’d see this:
Now you’ll be able to log on and take any actions you wish.
What do you think? As I don’t have need for remote access to computers without using domain privileges, I see this as a useful way to log in to infected or suspicious machines locally. In terms of return on investment, I’ve been extremely happy with further customizing my PXE boot menu with SpinRite (drive recovery), Recovery is Possible (live Linux over PXE!), and even Memtest86+.
After my last post with the local Administrator randomization script got some attention from John Strand (@strandjs), Tim Medin (@timmedin), and Tim Tomes (@LaNMaSteR53), I realized the issue what to do with local Administrator accounts was considerably more complicated. Here’s my attempt to map out the different possibilities.
As background, be sure you know that resetting a local Administrator (or bypassing it entirely) is trivial given physical access to a machine (via NT Password Reset, Kon-Boot, or similar utilities). Offline registry attacks assume there’s no drive encryption in place. The two types of attackers I’m assuming below are external (as in a penetration tester or malicious hacker) and internal, as in employees or contractors. I assume the external attackers don’t have physical access to each machine in the domain, as that would defeat any of the recommendations below.
In order of least to most secure, here are the basic options I see:
Do you need to access machines remotely using the local Administrator account? Since we’re discussing domain-joined Windows machines, the use cases for this requirement are small. The two situations I see this need are machines that aren’t connected to the domain (assuming Domain Admin credentials aren’t cached, which is a topic for a different blog post), and accessing machines that are infected or untrusted (as the domain token could be stolen and re-used elsewhere).
If so, be careful! This is where most people get into trouble. Standardizing on a local Administrator password means that anyone with brief physical access to any one of those machines can use those same credentials (without cracking the password hash, even) on all machines in the network. If this is both scary and new information, look up “Pass the Hash” attacks.
If you’re still sure you need remote access to machines using the local Administrator accounts, you’ll need to ensure the same password isn’t used across all machines in your domain. In other words, we’ll need to make those passwords individualized to each machine. These individualized passwords can be created using the output of a hashing algorithm seeded with some unique identifier of the machine together with a secret padding. If we can guarantee the padding isn’t disclosed, we’ll have a fairly secure password. The output of the SHA-1 algorithm is 160 bits, expressed as 40 hexadecimal characters. Plugging that output into Jason Fossen’s password complexity spreadsheet gives us an output of 1,157,804,805,602.22 years to crack an average password of that length directly, with 1,000 machines each generating 200,000 hashes per second. Needless to say, an attacker would be far better off trying to discover the method used to create the passwords (including the secret padding) than to attack each password individually.
The biggest concern for individualized passwords is setting them. My preferred approach, Group Policy, would show the secret padding, as it would have to be in the script. Accordingly, we’ll need to push out the individualized passwords from a trusted computer, setting the passwords on each remote machine. Unless I get requests otherwise, I’ll leave the actual individualized password script as an exercise for the reader.
I’ve recently started putting my bookmarks into Delicious. I have categories for Systems Administration, Security (mostly pen-testing), and Forensics.
This should obviate the need to put up “look, a shiny new link!” posts up, which has been otherwise quite tempting.
Here are a few examples of bookmarks to look at:
If you’re interested, you can add my feed to your RSS reader of choice.
From the review:
Whereas most other networking books focus on one technology or one aspect of network design, Oppenheimer really does guide the reader through designing a network in a top-down (gathering requirements to documentation) fashion. Overall, the book takes you from a 30,000 foot view to about a 2,000 foot view. Despite Oppenheimer’s Cisco-focused background and being published by Cisco Press, her book admirably avoids plugging Cisco as the end-all-be-all solution. Overall, I would recommend this book for all parts of network design, and recommend others for the actual IOS/device configuration (which Top-Down Network Design avoids).
As others have identified, the books is divided into four sections. The section titles are descriptive enough, so I’ll just point out the highlights by chapter instead.
The first chapter covers an introduction to network design, including analyzing business goals and constraints. It emphasizes the need for the network design to make “business sense,” as in justify the business itself. Constraining the network design to the budgetary and staffing constraints of the customer is also important — after all, what good is a highly-reliable, highly-complex network to a CCENT-level network engineer who can’t make necessary modifications without taking down the network?
The fourth chapter relates to the network traffic of the existing network. By categorizing users into “user communities” based off job role (usage of sets of applications) and categorizing the traffic flows themselves, one can describe at a high level the network flow while still providing useful data for technical purchase decisions. The traffic flows are categorized into groups such as peer-to-peer, client/server, server-to-server, terminal/host, and distributed computing.The traffic is also displayed by frame size, broadcast/multicast/unicast type, and error rate to give useful data. QoS requirements for voice and other sensitive applications are also discussed, as are different service categories based off the Asynchronous Transfer Mode Forum definitions.
I appreciate this model, as without these abstractions it’s tough to talk about network flow at a high level without losing specificity.
In chapter six, there’s a sizable section on naming schemes, especially in the Windows world. The “Guidelines for Assigning Names” section is full of solid advice, though the section on WINS can probably be safely removed in the next edition.
Chapter seven is mostly focused on the actual switching and routing protocols, but also covers the creation of decision trees to assist with protocol selection. Table 7-5 on page 230 is a *very* handy summary of the routing protocols covered in the text.
In the last chapter, number 14, Oppenheimer gives a summary of top-down network design by going through the steps of the design methodology, which I found very useful. She also highlights the importance of the network design document, details how to respond to client RFP’s, and then goes over the sections of the network design document in detail.
I found this to be an extremely useful book for its intended purpose. Top-Down Network Design will be a text I refer to for any network design needs I encounter in my future.
Full disclosure: I do know Priscilla Oppenheimer. I have taken several classes from her in networking and network forensics.