Presentation is loading. Please wait.

Presentation is loading. Please wait.

Examining IP Header Fields

Similar presentations


Presentation on theme: "Examining IP Header Fields"— Presentation transcript:

1 Examining IP Header Fields
There are 2 types of attack towards Network Intrusion Detection System (NIDS): Insertion Attacks - Where an attacker forces an NIDS to read information that isn’t valid, confusing it about what’s actually happening. Evasion Attacks - When attackers slips entire packet past the NIDS by making them look invalid when they aren’t.

2 Insertion Attack

3 Evasion Attack

4 INSERTION ATTACKS Attacker would to send the packet R E W T to obscure NIDS Attacker send three packet which is R , O , and EWT E W T O R Confuse about what’s actually happening, NIDS accepted the packet O NIDS sees R O E W T, but Victim host sees R E W T.

5 NIDS sees E W T, but Victim host sees R E W T.
EVASION ATTACKS Attacker would to send the packet E W T to obscure NIDS Attacker send two packet which is R, and E W T E W T R Attacker slips entire packet past the NIDS by making them look invalid when they aren’t. Packet R NIDS sees E W T, but Victim host sees R E W T.

6 5 ways to examine IP header fields either being attack or not :
1. IP Version Number There are two IP version numbers currently in use. There are IPv4 and IPv6. IPv4 is the most common and pervasive version number thus far. IPv6 is not yet in wide use in user networks. The IP version field must be validated by a receiving host (receiver) and if not valid, the datagram is discarded and no error message is sent to the sending host (sender). RFC 1121 protocol states that the datagram must be silently discarded if an invalid value is discovered. Using IP version number, it is rather difficult to detect insertion attack unless the attacker is on the same network as the NIDS.

7 IP VERSION NUMBER Datagram Sender Receiver
Invalid datagram IP Version Number (RFC 1121 PROTOCOL) Datagram Sender Receiver Datagram silently discarded. No error message sent to sender

8 Cont.. 2. Protocol Number Protocol number use the later version of network mapper (nmap) to scan a host for listening protocols. This is done using the –sO option. The target host is scanned for all 256 possibilities of protocols. Protocols are deemed listening when no Internet Control Message Protocol (ICMP) “protocol unreachable” message is returned.

9 Cont.. 2. Protocol Number There is a flaw in the logic use by nmap to discern listening protocols: Nmap assumes that the absence of an ICMP “protocol unreachable” message means that the protocol is listening. Yet, conditions such as the scanned site blocking outbound ICMP messages prevent the nmap scanner from getting these messages. Dropped packets, that might also cause the loss of packets and falsely influence nmap.

10 Cont.. 2. Protocol Number The author of nmap tried to mitigate the flaws by: Nmap sends duplicate packets for each protocol to deal with the problem of packet loss by using Differentiated Services Byte and The Don’t Fragment (DF) Flag. If nmap get no ICMP “protocol unreachable” message back, it doesn’t assume all protocols are listening. Instead, it wisely assumes that the traffic is being “filtered” and reports this.

11 Network Mapper (nmap) Protocol Number “Protocol Unreachable”
Receiver doesn’t support the protocol number Nmap scan a protocol number Network Mapper (nmap) Protocol Number “Protocol Unreachable” Sender Receiver Receiver send “protocol unreachable” message

12 Cont.. 3. IP Numbers IP numbers are 32-bit fields. The source IP number is located in the 12th through 15th bytes offset of the IP header; the destination IP number is located in the 16th through 19th bytes offset of the IP header. If users see an IP number entering their network that purports to be from their network, there is a misconfiguration problem with a host. Most likely, someone has crafted this packet and is spoofing an IP address in their range.

13 Cont.. 3. IP Numbers Users also should never see source IPs coming from the loopback address (identifies the local host), nor should not see any source IPs that fall in the Internet Assigned Numbers Authority (IANA) reserved private network numbers defined in RFC These address intended use is for local internal networks only. The method use to prevent these problems: A packet-filtering device should shun this traffic. Use decoy or spoofed source IP’s as a smokescreen. Users shouldn’t allow traffic with a broadcast destination IP address into or out of your network. Such destination addresses are typically used to quickly map other networks or use them as Smurf amplification sites.

14 Cont.. 4. IP Identification Number
The IP identification value is found in bytes 4 and 5 offset of the IP header. For each new datagram that a host sends, it must generate a unique IP ID number. This value is normally incremented by 1, although some use an increment of 256, for each new datagram sent by the host. The range for IP ID values is 1 through 65,535 because this is a 16- bit field. When the maximum value of 65,535 is reached, it should wrap around and start again.

15 Cont.. 4. IP Identification Number
If users see different “alleged” source IPs sending traffic to their network and that IPs appear to have a chronology of incrementing IP ID numbers, it is possible that the source IP are being spoofed. The –vv option of TCPdump can be used to display the IP ID number along with the time-to-live (TTL) value. Time-to-Live (TTL) - Number of hops/links which the packet may be routed over, decremented by most routers - used to prevent accidental routing loops IP Checksum

16 TCPdump Spoofed IP address
IP IDENTIFICATION NUMBER TCPdump display IP ID number with TTL value to receiver TCPdump Spoofed IP address Sender Receiver

17 Cont.. 4. IP Checksum Checksums are used to ensure that data has not gotten corrupted from source to destination. The IP checksum is found in the 10th and 11th bytes offset of the IP header. The algorithm used for TCP/IP is to divide the data that being checksummed into 16-bit fields. Each 16-bit field has a 1’s complement operation done on it and all of these 1’s complement values are added. The final value is considered to be the checksum.

18 Cont.. 4. IP Checksum The IP checksum is validated by each router through which it passes from source to destination and finally is validated by the destination host as well. Is the computed checksum does not agree with the one found in the datagram, the datagram is discarded silently. The IP checksum is examined and recomputed for each hop on the way from source to destination. Intermediate routers validate the IP checksum, and if it is correct, the TTL value is decremented by 1. The IP header checksum must be recomputed to reflect this change in the IP header.

19 The end


Download ppt "Examining IP Header Fields"

Similar presentations


Ads by Google