I recently came across an article from InfoWorld magazine which I absolutely loved. It listed 30 skills that every IT person should have. I couldn’t agree more with the article. It seems that more and more IT programs in colleges and universities are moving away from general Information Technology and having students focus on programming or information management. Schools are doing less and less of teaching the nuts of bolts of computers, how to fix minor issues, and that gray area where business and technology meets in the workplace.

It seems that more of the recent college graduates enter the workforce with either a very strong technical programming background with little to no business savvy or they come knowing the in’s and out’s of business but lack even the basic technology knowledge to take care of basic tasks.

For a few years now I’ve been a big champion for university programs to develop a middle ground between Information Technology or Information Systems and Management programs for IT professionals who love technology and see its application to business processes and understand the key role technology plays in business.

In any case, the InfoWorld article, states that these skills are a must, to the point that if you don’t have them, you should be fired.

Here are the key skills:

1. Be able to fix basic PC issues. These can be how to map a printer, back up files, or add a network card. You don’t need to be an expert and understand how to overclock a CPU or hack the registry, but if you work in IT, people expect you to be able to do some things.

[ If you have IT staffers who aren't up to snuff, fire them. Learn how to do it right. ]

2. Work the help desk. Everyone, from the CIO to the senior architect, should be able to sit down at the help desk and answer the phones. Not only will you gain a new appreciation for the folks on the phones, but you will also teach them more about your process and avoid escalations in the future.

3. Do public speaking. At least once, you should present a topic to your peers. It can be as simple as a five-minute tutorial on how IM works, but being able to explain something and being comfortable enough to talk in front of a crowd is a skill you need to have. If you are nervous, partner with someone who is good at it, or do a roundtable. This way, if you get flustered, someone is there to cover for you.

4. Train someone. The best way to learn is to teach.

5. Listen more than you speak. I very rarely say something I didn’t already know, but I often hear other people say things and think, “Darn, I wish I knew that last week.”

6. Know basic networking. Whether you are a network engineer, a help desk technician, a business analyst, or a system administrator, you need to understand how networks work and simple troubleshooting. You should understand DNS and how to check it, as well as how to ping and trace-route machines.

7. Know basic system administration. Understand file permissions, access levels, and why machines talk to the domain controllers. You don’t need to be an expert, but knowing the basics will avoid many headaches down the road.

8. Know how to take a network trace. Everyone in IT should be able to fire up wireshark, netmon, snoop, or some basic network capturing tool. You don’t need to understand everything in it, but you should be able to capture it to send to a network engineer to examine.

9. Know the difference between latency and bandwidth. Latency is the amount of time to get a packet back and forth; bandwidth is the maximum amount of data a link can carry. They are related, but different. A link with high-bandwidth utilization can cause latency to go higher, but if the link isn’t full, adding more bandwidth can’t reduce latency.

10. Script. Everyone should be able to throw a script together to get quick results. That doesn’t mean you’re a programmer. Real programmers put in error messages, look for abnormal behavior, and document. You don’t need to do that, but you should be able to put something together to remove lines, send e-mail, or copy files.

11. Back up. Before you do anything, for your own sake, back it up.

12. Test backups. If you haven’t tested restoring it, it isn’t really there. Trust me.

13. Document. None of the rest of us wants to have to figure out what you did. Write it down and put it in a location everyone can find. Even if it’s obvious what you did or why you did it, write it down.

14. Read “The Cuckoo’s Egg.” I don’t get a cut from Cliff Stoll (the author), but this is probably the best security book there is — not because it is so technical, but because it isn’t.

15. Work all night on a team project. No one likes to do this, but it’s part of IT. Working through a hell project that requires an all-nighter to resolve stinks, but it builds very useful camaraderie by the time it is done.

16. Run cable. It looks easy, but it isn’t. Plus, you will understand why installing a new server doesn’t really take five minutes — unless, of course, you just plug in both ends and let the cable fall all over the place. Don’t do that — do it right. Label all the cables (yes, both ends), and dress them nice and neat. This will save time when there’s a problem because you’ll be able to see what goes where.

17. You should know some energy rules of thumb. For example: A device consuming 3.5kW of electricity requires a ton of cooling to compensate for the heat. And I really do mean a ton, not merely “a lot.” Note that 3.5kW is roughly what 15 to 20 fairly new 1U and 2U servers consume. One ton of cooling requires three 10-inch-round ducts to handle the air; 30 tons of air requires a duct measuring 80 by 20 inches. Thirty tons of air is a considerable amount.

18. Manage at least one project. This way, the next time the project manager asks you for a status, you’ll understand why. Ideally, you will have already sent the status report because you knew it would be asked for.

19. Understand operating costs versus capital projects. Operating costs are the costs to run the business. Capital equipment is made of assets that can have their cost spread over a time period — say, 36 months. Operating costs are sometimes better, sometimes worse. Know which one is better — it can make a difference between a yes and no.

20. Learn the business processes. Being able to spot improvements in the way the business is run is a great technique for gaining points. You don’t need to use fancy tools; just asking a few questions and using common sense will serve you well.

21. Don’t be afraid to debate something you know is wrong. But also know when to stop arguing. It’s a fine line between having a good idea and being a pain in the ass.

22. If you have to go to your boss with a problem, make sure you have at least one solution.

23. There is no such thing as a dumb question, so ask it … once. Then write down the answer so that you don’t have to ask it again. If you ask the same person the same question more than twice, you’re an idiot (in their eyes).

24. Even if it takes you twice as long to figure something out on your own versus asking someone else, take the time to do it yourself. You’ll remember it longer. If it takes more than twice as long, ask.

25. Learn how to speak without using acronyms.

26. IT managers: Listen to your people. They know more than you. If not, get rid of them and hire smarter people. If you think you are the smartest one, resign.

27. IT managers: If you know the answer, ask the right questions for someone else to get the solution; don’t just give the answer. This is hard when you know what will bring the system back up quickly and everyone in the company is waiting for it, but it will pay off in the long run. After all, you won’t always be available.

28. IT managers: The first time someone does something wrong, it’s not a mistake — it’s a learning experience. The next time, though, give them hell. And remember: Every day is a chance for an employee to learn something else. Make sure they learn something valuable versus learning there’s a better job out there.

29. IT managers: Always give people more work than you think they can handle. People will say you are unrealistic, but everyone needs something to complain about anyway, so make it easy. Plus, there’s nothing worse than looking at the clock at 2 p.m. and thinking, “I’ve got nothing to do, but can’t leave.” This way, your employees won’t have that dilemma.

30. IT managers: Square pegs go in square holes. If someone works well in a team but not so effectively on their own, keep them as part of a team.

ShareThis

Let’s face it, Windows machines get hacked, and in some environments it happens a lot. Fortunately, Microsoft has built numerous tools into Windows so administrators and power users can analyze a machine to determine whether it’s been compromised. In this tip, which is the first of a two-part series, I’ll cover five useful command-line tools built into Windows for such analysis.

1) WMIC: A world of adventure awaits
Windows Management Instrumentation Command-line (WMIC) is not merely a command; it’s a world unto itself. Offering a command-line interface to the ultra-powerful Windows Management Instrumentation API within Windows, WMIC lets administrative users access all kinds of detailed information about a Windows machine, including detailed attributes of thousands of settings and objects. WMIC is built into Windows XP Professional, Windows 2003 and Windows Vista. To use WMIC, users must invoke it by running the WMIC command followed by the area of the machine the user is interested in (often referred to as an alias within the system). For example, to learn more about the processes running on a machine, a user could run:
C:\> wmic process

