Re: local address spoofing

[Chris Watt <cnww chebucto ns ca>]

At 18:32 29/07/00 +0200, Leonard den Ottolander wrote:

>Jul 20 03:30:24 joy kernel: Packet log: input DENY eth1 PROTO=17 
>192.168.0.1:68 255.255.255.255:67 L=328 S=0x00 I=2108 F=0x0000 T=128 (#3) 

Sounds like you have got a very tight firewall if you block BOOTP/DHCP
traffic by default. Provided that you're not using DHCP to get your own IP
address this is probably a Good Thing(tm).

> There are litteraly hundreds of these entries. So somebody is spoofing him 
>with a local address, and trying something with bootp

Since this is a universal broadcast packet (sent to 255.255.255.255)
attempting to talk to port 67 (the BOOTP/DHCP server port if memory serves)
one could assume that some fool on your network has a machine that think's
its old IP address is 192.168.0.1 and is trying to renew its lease. Another
possibility of course is that your ISP may be scanning for client machines
willing to assign leases on that subnet (a sure sign that a machine is
doing (badly implemented) connection sharing. Many ISPs disapprove of this
sort of thing).

>I changed the local address, to be able to set a route over eth1 to network 
>192.168.0.0, using 200.201.202.203 as the gateway.

Unless I misunderstand what you're doing this sounds like a _VERY_ odd
thing to do. 192.168.0.0 should properly be entirely ignored by your
external interface unless your ISP is actually using it for something you
need to communicate with. Some ISPs may run their internal only servers
(DHCP, DNS, etc.) on a reserved subnet to save "real" address space and to
make them more difficult to crack. I know a major ISP in my town has nearly
all its machines in the 10.0.*.* range, but it is IMHO generally bad
practice (obviously they disagree). 

> I can then ping 
>192.168.0.1, but get no answer.

If ipchains is denying packets from this host then the ping program cannot
get an answer, the host may be responding but the packet would just be
dumped and logged. If you're curious you might try flushing all your
ipchains rules and then pinging that host.

>1) Am I correct in assuming that this spoof can only come from the ISP's 
>network? If not, how does one route such requests?

This is not necessarily a spoof. ISP's commonly use reserved IP address
ranges (my own ISP uses the 192.168.0.0/24 subnet for some of its
hardware), also the Internet contains a (very) large number of badly
configured routers which will blithely route packets on reserved subnets,
it may be that your ISP is using one of these (a traceroute would probably
tell you whether the host is outside the jurisdiction of your ISP). In
general you should be fine provided you do not allow any packets to
reserved subnets to be routed through your "external" NIC and you do not
accept any such packets on that NIC. 

>2) Does anyone have suggestions on how to counter such spoofs? Pointers to 
>relevant websites are appreciated, and personal experiences are also welcome.

One well-documented way to prevent actual IP spoofing is to turn on source
address verification:

# This should be executed at boot time as part of your firewall setup.
# This is the best method: turn on Source Address Verification and get
# spoof protection on all current and future interfaces.
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then
  echo -n "Setting up IP spoofing protection..."
  for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
      echo 1 > $f
  done
  echo "done."
else
  echo PROBLEMS SETTING UP IP SPOOFING PROTECTION.  BE WORRIED.
  echo "CONTROL-D will exit from this shell and continue system startup."
  echo
  # Start a single user shell on the console
  /sbin/sulogin $CONSOLE
fi

However it does not really sound like you are experiencing IP spoofing. It
sounds like you're just sharing a network with a machine that really thinks
it's 192.168.0.1, and if your ISP is routing traffic from that address I
would expect it implies that either 1: your ISP has a bad router
configuration or 2: your ISP has a good reason to want this address routed
(i.e. they're using it).
--

Q:      What's tiny and yellow and very, very, dangerous?
A:      A canary with the super-user password.