Steve Shead Dot Com

A Slice of Me

All Entries Tagged With: "network"

Say Hello to My Little Friend Netstat

From: COMMAND LINE KUNG FU: PaulDotCom, Ed Skoudis, Hal Pomeranz, byte_bucket

Ed greets 2010:

Many times on our little blog here, I’ve spoken appreciatively of some of my favorite Windows command-line friends, including wmic, netsh, and sc. Yes, I’ve fought the desire to personify them, but I can’t help but think of them as buddies… Buddies with annoying quirks, a bad attitude, and flaws that sometimes let you down, but compadres nonetheless.

While spending some time over the holidays hanging out with these trustworthy sidekicks, something occurred to me: We haven’t spent nearly enough time on this blog with the good ol’ netstat command. Sure, we touched upon him a little bit in analyzing protocol statistics, checking out whether we’ve got a SYN flood, and even as an example of ways to get help from Windows commands. But, so far, I’ve truly let one of my most faithful and useful commands down by not giving him the spotlight he deserves. So, without further adieu, let’s look at some really useful invocations of netstat:

Detecting when a scan reaches a given target box: So, Mike Poor and I were at a client’s facilities conducting a large-scale vulnerability scan of thousands of hosts. Mike was running the scanning tool from the corporate headquarters, while I was located at another building sitting with the client in front of one of their Windows servers that was included in Mike’s scan. The client and I wanted to know when Mike’s scan would reach us. I asked the client if I could install a sniffer on their server, or connect my laptop to a span port on the switch so I could use my own sniffer to see when Mike’s scan reached us. “No dice,” said the client, who wasn’t authorized to let us install any software or get access to the switch. I asked the client if we could logon to the Windows server and run a simple single netstat command that would show us when Mike’s scan reached us, with approximately 1 second accuracy. He said, “Sure thing,” so I ran:

C:\> netstat -na | find /i "Listening"

Here, I’m just checking to make sure there is at least one listening TCP port, piping netstat’s output through the find command in a case-insensitive fashion (/i) because I didn’t want to hold down the shift-lock key to type LISTENING. Sure enough, on this Windows server, I saw several listening ports, including TCP 445. When Mike’s scanner reached us, it would open a connection to that port.

Then, I ran:

C:\> netstat -na 1 | find "[MikePoorIPaddr]"

That little space followed by a 1 means that Netstat will re-run approximately every 1 second. I scrape through its output looking for the string of Mike’s address. If I see no output, there is no connection from Mike. When I start seeing output, I’ll know that Mike’s scan has reached me. Sure, this isn’t perfect. It’s quite possible that the scanning tool will make and drop connections so quickly that they will fall in between the 1-second interval we’re working with here. However, that’s quite unlikely. And, sure enough, we were able to determine when Mike’s scan reached us, and finished with us. We then headed for lunch.

Detecting when a piece of malware starts interacting with the network: I was in my lab, fully clothed, analyzing some malware. After it finished some initialization actions, this little gem would start listening on TCP port 47145. Again, I wanted to know when it would start to listen, with 1-second accuracy… I ran:

C:\> netstat -na 1 | find ":47145"

I then wanted to go a little further, and find when the bad guy actually made a connection to this listener. For that, I executed:

C:\> netstat -na 1 | find ":47145" | find /i "Established"

Finding the mysterious cause of an ICMP Host Unreachable Message: A student who was taking my SANS 504 class told me that he was getting a mysterious ICMP Host Unreachable message coming from their border firewall back into their network a couple times per day, and he wanted to know what was triggering it. I asked him what the destination address of the packet was. It was one of their Windows 2003 servers. So, the Windows 2003 server was trying to send a message out through the firewall, but the firewall was responding that it didn’t know how to reach the destination machine. The student wanted to know which program on the Win2K3 box was sending the original message. I had him run:

C:\> netstat -nao 1 | find "[DestIPaddr]"

