Using idle scanning can reveal sensitive configuration information about targets via a side channel. Not only can this type of scan show services that might otherwise be invisible, it is also completely passive. This means that the target of the scan will never observe traffic from the actual source of the scans. Only the idle host will be aware of any contact with the scanning machine. This can allow attackers to perform reconnaissance to either perform a completely hidden scan, for instance by using an idle zombie in a third party organization making it extremely difficult to trace the origin of the scan, or to map trust relationships in an organization by using a zombie target within the target organization.
The EFF recently posted a "Call to Action" for an Open Wireless Movement (https://www.eff.org/deeplinks/2011/04/open-wireless-movement). The article lays out some compelling reasons for allowing open access to home wireless internet connections. The main reason they cite is civic duty, or community service. They state that providing digital access is a social responsibility that makes the world a better place.
The NSA has published a great guide on securing home internet connections titled "Best Practices for Keeping Your Home Network Secure" at http://www.nsa.gov/ia/_files/factsheets/Best_Practices_Datasheets.pdf. This fact sheet provides a lot of helpful guidance to Windows and Mac users. Sadly, it doesn't include any recommendations for Linux users. Aside from this notable shortcoming the document provides some great security tips for traditional, as well as emerging technologies.
Yesterday I was alerted to yet another reason why I don't trust my mobile platform. Even though I use Google Android, which is "open source" and even though I consider my self relatively privacy aware, an article in Tech Republic points out that Google is storing the keys to my wireless access points. These keys are the equivalent to passwords for these access points.
Securing an SSH server is a simple process that many administrators overlook. The following are four simple steps you can take to help lock down your SSH server. Given the widespread nature of SSH brute force attacks it is well worth the effort to enforce some extra restrictions on your SSH server. Most of the suggestions outlined below rely on configuration changes that can be implemented in your sshd_config file. Note there are two separate configuration files, ssh_config, and sshd_config on most installations. Be sure to edit the sshd_config file (the d is for daemon, or the SSH service).
Public keys are a great way to log into a remote machine without having to provide a password. This diminishes your security posture somewhat, but done right this can be mitigated. Using public keys allows you to leverage secure protocols like SSH in scripts and automation. Because the public key means there is no password challenge response, scripts can log in and out of remote hosts without human interaction.
Netcat is an oft maligned program that can easily be used for many interesting and useful purposes. While many admins have heard of netcat, it is usually in the context of detecting rootkits or evidence of intrusion. The fact that netcat is a favorite tool among malicious hackers does a great disservice to the tool, but it also demonstrates its utility.
Often times a system administrator will find open ports on a machine and wonder what they are for. It is easy enough to check to see the default use of a well known port (for instance, SMTP uses the default port 25), but this is no guarantee that the actual port observed is using the default service.
In the arsenal of defensive tools available for network administrators, firewalls probably occupy the most prominent, and vital position. Firewalls can be used as both a perimeter and host based defense against intrusion.
The proliferation of wireless networks is sometimes scary when you consider how insecure most wireless configurations are. With a little work, and some technical know-how you can easily break into most wireless networks or simply monitor the wireless traffic flowing all around you.
Brief instructions on how to set up local port forwarding to allow for a secure MySQL connection by tunneling through an existing SSH session. This allows for encryption as well as the ability to bypass firewalls that allow remote SSH connections but block remote MySQL connections.
Updated: May 1, 2008
Understanding the TCP/IP handshake, including sequencing negotiation, how to view and discover available ports on local and remote machines and how to monitor local TCP/IP connections.
Abusing unsecured wireless connections for fun and profit, including advice for protecting your own wireless connections.
A short description of the distinguishing characteristics of hubs and switches. How to choose the best one for your needs.
A short review of installing and running VNC, or Virtual Network Computing, on Linux including a brief review of functionality and customization.
A description of how to examine and change your Linux networking settings from the shell. Info on DNS, gateways and IP settings.
Installing, configuring and understanding cable and DSL routers for your home LAN.
Instructions for using native NT/2000 features to implement a simple firewall.
Getting some server functionality from your Windows desktop with a home operating system.
Finding open ports on a remote Unix or Linux machine.
A deeper look at TCP/IP and ports.
A quick look at TCP/IP, ports, and what goes on across the internet.
Listing of reserved IP address ranges and their classes.