Dictionary Attack

UDP, the User Datagram Protocol, is often used by applications that prefer to avoid the overhead of establishing a TCP connection (such as DNS, NFS, TFTP), or those that can tolerate occasional errors in the interest of efficiency (such as streaming audio or video). UDP is given the Internet protocol number of 17 and is defined in RFC 768 (www.faqs.org/rfcs/rfc768.html).

The UDP model is much simpler than that of TCP. There is no session-level error checking or retransmission built into the protocol. The packets do, however, contain a checksum. A receiving host can verify this checksum to ensure that the packet has not been corrupted during transit. The sending host, however, does not receive a protocol-level
acknowledgment that the packet was delivered. If any such reliability is needed, it is left to be implemented at the application level.

An example of an application-level, reliable protocol built on UDP is the Trivial File Transfer Protocol, or TFTP (see RFC 1350,  www.faqs.org/rfcs/rfc1350.html), which consists of server and client implementations. These two processes exchange crafted UDP packets that contain handshaking information along with the data being transferred. The
application programs must handle this handshaking themselves, as well as extracting the data. Contrast this with TCP data transfers, where the application receives only the data bytes and needn’t concern itself with the details of the data transfer.

UDP uses 16-bit port numbers, as does TCP, but UDP and TCP ports are distinctly different. As with TCP, there generally needs to be a listening process at the receiving host to accept and respond to the request. Under normal circumstances, the arrival of a UDP packet destined for a port with no listeners will cause the receiving host to respond with an ICMP port unreachable  message.

UDP Header
The UDP header consists of four 16-bit fields, totaling 8 bytes in length. These fields follow immediately after the IP header:

Source port A 16-bit field (values from 0 to 65,535).

Destination port  A 16-bit field (values from 0 to 65,535).

Length A 16-bit field (values from 0 to 65,535). This field is the length of the UDP header and data bytes, and it does not include the IP header. Typically, the UDP packet length should be the difference between the IP total length field and the IP header length. If there is a discrepancy, most implementations will discard the packet as invalid.

UDP checksum A 16-bit field (values from 0 to 65,535). This value is computed using ones-complement math over a pseudo-header, the UDP header, and the UDP data. The checksum is actually optional in UDP, and if this field is set to 0, the checksum will not be examined by the receiving host. This field was originally put in place as a performance-enhancing measure, but currently all packets should have a checksum. Those that do not may bear further examination for possible intrusion attempts.

Well, This is our first video, we hope you will like, is a 30 minutes lenght video, spoken (sorry) in english, where we try to teach you how to attack a WEP Shared Key 256 bit wireless.

Remember to update your aircrack-ng suite inside you will find the instructions.

ENJOY!!

To see the whole video in high-resolution click HERE

The standard TCP header is defined in RFC 791 and illustrated in Figure 2-5. It consists of a minimum of 20 bytes and a maximum of 60 bytes. The application-specific information, which is delivered to the application program, is located inthe data portion of the TCP packet.
 

The TCP header consists of the following fields:

Source port A 16-bit field (values from 0 to 65,535) that identifies the source port of the connection.

Destination port  A 16-bit field (values from 0 to 65,535) that identifies the destination port of the connection.

Sequence number A 32-bit field (values from 0 to 23 2 – 1 ) that identifies the current byte count (as of the end of this packet) relative to the initial sequence number (ISN), which is set in the initial SYN packet. Each byte transmitted, as well as the SYN and FIN flags, increment this value.

Acknowledgment number A 32-bit field (values from 0 to 23 2– 1 ) that holds the last sequence number of this communication transmitted by the other party and received correctly by the host. In the first packet sent (the initial SYN), this field is undefined.

Data offset A 4-bit field (values from 0 to 15) that indicates the number of 32-bit words in the header portion of the packet. The maximum size of a TCP header is thus 15 x 4 = 60 bytes. The minimum size of a TCP header (a header without optional arguments) is 5 words, or 20 bytes. Values of 0 through 4 are invalid.

Reserved A 6-bit field reserved for future expansion—it should always be 0.