As long as that program was trying to make a TCP connection, we’d see output from netstat for the half open connection, and could see the process ID number (the -o in netstat gives me the PID of the process using the port). We were then able to run the wmic command to get all kinds of info about that process:

C:\> wmic process where processid="[pid]" list full

Playing process whack-a-mole: I was playing a king-of-the-hill style capture the flag game, and my adversaries were trying to listen on a given TCP port on the target box, which I had already compromised. I wanted to simply kill any process that started on that port as quickly as possible. The netstat invocations listed above are quite nice, but they don’t really help much for this need. You see, putting the integer after the netstat invocation makes netstat run continuously, showing us its output every 1 second. We can scrape through that output with the find command, but we cannot then run any other command after that, such as a taskkill. That’s because netstat never stops running, so we cannot kickoff another command. For this, we’ll have to wrap things in a FOR /L loop to get our continuity of operation, and in a FOR /F loop, to parse out the PID from our netstat output, as follows:

C:\> for /L %i in (1,0,2) do @for /f "tokens=5" %j in ('netstat -nao ^| find ^":47145^"') do @taskkill /f /PID %j SUCCESS: The process with PID 3152 has been terminated. SUCCESS: The process with PID 2432 has been terminated. SUCCESS: The process with PID 4068 has been terminated.

Here, I’ve simply set up a FOR /L loop to count from 1 to 2 in steps of zero to implement a continuous loop. Then, at each iteration through the loop, I run a FOR /F loop set to parse the fifth column (the PID) from the output of a netstat -nao command, whose output itself is filtered by the find command looking for our port. Once I’ve got my PID, I then use taskkill to forcefully (/f) kill that PID. The evil listening process cannot listen for very long now.

Note that I’ve eliminated the 1 second delay — this thing will run as fast as it can, useful in a CtF game as long as you aren’t worried about being a performance hog. If you want a delay, we can simply add “& ping -n 2 127.0.0.1>nul” inside our FOR /F loop to ping ourselves twice (which takes about 1 second), as follows:

C:\> for /L %i in (1,0,2) do @(ping -n 2 127.0.0.1>nul & for /f "tokens=5" %j in ('netstat -nao ^| find ^":47145^"') do @taskkill /f /PID %j)

Create a real-time network sentinel by adding a date and timestamp and dumping process info: Now, let’s really get jiggy with it. Instead of killing processes or using the above commands in an interactive mode, wouldn’t it be nice if we could run a command that would just watch a given TCP port, and when it finds something using that port, it displays the date/time and various vital aspects of that process? Of course it would!

But, we’d only want it to print information when a new processID starts to listen on the given port. That way, if one process starts and listens for a while, and then stops, and another starts up, we would capture on our output the time and details of each process that interacted with the port, a diligent sentinel gathering data for us. That would allow us to run a command that can watch for given network activity over night, and then come back to see what happened and when it happened later. I use this concept and the resulting command a lot during investigations. Check this out:

C:\> cmd.exe /v:on /c "set status=0 & for /l %i in (1,0,2) do @for /f "tokens=5" %j in ('"netstat -nao ^| find ":47145""') do @if NOT !status!==%j echo !date! !time! & wmic process where processid="%j" list full & set status=%j"
Sun 01/03/2010 5:36:47.79

CommandLine=nc -l -p 47145 CSName=FRED2 Description=nc.exe ExecutablePath=C:\tools\netcat\nc.exe ExecutionState= Handle=3116 HandleCount=33 InstallDate= KernelModeTime=0 MaximumWorkingSetSize=1413120 MinimumWorkingSetSize=204800 Name=nc.exe OSName=Microsoft Windows XP Professional|C:\WINDOWS|\Device\Harddisk0\Partition1 OtherOperationCount=208 OtherTransferCount=124718 PageFaults=475 PageFileUsage=540672 ParentProcessId=3584 PeakPageFileUsage=540672 PeakVirtualSize=14987264 PeakWorkingSetSize=1953792 Priority=8 PrivatePageCount=540672 ProcessId=3116 QuotaNonPagedPoolUsage=2376 QuotaPagedPoolUsage=29780 QuotaPeakNonPagedPoolUsage=2376 QuotaPeakPagedPoolUsage=29924 ReadOperationCount=5 ReadTransferCount=15977 SessionId=0 Status= TerminationDate= ThreadCount=1 UserModeTime=300432 VirtualSize=14987264 WindowsVersion=5.1.2600 WorkingSetSize=1953792 WriteOperationCount=1 WriteTransferCount=72

