This is an old revision of the document!
NOTE : Some link might not work, but search based on the name and site.
Vulnerabilities due to improperly configured operating system software
Vulnerabilities due to failure to apply patches to known vulnerabilities
Failure to comply with password policy and improper access control settings
Existence of malicious software (Trojans, worms, etc.) or evidence of use
Existence of vulnerable or easily exploited services or processes
Vulnerabilities due to improperly configured applications
+"ucia.go" +tel +fax
allintitle: "index of /" site:.redhat.com
** Another site for effective search Netcraft
* whois cs-security-mnt * whois "@citicorp.com" @whois.arin.net
#nslookup >set querytype=any >cia.gov >server auth100.ns.uu.net #zone transfer using nslookup. >ls -d ucia.gov
dig @relay2.ucia.gov ucia.gov axfr
dig @relay2.ucia.gov 129.81.198.in-addr.arpa axfr
$ nslookup > set querytype=mx > bankofengland.co.uk
txdns -f mail-dict.txt bankofengland.co.uk
Reading/Understanding Header of Returned Mail.
The original message was received at Fri, 1 Mar 2002 07:42:48 -0500 from ain-relay2.net.ucia.gov [192.168.64.3] ----- The following addresses had permanent fatal errors ----- <[email protected]> ----- Transcript of session follows ----- ... while talking to mailhub.ucia.gov: >>> RCPT To:<[email protected]> <<< 550 5.1.1 <[email protected]>... User unknown 550 <[email protected]>... User unknown ----- Original message follows ----- Return-Path: <[email protected]> Received: from relay2.net.ucia.gov by puff.ucia.gov (8.8.8+Sun/ucia internal v1.35) with SMTP id HAA29202; Fri, 1 Mar 2002 07:42:48 -0500 (EST) Received: by relay2.net.ucia.gov; Fri, 1 Mar 2002 07:39:18 Received: from 220.127.116.11 by relay2.net.ucia.gov via smap (4.1) id xma026449; Fri, 1 Mar 02 07:38:55 -0500
Reading above header in English
In particular, the following data in this transcript is useful: • The Internet-based relay2.ucia.gov gateway has an internal IP address of 192.168.64.3 and an internal DNS name of relay2.net.ucia.gov. • relay2.ucia.gov is running TIS Gauntlet 4.1 (smap 4.1, a component of TIS Gauntlet, is mentioned in the via field). • puff.ucia.gov is an internal SMTP mail relay system running Sun Sendmail 8.8.8. • mailhub.ucia.gov is another internal mail relay running Sendmail (this can be seen from analyzing the SMTP server responses to the RCPT TO: command).
From a network scanning perspective, the following types of ICMP messages are useful:
$ sing -echo 192.168.0.255 $ sing -tstamp 192.168.0.50 $ sing -mask 192.168.0.25
$ nmap -sP -PI 192.168.0.0/24 (Performing a ping sweep with Nmap)
You can get how to use by simply running application $ icmpscan –c -t 500 -r 1 192.168.1.0/24
Enumerating subnet network and broadcast addresses with Nmap
nmap -sP 18.104.22.168/26
Useful details about subnet network and broadcast addresses and CIDR slash notation can be found at http://en.wikipedia.org/wiki/ Classless_Inter-Domain_Routing.
Accessible TCP ports can be identified by port scanning target IP addresses. The
following nine different types of TCP port scanning are used in the wild by both
attackers and security consultants:
Standard scanning methods Vanilla connect( ) scanning Half-open SYN flag scanning Stealth TCP scanning methods Inverse TCP flag scanning ACK flag probe scanning TCP fragmentation scanning Third-party and spoofed TCP scanning methods FTP bounce scanning Proxy bounce scanning Sniffer-based spoofed scanning IP ID header scanning
Using Nmap to perform IP ID header scanning
nmap -P0 -sI 192.168.0.155 192.168.0.50
Probe packets can be fragmented easily with fragroute to fragment all probe packets
flowing from your host or network or with a port scanner that supports simple
fragmentation, such as Nmap. Many IDS sensors can’t process large volumes of fragmented
packets because doing so creates a large overhead in terms of memory and
CPU consumption at the network sensor level.
Dug Song’s fragtest utility can determine exactly which types of fragmented
ICMP messages are processed and responded to by the remote host. ICMP
echo request messages are used by fragtest for simplicity and allow for easy analysis;
the downside is that the tool can’t assess hosts that don’t respond to ICMP
After undertaking ICMP probing exercises (such as ping sweeping and hands-on use
of the sing utility) to ensure that ICMP messages are processed and responded to by
the remote host, fragtest can perform three particularly useful tests:
overlapping fragment, favoring older data in reassembly (using the frag-old
an example that uses fragtest to assess responses to fragmented ICMP echo
request messages with the frag, frag-new, and frag-old options:
$ fragtest frag frag-new frag-old www.bbc.co.uk frag: 467.695 ms frag-new: 516.327 ms frag-old: 471.260 ms
The fragroute utility intercepts, modifies, and rewrites egress traffic destined for a
specific host, according to a predefined rule set. When built and installed, version 1.2
comprises the following binary and configuration files:
/usr/local/sbin/fragtest /usr/local/sbin/fragroute /usr/local/etc/fragroute.conf
The fragroute.conf file defines the way fragroute fragments, delays, drops, duplicates,
segments, interleaves, and generally mangles outbound IP traffic.
Using the default configuration file, fragroute can be run from the command line in
the following manner:
$ cat /usr/local/etc/fragroute.conf tcp_seg 1 new ip_frag 24 ip_chaff dup order random print $ fragroute Usage: fragroute [-f file] dst $ fragroute 192.168.102.251 fragroute: tcp_seg -> ip_frag -> ip_chaff -> order -> print
Egress traffic processed by fragroute is displayed in tcpdump format if the print
option is used in the configuration file. When running fragroute in its default configuration,
TCP data is broken down into 1-byte segments and IP data into 24-byte
segments, along with IP chaffing and random reordering of the outbound packets.
fragroute.conf. The fragroute man page covers all the variables that can be set within
the configuration file. The type of IP fragmentation and reordering used by fragtest
when using the frag-new option can be applied to all outbound IP traffic destined for
a specific host by defining the following variables in the fragroute.conf file:
ip_frag 8 old order random print
TCP data can be segmented into 4-byte, forward-overlapping chunks (favoring
newer data), interleaved with random chaff segments bearing older timestamp
options (for PAWS elimination), and reordered randomly using these fragroute.conf
tcp_seg 4 new tcp_chaff paws order random print
I recommend testing the variables used by fragroute in a controlled environment
before live networks and systems are tested. This ensures that you see decent results
when passing probes through fragroute and allows you to check for adverse reactions
to fragmented traffic being processed. Applications and hardware appliances
alike have been known to crash and hang from processing heavily fragmented and mangled data!
Using Nmap to perform a fragmented SYN scan
$ nmap -sS -f 192.168.102.251
Using Nmap to specify decoy addresses
$ nmap -sS -P0 -D 22.214.171.124,ME,126.96.36.199 192.168.102.251
tools that can assess and exploit source routing vulnerabilities found in
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:
The basic usage of the tool is as follows:
$ lsrscan usage: lsrscan [-p dstport] [-s srcport] [-S ip] [-t (to|through|both)] [-b host<:host ...>] [-a host<:host ...>] <hosts>
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:
$ lsrtunnel usage: lsrtunnel -i <proxy IP> -t <target IP> -f <spoofed IP>
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 Link
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:
The TCP timestamp option is defined in RFC 1323.
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:
If a SYN/ACK packet is received, the port is considered open.
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).
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.
If no packet is received, an intermediary security device silently dropped it.