Understanding Bash STDOUT / STDERR using Hping3

Commands run on bash prompt can output content to standard output (STDOUT) and standard error (STDERR)

If you wish to suppress some data, it can be done by redirecting content from either sources to /dev/null. Alternate notations for the above are :



/dev/null refer to the Null Device File that discards all data written to it (http://en.wikipedia.org/wiki/Null_device)

Taking the example of hping3, we can see different outputs as below

The default output of hping3 is sent to both STDOUT and STDERR. The ping responses are sent to the STDOUT, whereas the packet summary/statics is sent to STDERR

Default Output

Default Output

When we send the output from hping3 to /dev/null, only the STDOUT is sent to /dev/null. The other part of the output is not sent to /dev/null as it is actually sent to STDERR

STDOUT to /dev/null

STDOUT to /dev/null

If we want to send the STDERR to /dev/null, we can do the same using the notation 2> . As mentioned earlier the integer notation for STDERR is ‘2’. Thus ‘2>’ represents redirecting STDERR to non-standard location.

STDERR to /dev/null

STDERR to /dev/null

If you don’t want any output from a command, you can simply redirect STDERR to STDOUT which in-turn is redirected to /dev/null

Both STDERR and STDOUT to /dev/null

Both STDERR and STDOUT to /dev/null

If in some weird use-case you wish to push everything to STDERR, it can be done using 1>&2



Knowing how to redirect STDOUT and STDERR is very useful when scripting in bash.

Hacking Guest Wifi Networks

(Cross-posting from my organization’s blog – http://niiconsulting.com/checkmate/2014/03/insecure-implementation-guest-wireless-networks/)

Most large organizations provide wireless facilities for their guest, which may include vendors, consultants, business associates, employees from other regions etc.

Certain points should be considered while implementing a guest wireless network.

  1. Encryption in use
  2. Captive Portals or Guest Authentication
  3. Network Segregation

Finding the SSID of a Hidden wireless network

To simplify the connectivity for guest devices some organizations configure their networks without encryption i.e. ‘OPEN’. To prevent un-authorized entities from connecting to their networks most of these networks are configured as HIDDEN. As is well known, this configuration does not really provide any security. It is simply a method of obfuscation (Non-Broadcast Wireless SSIDs Why hidden wireless networks are a bad idea).

To identify the SSID of a hidden network you would need:

  1. Wireless adapter which supports packet injection (http://www.aircrack-ng.org/doku.php?id=compatible_cards)
  2. Aircrack-ng wireless suite (http://www.aircrack-ng.org/)

I will be using an Alfa AWUS036H adapter. This card is well supported by Aircrack-ng.

Continue reading

How-to: Modify Apache-Coyote/1.1 Banner

If you’ve ever done a penetration test or got one done, you may have come across the following scenario:

HTTP Service running on port 8080, revealing the version information of the product in it banner.
The banner  revealed is Apache-Coyote/1.1.
This is the banner of the Apache Tomcat Web Server which runs on port 8080 by default.

Apache-Coyote/1.1 Version Disclosure

Now, as per good security practice, the banner should be removed or modified, so that it no longer reveals the version number.
This can be achieved by editing your server.xml configuration file found at the below location:


Original server.xml reveals version information

Modified server.xml

You may need to restart your server for the changes to reflect.
Once the Tomcat server is up, test the server to see if it shows the custom header.


> telnet localhost 8080

Web Server with Custom HTTP Banner


Hope this helps others who are looking for a solution to the banner version disclosure

Check out OWASP’s article on Securing Tomcat for more details.