Output of that command will likely look pretty ugly because an output format wasn’t specified. With WMIC, output can be formatted in several different ways, but two of the most useful for analyzing a system for compromise are the “list full” option, which shows a huge amount of detail for each area of the machine a user is interested in, and the “list brief” output, which provides one line of output per report item in the list of entities, such as running processes, autostart programs and available shares.

For example, we can look at a summary of every running process on a machine by running:
C:\> wmic process list brief

That command will show the name, process ID and priority of each running process, as well as other less-interesting attributes. To get even more detail, run:
C:\> wmic process list full

This command shows all kinds of details, including the full path of the executable associated with the process and its command-line invocation. When investigating a machine for infection, an administrator should look at each process to determine whether it has a legitimate use on the machine, researching unexpected or unknown processes using a search engine.

Beyond the process alias, users could substitute startup to get a list of all auto-start programs on a machine, including programs that start when the system boots up or a user logs on, which could be defined by an auto-start registry key or folder:
C:\> wmic startup list full

A lot of malware automatically runs on a machine by adding an auto-start entry alongside the legitimate ones which may belong to antivirus tools and various system tray programs. Users can look at other settings on a machine with WMIC by replacing “startup” with “QFE” (an abbreviation which stands for Quick Fix Engineering) to see the patch level of a system, with “share” to see a list of Windows file shares made available on the machine and with “useraccount” to see detailed user account settings.