Flags A 6-bit field that contains the following six 1-bit flags:
URG Urgent

ACK Acknowledgment

PSH Push

RST Reset connection

SYN Synchronize connection

FIN Finish

Window A 16-bit field (values from 0 to 65,535) that indicates the amount of receive buffer space available. This field has important performance implications, as it tells the remote system how much traffic the local host can accept, and thus how many packets the remote host can send before expecting an acknowledgment. The TCP Window Scale option modifies the behavior of this field.

Checksum A 16-bit field (values from 0 to 65,535). This value is computed using ones-complement arithmetic over a pseudo-header, the TCP header, and the TCP data. The receiving system recomputes this value and drops the packet if the checksum is invalid—in this case, the TCP timeout mechanism will cause the packet to be retransmitted by the sender.

Note The pseudo-header used to compute UDP and TCP checksums includes the source and destination IP addresses, as well as the protocol specific header. At the packet’s final destination, the checksum is recomputed using the source and destination addresses obtained from the header of the IP packet which transported the protocol-specific packet. If the checksums agree, then we can have a high degree of confidence that the packet reached the intended destination host, as well as the correct protocol- specific port.

Urgent pointer A 16-bit field (values from 0 to 65,535) that points to the last byte of any urgent data that an application wishes to transfer immediately to the receiving host, bypassing normal buffering. This field should have a value of 0 unless the Urgent flag is set.

Options This field can be used for various option capabilities that tune the behavior of the TCP communications.These are padded as necessary to bring the TCP header length to an even multiple of 32 bits.

Data The application data is placed here. The length of this field should match the total packet size identified in the IP header, minus the Internet header length, minus the TCP data offset (all scaled as appropriate to reflectbytes).

TCP, the Transmission Control Protocol, can rightly lay claim to being the crown jewel of the IP protocol suite it is by ar the most widely used protocol, as well as the one that is responsible for carrying the majority of the Internet’s useful ontent. TCP adds to the best-effort delivery capabilities of IP.

TCP Reliable Delivery

TCP, being embedded within an IP packet, paradoxically must employ the unreliable delivery mechanisms of IP to nsure reliability. Of course, perfect reliability is not possible in the real world, due to hardware, routing, and software ailures, but TCP nevertheless achieves a high degree of reliability by employing three distinct, cooperating processes:

TCP checksum The TCP checksum is computed over the entire TCP packet, including the data portion. If the omputed checksum does not match the packet contents, the receiving host discards the packet. In that case, he packet timeout mechanism (described below) eventually causes the sending host to retransmit the packet.

Mutual acknowledgment of received data Each system maintains a count of bytes received properly from the ther host (known as the acknowledgment or ACK number), as well as the number of bytes sent to the other host known as the sequence or SYN number). Both systems thus know the expected amount of traffic that the other host should have seen. If a host fails to acknowledge data sent to it (by failing to increment the ACK number properly), the other host will resend that traffic again upon receipt of the next ACK number that is greater than the expected value (that is, if there is a gap in the sequence of numbers). Thus, each host acknowledges the traffic that the other host has sent, and each host is aware of the traffic that the other side has received.

Packet timeout As IP’s non-guaranteed delivery may silently drop a packet, TCP will wait for an expected response to the sent packet for a given period of time, and then will retransmit the packet, on the assumption that either the packet or its response was lost. If a host receives a packet that it has already received and responded to, it will assume that the response was lost in transit and will retransmit its initial response.

Retransmissions may occur multiple times with varying timeouts before TCP decides that the IP layer is hopelessly broken at that point, it will signal an error to the application.

TCP Communications Model

Each TCP connection is uniquely identified by four distinct items (a four-tuple): the IP addresses of the two communicating systems and the TCP ports used by each system. This does not mean that two systems cannot communicate using the same service on more than one connection—multiuser systems support multiple telnet connections from the same client. In such a case, the IP addresses will be the same, and the telnet service will be found on the standard TCP port 23. However, the client system will use a different port for each connection, thus keeping thetraffic for each connection distinct.

