Tag Archives: DoS

Old Skills – Still Valuable

I have been working with various Linux distributions much more these days than in the past. Spending all that time in the shell has flooded the mind with memories of days gone by. When we used to have to know our systems well to properly configure the simple task of booting (config.sys and autoexec.bat), we had to master many technical skills. I am amazed, nearly every day, at how often those old skill still prove valuable to me.

Remember screens like this?

Config.sys in Edit
The mem Command

If not, you didn’t work with DOS. If so, you did. If not, don’t distress, you can learn the skills you need to get by in the Windows Command Prompt, PowerShell or the shell in a Linux distribution.

In this post, I’m going to focus on three skills we had to master in the DOS days that are still valuable today. They were:

  1. Getting Help
  2. System Diagnostics with Commands
  3. Automating Work

Getting Help

At the DOS prompt (and still in the Command Prompt or PowerShell in Windows and the shell in Linux) help was always just a simple switch away. For nearly every command or program, you could simply add a /? to the command to find out exactly what the command could do. Those who learned (and still learn) commands this way are always more powerful users or administrators than those who simply learn specific command parameters for specific tasks from books, blogs and articles.

The reason for this reality is simple: when you use the help to see all the command can do, you often learn of uses that others have not demonstrated or used themselves.

Consider the mem command shown earlier from DOS. If you simply typed mem and pressed ENTER, you saw a screen like the following.

Simple mem Command Output
Simple mem Command Output

Now look at all you learned about the mem command if you used the /? parameter.

Getting Help for the mem Command
Getting Help for the mem Command

I can already hear someone saying, “Wait, Tom. The mem command is not in the Windows Command Prompt anymore. How does this help?” That’s a great question. The answer is that you can find other commands, related to memory, that you can use and use with power when you learn to get help. Consider the tasklist command in Windows.

The following screen shows the output of a basic tasklist command with no parameters:

Raw tasklist Command Output
Raw tasklist Command Output

It is showing every process, regardless of the memory consumed by it. Now, look at the help for the tasklist command using the /? parameter.

tasklist Help
tasklist Help

Notice that you can do several things to refine the list, particularly in relation to memory usage.

Armed with this information, I can now use the /FI filter parameter to see only tasks consuming more than 15,000 kilobytes of memory with the tasklist /FI “MEMUSAGE gt 15000” command.

Filtering for High Memory Usage Tasks with tasklist
Filtering for High Memory Usage Tasks with tasklist

As you can see, getting help is key to learning Command Prompt or shell commands. In Linux, you typically use the —help parameter for this. In PowerShell, use the Get-Help cmdlet to accomplish this.

System Diagnostics with Commands

The old DOS prompt gave us several tools for performing system diagnostics. In addition to the mem command, you had commands like checkdsk, ver (both still in the Command Prompt), and  undelete (sadly, no longer with us). The Command Prompt is actually far more powerful today in Windows than it ever was in DOS. Dozens of additional commands are available for diagnostics. In addition to tasklist, important commands include:

  • sc – service management
  • ipconfig – IP configuration viewing and management
  • netsh – a plethora of networking functions
  • systeminfo – viewing information about hardware and software
  • ftype – working with file associations

This is a very brief starter list. Type help at the Command Prompt (just like in DOS by the way) to see a list of common commands as shown in the following image. Remember to use the /? parameter with them to learn all the details of how they work.

Partial Output from the Command Prompt help Command
Partial Output from the Command Prompt help Command

Automating Work

Finally, you can automate the Command Prompt using batch files and PowerShell or the Linux shell using scripts (PowerShell scripts and bash scripts respectively). The batch files work almost entirely the same in the Windows Command Prompt today as they did in DOS 25+ years ago when I used them. Of course, some of the old commands are gone, but the logic and concepts are still the same.

The point of this post is simple. Never discount old knowledge. It continues to benefit you today. In fact, I can say plainly that I passed a certification exam a couple of years ago almost entirely because I knew DOS all those years ago. And, yes, I still have my old DOS books including great books on batch files. Here’s a picture of just one.

Inside MS-DOS 6.22
Inside MS-DOS 6.22

And, yes as well, the Disk is still included after all these years 🙂

Happy shelling!

You Cannot Prevent a Wireless DoS Attack (wireless denial of service attack)

I'm not sure why it's such a big deal to me, but I get very frustrated by articles and blogs with titles like the following:

How to prevent wireless DoS attacks

I think it's because, um, YOU CAN'T! You simply cannot prevent a wireless DoS attack against the RF layer of the network.

Don't let wireless intrusion prevention system (WIPS) vendors fool you. You can detect a wireless denial of service (DoS) attack, but you cannot prevent it if it is an RF-level attack. Sure, if it's a frame level attack, you can prevent it through algorithms and dynamic network configuration management procedures. But if you're dealing with a physical level (RF) DoS attack, you can only remove it once the source is located – you cannot prevent it.

All I need is a 2.4 GHz RF generator and I can blanket the entire 2.4 GHz license free ISM band that is used by 802.11 b/g/n. With a 5 GHz RF generator, I could potentially do the same for the U-NII bands used by 802.11a/n. The point is that an RF generator or set of such generators can completely saturate the available spectrum with energy levels that prevent functional communications on any allowed channel. Dynamic channel management and "self-healing" solutions cannot help with this.

A good old fashioned human being with a spectrum analyzer is one of the best ways to locate a physical layer wireless DoS attack. WISP solutions may also be able to triangulate the source of the attack if sensors or multi-purpose access points (access points that both provide wireless functionality and sensing abilities) are used; however, it's not like the WIPS system can somehow zap the attacking device and kill it (though that's a nice thought for the future). The end result is that a physical layer DoS simply CANNOT be prevented. It can only be mitigated (i.e., the severity is reduced by detecting it quickly, locating it and eradicating it).

Personally, I find no greater joy in my IT work than tracking down an attacker and letting him see me with my spectrum analyzer as he flees in fear (and I memorize is license plate number to report him to the police). Would I really even want a software program and hardware set to take away that joy?

Inventors of the world, if you can find a true solution that truly prevents wireless denial of service attacks, you can make billions. Get started.

UPDATE: About an hour after first writing this post I was extremely annoyed by the following press release:


Notice the press release uses the phrase DoS attack prevention, but then the actual press release admits frankly that all it does is "counter wireless DoS attacks". My point is still the same: On a wired network, you can immediately shut of the port from which a DoS attack is originating . This can be accomplished in just a few seconds. You cannot accomplish this today when a wireless DoS attack is launched against the entire unlicensed spectrum in which your wireless LAN operates. Please, vendors, just be honest and quit using the word prevent in relation to wireless DoS attacks!