Ethical Hacker and Scanning Tools

Ethical Hacker and Scanning Tools

Can an ethical hacker simulate the scanning techniques to ensure the security of the network? The first and foremost armor is knowledge itself. The results of a scanner can be misleading if the ethical hacker does not have a good knowledge of common vulnerabilities, commonly affected hosts, and patterns indicating misuse.

Apart from this, performing an exhaustive scan against all the systems in a large enterprise is usually not feasible due to network constraints, stability of the backbone and scanned systems, and the dynamic nature of network deployments (wireless, DHCP, etc.). Therefore mere scanning does not a security check complete.

Tool: ipEye, IPSecScan

ipEye is a command-line driven port scanner written by Arne Vidstrom. It is a lightweight powerful tool bearing similarities with the command shell tools seen with UNIX. However, this port scanner is restricted to the Windows platform - 2000 and XP. Another drawback of this tool is that the hacker needs to know the specific IP before he can initiate a scan.

The basic usage for ipEye is:

ipEye -p [optional parameters]

The scantype parameter can take values of: -syn = SYN scan, -fin = FIN scan, -null = Null scan, - xmas = Xmas scan

However, the FIN, Null and Xmas scans don't work against Windows systems. Of these scan types, only the SYN SCAN is valid when scanning a Windows system. ipEye will scan the requested ports, given a valid IP address, and return a list of the FIN, Null and Xmas scans don't work against Windows systems.

"Closed" indicates that there is a computer on the other end, but there is no service that listens at the port.

"Reject" indicates the presence of a firewall or packet filtering device (sending a reset back) protecting the port.

"Drop" indicates the presence of a firewall or packet filtering device that drops packets directed to port, or it indicates that the particular system is not alive on the target network.

"Open" indicates that there is a service listening at the port.

                                                    

Note in the above scan we see ports 135 and 139 as open.

 

       

Let us see the same scan done with IPSecScan. IPSecScan is a tool that can scan either a single IP address or a range of IP addresses looking for systems that are IPSec enabled.



In the scan above we have specified a range of IP addresses from 192.168.2.1 to 192.168.2.118. Note that the scan returns "Disabled" for some IPs - such as IP 192.168.2.1. This indicates that the system either doesn't support IPSec, has IPSec disabled, or that it is configured not to reveal that it has IPSec enabled.


IPsec is the short for IP Security. It is a set of protocols developed by the IETF to support secure exchange of packets at the IP layer.


IPsec = AH + ESP + IPcomp + IKE


Authentication Header (AH): provides authenticity guarantee for packets, by attaching strong crypto checksum to packets. If a packet is received with AH and the checksum operation is successful, it indicates that the packet was originated by the expected peer (the packet was not generated by impersonator) and that the packet was not modified in transit. Unlike other protocols, AH covers the whole packet, from the IP header to the end of the packet.


Encapsulating Security Payload (ESP) provides confidentiality guarantee for packets, by encrypting packets with encryption algorithms. If a packet is received with ESP and successfully decrypted it indicates that the packet was not wiretapped in the middle, if the sender and the receiver share a secret key, and no other party knows the key.


ESP provides encryption service to the packets. However, encryption tends to give negative impact to compression on the wire (such as ppp compression). IP Compression (IPcomp) provides a way to compress packet before encryption by ESP.


As discussed above, AH and ESP need shared secret key between peers. For communication between distant locations, there is a need to provide ways to negotiate keys in secrecy. Internet Key Exchange (IKE) makes this possible.


IPsec has been deployed widely to implement Virtual Private Networks (VPNs). IPsec supports two encryption modes: Transport and Tunnel.


Transport mode encrypts only the data portion (payload) of each packet, but leaves the header untouched. The more secure Tunnel mode encrypts both the header and the payload. On the receiving side, an IPSec-compliant device decrypts each packet.


For IPsec to work, the sending and receiving devices must share a public key. This is accomplished through a protocol known as Internet Security Association and Key Management Protocol/Oakley (ISAKMP/Oakley), which allows the receiver to obtain a public key and authenticate the sender using digital certificates.


 Note  security of IPsec protocols depend on the secrecy of secret keys. If secret keys are compromised, IPsec protocols can no longer be secure.


Reference for readers: Old IPsec suite - RFC1825, New IPsec suite - RFC2401