network_security_assesment
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
network_security_assesment [2009/06/07 23:08] k2patel |
network_security_assesment [2009/06/26 08:01] k2patel |
||
|---|---|---|---|
| Line 281: | Line 281: | ||
| Classless_Inter-Domain_Routing. | Classless_Inter-Domain_Routing. | ||
| </code> | </code> | ||
| - | |||
| ==== TCP Port Scanning ==== | ==== TCP Port Scanning ==== | ||
| Line 406: | Line 405: | ||
| </code> | </code> | ||
| + | Using Nmap to specify decoy addresses | ||
| + | <code bash> | ||
| + | $ nmap -sS -P0 -D 62.232.12.8,ME,65.213.217.241 192.168.102.251 | ||
| + | </code> | ||
| + | |||
| + | == Assessing source routing vulnerabilities == | ||
| + | tools that can assess and exploit source routing vulnerabilities found in\\ | ||
| + | remote networks: | ||
| + | * LSRScan [[ http://www.synacklabs.net/projects/lsrscan | lsrscan ]] | ||
| + | * LSRTunnel [[ http://www.synacklabs.net/projects/lsrtunnel | lsrtunnel ]] | ||
| + | LSRScan. The LSRScan tool crafts probe packets with specific source routing options\\ | ||
| + | to determine exactly how remote hosts deal with source-routed packets. The tool\\ | ||
| + | checks for the following two behaviors: | ||
| + | * Whether the target host reverses the source route when sending packets back | ||
| + | * Whether the target host can forward source-routed packets to an internal host, by setting the offset pointer to be greater than the number of hops defined in the loose hop list | ||
| + | The basic usage of the tool is as follows: | ||
| + | <code bash> | ||
| + | $ lsrscan | ||
| + | usage: lsrscan [-p dstport] [-s srcport] [-S ip] | ||
| + | [-t (to|through|both)] [-b host<:host ...>] | ||
| + | [-a host<:host ...>] <hosts> | ||
| + | </code> | ||
| + | LSRTunnel. LSRTunnel spoofs connections using source-routed packets. For the tool\\ | ||
| + | to work, the target host must reverse the source route (otherwise the user will not see\\ | ||
| + | the responses and be able to spoof a full TCP connection). LSRTunnel requires a\\ | ||
| + | spare IP address on the local subnet to use as a proxy for the remote host.\\ | ||
| + | Running LSRTunnel with no options shows the usage syntax: | ||
| + | <code bash> | ||
| + | $ lsrtunnel | ||
| + | usage: lsrtunnel -i <proxy IP> -t <target IP> -f <spoofed IP> | ||
| + | </code> | ||
| + | |||
| + | == Using Specific Source Ports to Bypass Filtering == | ||
| + | information regarding circumvention of Firewall-1 in certain\\ | ||
| + | configurations, consult the excellent presentation from Black Hat Briefings 2000 by\\ | ||
| + | Thomas Lopatic et al. titled “A Stateful Inspection of Firewall-1” available as a Real\\ | ||
| + | Media video stream and PowerPoint presentation from [[ http://www.blackhat.com/html/bh-usa-00/bh-usa-00-speakers.html | Link]] | ||
| + | |||
| + | === Low-Level IP Assessment === | ||
| + | Tools such as Nmap, Hping2, and Firewalk perform low-level IP assessment. | ||
| + | |||
| + | Insight into the following areas of a network can be gleaned through low-level IP assessment: | ||
| + | |||
| + | * Uptime of target hosts (by analyzing the TCP timestamp option) | ||
| + | * TCP services that are permitted through the firewall (by analyzing responses to TCP and ICMP probes) | ||
| + | * TCP sequence and IP ID incrementation (by running predictability tests) | ||
| + | * The operating system of the target host (using IP fingerprinting) | ||
| + | |||
| + | The TCP timestamp option is defined in RFC 1323. | ||
| + | == Analyzing Responses to TCP Probes == | ||
| + | A TCP probe always results in one of four responses. These responses potentially\\ | ||
| + | allow an analyst to identify where a connection was accepted, or why and where it\\ | ||
| + | was rejected, dropped, or lost: | ||
| + | * TCP SYN/ACK | ||
| + | If a SYN/ACK packet is received, the port is considered open. | ||
| + | * TCP RST/ACK | ||
| + | If an RST/ACK packet is received, the probe packet was rejected by either the\\ | ||
| + | target host or an upstream security device (e.g., a firewall with a reject rule in its policy). | ||
| + | * ICMP type 3 code 13 | ||
| + | If an ICMP type 3 code 13 message is received, the host (or a device such as a\\ | ||
| + | firewall) has administratively prohibited the connection according to an Access Control List (ACL) rule. | ||
| + | * Nothing | ||
| + | If no packet is received, an intermediary security device silently dropped it. | ||
| - | [[87]] | + | [[100]] |
network_security_assesment.txt · Last modified: 2020/08/10 02:35 (external edit)
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