A handy option within WMIC is the ability to run an information-gathering command on a repeated basis by using the syntax “/every:[N]” after the rest of the WMIC command. The [N] here is an integer, indicating that WMIC should run the given command every [N] seconds. That way, users can look for changes in the settings of the system over time, allowing careful scrutiny of the output. Using this function to pull a process summary every 5 seconds, users could run:
C:\> wmic process list brief /every:1

Hitting CTRL+C will stop the cycle.

2) The net command: An oldie but a goodie
While WMIC is a relatively new command, let’s not lose site of some useful older commands. One of my favorites is the venerable “net” command. Administrators can use this to display all kinds of useful information.

For example, the “net user” command shows all user accounts defined locally on the machine. The “net localgroup” command shows groups, “net localgroup administrators” shows membership of the administrators group and the “net start” command shows running services.

Attackers frequently add users to a system or put their own accounts in the administrators groups, so it’s always a good idea to check the output of these commands to see if an attacker has manipulated the accounts on a machine. Also, some attackers create their own evil services on a machine, so users should be on the lookout for them.

3) Openfiles: Deep scrutiny
Many Windows administrators are unfamiliar with the powerful openfiles command built into Windows. As its name implies, this command shows all files that are opened on the box, indicating the process name interacting with each file. It’s built into modern versions of Windows, from XP Pro to Vista. Like the popular lsof command for Linux and Unix, it’ll show administrators all open files on the machine, giving the process name and full path for each file. Unlike lsof, however, it doesn’t provide many more details, such as process ID number, user number and other information.

Considering the volume of information it gathers, it’s no surprise that the openfiles command is a performance hog. Thus, the accounting associated with openfiles is off by default, meaning users can’t pull any data from this command until it is turned on. This function can be activated by running:
C:\> openfiles /local on

Users will need to reboot, and when the system comes back, they will be able to run the openfiles command as follows:
C:\> openfiles /query /v

This command will show verbose output, which includes the user account that each process with an open file is running under. To get an idea of what malware has been installed, or what an attacker may be doing on a machine, users should look for unusual or unexpected files, especially those associated with unexpected local users on the machine.

When finished with the openfiles command, its accounting functionality can be shut off and the system returned to normal performance by running the following command and rebooting:
C:\> openfiles /local off

4) Netstat: Show me the network
The Windows netstat command shows network activity, focusing on TCP and UDP by default. Because malware often communicates across the network, users can look for unusual and unexpected connections in the output of netstat, run as follows:
C:\> netstat -nao

The –n option tells netstat to display numbers in its output, not the names of machines and protocols, and instead shows IP addresses and TCP or UDP port numbers. The –a indicates to display all connections and listening ports. The –o option tells netstat to show the processID number of each program interacting with a TCP or UDP port. If, instead of TCP and UDP, you are interested in ICMP, netstat can be run as follows:
C:\> netstat –s –p icmp

