Your choice of fonts may at first seem a bit limited. To get more
font choices, you can add them to the console font list. The limited
default font list is supposed to prevent you from choosing
unsuitable fonts for your console.

One reason for this is that the console always uses the same width for each
character (fixed width fonts). This restricts the use of most Windows fonts
because they're proportional typefaces: every character has its own width.
For example, an "i" is narrower than an "m". If you're sure that a certain font
will work in the console, then here's how to add the font to the console font
list.

Open your registry editor. In the key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\
CurrentVersion\Console\TrueTypeFont

insert a new "string value" and give
this entry the name "00" (numbers, not letters).
If there's already an entry that has this name, then call the new entry "000"
or add as many zeroes as required to avoid conflicts with existing entries.
You should then double-click your new entry to open it and enter the name of
the font. The name must be exactly the same as the official font name, just
the way it's stated under the key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Fonts.

To effectively disable AutoRun in Microsoft Windows, import the following registry value:

REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYS:DoesNotExist"

To import this value, perform the following steps:

1. Copy the text
2. Paste the text into Windows Notepad
3. Save the file as "autorun.reg"
   Note: In certain circumstances, Notepad may automatically add a .txt extension to saved files. To ensure that the file is saved with the proper extension, select All Files in the "Save as type:" section of the "Save As" dialog.
4. Navigate to the file location
5. Double-click the file to import it into the Windows registry

Microsoft Windows can also cache the AutoRun information from mounted devices in the MountPoints2 registry key. We recommend restarting Windows after making the registry change so that any cached mount points are reinitialized in a way that ignores the Autorun.inf file. Alternatively, the following registry key may be deleted:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

Once these changes have been made, all of the AutoRun code execution scenarios described above will be mitigated because Windows will no longer parse Autorun.inf files to determine which actions to take.

Source: http://www.us-cert.gov/cas/techalerts/TA09-020A.html

TCP Header (IP v4)

Bit offset	0–3				4–7				8–15								16–31
0	Source address
32	Destination address
64	Zeros								Protocol								TCP length
96	Source port																Destination port
128	Sequence number
160	Acknowledgement number
192	Data offset				Reserved				Flags								Window
224	Checksum																Urgent pointer
256	Options (optional)
256/288+	Data

TCP Header (IP v6)

Bit offset	0-7								8–15								16–23								24–31
0	Source address
32
64
96
128	Destination address
160
192
224
256	TCP length
288	Zeros																								Next header
320	Source port																Destination port
352	Sequence number
384	Acknowledgement number
416	Data offset				Reserved				Flags								Window
448	Checksum																Urgent pointer
480	Options (optional)
480/512+	Data

SYN

This is the default scan and is good for most purposes. It is quieter than a TCP Connect scan, that is, it won’t show up on most simple logs. It works by sending a single TCP SYN packet to each possible port. If it gets a SYN ACK packet back, then Nmap knows there is a service running there. If it doesn’t get a response, it assumes the port is closed. The SYN scan does not complete the TCP handshake by sending an ACK back to the machine; as far as the scanee is concerned, it never sees a valid connection. However, the remote system will hold this “half socket” open until it times out from not receiving a response. Some servers and IDS programs are smart enough to catch this now, but the SYN scan will be invisible to most machines.

 

TCP Connect
This works much like the SYN scan, except it completes the full TCP handshake and makes a full connection. This scan is not only noisy but also puts more load on the machines being scanned and the network. However, if stealth or bandwidth is not an issue, a Connect scan is sometimes more accurate than the SYN scan. Also, if you don’t have administrator or root privileges on the Nmap machine, you won’t be able to run anything other than a Connect scan because the specially crafted packets for other scans require low-level OS access.

 

Ping Sweep
This does a simple ping of all the addresses to see which ones are answering to ICMP. If you don’t really care about what services are running and you just want to know which IP addresses are up, this is a lot faster than a full port scan. However, some machines may be configured not to respond to a ping (for example, machines running the new XP firewall) but still have services running on them, so a ping sweep is not as accurate as a full port scan.

 

UDP Scan
This scan checks to see if there are any UDP ports listening. Since UDP does not respond with a positive acknowledgement like TCP and only responds to an incoming UDP packet when the port is closed, this type of scan can sometimes show false positives. However, it can also reveal Trojan horses running on high UDP ports and hidden RPC services. It may be quite slow, since some machines intentionally slow down responses to this kind of traffic to avoid being overwhelmed. Machines running Windows OS, however, do not implement this slowdown feature, so you should be able to use UDP to scan Windows hosts normally.

FIN Scan
This is a stealthy scan, like the SYN scan, but sends a TCP FIN packet instead. Most but not all computers will send a RST packet back if they
get this input, so the FIN scan can show false positives and negatives, but it may get under the radar of some IDS programs and other countermeasures.

NULL Scan
Another very stealthy scan that sets all the TCP header flags to off or null. This is not normally a valid packet and some hosts will not know what to do with this. Windows operating systems are in this group, and scanning them with NULL scans will produce unreliable results. However, for non-Windows servers protected by a firewall, this can be a way to get through.

XMAS Scan
Similar to the NULL scan except all the flags in the TCP header are set to on (hence the name—it lights up like a Christmas tree). Windows machines won’t respond to this due to the way their TCP stack is implemented.

 

Bounce Scan
This tricky scan uses a loophole in the FTP protocol to “bounce” the scan packets off an FTP server and onto an internal network that would normally not be accessible. If you have the IP address of an FTP server that is attached to the local LAN, you may be able to breach the firewall and scan internal machines. It’s a good idea to test to see if your network is vulnerable to this exploit. Most current FTP servers have fixed this security hole. Note: You must input a valid FTP server that would have access to the network in addition to the IP addresses to be scanned.

RPC Scan
This special type of scan looks for machines answering to RPC (Remote Procedure Call) services. RPC, which allows remote commands to be run on the machine under certain conditions, can be a dangerous service. Since RPC services can run on many different ports, it is hard to tell from a normal scan which ones might be running RPC. This scan will probe the ports found open on a machine with commands to show the program name and version if RPC is running. It’s not a bad idea to run one of these scans every so often just to find out if and where you have these services running.

Windows Scan
This scan relies on an anomaly in the responses to ACK packets in some operating systems to reveal ports that are supposed to be filtered. Operating systems that are known to be vulnerable to this kind of scan include some versions of AIX, Amiga, BeOS, BSDI, Cray, DG/UX, Digital UNIX, FreeBSD, HP/UX, IRIX, MacOS, NetBSD, OpenBSD, OpenStep, OpenVMS, OS/2, QNX, Rhapsody, SunOS 4.X, Tru64 UNIX, Ultrix, VAX, and VxWorks.

Idle Scan
This type of scan is a new feature for Nmap version 3.0. It is a super stealthy ethod whereby the scan packets are bounced off an external host. You don’t need to have control over the other host but it does have to setup and meet certain requirements. You must input the IP address of our “zombie” host and what port number to use. While this scan is very hard to track back to the original scanner, it is probably not very useful to ost administrators scanning their own networks. It is one of the more controversial options in Nmap since it really only has a use for malicious attacks.