Under normal conditions, a listening process must be running on the receiving host to accept and respond to TCP connection requests. If a TCP packet is received that is destined for a port with no listeners, a TCP RST packet will be sent back to the source by the receiving host.

TCP uses 16-bit port numbers, which means that there are 65,536 possible ports. These ports are normally divided into two distinct ranges: 0 through 1,023 represent the well-known services that are (on Unix systems) only accessible by the root account. Ports 1,024 through 65,535 are termed ephemeral ports, which user programs can access and use to provide services or use as client ports for establishing connections.

To reliably maintain a connection between two systems requires a well-defined process for session establishment, maintenance, and teardown.
The receiving host socket is in a passive, listening state, awaiting an incoming connection request from the initiator.

The initiating system sends an initial TCP packet with the SYN flag set, and an initial sequence number (ISN) chosen pseudo-randomly. Each byte transmitted, as well as a few flags (SYN or FIN), will increment this sequence number. In effect, the initiator is signaling that it will start numbering the bytes transferred over the connection starting from the ISN. The SYN flag itself consumes the first sequence number.

The receiver will respond with a SYN/ACK packet, indicating its readiness to establish a connection, and acknowledging the initiator’s SYN. In the response, the receiver puts the initiator’s ISN+1 in the Acknowledgment field and sets up its own ISN in the SYN field.

The three-way handshake is then completed when the initiating system sends an ACK packet back to the responding system. The purpose of this packet is to let the responding system know that the connection is fully established.

At this point, the session is established. When either party wishes to send data to the other, it will send a packet with the ACK flag set, with an acknowledgment of the last sequence number (in the Acknowledgment field) received from the remote host, and with its own sequence number incremented to reflect the amount of data being transmitted. The actual data to be sent is included in the TCP data portion of the packet. If there is no data to be sent, and the host is merely acknowledging the data received from the other party, a packet with no TCP data portion is sent.

When a system is finished with the communication, it will send a FIN/ACK packet, signaling that it wishes to close the connection. However, a connection cannot be closed by only one side. Rather, by closing the connection, the system is indicating that it has no more data to send. The host receiving the initial FIN sends an ACK acknowledging the FIN, and if that system doesn’t have any more data to send either, it sends a FIN as well.
When the system that first closed the connection responds with an ACK of its own, the connection will be considered closed. Either party can also abort the connection by sending a RST/ACK packet, which will cause the connection to be immediately closed.

It would be desirable for systems to determine the maximum MTU they could
use in communications to avoid the overhead of fragmentation. According to RFC 791, all devices talking to IP must support a minimum MTU of 68 bytes, so fragmentation can be avoided by transmitting IP packets of 68 bytes which allows for an IP header of up to 60 bytes, and a fragment size of 8 bytes. Unfortunately, most useful packets will not fit into 68 bytes, so they may need to be fragmented anyway.

However, it is possible, by the use of some trickery, for a host to determine the maximum MTU that a link between two systems will support, as follows:

A host will assemble a maximum-size test packet (as defined by the interface MTU), set the Do Not Fragment bit, and send it on the wire to the destination.

If the packet reaches a router that would need to fragment the packet to forward it, but cannot, due to the Do Not Fragment bit, the router will send back an ICMP 吐ragmentation needed, but Do Not Fragment bit set_ error
message.

When the sending host receives the ICMP message, it will know that one of the links between the two hosts requires a smaller MTU, and thus can send a smaller test packet in the same manner. The appropriate size can be determined mathematically by dividing the packet size in half, or by successively trying popular default packet sizes for various media (4,352 for FDDI, 1,500 for Ethernet, 576 for X.25 and ISDN, and so on), until a suitable frame size is discovered that can accommodate the full end-to-end link without fragmentation.

If, on the other hand, no ICMP message is received after a suitable time delay, the sending host assumes that traffic can be sent to the target without danger of fragmentation.

