I have been told that a major network experienced a Flood DoS on New Years Eve in the Northeast - "We received a massive attack early this morning with signatures matching what your papers described." In the Southeast my cable-modem network was out on 1/1/00 when I checked at 2:00 a.m. and then came back up about 7:00 p.m.
Update 1/3/00: The Northeast attack was by 1500-byte UDP packets from two UNIX boxes on a U. California campus (not a Mac DoS Attack). If there was a Mac attack planned for New Years Eve, it may have been preempted by other attacks on the high-speed cable-modem networks. In any case, the danger of such an attack is still present until most users of Apple's Mac OS9 and some users of OS8.6 (with OT 2.5.1 and 2.5.2) install the OT 2.6 upgrade.
Reflection Attack
Even without byte-amplification, reflecting flood packets off a number of different hosts can be used to hide the identity of an attacker - JAC
Date: Thu, 6 Jan 2000 11:45:59 -0500
FYI...we filed a Fed CIRC and have been in touch with CERT
concerning
suspicious activity...a number of trace route events caught by
RealSecure.
However, after placing the sniffer outside the IDS and firewall,
we noticed
the source address was spoofed and the TTL was expired. This
would generate
a response back from us to the target specified in the destination.
The
number of these packets is running in the low thousands, not enough
to deny
services but enough to raise our curiosity.
CERT contacted us a few moments ago and indicated an increase
in this type
of activity. At this point they are not sure what is going on
as the
packets are widely distributed and don't appear to have the intensity
to
flood a network. You may see some of the same and I suggest you
report that
activity as some pattern may develop.
>> One of my programmers (with VERY limited Linux knowledge)
will be
>> contacting you shortly (if has not already done so) with
the IPs we
>> see as part of the hacks.
>>
>> The "appropriated IP" issue is very confusing.
Here is something of a
>> chronology:
>>
>> 1) G4 is booted and displays error msg "That IP
is already in use
>> by... [hardware address for Linux box #1].
>> 2) Owner of G4 enters a new (previously unassigned) static
IP address
>> but again gets message... "That IP is already in
use by... [hardware
>> address for Linux box #1]
>> 3) Owner of G4 enters yet another (known to be unassigned)
static IP
>> address but again gets message... "That IP is already
in use by...
>> [hardware address for Linux box #1]
>> 4) Linux box #1 is identified (by MAC # displayed on
G4) and is
>> immediately shut down. (It's log clearly shows signs
of hacking.)
>> 5) G4 is booted successfully.
>> 6) G4 is immediately re-booted and displays error msg
"That IP is
>> already in use by... [hardware address for Linux box
#2].
>> 7) Linux box #2 is identified as new culprit (using MAC
# displayed
>> in error message shown on G4) and is immediately shut
down.
>> 8) G4 boots normally and has full network services.
>>
>> Does this make sense to you?
==============
The Mac OpenTransport software (OT) has a nice feature which prevents IP address conflicts. Before assigning a new TCP/IP address to a port, it sends out an Ethernet ARP (Address Resolution Protocol Message) "Who has <new IP>?" If another host X is using that address, it replies with an ARP message "<host X Ethernet address> has <new IP>." In this case the Mac reports in a dialog box to the user "IP <new IP> already in use by <host X Ethernet address>" and will not use the new IP address.
In your case, the compromised Linux host is replying to all ARP messages that it has (is using) whatever IP address is requested. It could even give a false Ethernet address in the reply to make it harder to find the culprit. This will paralyze your network until the compromised Linux host is shut down.
It looks like your Macintosh G4's are working normally. I recommend contacting CERT for instructions on how to recover the Linux boxes. They may want a file dump so that they can examine the hacker code.
The OT Upgrade to version 2.6 is available, and does not have the problems the OT Tuner had. The link to it is on http://www.csc.gatech.edu/macattack.
John Copeland