In this command, I start by running a cmd.exe with /v:on to enable delayed variable expansion. I’ll need that, because I need to store status to track if the PID using the port changes. I then set my initial status to zero, since no process should have that PID. I then start a FOR /L loop to run everything continuously. Then, I run a FOR /F loop to invoke my netstat command, piping its output through the find command to look for that port (47145, although you could also look for an IP address, as shown earlier in the article). I take the fifth column of output, the PID, and store it in iterator variable %j. Then, in the do clause of my FOR /F loop, I use an IF command to see if my status has changed (if the status variable is NOT the same as my PID, it has changed since the last iteration). When I detect such a change, I print out the date and time (note that !status!, !date!, and !time! have the exclamation points because I want their values to float over time with delayed variable expansion). I also run wmic to get full details of the given process. Finally, I set my status to the current PID. That way, I can check to see if it changes in the next go-round. This may look complicated, but it is darn useful. I’m simply dumping output to the screen here, but you could append it to a results file if you’d like by using >>results.txt at the end.

As you can see, there are a lot of fun things my little friend netstat can do using these building blocks.

Hal jumps in:

It’s always been interesting to me how much Windows completely ripped off the Windows netstat command is like the Unix version. With some minor changes, most of Ed’s examples work perfectly well on most Unix systems. Obviously, you end up using “grep” instead of “find” to filter the output, but the netstat options are almost 100% compatible. Here’s the Unix equivalent of Ed’s first netstat command as an example of what I’m talking about:

$ netstat -na | grep -i listen

Note that the output that Ed wants to match in this example is “LISTEN” in the Unix universe, not “LISTENING”.

One important difference between Unix and Windows netstat is the way you get netstat to run continuously rather than producing one set of output and then exiting. With the Unix version, you need to use “-c” to specify continuous mode:

$ netstat -nac | grep <Mike's IP addr>

The interval for “-c” is fixed at one second– you can’t specify your own interval like you can with Windows. If you want to use a less frequent interval, you’ll have to write your own loop and use “sleep”, like so:

$ while :; do netstat -na | grep <Mike's IP addr>; sleep 5; done

Frankly, though, I think I’d just use our old friend the “watch” command instead of either “netstat -c” or the loop option:

$ watch -n 1 'netstat -na | grep <Mike's IP addr>'

The watch command is not only quicker to type than the loop, it allows us to easily choose our preferred monitoring interval, which we can’t do with “netstat -c”.

But really I wouldn’t use netstat for this at all as long as I was on a machine that had the lsof command installed. With lsof, not only can I do this in less keystrokes, but I’ll also get more information than I would from the netstat. lsof is *my* little friend and the friend of Unix admins everywhere.

The downside is that you usually have to be root to get complete output from lsof:

# watch -n 1 lsof -nPi @<Mike's IP addr>

“lsof -i @<ipaddr>” show you all connections related to the specified IP address. As with netstat, “-n” suppresses IP address to hostname mappings. However, while “netstat -n” also suppresses port number to port name mappings, lsof wants you to use the “-P” option to show numeric port numbers.

We can also use lsof to do something similar to Ed’s port monitoring examples:

# watch -n 1 lsof -nPi :47145

Notice that you prefix port numbers with a colon when using lsof, while IP addresses are prefixed with “@” as we saw above. This allows us to stack IP address and port combinations to be even more specific. For example, suppose I was interested in SSH connections to a particular box, I could write:

# watch -n 1 lsof -nPi tcp@<ipaddr>:22