Of course, this mechanism is not completely reliable. ICMP traffic is dependent on the best-effort delivery resources of IP. Although packet corruption is minimized by the use of a checksum, the message could be sent but dropped somewhere in the network, and the sending host would assume that the Path MTU is larger than it really is. Also, since routing is dynamic, the path could change, and the MTU might increase or decrease as a result. Some sites, for example, may have an emergency low-performance link to the Internet, for use when the main link fails. If this emergency link uses a different type of medium than the normal link, it likely will also have a different MTU. If the MTU is lower, traffic using the link will likely be fragmented, exacerbating the performance problems. Thus, it is important that ICMP traffic not be discarded at a network perimeter to allow these sorts of network issues to be signaled to hosts or internal routers for action.

More information on the process of Path MTU discovery can be found in RFC 1191 (www.faqs.org/rfcs/rfc1191.html).

The IP Header

The standard IP header is defined in RFC 791. It consists of a minimum of 20 bytes and
ranges up to a maximum of 60 bytes. Embedded in the data portion of the IP packet is the protocol-specific packet (such as a TCP or UDP packet).

These are the header fields:

Version number A 4-bit field (values from 0 to 15) that specifies which version of IP the packet refers to. On the current Internet, this value will generally be 4, although the next generation IPv6 uses a value of 6.

Internet header length (IHL) A 4-bit field (values from 0 to 15) that specifies the length of the header in 32-bit (4-byte) words. Padding bytes are added to fill up the header to a multiple of 32 bits. Note that the maximum header length is thus 15 x 4 bytes = 60 bytes.

Type of service (TOS) An 8-bit field (values from 0 to 255) that encodes the service type desired for the packet. This field has been slowly gaining in usage. It encodes, via bit-level fields, the desired delivery characteristics of the packet from the following types: minimize delay, maximize throughput, maximize reliability, minimize monetary cost, and normal service. Routers can use this information to make routing decisions to conform to these requests.

Total length A 16-bit field (values from 0 to 65,535) that specifies the total length of the packet in bytes. There are few, if any, physical media that can directly transport a packet of the maximum size. If the packet is larger than the physical media can transport, the packet will be fragmented into multiple smaller packets that the media can transport. The next three fields support this fragmentation process.

IP identification A 16-bit field (values from 0 to 65,535), used to tie the fragments of a packet together. All fragments of an original packet will have this field replicated from the original packet to allow the fragments to be identified and reassembled into the original packet.

Flags A 3-bit field (values from 0 to 7) that contains three flags (most normal packets will have these 3 bits set to 000):
Reserved (should always be 0)

Do Not Fragment bit (D), which can have the following values:
0 Packet may be fragmented during transport

1 Packet is not to be fragmented (ICMP error message returned to the sending host if the packet
reaches a router which needs to fragment the packet, but cannot due to this bit being set)

More Fragments bit (M), which can have the following values:
 

0 This is the last (or only) fragment

1 More fragments exist

Fragment offset A 13-bit field (values from 0 to 8,191) that when multiplied by 8 gives the offset into the reassembled packet of the current fragment. In an unfragmented packet, this field will be set to 0.

Time to live (TTL) An 8-bit field (values from 0 to 255) that specifies the lifetime of the packet in the
Internet—each time a packet takes another hop through a router, this field is decremented by one. If the TTL value drops to zero, the packet is discarded, and an ICMP TTL exceeded message is sent back to the originating system. This field ensures that packets cannot persist on the Internet indefinitely in the event of a routing loop or other malfunction. Various operating systems have default settings for this field, but rarely is a value of more than 32 necessary in the current Internet.

Protocol An 8-bit field (values from 0 to 255) that identifies which protocol is being used by the message being transported in this packet. The data portion of the IP packet contains the protocol-dependent header, as well as the actual data being transported between the communicating systems. These are some common values:
1 ICMP

6 TCP

17 UDP

IP header checksum A 16-bit field (values from 0 to 65,535) that is a checksum of the IP header computed using ones-complement arithmetic. Each hop from one router to the next will cause this field to be recomputed as the header contents change, the most common change being that the TTL field will be decremented, although fragmentation, and some options, such as Record route, and Internet timestamp can also alter the header.

