Learn Ethical Hacking & get free Hacking Tools
Learn Ethical Hacking & Get free hacking tools and softwares
Learn Ethical Hacking & get free Hacking Tools
|  |
- Next Topic: Denial of Service attacks
- Sniffers - Summary
- DNS Sniffing and Spoofing
- Sniffers - Tool and Softwares: Network Sniffers
- Macof, MailSnarf, URLSnarf, WebSpy
- Man in the Middle Attack
- bX-572dn8 Blog Posting Error
- ARP Spoofing & Sniffing HTTPS and SSH
- Active Sniffing and Passive Sniffing
- Sniffers - Tool and Softwares: Network Sniffers - 6
- Sniffers - Tool and Softwares: Network Sniffers - 5
- Sniffers - Tool: Ethereal : Network Sniffers - 4
|
Next Topic: Denial of Service attacks Posted: 19 Jun 2009 06:46 AM PDT Friends, tomorrow onwards, we will look at various aspects of Denial of Service attacks. The discussion will include topics such as:
On February 6th, 2000, Yahoo portal was shut down for 3 hours. Then retailer Buy.com Inc. (BUYX) was hit the next day, hours after going public. By that evening, eBay (EBAY), Amazon.com (AMZN), and CNN (TWX) had gone dark. And in the morning, the mayhem continued with online broker E*Trade (EGRP) and others having traffic to their sites virtually choked off. (Business Week Online, 12 February 2000) What became obvious over the hours was the victimization of the site by a distributed denial of service attack from hundreds of geographically dispersed Internet-connected machines sending millions of request for service packets. This resulted in an operational problem that eventually left the organization incapable of serving its legitimate customers. According to the Yankee Group, estimated costs of the above mentioned attack totaled $1.2 billion cumulative and the attack on Amazon alone cost between $200,000 and $300,000 per hour. The loss in terms of customer goodwill, corporate reputation and public trust is likely to have been greater - given the mainstream media coverage of these attacks largely because of its sheer scale and high profile victims. The first DoS attack was recorded way back in 1988 and was instrumental in setting up of the CERT Coordination Center. The February 2000 attack was not the last either despite law enforcement agencies scooping up a 15-year-old Canadian teenager, who went by the alias "Mafia boy", who had reportedly launched the attacks using a DDoS tool called Tribe Flood Network 2000. Major DDoS attacks still make the news. In January 20 01, Microsoft became the victim of such an attack. Microsoft's primary Web site and associated sites for MSN such as, online travel site Expedia.com, the auto sales site CarPoint, and the Microsoft email service Hotmail were inaccessible for several hours. The Code Red Worm targeting the white house in the stillborn second phase of its attack amassed 359,000 machines worldwide in just 14 hours. Even CERT was not spared as in May 2000; a DDoS was launched against it resulting in losses that totaled $100,000.
A "denial-of-service" attack is characterized by an explicit attempt by attackers to prevent legitimate users of a service from using that service. Examples include
Not all service outages, even those that result from malicious activity, are necessarily denial-of-service attacks. Other types of attack may include a denial of service as a component, but the denial of service may be part of a larger attack. Illegitimate use of resources may also result in denial of service. For example, an intruder may use of an anonymous ftp area as a place to store illegal copies of commercial software, consuming disk space and generating network traffic A denial of service attack can also destroy programming and files in a computer system. Although usually intentional and malicious, a denial of service attack can sometimes happen accidentally. A denial of service attack is a type of security breach to a computer system that does not usually result in the theft of information or other security loss. However, these attacks can cost the target person or company a great deal of time and money.
DoS attacks exploit the asymmetric nature of certain types of network traffic. One attack method seeks to cause the target to use more resources processing traffic than the attacker does sending the traffic. Amarjit Singh ---Regards,
Amarjit Singh   |
||||||||||||
|
Posted: 19 Jun 2009 06:42 AM PDT
Amarjit Singh ---Regards,
Amarjit Singh   |
||||||||||||
|
Posted: 19 Jun 2009 06:41 AM PDT
Typically, a DNS Server contains the records only for the machines of the domain it has authority over. If it has to answer queries about machines outside its domain, it has to send a request to the other DNS Server which handles these machines. As frequent communication is not practical, the DNS server keeps a cache and stores in it all the replies returned by other DNS servers. When an attacker wants to poison a DNS cache, he will use a faulty DNS - which can be his own domain running a hacked DNS server. The DNS server is termed as hacked because the IP address records are manipulated to suit the attacker's needs.
The next level of protection can reside on the access routers. This could also be used in order to prevent IP spoofing at its most common source. While these filters can be sometimes tricky when it comes to combining dynamic IP and 'multi-POP' static IP routing, if implemented well, these filters can completely prevent IP spoofing that originates from an access network.
A personal firewall must be configured to block UDP 53 destination port to check outgoing DNS traffic in order to ensure that the DNS Server does not answer before WinDNSSpoof does. The working of WinDNSSpoof then takes care of spoofing only those packets that are required to - while the rest are allow to go through. This is made possible by specifying the MAC address of the DNS server or the default gateway in case the DNS server is in another network. Usage: wds -h Example: wds -n www.targetsite.com -i 216.239.39.101 -g 00-00-39-5c-45-3b Amarjit Singh ---Regards,
Amarjit Singh   |
||||||||||||
|
Sniffers - Tool and Softwares: Network Sniffers Posted: 19 Jun 2009 06:39 AM PDT
SMAC has 2 modes of operation: [WBEM ON] and [WBEM OFF]. If the "Windows Management Instrumentation (WMI)" service is running, it will be running on [WBEM ON] mode. Otherwise, it is on [WBEM OFF] mode. The [WBEM ON] mode shows more information. The tool also allows the user to log and track SMAC activities. SMAC takes advantage of the NdisReadNetworkAddress function in the Microsoft Device Driver Development Kit (DDK.) NdisReadNetworkAddress(...) is called by the network adapter driver to obtain a user specified MAC address in the registry. After the driver confirms that there is a valid MAC address specified in the registry key, the driver then programs the MAC address to its hardware registers to override the burnt-in MAC address. SMAC was designed originally as a security vulnerability testing tool for MAC address authorization and authentication systems, Intrusion Detection Systems and MAC address based software licenses testing tool. When changing MAC address, the user must ensure that they assign MAC addresses according to IANA Number Assignments database.
Usage Examples: # macchanger eth1 Current MAC: 00:40:96:43:ef:9c [wireless] (Cisco/Aironet 4800/340) Faked MAC: 00:40:96:43:ef:9d [wireless] (Cisco/Aironet 4800/340) # macchanger -A eth1 Current MAC: 00:40:96:43:39:a6 [wireless] (Cisco/Aironet 4800/340) Faked MAC: 00:10:5a:1e:06:93 (3Com, Fast Etherlink XL in a Gateway 2000)
Iris can reconstruct raw data in packets and turn it into complete HTTP, SMTP and POP3 sessions in their original format. The user can view both outgoing and incoming email messages, web browsing sessions, instant messenger exchanges, non-encrypted web-based email and FTP transfers. Using this, the user can set up automated screens to monitor the Web-browsing patterns of the network. With Iris, the user is able to read the actual text of an email - as well as any attachments - exactly as it was sent. Iris will reconstruct the actual html pages that network users have visited and even simulate cookies for entry into password-protected websites. Iris provides a larger variety of statistical measurements such as pie charts and bar graphs, and provides information on protocol distribution, top hosts, packet-size distribution and bandwidth usage. Iris' Packet Editor gives the ability to create custom or spoof packets and to send them across the Internet, to specific ports or addresses, or repeatedly across the network. Iris has a fast packet injector that handles up to 9000 packets per second. Iris can be easily configured to only capture specific data through any combination of packet filters. Packet filters can be based on the hardware or protocol layer, any number of key words, MAC or IP address, source and destination port, custom data and size of the packets
NetIntercept 1.2 captures LAN traffic using a standard Ethernet interface card placed in promiscuous mode and a modified UNIX kernel. The capture subsystem runs continuously, whether or not the GUI is active. NetIntercept performs stream reconstruction on demand. When the user selects a range of captured network traffic to analyze, NetIntercept assembles those packets into network connection data streams. The reconstructed streams are then presented to the NetIntercept analysis subsystem for identification and analysis. Once TCP streams are reconstructed and parsed, some of the objects that they contain need to be stored for long periods of time. Examples of such objects are web pages, files transferred by FTP, and e-mail attachments. Besides controlling data capture and analysis, the GUI offers sophisticated search criteria. A user can find one or many network connections according to the time of day, source or destination hardware or Internet address, source or destination TCP or UDP port name or number, username associated with the connection, electronic mail sender, recipient(s) or subject header, file name or World Wide Web URI associated with the transfer, specific protocols or content types recognized in the connection's contents. Once a connection has been identified, the user can drill down to view the search criteria extracted from it ---Regards, Amarjit Singh---Regards,
Amarjit Singh   |
||||||||||||
|
Macof, MailSnarf, URLSnarf, WebSpy Posted: 19 Jun 2009 06:36 AM PDT Macof floods the local network with random MAC addresses, causing some switches to fail open in repeating mode, and thereby facilitates sniffing. Mailsnarf is capable of capturing and outputting SMTP mail traffic that is sniffed on the network urlsnarf is a neat tool for monitoring Web traffic. Webspy allows the user to see all the WebPages visited by the victim. Each of the tools included in the dsniff distribution has some unique function. In general, the tools dsniff, filesnarf, mailsnarf, msgsnarf, urlsnarf, and webspy are used to passively monitor a vulnerable shared network. By overloading the switch, a hacker could have access to all the data passing through the switch.
The whole process of sniffing another's mail becomes an easy task with mailsnarf. Once the attacker has access to the target subnet, he can use mailsnarf to capture mail traffic that passes through the network subnet or Ethernet switch.
The only drawback of urlsnarf is that at present, it is hard coded to monitor TCP ports 80 (clear-text HTTP), 3128 (MS-proxy), and 8080 (generic/squid proxy). HTTP traffic going to other TCP ports is ignored. Because urlsnarf generates output as CLF log lines, the output can be piped to any log analysis program that uses CLF Web server logs.
Amarjit Singh ---Regards,
Amarjit Singh   |
||||||||||||
|
Posted: 19 Jun 2009 06:35 AM PDT 
Attackers position themselves between two systems and actively participate in the connection to gather data. The attacker may also run the dnsspoof program configured to send false DNS information so that a DNS query for a given website will resolve to the attacker's IP address. Then the attacker will activate webmitm program such that it will transparently proxy all HTTP and HTTPS traffic it receives. The DNS spoof program detects DNS request for www.website.com and redirects the client to attacker's machine. The ARP table convinces the victim's machine that it is indeed talking to the intended web server. The victim's browser starts to establish a secure connection. All messages for establishing SSL connection are sent to webmitm running on the attacker's machine. webmitm acts as a SSL proxy, establishing two SSL connections - one from victim to the attacker's machine and the other from attacker's machine to the actual web server. When establishing the SSL session between the victim machine and the attacker machine, webmitm will send the attacker's own certificate. The victim's browser will notice that the certificate is not signed by a trusted Certificate Authority and show a message to the user asking the user whether to accept this un-trusted certificate or not. The normal tendency is to accept it, thinking it is some error message. ---Regards,Amarjit Singh ---Regards,
Amarjit Singh   |
||||||||||||
|
Posted: 19 Jun 2009 06:33 AM PDT Hi friends, today while posting I have seen an error. Screen shot attached below. I click back and repost it and its done. Can any one tell me pls... why this error occurs ??  Amarjit Singh ---Regards,
Amarjit Singh   |
||||||||||||
|
ARP Spoofing & Sniffing HTTPS and SSH Posted: 19 Jun 2009 06:28 AM PDT  A possible way to sniff information would be to control an ARP table of a computer. ARP spoofing involves changing the MAC to IP address entries, causing traffic to be redirected from the legitimate system to an unauthorized system of the attacker's choice. This is achieved by sending out a forged ARP packet to the target system, telling it that its default gateway has changed to the attacker's system. This way, whenever the target system sends traffic on the network, it will send it to the attacker's system first, which then forwards the packet on to its original destination as if nothing ever happened.
Usually, such attempts are preceded by the scanning and enumeration phases where the attacker draws up a map of the network and discovers the network topology. Looking at the network topology the attacker can decipher the IP address of the default router for the LAN. He then sets up the attack by configuring the IP layer of the attacker's machine to forward any packet it receives from the LAN to the IP address of the default router (IP forwarding). The next step in the attack is sending the fake ARP replies to the victim's machine. This ARP changes the victims ARP table by remapping the default router's IP (layer 3) to attacker own MAC address (layer2). The victim machine sends the data, forwarding it to what it thinks is the default router (but unknowingly using the attackers MAC address). The attacker sniffs the information using any kind of sniffing tool. The attacker's machine will promptly forward the victim's traffic to default router on the LAN. Upon reaching the default router the traffic is transmitted to the outside world. The attacker is now sniffing in a switched environment.
One of the precautionary measures advocated to check information leakage by sniffing, is to use a secure protocol. While the S's in HTTPS, SSL and SSH stands for secure, the underlying basis of this is a trust relationship between public keys. When an HTTPS connection is established, the server sends a certificate which the browser verifies. This certificate is like a digital driver's license identifying the Web server - that, it is indeed who it claims to be. This is endorsed by a certification authority by placing its digital signature on the certificate. The browser on its part verifies the signature on the certificate to ensure that it is authentic and to verify server's identity. If the certificate was signed by a trusted Certificate Authority, an SSL connection will be established. Now, an SSL connection uses a session key to encrypt all data sent by server and client. On the other hand, SSH does not support digital certificates though it is based on the public key cryptography. With SSH, a session key is transmitted in an encrypted fashion using a public key stored on the server. As such, these protocols SSL and SSH are sound from a security standpoint. The problem however lies in the basis of these protocols, namely trust certificates and public keys. For SSL, if a web server sends the browser a certificate and if the browser does not recognize the certificate, it will prompt the user for his consent/approval to accept the certificate. For SSH the user will be warned that server's public key has changed. Nevertheless, he will still be permitted to establish connection to the server, thereby exposing him to attacks. Let us see how dsniff can be used by crackers to exploit this aspect. Amarjit Singh ---Regards,
Amarjit Singh   |
||||||||||||
|
Active Sniffing and Passive Sniffing Posted: 19 Jun 2009 06:22 AM PDT Passive Sniffing  A packet sniffer is seldom the only tool used for an attack. This is because a sniffer can work only in a common collision domain. A common collision domain is a network segment that is not switched or bridged (i.e. connected through a hub). Any traffic that is not switched or bridged on a network segment can be seen by all machines on that segment. As sniffers gather packets at Data Link Layer it can potentially grab all the packets on the LAN of the machine running the Sniffer program. This is because on a network with a hub implements a broadcast medium shared by all systems on the LAN. Any data sent across the LAN is actually sent to each and every machine connected to the LAN. If an attacker runs a Sniffer on one system on LAN, he can gather data sent to and from any other system on the LAN. Majority of the Sniffer tools are ideally suited to sniff data in a hub environment. These tools are called passive sniffers as they passively wait for the data to be sent and capture them. They are efficient in silently gathering the data from the LAN.
Active Sniffing  One countermeasure against passive sniffing is to replace the network hub with a switch. Unlike a hub based network, switched ethernet does not broadcast all information to all systems on the LAN. The switch regulates the flow of data between its ports by actively monitoring the MAC address on each port, which helps it pass data only to its intended target. In other words, the main difference between a switch and hub is that while a hub has no mapping, and thus broadcasts line data to every port on the device, a switch looks at the MAC address associated with each frame passing through it and sends the data to the required connection on the switch. The switch thereby limits the data that a passive sniffer can gather. If there is a passive sniffer activated on a switched LAN, the sniffer will only be able to see data going to and from one machine - i.e. the system on which it is installed. However, it must be noted that the development of switched networks was driven by the need for more bandwidth, and not for the need of more secure networks. Since the evolution was not driven by security needs, there are ways to circumvent this network posture and sniff the traffic. So how does an attacker sniff on a switched LAN? The sniffers for a switched LAN actively inject traffic into the LAN to enable sniffing of the traffic. Hence the term 'active sniffing'. Some of the methods used in the attack include ARP Spoofing, MAC Flooding and MAC Duplicating etc.
In a switched network, the ARP table ensures that IP addresses are mapped to MAC addresses . However, this does not stop sniffing, as we see in ARP Spoofing. One way to sniff in a switched network is to convert the functionality of a switch to that of a hub. In other words, to make a switch change its default directed output to broadcast method . One way of accomplishing this is to foil the switch by flooding the network with too many frames. When this happens, some switches become unable to perform the IP to MAC mappings and then "fail out" to broadcasting.
Written by Dug Song, this collection of tools (bundled with the main dsniff utility) has certain unique functionality. However, they can be categorized as having similar baseline functionality. In general, the tools dsniff, filesnarf, mailsnarf, msgsnarf, urlsnarf, and webspy can be used to sniff on a compromised host behind a firewall and look for interesting content. These tools can be put to good use by network administrators or be used to obtain sensitive information such as login information that is sent in the clear or is weakly encrypted. These tools can also auto detect various messaging protocols (about 30 are included) when dsniff is launched with the "-m" option. urlsnarf is capable of intercepting all http requests from the network it is deployed on, and formatting them into the Common Log Format (CLF) used by MS IIS and Apache. This makes it possible to conduct a log analysis by using suitable programs to interpret the results obtained from urlsnarf. urlsnarf is hard-coded to listen on ports 80 (where clear text http resides) as well as port 3128 (MS-proxy) and 8080 (generic proxy). arpspoof, dnsspoof, and macof work on the interception of switched network traffic that is usually unavailable to a sniffer program due to the segment switching that occurs at the ISO layer 2 level. sshmitm and webmitm implement active man-in-the-middle attacks against redirected SSH and HTTPS sessions by exploiting weak bindings in ad-hoc PKI. Amarjit Singh ---Regards,
Amarjit Singh   |
||||||||||||
|
Sniffers - Tool and Softwares: Network Sniffers - 6 Posted: 19 Jun 2009 06:14 AM PDT
WinDump is simple to use and works at the command prompt level. The syntax that we have used as seen in our screenshot here, is Windump -n -S -vv. The -n option tells Windump to display IP addresses instead of the computers' names. The -S option indicates that the actual TCP/IP sequence numbers should be shown. If this option is omitted, relative numbers will be shown. The -vv options make the output more verbose, adding fields such as time to live and IP ID number to the sniffed information. Let's take a closer look at how WinDump records various types of packets. Here's a TCP example, which shows a data packet with the PUSH and ACK flags set. First, we have the WinDump log entry for the packet. Immediately after it is the same entry, but with an explanation added for each field: 20:50:00.037087 IP (tos 0x0, ttl 128, id 2572, len 46) 192.168.2.24.1036 > 64.12.24.42.5190: P [tcp sum ok] 157351:157357(6) ack 2475757024 win 8767 (DF) The above entry can be deciphered as 20:50:00.037087 [timestamp] IP [protocol header follows] (tos 0x0, ttl 128, id 2572, len 46) 192.168.2.24.1036 [source IP:port] > 64.12.24.42.5190: [destination IP:port] P [push flag] [tcp sum ok] 157351:157357 [sequence numbers] (6) [bytes of data] ack 2475757024 [acknowledgement and sequence number] win 8767 [window size] (DF) [don't fragment set] The next example is UDP. 20:50:11.190427 [timestamp] IP [protocol header follows] (tos 0x0, ttl 128, id 6071, len 160) 192.168.2.28.3010 [source IP:port] > 192.168.2.1.1900: [destination IP:port] udp [protocol] 132 ICMP log entry looks as given below. 20:50:11.968384 [timestamp] IP [protocol header follows] (tos 0x0, ttl 128, id 8964, len 60) 192.168.2.132 [source IP] > 192.168.2.1: [destination IP] icmp [protocol type] 40: [Time to live] echo request seq 43783 [sequence number] Finally, WinDump will also capture ARP requests and replies. 20:50:37.333222 [timestamp] arp [protocol] who-has 192.168.2.1 [destination IP] tell 192.168.2.118 [source IP] 20:50:37.333997 [timestamp] arp [protocol] reply 192.168.2.1 [destination IP] is-at 0:a0:c5:4b:52: fc [MAC address]  Amarjit Singh ---Regards,
Amarjit Singh   |
||||||||||||
|
Sniffers - Tool and Softwares: Network Sniffers - 5 Posted: 19 Jun 2009 06:11 AM PDT There are three main modes in which Snort can be configured: sniffer, packet logger, and network intrusion detection system.
Snort logs packets in either tcpdump binary format or in Snort's decoded ASCII format to logging directories that are named based on the IP address of the foreign host. In our lab, we start using Snort as a packet sniffer and a packet analyzer. Apart from running in a promiscuous mode, we will also see how it will help us log interesting IPs. Using Snort as a packet sniffer and packet analyzer is an easy process. The man pages are very helpful. From the command line prompt we set Snort to a verbose display of the packets sniffed and analyzed. e.g. - The command given below captures all the packets belonging to the class C internal IP's of the type 192.168.20.*. C:\>snort -v -d -e -i etho -h 192.168.20.0/24 -1 log The '-v' switch brings forth a verbose response. The '-d' switch helps in dumping the decoded application layer data While '-e' shows the decoded Ethernet headers. The '-i' switch specifies the interface to be monitored for packet analysis. The '-h' switch specifies which class of network packets has to be captured. The -l option tells snort to dump the packets in the log file. The packets are captured in hex format by default (this can be changed to binary -b) and sorted by IP address to facilitate easy mapping and decoding of data. 06/22-16:36:44.959860 0:C1:26:E:AF:10 -> 0:A0:C5:4B:52:FC type:0x800 len:0x4D 192.168.2.96:1629 -> 203.124.250.69:53 UDP TTL:128 TOS:oxo ID:38429 IpLen:20 DgmLen:63 Len: 43 00 02 0100 00 00 01 00 00 00 00 00 00 03 77 77 77 .............www 09 61 69 72 6C 69 6E 65 72 73 03 6E 65 74 00 00 .airliners.net.. 01 00 01 ... Amarjit Singh ---Regards,
Amarjit Singh   |
||||||||||||
|
Sniffers - Tool: Ethereal : Network Sniffers - 4 Posted: 19 Jun 2009 06:09 AM PDT
Recent versions of Ethereal have included many enhancements to the interface. Live data can be read from Ethernet, FDDI, PPP, Token-Ring, IEEE 802.11, Classical IP over ATM, and loopback interfaces (at least on some platforms; not all of those types are supported on all platforms). Let us take a closer look. We run Ethereal over the LAN (which is not switched) and take a look at the captured data. We sort by the protocol and notice a POP session.
Ethereal lets us follow the entire conversation as shown in the screenshot below.   We are able to reconstruct the client-server conversation as displayed by two different colors. We are able to make out the email service provider, the user name and password from the reconstruction of the sniffed packets. That is not all. We were also able to pick a chat thread from the thousands of packets that passed by in the two minutes. ---Regards,Amarjit Singh ---Regards,
Amarjit Singh   |
| You are subscribed to email updates from Learn Ethical Hacking & Get free hacking tools and softwares
To stop receiving these emails, you may unsubscribe now. | Email delivery powered by Google |
Inbox too full?  |
|
| Google Inc., 20 West Kinzie, Chicago IL USA 60610 | |
Learn Ethical Hacking & Get free hacking tools and softwares
- Denial of Service attacks : Hacking Tool
- Ping of Death
- What is Distributed Denial of Service Attacks
- Types of Denial-of-Service Attacks
|
Denial of Service attacks : Hacking Tool Posted: 23 Jun 2009 02:21 AM PDT
Jolt is a program, which effectively freezes some Windows 95 or Windows NT machines. It is based on old code, which freezes old SysV and Posix implementations. Jolt works by sending a series of spoofed & highly fragmented ICMP packets to the target, which then tries to reassemble the received fragments. As a result, of Jolt Windows 95/NT ceases to function altogether. This will affect unpatched Windows 95, Memphis and Windows NT machines, which are not behind a firewall that blocks ICMP packets. This will also affect old MacOS machines, and it is possible it is also useful against old SysV/POSIX implementations.
After receiving spoofed connection request (SYN) packets over TCP/IP, a computer running Windows 95 or Windows NT may begin to operate slowly. After about one minute, Windows returns to normal operation. Variations of this attack can cause any Windows PC to stop responding. (hang) This behavior occurs due to "Land Attack." Land Attack sends SYN packets with the same source and destination IP addresses and the same source and destination ports to a host computer. This makes it appear as if the host computer sent the packets to itself. Windows 95 and Windows NT operate slowly while the host computer tries to respond to itself.
Smurf is a simple yet effective DDoS attack technique that takes advantage of the ICMP (Internet Control Message Protocol). ICMP is normally used on the internet for error handling and for passing control messages. One of its capabilities is to contact a host to see if it is "up" by sending an "echo request" packet. The common "ping" program uses this functionality. Smurf is installed on a computer using a stolen account, and then continuously "pings" one or more networks of computers using a forged source address. This causes all the computers to respond to a different computer than actually sent the packet. The forged source address, which is the actual target of the attack, is then overwhelmed by response traffic. The computer networks that respond to the forged ("spoofed") packet serve as unwitting accomplices to the attack.
The "smurf" attack's cousin is called "fraggle", which uses UDP echo packets in the same fashion as the ICMP echo packets; it was a simple re-write of "smurf". There are two parties who are hurt by this attack... the intermediary (broadcast) devices--let's call them "amplifiers", and the spoofed address target, or the "victim". The victim is the target of a large amount of traffic that the amplifiers generate. Let's look at a scenario to see the nature of this attack. Assume a co-location switched network with 250 hosts, and that the attacker has a T1. The attacker sends, say, a 234b/s stream of ICMP echo (ping) packets, with a spoofed source address of the victim, to the broadcast address of the "bounce site". These ping packets hit the bounce site's broadcast network of 250 hosts; each of them takes the packet and responds to it, creating 250 ping replies out-bound. If you multiply the bandwidth, 58.5 Mbps is used outbound from the "bounce site" after the traffic is multiplied. This is then sent to the victim (the spoofed source of the originating packets). The perpetrators of these attacks rely on the ability to source spoofed packets to the "amplifiers" in order to generate the traffic which causes the denial of service. In the case of the smurf or fraggle attack, each host which supports this behavior on a broadcast LAN will happily reply with an ICMP or UDP (smurf or fraggle, respectively) echo-reply packet toward the spoofed source address, the victim. The amount of bandwidth and packets per second (pps) that can be generated by this attack is quite large. Many hosts cannot process this many packets per second; many hosts are connected to 10 Mbps Ethernet LANs where more traffic than wire speed is sent. Therefore, the ability to drop these packets at the network border, or even before it flows down the ingress pipes, is desired.
In the TCP/IP protocol, a three-way handshake takes place as a service is connected to. First in a SYN packet from the client, with which the service responses with a SYN-ACK. Finally, the client responds to the SYN-ACK and the conversation is considered started. A SYN Flood attack is when the client does not response to the SYN-ACK, tying up the service until the service times out, and continues to send SYN packets. The source address of the client is forged to a non-existent host, and as long as the SYN packets are sent faster than the timeout rate of the TCP stack waiting for the time out, the resources of the service will be tied up. This is a simplified version of what exactly happens. During a SYN flood attack, the attacker sends a large number of SYN packets alone, without the corresponding ACK packet response to the victim's SYN/ACK packets. The victim's connections table rapidly fills with incomplete connections, crowding out the legitimate traffic. Because the rate of attacking SYN packets usually far exceeds that of normal traffic, even when a table entry eventually is cleared out, another attacking SYN packet rather than a legitimate connection will fill it. But because SYN packets are a necessary part of legitimate traffic, they cannot be filtered out altogether. Second, SYN packets are relatively small, so an attacker can send large numbers of packets using relatively low-bandwidth Internet connections. Finally, because the attacker does not need to receive any data from the victim, the attacker can place random source IP addresses in the attacking packets to camouflage the actual source of the attack, and make filtering all but impossible. The basic purpose of a SYN flood is to use up all new network connections at a site and thus prevent legal users from being able to connect. TCP connections are made by first sending a request to connect with an ID in it. The receiving connection sends out an acknowledgment saying it's ready and then the sending system is supposed to send an acknowledgment that the connection has been made. The SYN (Synchronize sequence Number) packet is the first of these and contains the ID the receiver is supposed to reply to. If a fake ID is in that packet then the receiving system never gets a connection acknowledgment. Eventually, the connection will time out and that incoming channel on the receiver will become available again for another request. A SYN flood sends so many such requests that all incoming connections be continuously tied up waiting for acknowledgments that never come. This makes the server generally unavailable to legal users (unless one happens to sneak in just at the moment one of the tied-up connections times out).
The blue bomb derives its name from the effect it sometimes causes on the display as the operating system is terminating - a white-on-blue error screen that is commonly known as blue screen of death. Blue bombs are sometimes sent by multi-player game participants who are about to lose or users of Internet Relay Chat (IRC) who are making a final comment. This is known as "nuking" someone. A commonly used program for causing the blue bomb is WinNuke. Many Internet service providers are filtering out the packets so they do not reach users.
WinNuke is practically an outdated attack. All the new Windows versions are immune to WinNuke.
Jolt2 enables users across different networks to send IP fragment-driven denial of service attacks against NT/2000 by making victim's machine utilize 100% of its CPU when it attempts to process the illegal packets. Usage: c: \> jolt2 1.2.3.4 -p 80 4.5.6.7 The above command launches the attack from the attacker's machine with a spoofed IP address of 1.2.3.4 against the IP address 4.5.6.7 The victim's machine CPU resources reach 100% causing the machine to lock up.
Bubonic.c is a denial of service program written against Windows 2000 machines and certain versions of Linux. It has been noted to work against certain versions of Linux. The denial of service works by randomly sending TCP packets with random settings, etc. This in turn brings the load up causing the box to crash with error code: STOP 0x00000041 (0x00001000, 0x00001279, 0x000042A, 0x00000001) MUST_SUCCEED_POOL_EMPTY
Targa is a free software packet available in the Internet. Targa contains many of the most well known protocol or Operating System based DoS attacks. The attacker must be logged in with root permissions; since most of the attacks, use IP spoofing that requires root privileges. The attack can be done from any machine on which the targa.c code compiles. Mainly, the Targa packet is intended to be used in Linux or BSD Unix computers. Target platforms can be any possible Operating System. However, the attacks do not have an impact on all Operating Systems. The attacks that can be done with the Targa kit:
|
Amarjit Singh ---Regards,
Amarjit Singh   |
|
Posted: 23 Jun 2009 02:16 AM PDT Ping of Death
When a large ICMP packet is sent by a hostile machine to a target, the target receives the ping in fragments and starts reassembling the packet. However, due to the size of the packet once it is reassembled it is too big for the buffer and overflows it. Many operating systems did not know what to do when they received an oversized packet, so they froze, crashed, or rebooted. Ping of death attacks are particularly malicious because the identity of the attacker sending the oversized packet can be easily spoofed and also because the attacker just needs an IP address to carry out his attack. Windows 95 and Windows NT are capable of sending such a packet. By simply typing in "ping target -165500" you can send such a ping. There are also source code examples available for Unix platforms that allow large ping packets to be constructed. By the end of 1997, operating system vendors had made patches available to avoid the ping of death. However, many Web sites continue to block Internet Control Message Protocol (ICMP) ping messages at their firewalls to prevent any future variations of this kind of denial of service attack. Ping of death is also known as "long ICMP". Variations of the attack include jolt, sPING, ICMP bug, and IceNewk. |
---Regards, Amarjit Singh ---Regards,
Amarjit Singh   |
|
What is Distributed Denial of Service Attacks Posted: 23 Jun 2009 01:45 AM PDT
DDoS attacks involve breaking into hundreds or thousands of machines all over the Internet. Then the attacker installs DDoS software on them, allowing them to control all these burgled machines to launch coordinated attacks on victim sites. These attacks typically exhaust bandwidth, router processing capacity, or network stack resources, breaking network connectivity to the victims. DDoS is a combination of DoS attacks staged or carried out in concert from various hosts to penalize the target host from further serving its function. DDoS is term coined when the source of the attack is not coming from a single source, but multiple sources. DDoS cannot be eliminated with merely filtering the source IPs since it is often launched from multiple points installed with agents. Some known DDoS tools are Mstream, Trinoo, TFN2K (Tribe Flood Network), Stacheldraht and Shaft. DDoS attack is an example of a bandwidth attack.
|
---Regards, Amarjit Singh ---Regards,
Amarjit Singh   |
|
Types of Denial-of-Service Attacks Posted: 23 Jun 2009 01:43 AM PDT Types of Denial-of-Service AttacksThere are several general categories of DoS attacks. Some groups divide attacks into three classes: bandwidth attacks, protocol attacks, and logic attacks.
An attacker can consume bandwidth by transmitting any traffic at all on your network connection. A basic flood attack might use UDP or ICMP packets to simply consume all available bandwidth. For that matter, an attack could consist of TCP or raw IP packets, as long as the traffic is routed to your network. A simple bandwidth-consumption attack can exploit the throughput limits of servers or network equipment by focusing on high packet rates—sending large numbers of small packets. High-packet-rate attacks typically overwhelm network equipment before the traffic reaches the limit of available bandwidth. Routers, servers, and firewalls all have constraints on input-output processing, interrupt processing, CPU, and memory resources. Network equipment that reads packet headers to properly route traffic becomes stressed handling the high packet rate (packets per second), not the volume of the data (Mbps). In practice, denial of service is often accomplished by high packet rates, not by just traffic volume.
There are many variations on these common types of attacks and many varieties of attack tools to implement them. Denial-of-service attacks may be effective because of a combination of effects. For example, an attack that does not fully consume bandwidth or overload equipment throughput may be effective because it generates enough malformed traffic to crash a particular service, such as a web server or mail server. |
---Regards, Amarjit Singh---Regards,
Amarjit Singh   |
Learn Ethical Hacking & Get free hacking tools and softwares
|
A “Multivendor Post” to help our mutual iSCSI customers using VMware Posted: 24 Jun 2009 05:58 AM PDT SOURCE: Click Here Posted by: Dan Israel Today’s post is one you don’t often find in the blogosphere, see today’s post is a collaborative effort initiated by me, Chad Sakac (EMC), which includes contributions from Andy Banta (VMware), Vaughn Stewart (NetApp), Eric Schott (Dell/EqualLogic), and Adam Carter (HP/Lefthand), David Black (EMC) and various other folks at each of the companies. Together, our companies make up the large majority of the iSCSI market, all make great iSCSI targets, and we (as individuals and companies) all want our customers to have iSCSI success. I have to say, I see this one often - customer struggling to get high throughput out of iSCSI targets on ESX. Sometimes they are OK with that, but often I hear this comment: "…My internal SAS controller can drive 4-5x the throughput of an iSCSI LUN…" Can you get high throughput with iSCSI with GbE on ESX? The answer is YES. But there are some complications, and some configuration steps that are not immediately apparent. You need to understanding some iSCSI fundamentals, some Link Aggregation fundamentals, and know some ESX internals – none of which are immediately obvious… If you’re interested (and who wouldn’t be interested with a great topic and a bizzaro-world “multi-vendor collaboration”... I can feel the space-time continuum collapsing around me :-), read on... We could start this conversation by playing a trump card; 10GbE, but we’ll save this topic for another discussion. Today 10GbE is relatively expensive per port and relatively rare, and the vast majority of iSCSI and NFS deployments are on GbE. 10GbE is supported by VMware today (see the VMware HCL here), and all of the vendors here either have, or have announced 10GbE support. 10GbE can support the ideal number of cables from an ESX host – two. This reduction in port count can simplify configurations, reduce the need for link aggregation, provide ample bandwidth, and even unify FC using FCoE on the same fabric for customers with existing FC investments. We all expect to see rapid adoption of 10GbE as prices continue to drop. Chad has blogged on 10GbE and VMware here. This post is about trying to help people maximize iSCSI on GbE, so we’ll leave 10GbE for a followup. If you are serious about iSCSI in your production environment, it’s valuable to do a bit of learning, and it’s important to do a little engineering during design. iSCSI is easy to connect and begin using, but like many technologies which excel in terms of their simplicity the default options and parameters may not be robust enough to provide an iSCSI infrastructure which can support your business. With that in mind, this post is going to start with sections called “Understanding” which will walk through protocol details and ESX Software Initiator internals. You can skip them if you want to jump to configuration options, but a bit of learning goes a long way into understanding the WHY of the HOWs (which I personally always think makes them easier to remember). Understanding your Ethernet Infrastructure Do you have a “bet the business” Ethernet infrastructure? Don’t think of iSCSI (or NFS datastores) use here as “it’s just on my LAN”, but “this is the storage infrastructure that is supporting my entire critical VMware infrastructure”. IP storage needs the same sort of design thinking applied to FC infrastructure. Here are some things to think about: Are you separating you storage and network traffic on different ports? Could you use VLANs for this? Sure. But is that “bet the business” thinking? Do you want a temporarily busy LAN to swamp your storage (and vice-versa) for the sake of a few NICs and switch ports? If you’re using 10GbE, sure – but GbE? Think about Flow-Control (should be set to receive on switches and transmit on iSCSI targets) Enable spanning tree protocol with either RSTP or portfast enabled Filter / restrict bridge protocol data units on storage network ports If you want to squeeze out the last bit, configure jumbo frames (always end-to-end – otherwise you will get fragmented gobbledygook) Use Cat6 cables rather than Cat5/5e. Yes, Cat5e can work – but remember – this is “bet the business”, right? Are you sure you don’t want to buy that $10 cable? You’ll see later that things like cross-stack Etherchannel trunking can be handy in some configurations. Each Ethernet switch also varies in its internal architecture – for mission-critical, network intensive Ethernet purposes (like VMware datastores on iSCSI or NFS), amount of port buffers, and other internals matter – it’s a good idea to know what you are using. If performance is important, have you thought about how many workloads (guests) are you running? Both individually and in aggregate are they typically random, or streaming? Random I/O workloads put very little throughput stress on the SAN network. Conversely, sequential, large block I/O workloads place a heavier load. In the same vein, be careful running single stream I/O tests if your environment is multi-stream / multi-server. These types of tests are so abstract they provide zero data relative to the shared infrastructure that you are building. In general, don’t view “a single big LUN” as a good test – all arrays have internal threads handling I/Os, and so does the ESX host itself (for VMFS and for NFS datastores). In general, in aggregate, more threads are better than fewer. You increase threading on the host with more operations against that single LUN (or file system), and every vendor’s internals are slightly different, but in general, more internal array objects are better than fewer – as there are more threads. Not an “Ethernet” thing, but while we’re talking on the subject of performance generally and not skimping, there’s no magic on the brown spinny things – you need enough array spindles to support the IO workload – often not enough drives in total, or an under-configured specific sub/group of drives – every vendor does this differently (aggregates/RAID groups/pools), but all have some sort of “disk grouping” out of which LUNs (and file systems in some cases) get their collective IOPs. Understanding: iSCSI Fundamentals We need to begin with a prerequisite nomenclature to establish a start point. If you really want the “secret decoder ring” then start here: http://tools.ietf.org/html/rfc3720 This diagram is chicken scratch, but it gets the point across. The red numbers are explained below.  iSCSI initiator = an iSCSI client, and serves the same purpose as an HBA, sending SCSI commands, and encapsulating in IP packets. This can operate in the hypervisor (example in this case this would be the ESX software initiator or hardware initiator) and/or in the guests (example – the Microsoft iSCSI initiator). iSCSI target = an iSCSI server, usually on an array of some type. Arrays vary in how they implement this. Some have one (the array itself), some have many, some map them to physical interfaces, some make each LUN an iSCSI target. iSCSI initiator port = the end-point of an iSCSI session, and is not a TCP port. After all the handshaking, the iSCSI initiator device creates and maintains a list of iSCSI initiator ports. Think of the iSCSI initiator port as the “on ramp” for data. iSCSI network portal = an IP address or grouping of IP addresses used by iSCSI initiator or target (in which case it’s IP address and TCP port). There can be groupings of network portals into.. portal groups (see Multiple Connections per Session) iSCSI Connection = a TCP Connection, and carries control info, SCSI commands and data being read or written. iSCSI Session = one or more TCP connections that form an initiator-target session Multiple Connections per Session (MC/S) = iSCSI can have multiple connections within a single session (see above). MPIO = Multipathing, and used very generally as a term – but exists ABOVE the whole iSCSI layer (which in turn is on top of the network layer) in the hypervisor and/or in the guests. As an example, when you configure the ESX storage multipathing, that’s MPIO. MPIO is defacto load-balancing and availability model for iSCSI Understanding: Link Aggregation Fundamentals The next thing as a core bit of technology to understand is Link Aggregation. The group spent a fair amount of time going around on this as we were writing this post. Many people jump to this as a way as and “obvious” mechanism to provide greater aggregate bandwidth than a single GbE link can provide. The core thing to understand (and the bulk of our conversation – thank you Eric and David) is that 802.3ad/LACP surely aggregates physical links, but the mechanisms used to determine the whether a given flow of information follows one link or another are critical. Personally, I found this doc very clarifying.: http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf You’ll note several key things in this doc: All frames associated with a given “conversation” are transmitted on the same link to prevent mis-ordering of frames. So what is a “conversation”? A “conversation” is the TCP connection. The link selection for a conversation is usually done by doing a hash on the MAC addresses or IP address. There is a mechanism to “move a conversation” from one link to another (for loadbalancing), but the conversation stops on the first link before moving to the second. Link Aggregation achieves high utilization across multiple links when carrying multiple conversations, and is less efficient with a small number of conversations (and has no improved bandwith with just one). While Link Aggregation is good, it’s not as efficient as a single faster link. It’s notable that Link Aggregation and MPIO are very different. Link Aggregation applies between two network devices only. Link aggregation can load balance efficiently – but is not particularly efficient or predictable when there are a low number of TCP connections. Conversely MPIO applies on an end-to-end iSCSI session – a full path from the initiator to the target. It can be efficient in loadbalancing with a low number of TCP sessions. While Link Aggregation can be applied to iSCSI (as will be discussed below), MPIO is generally the design point for iSCSI multipathing. Understanding: iSCSI implementation in ESX 3.x The key to understanding the issue is that the ESX 3.x software initiator only supports a single iSCSI session with a single TCP connection for each iSCSI target. Making this visual… in the diagram above, while in iSCSI generally you can have multiple “purple pipes” each with one or more “orange pipes” to any iSCSI target, and use MPIO with multiple active paths to drive I/O down both paths. You can also have multiple “orange pipes” (the iSCSI connections) in each “purple pipe” (single iSCSI session) - Multiple Connections per Session (which effectively multipaths below the MPIO stack), shown in the diagram below. But in the ESX software iSCSI intiator case, you can only have one orange “pipe” for each purple pipe for every target (green boxes marked 2), and only one “purple pipe” for every iSCSI target. The end of the “purple pipe” is the iSCSI intiator port – and these are the “on ramps” for MPIO So, no matter what MPIO setup you have in ESX, it doesn't matter how many paths show up in the storage multipathing GUI for multipathing to a single iSCSI Target, because there’s only one iSCSI initiator port, only one TCP port per iSCSI target. The alternate path to the gets established after the primary active path is unreachable. This is shown in the diagram below. VMware can’t be accused of being unclear about this. Directly in the iSCSI SAN Configuration Guide: “ESX Server‐based iSCSI initiators establish only one connection to each target. This means storage systems with a single target containing multiple LUNs have all LUN traffic on that one connection”, but in general, in my experience, this is relatively unknown. This usually means that customers find that for a single iSCSI target (and however many LUNs that may be behind that target – 1 or more), they can’t drive more than 120-160MBps. This shouldn’t make anyone conclude that iSCSI is not a good choice or that 160MBps is a show-stopper. For perspective I was with a VERY big customer recently (more than 4000 VMs on Thursday and Friday two weeks ago) and their comment was that for their case (admittedly light I/O use from each VM) this was working well. Requirements differ for every customer. Now, this behavior will be changing in the next major VMware release. Among other improvements, the iSCSI initiator will be able to use multiple iSCSI sessions (hence multiple TCP connections). Looking at our diagram, this corresponds with “multiple purple pipes”for a single target. It won’t support MC/S or “multiple orange pipes per each purple pipe” – but in general this is not a big deal (large scale use of MC/S has shown a marginal higher efficiency than MPIO at very high end 10GbE configurations) . Multiple iSCSI sessions will mean multiple “on-ramps” for MPIO (and multiple “conversations” for Link Aggregation). The next version also brings core multipathing improvements in the vStorage initiative (improving all block storage): NMP round robin, ALUA support, and EMC PowerPath for VMware which integrates into the MPIO framework and further improves multipathing. In the spirit of this post, EMC is working to make PowerPath for VMware as heterogeneous as we can. Together – multiple iSCSI sessions per iSCSI target and improved multipathing means aggregate throughput for a single iSCSI target above that 160MBps mark in the next VMware release, as people are playing with now. Obviously we’ll do a follow up post. (Strongly) Recommended Additional Reading I would STRONGLY recommend reading a series of posts that the inimitable Scott Lowe has done on ESX networking, and start at his recap here: Also – I would strongly recommend reading the vendor documentation on this carefully.
> Network Performance Guidelines > VMware Virtual Infrastructure 3.x Considerations, Configuration and Operation Using an Equallogic PS Series SAN ENOUGH WITH THE LEARNING!!! HOW do you get high iSCSI throughput in ESX 3.x? As discussed earlier, the ESX 3.x software initiator really only works on a single TCP connection for each target – so all traffic to a single iSCSI Target will use a single logical interface. Without extra design measures, it does limit the amount of IO available to each iSCSI target to roughly 120 – 160 MBs of read and write access. This design does not limit the total amount of I/O bandwidth available to an ESX host configured with multiple GbE links for iSCSI traffic (or more generally VMKernel traffic) connecting to multiple datastores across multiple iSCSI targets, but does for a single iSCSI target without taking extra steps. Here are the questions that customers usually ask themselves: Question 1: How do I configure MPIO (in this case, VMware NMP) and my iSCSI targets and LUNs to get the most optimal use of my network infrastructure? How do I scale that up? Question 2: If I have a single LUN that needs really high bandwidth – more than 160MBps and I can’t wait for the next major ESX version, how do I do that? Question 3: Do I use the Software Initiator or the Hardware Initiator? Question 4: Do I use Link Aggregation and if so, how? Here are the answers you seek… . . . Question 1: How do I configure MPIO (in this case, VMware NMP) and my iSCSI targets and LUNs to get the most optimal use of my network infrastructure? How do I scale that up? Answer 1: Keep it simple. Use the ESX iSCSI software initiator. Use multiple iSCSI targets. Use MPIO at the ESX layer. Add Ethernet links and iSCSI targets to increase overall throughput. Ser your expectation for no more than ~160MBps for a single iSCSI target. Remember an iSCSI session is from initiator to target. If use multiple iSCSI targets, with multiple IP addresses, you will use all the available links in aggregate, the storage traffic in total will load balance relatively well. But any individual one target will be limited to a maximum of single GbE connection's worth of bandwidth. Remember that this also applies to all the LUNs behind that target. So, consider that as you distribute the LUNs appropriately among those targets. The ESX initiator uses the same core method to get a list of targets from any iSCSI array (static configuration or dynamic discovery using the iSCSI SendTargets request) and then a list of LUNs behind that target (SCSI REPORT LUNS command). So, to place your LUNs appropriately to balance the workload:
Select your active paths in the VMware ESX multi-pathing dialog to balance the I/O across the paths to your targets and LUNs using the Virtual Center dialog shown below (from the VMWare iSCSI SAN Configuration Guide). Also it can take up to 60 seconds for the standby path to become active as the session needs to be established and the MPIO failover needs to occur, as noted in VMware iSCSI configuration guide. There are some good tips there (and in the Vendor best practice docs) about extending guest timeouts to withstand the delay without a fatal I/O error in the guest.  Question 2: If I have a single LUN that needs really high bandwidth – more than 160MBps and I can’t wait for the next major ESX version, how do I do that? Answer 2: Use an iSCSI software initiator in the guest along with either MPIO or MC/S This model allows the Guest Operating Systems to be “directly” on the SAN and to manage their own LUNs. Assign multiple vNICs to the VM, and map those to different pNICs. Many of the software initiators in this space are very robust (like the Microsoft iSCSI initiator). They provide their guest-based multipathing and load-balancing via MPIO (or MC/S) based on the number of NICs allocated to the VM. As we worked on this post, all the vendors involved agreed – we’re surprised that this mechanism isn't more popular. People have been doing it for a long time, and it works, even through VMotion operations where some packets are lost (TCP retransmits them – iSCSI is ok with occasional loss, but constant losses slow TCP down – something to look at if you’re seeing poor iSCSI throughput). It has a big downside, though – you need to manually configure the storage inside each guest, which doesn’t scale particularly well from a configuration standpoint – so for most customers they stick with the “keep it simple” method in Answer 1, and selectively use this for LUNs needing high throughput. There are other bonuses too:
There are, of course, things that negative about this approach.
Question 3: Do I use the Software Initiator or the Hardware Initiator? Answer 3: In general, use the Software Initiator except where iSCSI boot is specifically required. This method bypasses the ESX software initiator entirely. Like the ESX software initiator, hardware iSCSI initiators uses the ESX MPIO storage stack for multipathing – but doesn’t have the single connection per target limit. But, since you still have all the normal caveats with static load balancing and using the ESX NMP software (active/passive model, with static, manual loadbalancing), this won’t increase the throughput for a single iSCSI target. In general, across all the contributors from each company, our personal preference is to use the software initiator. Why? In general it’s simple, and since it’s used very widely, very tested, very robust. It also has a clear 10GbE support path. Question 4: Do I use Link Aggregation and if so, how? Answer 4: There are some reasons to use Link Aggregation, but increasing a throughput to a single iSCSI target isn’t one of them in ESX 3.x. What about Link Aggregation – shouldn’t that resolve the issue of not being able to drive more than a single GbE for each iSCSI target? In a word – NO. A TCP connection will have the same IP addresses and MAC addresses for the duration of the connection, and therefore the same hash result. This means that regardless of your link aggregation setup, in ESX 3.x, the network traffic from an ESX host for a single iSCSI target will always follow a single link. So, why discuss it here? While this post focuses on iSCSI, in some cases, customers are using both NFS and iSCSI datastores. In the NFS datastore case, MPIO mechanisms are not an option, load-balancing and HA is all about Link Aggregation. So in that case, the iSCSI solution needs to work in with concurrently existing Link Aggregation. Now, Link Aggregation can be used completely as an alternative to MPIO from the iSCSI initiator to the target. That said, it is notably more complex than the MPIO mechanism, requiring more configuration, and isn’t better in any material way. If you’ve configured Link Aggregation to support NFS datastores, it’s easier to leave the existing Link Aggregation from the ESX host to the switch, and then simply layer on top many iSCSI targets and MPIO (i.e. “just do answer 1 on top of the Link Aggregation”). To keep this post concise and focused on iSCSI, the multi-vendor team here decided to cut out some of NFS/iSCSI hybrid use case and configuration details, and leave that to a subsequent EMC Celerra/NetApp FAS post. In closing..... I would suggest that anyone considering iSCSI with VMware should feel confident that their deployments can provide high performance and high availability. You would be joining many, many customer enjoying the benefits of VMware and advanced storage that leverages Ethernet. To make your deployment a success, understand the “one link max per iSCSI target” ESX 3.x iSCSI initiator behavior. Set your expectations accordingly, and if you have to, use the guest iSCSI initiator method for LUNs needing higher bandwidth than a single link can provide. Most of all ensure that you follow the best practices of your storage vendor and VMware. Posted at 09:00 AM in EMC Competitors, EMC VMware Tech Stuff, iSCSI | Permalink Digg This | Save to del.icio.us Amarjit Singh |
---Regards,
Amarjit Singh   |