From: spiekey [mailto:spiekey@hotmail.com] Sent: Tuesday, October 30, 2001 2:37 PM To: suse-security@suse.com Subject: [suse-security] how to detect spoofing hosts Hello! Let´s say i have a big LAN, with a few gateways and a firewall. As bigger your networks get´s the more you will be conflicted with pepole who want to "explore" your LAN. Thats why i was wondering how you can detect spoofing hosts. And why can spoofing be so dangerous, i couldn´t think of an good example. Thank you! Spiekey try using arpwatch. It will detect IP-Spoofing if the attacker is unable to spoof his MAC.

On Tue, 30 Oct 2001, spiekey wrote:

Hello! Let�s say i have a big LAN, with a few gateways and a firewall. As bigger your networks get�s the more you will be conflicted with pepole who want to "explore" your LAN. Thats why i was wondering how you can detect spoofing hosts. And why can spoofing be so dangerous, i couldn�t think of an good example.

Quick answer: you can detect spoofing hosts if they pretend to be an IP address that you run. You get logs on one machine saying it got a request from a particular IP address; but on the machine that has that IP address, it doesn't say the request was sent. Also, if a packet headed for another machine goes by the same ethernet segment that the machine whose IP address it's using is on, then the machine whose IP address the spoofer is pretending to have will log the event. Spoofing is dangerous because most networks allow extra priveleges to machines in some ranges of IP addresses (the "local network", or "network peers") or huge priveleges to particular machines (servers, controllers, etc). Spoofing is therefore a way for crackers to get the priveleges of those machines. Bear

Yup, On 30-Oct-01 spiekey wrote:

Hello! Let�s say i have a big LAN, with a few gateways and a firewall. As bigger your networks get�s the more you will be conflicted with pepole who want to "explore" your LAN.

That's right. Spoofing also takes places from the inside to the outside world, so it's equally important to train your boarder routers/firewalls to drop any packet pretending to originate from an other network than the one you're in. A simple anti-spoofing technique would include a couple of filtering rules on the router which drop any packets coming in on the world-dev of the router, but pretending to originate from the internal LAN.

Thats why i was wondering how you can detect spoofing hosts. And why can spoofing be so dangerous, i couldn�t think of an good example.

If you suspect a TCP connection to be spoofed, one way of verifying it would be to measure/calculate the real TTL between you and the suspicious IP. The attacker normally sits on an other part of the internet, so it's likely that his/her spoofing alters the original TTL of the packets and thus might give you a clue that something is wrong. However, it's very important that this TTL measurement/calculation is done immediately, before any routes may change; as this is most likely, and even the most determined admin at least needs a couple of hours of nights' rest, the TTL method is not useable for forensics/post-mortem analysis of cracked hosts. You cold use tcpdump or snort together with a script to log the TTLs and do some measurements, but there's also a tool called despoof, written by Simple Nomad/Razor, which does just that. Get it from http://razor.bindview.com/tools/index.shtml . Furthermore, spoofing detection for internal LANs may be done by MAC address logging/examining; it's always suspicious if a certain IP first comes from MAC a, but ten minutes later from MAC b, and so on, specially if there's no DHCP.

And why can spoofing be so dangerous, i couldn�t think of an good example.

Spoofing, done correctly, is indeed very dangerous. For example, if you use a packet filter firewall (ipchains) and some faulty tcp DNS rules (e. g. for zone transfers) where a certain IP of a nameserver (say from your provider) has unlimited access to your system (I have many examples of this in my book), an attacker could abuse this trust-relationship to impersonate the host you trust in, which would render any firewall and IDS useless. Imagine four hosts on the internet, A, B, C and D. A would be the target, B the host the target trusts in, C an unreachable host, and D would be the attacker. Now, the attacker has to make sure that the trusted host (B) is not reachable by the target (A) anymore. For this, (s)he could use some sort of SYN flooding to make sure the real trusted host B does not tap into the spoofed communication between the attacker and the target. As a return-address, the attacker uses the one of host C (an unreachable host, prolly a ntp server or any other existing IP which does not respond, e. g. to icmp packets). B now desperately tries to contact C, but since C does not respond (and B has a lot of half-assed SYNs in its backlog), B's requests take their time while the attack continues... After D (the attacker) has successfully SYN flooded B (the trusted host), D connects to A (e. g. on the smtp port (25)) and writes down the initial sequence number (ISN) of the packets coming back from A. Every packet has its own sequence number, which is the core of the connection-oriented TCP protocol, as TCP guarantees that any packet will reach its destination, and will not arrive twice. The trick of the spoofing attack is to find out the current/next TCP sequence number of the packets destined for host A. Which can difficult, since A might server other clients in the meantime, which again alters the sequence numbers. Now D sends packets to certain ports (with "certain" requests...) to A, with the IP of B (the trusted host). If the sequence number of the packet A has sent was right and B is still unable to answer due to the aforementioned SYN flood, A would believe that D really is B, and would proceed with the normal three-way handshake... [...] voila, another one bites the dust... This (simplified) example of IP spoofing shows that it's highly dangerous to set up a trust relationship between hosts on the internet, if the only means of authorization between these hosts would be their IP address (rlogin, rsh, any "r" command, but also (improperly configured) sshd...etc...). A little bit of trust relationship may lead to a complete compromise of a host, even if this particular host has been put behind a firewall or generally is rated as "safe".

Thank you!

Spiekey

Boris Lorenz <bolo@lupa.de> ---