Source address A 32-bit field that contains the source IP address of the packet. The traditional dotted format (1.2.3.4) is a convenient designation for the four bytes that make up this 32-bit field.

Destination address A 32-bit field that is the destination IP address of the packet.

Options A 0- to 40-byte field. Multiple optional features are allowed in this field, some of which have security implications.

Padding A series of 8-bit bytes consisting of all 0’s to pad the header up to the number of 32-bit words specified in the IHL field.

Data This field contains the data portion of the IP packet. Its length should be the difference between the Total length field and the IHL field (which, being a count of 32-bit words, must be multiplied by 4 to convert to bytes).
Its contents are dependent on the protocol in use, but will typically consist of a protocol header and data bytes.

IP Fragmentation

It was understood by the developers of the IP protocol suite that a sending host might have little or no idea of the characteristics of the physical network through which traffic may be routed, and thus could not adjust packet sizes to fit the requirements of that network. Also, as traffic routing is an adaptive, dynamic process, a packet size appropriate for a known network may not be appropriate for an alternative routing pathway. If the preferred pathway goes down for
any reason, routing protocols will attempt to develop alternative pathways, and they may not have the same Maximum Transmission Unit (MTU—the maximum packet size that the media will support).

These considerations drove the development of a packet fragmentation and reassembly process. The decision to fragment a packet is made by a router when the MTU of the next hop is smaller than the packet size. The packet can be flagged to disallow fragmentation, in which case an ICMP error message (fragmentation needed, but Do Not Fragmentbit set_) is sent back to the originating host. Otherwise, the original packet will be split into two or more packets containing the fragments and the regenerated IP header with changes made to the appropriate fields and a recalculated checksum.

Fragmentation could take place several times, as one router may split a packet to match its MTU, then pass the fragments on to another router that may have an even smaller MTU, thus necessitating another fragmentation of the previously fragmented packet. Thus, the receiving host is the most reasonable place to reassemble the packet, although IDSs often perform reassembly as well, in order to examine packet contents.

Three fields in the IP header are used to support the fragmentation of packets:

IP identification This 16-bit field is the glue that binds the fragments together—every packet is stamped with this field, which on modern systems is generated via a pseudo-random process. For each IP packet thereafter, this number is generally incremented by 1. Each fragment of the original packet will contain the same value in the IP ID field, and the receiving host will use this value to collect together all the fragments for reassembly. Note that since this field is only 16 bits long, the value must wrap around after 65,535 packets.

Fragmentation offset This 13-bit field defines which portion of the original packet the current fragment references. As the maximum packet size in IP is 65,535 bytes, which is represented in 16 bits, it would seem that 16 bits would be required to identify a fragment offset, yet this field is only 13 bits long. The solution is to multiply the fragmentation offset field by 8 (23 ) .  Th i s  m ea n s  th a t packets are only split on multiples of 8 bytes, which is certainly fine-grained enough.

Flags This 3-bit field has three 1-bit flags: a reserved bit that should always be 0, a Do Not Fragment bit that indicates whether fragmentation is allowed for this packet, and a More Fragments bit that indicates whether further fragments are being sent or not.

For an unfragmented packet, the fragmentation offset will be set to 0, and the More Fragments bit will be cleared, indicating that the packet is complete.

The receiving system will collect the fragments, identified by the IP ID field, until the last fragment is received, which is signified by a 0 in the More Fragments bit. If there are no holes in the completed packet, the packet is ready for further processing. If a fragment was not received, there will be a hole in the buffer, and the system will have to wait until it is received. If a timeout occurs before IP has received every fragment, the received buffer will be discarded, and depending on the upper-level protocol, the entire packet may be retransmitted, with the possibility of fragmentation
occurring again.

RFC 1122 recommends that the reassembly time be between 60 and 120 seconds, and that an ICMP time-exceeded error be sent to the source host if the timer expires and the first fragment of the datagram has been received. This ICMP message contains the first 64 bits of fragment 0 (or less if the fragment is less than 8 bytes long).