The above example also shows how to specify a particular protocol type (usually “tcp” or “udp”) along with the IP address and port information. If I just wanted SSH connections to all IP addresses, I could do:

# watch -n 1 lsof -nPi tcp:22

Another advantage to using lsof instead of netstat is that lsof’s “-t” option makes “process whack-a-mole” dead easy:

# while :; do kill -9 `lsof -t -i :47145`; done

As we discussed back in Episode #69, “lsof -t” just outputs the PIDs of the matching processes. This means it’s easy to kill those processes by using backticks and the kill command as we’re doing here.

Ed’s final monitoring loop is interesting. Here’s how I’d do something similar on a Linux machine:

# while :; do pid=`lsof -ti :47145` [[ "X$pid" == "X" || "X$pid" == "X$lastpid" ]] && continue lastpid=$pid echo -n '*** ' date ps e --cols 1600 -fl -p $pid lsof -p $pid done

I’m first getting the PID of the process we’re interested in using “lsof -t…”. If there’s currently no PID associated with this port, or if the current PID is the same as the previous time we ran the loop then we just start the loop all over again.

Otherwise I update the value of $lastpid and output some info about the new process. You could choose to use whatever commands you want, but here I start by throwing out some asterisks with “echo -n” so that it’s easier to find the start of each section of output. Then I follow that up with the date command to get a timestamp. Since I used “echo -n”, the date output will appear on the same line as the asterisks.

Then I use the ps command to dump some information about the process. “ps e” will dump any environment variables that are set in the process context. Since this output tends to be long, I also add the “–cols 1600″ option to specify the screen width as a larger value so that the output doesn’t get truncated (on narrower displays, the lines will simply wrap). I also use “-fl” to get the most detailed output possible. The “-p” option is used to specify the PID we’re interested in. While the ps command will give us plenty of output, I’m also using lsof to dump information about all of the open files associated with the process.

It’s worth noting that both Ed’s loop and mine assume that only one process at a time is ever going to be associated with the port we’re monitoring. But if the port is a back-door login port, you might actually have multiple connections to the port at the same time. I’d finesse this in bash by using an array to track multiple PIDs at the same time, but I think it would be next to impossible for Ed to deal with this in cmd.exe.

Tim leaps in:

Of course we can use netstat in PowerShell, but it would be mostly redundant (with the exception of the all of Ed’s For Loops). Also, Hal seems upset about Windows “stealing” netstat so let’s try the same thing in PowerShell without using netstat. Without netstat we will have to use the .NET framework available to us through PowerShell.

Here is the PowerShell and .Net equivalent of the first netstat command.

PS C:\> ([Net.NetworkInformation.IPGlobalProperties]:: GetIPGlobalProperties()).GetActiveTcpListeners() AddressFamily Address Port ------------- ------- ---- InterNetwork 0.0.0.0 80 InterNetwork 0.0.0.0 135 InterNetwork 0.0.0.0 445 InterNetwork 192.168.1.5 139 ...

Most of the information we are going to need is accessed via the IPGlobalProperties object’s methods and properties. Since we are going to be using it a lot let’s dump it into a variable so we can save keystrokes in future commands.

PS C:\> $a = [Net.NetworkInformation.IPGlobalProperties]::GetIPGlobalProperties()

Now we can run the first command again like this:

PS C:\> $a.GetActiveTcpListeners()

The name of this method is pretty self explanatory, it returns the active TCP listeners. Not much to talk about, so we’ll move on.

The next task is to find out when Mike connects.

PS C:\> while (1) {$a.GetActiveTcpConnections() | ? {$_.RemoteEndPoint.Address -eq "[MikePoorIPaddr]"} }

We use a while loop that will run forever since “1″ is always true (except for very small values of 1). Then we get the active TCP connections and look for Mike’s IP address.

This will really hit the processor, so we probably should put in a delay of a at least a half a second.

PS C:\> while (1) {$a.GetActiveTcpConnections() | ? {$_.RemoteEndPoint -like "[MikePoorIPaddr]:*"; sleep -milliseconds 500}}