This indicates that the command will return statistics (-s) of the ICMP protocol. Although not as detailed as the TCP and UDP output, users can see if a machine is sending frequent and unexpected ICMP traffic on the network. Some backdoors and other malware communicate using the payload of ICMP Echo messages, the familiar and innocuous-looking ping packets seen on most networks periodically.

Like WMIC, the netstat command also lets us run it every N seconds. But, instead of using the WMIC syntax of “/every:[N]“, users simply follow their netstat invocation with a space and an integer. Thus, to list the TCP and UDP ports in use on a machine every 2 seconds, users can run:
C:\> netstat –na 2

5) Find: Searching output for useful stuff
Most of the commands I have discussed so far spew a lot of output on the screen, which could be hard for a human to look through to find a specific item of interest. But, Windows comes to the rescue. Users can search through the output of a command using the built-in find and findstr commands in Windows. The find command looks for simple strings, while findstr supports regular expressions, a more complex way to specify search patterns. Because the regular expressions supported by findstr go beyond the scope of this tip article, let’s focus on the find command. By default, find is case sensitive – use the /i option to make it case insensitive.

The find command also has the ability to count. Invoked with the /c command, it’ll count the number of lines of its output that include a given string. Users often want to count the number of lines in the output of a command to determine how many processes are running, how many startup items are present, or a variety of other interesting tidbits on a machine. To count the lines of output, users could simply pipe their output through find /c /v “”. This command will count (/c) the number of lines that do not have (/v) a blank line (“”) in them. By counting the number of non-blank lines, the command is, in effect, counting the number of lines.

Now, with the find command, users can look through the output of each of the commands I’ve discussed so far to find interesting tidbits. For example, to look at information every second about cmd.exe processes running on a machine, type:
C:\> wmic process list brief /every:1 | find “cmd.exe”

Or, to see which autostart programs are associated with the registry hive HKLM, run:
C:\> wmic startup list brief | find /i “hklm”

To count the number of files open on a machine on which openfiles accounting is activated, type:
C:\> openfiles /query /v | find /c /v “”

Whenever counting items in this way, remember to subtract the number of lines associated with column headers. And, as a final example, to see with one-second accuracy when TCP port 2222 starts being used on a machine, along with the process ID using the port, run:
C:\> netstat –nao 1 | find “2222″

Researching output
With these five tools, users can get a great deal of information about the configuration and security state of a Windows machine. To use each command in identifying a compromise, however, a user needs to compare the current settings of the machine under analysis to a “normal,” uninfected machine.

There are three options for establishing a baseline comparison. First, if the user is an experienced malware hunter, he or she may have a sense of what is right and what is wrong with a given kind of machine, identifying evil or unusual stuff based on experience. Alternatively, this comparison can be performed against a clean, uninfected machine, if there is one handy. If there isn’t, a user may need to rely on a third option — researching specific files, process names, file names and port numbers identified by these commands and searching for them online to determine whether they are normal for a given machine and the software it has installed, or whether they are associated with a some type of malware.

In this tip, I have discussed five powerful built-in Windows commands. In a future installment, I’ll finish out our top 10 list by looking at some little-known but immensely useful features of the tasklist, reg and ipconfig commands, as well as iterating with FOR loops and launching administrative GUIs via the command-line.

About the author:
Ed Skoudis is a SANS instructor and a founder and senior security consultant with Intelguardians, a Washington, DC-based information security consulting firm. His expertise includes hacker attacks and defenses, the information security industry and computer privacy issues. In addition to Counter Hack Reloaded, Ed is also the author of Malware: Fighting Malicious Code. He was also awarded 2004, 2005 and 2006 Microsoft MVP awards for Windows Server Security, and is an alumnus of the Honeynet Project. As an expert on SearchSecurity.com, Ed answers your questions related to information security threats.

ShareThis