Fragmentation solves the problems of varying frame sizes between communicating hosts at a performance penalty, security problems can result from fragments. Fragments have been used to evade firewalls and intrusion-detection systems. Wouldn’t it be nice for systems to be able to determine the maximum size packets that could be transmitted on a link, and thus avoid the overhead of using fragmentation? There is, in fact, a process that determines the MTU between two hosts so that (unless the route changes) packets can be sent without resorting to
fragmentation. It’s called Path MTU discovery.

Although the OSI model is useful for understanding and describing the network functions that apply during communication, the IP suite of protocols does not conform to the model described by OSI. It was developed independently of OSI, and the IP designers used the simpler conceptual model . Generally, TCP/IP networking is split into four categories:

Network hardware
This category covers the network hardware components (corresponding to the OSI model’s physical and data-link layers) that are relied upon by TCP/IP. The network stack is coded to efficiently utilize these components, and unlike the OSI model, there is no distinct separation between the functions of these
components. When a packet is to be sent down the wire,  the IP software (often called the network stack_) will communicate with a device driver for the network card, which will encapsulate the data appropriately for thedata-link layer, and send it out to the physical medium. In many cases (Ethernet, frame relay, and others), the network hardware performs a checksum on the data that it transports.

IP The Internet Protocol works at the network layer to provide a routing and delivery mechanism for traffic. IP packets include a checksum that provides a reasonable assurance that a received packet has not been corrupted in transit. However, IP does not provide guaranteed delivery of packets or retransmission of corrupted or lost packets.

Transport protocols TCP and UDP (the User Datagram Protocol) work at the transport and session layers. TCP provides for reliable virtual circuits_ with error correction. UDP provides no such reliability features, but does provide a lighter-weight mechanism for delivery of data, and it relies on application- level techniques to make provisions for lost packets. ICMP (the Internet Control Message Protocol), which provides feedback on network status, is also found at this level.

Presentation and application layers
The presentation and application layers are generally merged when the application receives the data, although some applications (X Windows being an example) act as presentation-level services on behalf of other application programs that employ their services. However, such services are not part of the networking layer—they provide a layering at the application level.

Internet Protocol (IP)
IP (the Internet Protocol) provides a basic framework for the transport of traffic from source to destination on the Internet. (See RFC 1180 for a TCP/IP tutorial; www.faqs.org/rfcs/rfc1180.html). By design, it functions as an encapsulation (wrapper) and transport mechanism for this traffic. There is a header checksum to validate that the packet header, but not necessarily the data, has not been corrupted in transit. However, IP provides no facilities for retransmission or error correction.

Best-Effort Delivery
IP is responsible for the routing and delivery of packets on the Internet. If a packet is lost in transmission, as, for instance, during a period of congested activity, IP will not, of itself, trigger a retransmission. Instead, it is up to the higher-level protocol to detect that the packet has not been delivered and to take corrective action. IP will also be the transport mechanism for that corrective action, so it is possible that the first corrective action taken may, in turn, not be delivered. The higher-level protocols built on top of IP are expected to implement the necessary error-correction
measures for that eventuality. TCP, for instance, has mechanisms to trigger multiple retransmissions. Only after repeated failures to communicate does TCP decide that the transport layer (IP) is fatally broken and, in this case, it provides a notification to the application requesting the communication.

Encapsulation
In the layered approach we have been discussing, each layer is embedded (or encapsulated) in a wrapper from the next lower-level protocol. On an Ethernet network, for instance, the actual wire protocol consists of Ethernet frames, which are addressed using 48-bit hardware addresses for the source and destination Ethernet adapters, and this includes a cyclical redundancy check (CRC) code to ensure reliability. Embedded in the data portion of this frame will be an IP packet, which encodes its source and destination using 32-bit IP addresses, and it also contains a checksum for
reliability. Embedded as the data portion of the IP packet is a protocol-specific packet. In the case of TCP or UDP, this will contain source and destination ports, along with yet another checksum. The data portion of this packet will consist of the application or presentation layer data. Thus, each successive layer’s message is treated as data by the layer below it, which provides an extensible framework.