…or maybe two seconds

PS C:\> while (1) {$a.GetActiveTcpConnections() | ? {$_.RemoteEndPoint -like "[MikePoorIPaddr]:*"; sleep 2}}

So no we move on to the malware that Ed was analyzing. In the example, the port to be monitored is TCP 47145.

PS C:\> $a.GetActiveTcpListeners | ? {$_.Port -eq 47145}

We get the active tcp listeners and then filter the results for connections where the local port is 47145.

Now we have the problem of killing the process. Without using netstat we don’t have a way to determine the PID. It looks like we will have to cave in an use our old friend netstat (even though Hal is trying to poison this friendship).

PS C:\> netstat -ano | ? {$_ -like "*:47145 *"} | % { $_ -match "\d+$"; stop-process $matches[0] }

The output of netstat is filtered for connections on port 47145. Using a regular expression inside the ForEach-Object loop we look for a number at the end of the line. In regular-expression-land \d+ means at least one numeric digit and $ means it has to be at the end of the line. The number that we found is represented by the $matches object so we use the first and only match, $matches[0], with stop-process to kill it.

Ed’s grand finale, the monitoring loop done in PowerShell.

PS C:\> while(1) {netstat -ano | ? {$_ -like "*:47145 *"} | % { $_ -match "\d+$"; Get-Process -id $matches[0] | Format-List *; (Get-Process -id $matches[0]).WaitForExit() } }

While it ain’t pretty, I think we can safely say that the PowerShell version is the easiest to read of the bunch (finally), but I did add a few extra line breaks and spaces to make it even easier to read. How does it work?

First, we have our friendly infinite while loop. Nested inside the loop is our netstat command and our filter to search for port 47145. As before, we use the match operator to find the PID. Then we get all of the properties for the process. Piping the Get-Process command into Format-List * will display all the properties, not just the most commonly used properties. Finally we wait for the process to end and then our loop continues from the beginning. By using the WaitForExit method we know when that process dies and we can look for a new process. We don’t have to worry about finding, keeping track of, and comparing the PID. It makes it much easier and cleaner. It also has the added benefit of being very light on system resources while it is waiting.

admin | Jan 05, 2010 | Comments 0

Man-in-the-middle attacks demoed on 4 smartphones

Security researchers from SMobile Systems have released a paper detailing successful man-in-the-middle attacks against several smartphones.

The SSL enabled log in sessions on the tested, Nokia N95, HTC Tilt, Android G1 and iPhone 3GS devices was sniffed using the publicly available SSLstrip tool, with the attack taking place over insecure Wi-Fi network, now prevalent literally everywhere. Here’s the scenario they used, and possible mitigation approaches:

“The attacker visits the same cafe that offers a free Wi-Fi hotspot and decides to employ basic host, network identification and enumeration tools from the laptop to enumerate all the active devices connected to the Wi‐Fi hotspot. From the results, the attacker notices a MAC address referring to a Nokia smartphone. The attacker know that there is little to no detection capabilities present on an overwhelming majority of smartphone’s in use today, so the owner would likely never find out about a successful man-in-the-middle- attack (MITM).

The well-informed attacker creates a successful MITM attack. In the meantime, the smartphone owner accesses the online bank website and enters the login credentials required to gain access to the banking information. In this scenario, all of the communication between the smartphone and the online bank site is routed through the attacker’s machine and the attacker can see the login details in plain text, as well as can capture all the sites accessed by the victim.”

The awareness-raising test aims to educate users on approaching convenient and free, public Wi-Fi networks with caution, emphasizing on how their mobile service provider’s 3G connection, or the one offered by a trusted Wi-Fi network should always be considered as their first choice.
Anyway, just how insecure or susceptible to compromise are the majority of Wi-Fi networks found on high-trafficked locations such as airports or international cities? The answer is sadly, self-evident with data backing it up available publicly.