Although having multiple checksums may seem redundant, the design actually allows each layer to detect faults emanating from the layer before it, and to take appropriate action. If the implementation employed only one check code, the traffic would need to travel completely from source to destination before any transmission faults could be detected. Using multiple checksums allows for detection of faults on the local Ethernet using the Ethernet CRC, faults in clean packet transmission between connected networks via the IP checksum, and faults in delivery to the final destination by the protocol-specific checksum. Corrective action can thus be taken at the point where the fault
occurred. The redundancy contributes to the reliability and efficiency of the Internet, as well as assisting in failure detection.

 Intrusion-Detection and Intrusion-Prevention MythsThere are several untrue intrusion-detection and intrusion-prevention myths. These assertions repeatedly come up, even though some are diametrically opposed to others.

Myth 1: Intrusion detection and intrusion prevention are basically the same technology. Many believe that because some IDS systems have TCP kill and RESET capabilities that they are pretty much the same thing as IPS. The truth is that each of these technologies are separate in design and in function. An IPS device sits inline, and all the packets have to pass through it. If a suspicious packet has been detected, it can be dropped. With IDS this is not the case the suspicious packets are sent on to the internal interface to be analyzed, an alert is then sent, and a response generated. The latency involved in an IDS often results in a failed response. That is because an IDS is designed for detecting intrusions, not responding to them, though they do have some rudimentary response capabilities.

Myth 2: Intrusion-detection systems give too many false positives to be of any real value. It is true that IDSs do give what appear to be false positives. Typically, signatures released by vendors are accurate, but sometimes legitimate traffic sets them off. You need to properly fine-tune the IDS for your particular network. What often happens is that an organization implements IDS and doesn’t tune it, and soon the administrators feel overwhelmed by the alerts, which are mostly false positives. If an organization starts out on small segments of the network at a time and gets the IDS tuned to better understand what is and is not legitimate, the results will be better.

Myth 3: Intrusion detection will eventually replace firewalls. Wrong! This will not happen. IDSs and firewalls perform separate and distinct functions on the network. We will likely see that most firewalls have some IDS and IPS capabilities, but IDS and IPS are just single layers in a security program, and they are not meant to replace firewalls.

Myth 4: IDS systems are on the way out, and IPS and firewalls are the wave of the future. IDSs are far from becoming obsolete. We may see the integration of IDS and IPS capabilities within firewalls and routers, but the technology remains the same and the need is apparent. The wave of the future is seeing how the two can complement each other, not in debating which is better. There is some traffic that you do not want a response to, and that traffic is better passed off to an IDS.

Myth 5: IDSs are the wave of the future. This is the opposite of the previous myth, but the answer is much the same. Both IDS and IPS technologies have a place in securing a network or host. There is no one 都ilver bullet_ that will take care of everything. Intrusion detection is here to stay, but it is not the only technology in the game-IPS is also needed.

Myth 6: IDSs and IPSs will catch or stop all network intrusions. This seems like a ridiculous statement to the technically minded, but it is often asked by management. Yes, IDS and IPS will help to prevent and deter some attacks, but they will never be able to catch everything.

Myth 7: When an organization implements IDS or IPS, it should need fewer security professionals. There is some truth to this myth in that automating intrusion detection can reduce the number of individuals needed to detect security breaches in systems and networks. At the same time, however, one of the big issues with IDS and IPS is that they do a good job at finding attacks, but there needs to be a trained professional on the other end who can interpret and react to the information. While this may seem like additional overhead, the attacks would be there whether or not you detected them.

Myth 8: You need real-time detection in order to get any real value from an IDS. Real time is a bit of a misnomer, as the response and identification will always come after the attack has entered the network or host. Abetter approach is to ask whether the alert or response is accurate and is in time for the necessary response. While faster can be better, it also has disadvantages, such as cost and more difficult data handling-data that are received in real time needs to be handled in real time.