Go through related posts: GPU-Accelerated Wi-Fi password cracking goes mainstream; D-Link router’s CAPTCHA flawed, WPA passphrase retrieved; Survey: 88% of Mumbai’s wireless networks easy to compromise

Last year, AirTight Networks conducted a major wireless network security study by visiting 14 airports (11 in the U.S and 3 in the Asia-Pacific) and found out that a huge percentage of the 478 Wi-Fi Access Points analyzed are either open, or using outdated encryption protocols. Even more interesting was the fact that users were falling victims to “viral” Wi-Fi networks using descriptive and lucrative names seeking to establish legitimacy.

The prevalence of such “handy”, but easy to compromise Wi-Fi networks internationally, is virtually the same. For instance, similar wardriving tests conducted in Paris; Santiago, Chile; China; Monterrey — Mexico, Sao Paulo – Brazil, Caracas (Venezuela), Warsaw, and London offer similar insights into the “security” of such public networks.

Possible mitigation practices? According to Marlinspike, the author of the tool:
Cautious users, for example, have been advised to explicitly visit https URLs or to use bookmarks in order to protect themselves from sslstrip, while other SSL/TLS based protocols such as imaps, pop3s, smtps, ssl/irc, and SSL-based VPNs never present an opportunity for stripping. This talk will outline some new tools and tricks aimed at these points of communication, ultimately providing highly effective attacks on SSL/TLS connections themselves.
How often do you face the trade-off of using a public, and possible insecure Wi-Fi hotspot, for the sake of convenience instead of sticking to your 3G data plan, even when traveling abroad?

Have you ever avoided using your mobile device and instead used your laptop at an airport, due to your host-based firewall’s better ARP filtering features — if any — enabling the detecting of changed MAC address for a (trusted) gateway network adapter in order to detect possible MItM attempts?

How EV SSL-aware is your E-banking provider, especially if you’re E-banking over a mobile device? Or do you simply “VPN-and-forget” over a public Wi-Fi network?

admin | Nov 17, 2009 | Comments 0

Fishing for Network Configs

From: COMMAND LINE KUNG FU: PaulDotCom, Ed Skoudis, Hal Pomeranz, byte_bucket

Ed kicks it off:

Man, we’ve covered a lot of topics in our 54 episodes prior to this one. But, in our rush to get you the latest chocolate-covered command-line fu, occasionally we’ve missed some fundamentals. People write in with questions (which we love) about such items, inspiring a new episode. Back in May, we received a great question from Johnny C:

> I have a suggestion for command line kungfu.
> I need to be able to change my IP Address back and forth from DHCP
> where everything is dynamic to a dedicated IP address.
> I’ve worked with this for a while and my problems have been not able
> to update DNS on Windows

Ah… good one, sir! Let’s face it: the built-in Windows GUI associated with network configuration changes is horrible… forcing numerous clicks through various screens to make even small tweaks. At least we don’t have to live through the dreaded reboots of the Windows 95 era just to change IP addresses anymore.

On Windows, for manipulating network configs at the command line, netsh rocks, and it can do what you want, Johnny C, and much more. In fact, when I’ve got a lazy summer afternoon with nothing better to do, I fire up netsh (or the equally fun and interesting wmic command) and just explore, sometimes for hours on end. The netsh command (like wmic) can run in two modes: either as a little command interpreter of itself (by typing netsh and hitting Enter) lending itselve to exploration, or as a single shot command of netsh followed by various options.

To get a glimpse of the capabilities of netsh, run the following:

C:\> netsh netsh> ?

The following commands are available:

Commands in this context: .. - Goes up one context level. ? - Displays a list of commands. abort - Discards changes made while in offline mode. add - Adds a configuration entry to a list of entries. advfirewall - Changes to the `netsh advfirewall' context. alias - Adds an alias. bridge - Changes to the `netsh bridge' context. bye - Exits the program. commit - Commits changes made while in offline mode. delete - Deletes a configuration entry from a list of entries. dhcpclient - Changes to the `netsh dhcpclient' context. dump - Displays a configuration script. exec - Runs a script file. exit - Exits the program. firewall - Changes to the `netsh firewall' context. help - Displays a list of commands. http - Changes to the `netsh http' context. interface - Changes to the `netsh interface' context. ipsec - Changes to the `netsh ipsec' context. lan - Changes to the `netsh lan' context. nap - Changes to the `netsh nap' context. netio - Changes to the `netsh netio' context. offline - Sets the current mode to offline. online - Sets the current mode to online. p2p - Changes to the `netsh p2p' context. popd - Pops a context from the stack. pushd - Pushes current context on stack. quit - Exits the program. ras - Changes to the `netsh ras' context. rpc - Changes to the `netsh rpc' context. set - Updates configuration settings. show - Displays information. unalias - Deletes an alias. winhttp - Changes to the `netsh winhttp' context. winsock - Changes to the `netsh winsock' context. wlan - Changes to the `netsh wlan' context.

Nice! Lots of very useful stuff, including “interface” and “firewall” (the latter of which we discussed in Episode #30). There’s also some really nifty settings for ipsec (on 2003 and later) and wlan (on Vista and later) contexts. To change to an individual context, just type its name (such as “interface”) and then type ? at the netsh> prompt to get more info about it. You can then navigate down by entering follow-up commands and contexts, and then pop back up to earlier contexts entering a command of dot-dot (“..”). I wish there was a “back” command instead of .., but I can cope. There’s even a pushd and popd command for netsh contexts, rather similar to the pushd and popd for directories we discussed in Episode #52.

One of my most common uses of netsh is to change IP address settings of the machine. In the spirit of the cliche “Give a man a fish and feed him for a day… teach him to fish and feed him for life”, let me show you how you can fish around inside of netsh.

We first invoke netsh and then move to the interface context:

C:\> netsh netsh> interface netsh interface> ?

Here, you can see options for various elements we can configure on the machine. Of particular interest to us now is ip (on XP and 2003) or ipv4 (on Vista and later). Happily, you can just type “ip” on Vista, and it will take you to the ipv4 context, so our netsh commands for changing addresses and such are compatible between various versions of our beloved Windows operating system.

netsh interface> ip netsh interface ip> set ?

Now, we can get a sense of the various items we can set, including addresses, dns, and wins. But, wouldn’t it be nice if Windows would give us examples of how to set each? Well, ask and ye shall receive:

netsh interface ip> set address ? Usage: set address [name=] [[source=]dhcp|static] [[address=][/] [[mask=] ] [[gateway=]|none [gwmetric=]] [[type=]unicast|anycast] [[subinterface=] ] [[store=]active|persistent]
Examples:

set address name="Local Area Connection" source=dhcp set address "Local Area connection" static 10.0.0.9 255.0.0.0 10.0.0.1 1

If you’d like to get a list of all interfaces available on the machine, you could run (from the normal C:\> prompt, not within netsh):

C:\> netsh interface show interface

I know… it looks like it is redundantly repeating itself twice back to back, and it is. But, that’s the command. Now, we know how to refer to our network interfaces for manipulating them.

Then, to set an IP address, we could just run the command:

C:\> netsh interface ip set address name="Local Area Connection" static 10.10.10.10 255.255.255.0 10.10.10.1 1

This will set our IP address to 10.10.10.10, with a netmask of 255.255.255.0, a default gateway of 10.10.10.1, and a routing metric (number of hops to that gateway) of 1.

For DHCP, we simply run:

C:\> netsh interface ip set address name="Local Area Connection" source=dhcp

OK…. now to answer Johnny C’s specific question, setting our primary DNS server:

C:\> netsh interface ip set dnsserver name="Local Area Connection" static 10.10.10.85 primary

And, if you’d rather get that info from DHCP, you could use:

C:\> netsh interface ip set dnsserver name="Local Area Connection" source=dhcp
I frequently find myself changing between my laboratory network and my production network, which have completely different IP addressing schemes. To help make a quick switch between them, I don’t use those one of those goofy network configurator GUIs, because, well, they are kind of tawdry. Instead, I’ve created two simple scripts that I keep on my desktop: test.bat and prod.bat. Each one contains two netsh commands. The first command sets my IP address, netmask, and default gatewy for either prod or test, and the second command sets my DNS server. When I want to invoke them, I simply run them with admin privs (based on either being logged in as admin, or right clicking and selecting “run as administrator”).

Hal kicks it old school:

Where the Windows way is to have one big command that does everything, remember the Unix design religion is to have a bunch of small commands that do simple things and then combine them to produce the effect you want. It doesn’t help that Unix systems have been networked devices since the earliest days of the Internet– we’ve got multiple generations of command interfaces to deal with. But let me try to hit the high points.

Suppose our system is normally configured to use DHCP but we want to manually move it onto a new network with a static address assignment. Step one is to change your IP address with the ifconfig command:

# ifconfig eth0 10.10.10.1 netmask 255.255.255.0 # ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:0C:29:18:C3:0D inet addr:10.10.10.1 Bcast:10.10.10.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe18:c30d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:55 errors:0 dropped:0 overruns:0 frame:0 TX packets:158 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:7542 (7.3 KiB) TX bytes:32712 (31.9 KiB) Interrupt:18 Base address:0x2024
As you can see from the example above, you can also use ifconfig to display information about an interface’s configuration (“ifconfig -a” will display the configuration information for all interfaces on the system).

However, changing the IP address with ifconfig doesn’t have any impact on your routing table. You’ll probably need to add a default route when you change the IP address:

# route add default gw 10.10.10.254 # netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 10.10.10.254 0.0.0.0 UG 0 0 0 eth0

I should note that as you move from on Unix distribution to another, the route command syntax tends to change in minor ways, rendering a command that is syntactically correct on one system completely useless on another. The above example is for Linux. Oh and by the way, if your DHCP configuration has created a default route for the network you used to be on, you can remove it with “route del default gw “.

The last thing you have to do is update your list of local DNS servers. This list is configured in /etc/resolv.conf. Most DHCP clients will simply overwrite the contents of this file with the name servers and local domain they learn from their DHCP servers, but you can also edit this file directly. A sample file might look like:

nameserver 10.10.10.100 search somedomain.com

Replace “somedomain.com” with the default domain you want the host to use for looking up unqualified host names. You can have multiple “nameserver” lines in your file for redundancy. However, I warn you that the timeout on the first lookup is long enough that your users will pick up the phone and call you to tell you the “network is down” before the system fails over to the next name server in the list.

The combination of ifconfig, route, and editing your resolv.conf file should be sufficient to get you manually moved onto a new network. The more interesting question is how to you revert back to using DHCP to configure your network interface? Assuming your machine is configured by default to use DHCP, the easiest thing is to just shut down and then reactivate your network interface. Of course the process for doing this is completely different for each Unix system you encounter. On most Linux systems, however, the following will work:

# ifdown eth0 # ifup eth0

Determining IP information for eth0... done. # ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:0C:29:18:C3:0D inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe18:c30d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:56 errors:0 dropped:0 overruns:0 frame:0 TX packets:228 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:7884 (7.6 KiB) TX bytes:44273 (43.2 KiB) Interrupt:18 Base address:0x2024

By the way if you’re looking for your static network interface configuration information, you’ll find it in /etc/sysconfig/network-scripts/ifcfg-eth0 on Red Hat systems (including CentOS and Fedora) and in /etc/network/interfaces on Debian systems. This is the place where you can set the default interface configuration parameters to be used when booting. Be aware, however, that on modern Ubuntu systems network configuration is under the control of NetworkManager by default– a GUI-based network configuration tool very reminiscent of the Windows network configuration GUI. Helpful for people coming over from the Windows environment I guess, but kind of a pain for us old farts who are used to configuring network interfaces with vi.

admin | Aug 11, 2009 | Comments 0