Also keep in mind the recent discovery of the trinoo and tfn ICMP attacks.
here's a brief excerpt from a sans bullitin and some links in there:
"Nearly fifty of you responded to last week's request for information on
the ICMP ECHO REPLY probes. The data helped illuminate a virulent new
strain of attack. This internet collaboration thing really works!
Thanks for your help.
Crackers use ICMP Echo Replies as probes and clandestine controls
because these parts of the protocol are also widely used for network
management tasks and thus are commonly not screened as much as other
services. The data supplied helped to uncover a pair of force-multiplier
attack tools that use this clandestine channel. They have names now:
trinoo and tfn (for Tribal Flood Network). Attackers first compromise
hundreds or thousands of unprotected systems using widely known
vulnerabilities that have not been patched on those systems. The attacker
then installs network traffic generator programs on each of those
machines. When the attacker identifies a site to close down, he/she tells
all of the hidden programs to attack at the same time, and uses
instructions hidden in ICMP Echo Reply to give the command. Since the
Echo Reply is often a critical tool of the network manager, defense
against these attacks is very difficult. See
http://www.sans.org/newlook/resources/flashadv.htm
for the SANS Flash Advisory (and sometimes other updates, too)."
Your probes may be totally unrelated, but the mbone has been poised for
years as a swift road of attack against multiple hosts, and it's only just
begun.
spiff
On Sun, 28 Nov 1999, Enno Rey wrote:
> Jasper Jans wrote:
>
> > After setting up a firewall i noticed a lot of traffic being rejected
> > comming from 224.0.0.1. This is so called multicast traffic.
> >
> > Nov 27 23:55:23 badaboom kernel: Packet log: input REJECT eth0 PROTO=2
> > xxx.xxx.xxx.xxx:65535 224.0.0.1:65535 L=28 S=0xC0 I=36214 F=0x0000 T=1
> > Nov 27 23:55:33 badaboom kernel: Packet log: input REJECT eth0 PROTO=17
> > xxx.xxx.xxx.xxx:1484 224.0.0.1:4242 L=57 S=0x00 I=2340 F=0x0000 T=1
> > Nov 27 23:56:09 badaboom kernel: Packet log: input REJECT eth0 PROTO=17
> > xxx.xxx.xxx.xxx:1483 224.0.0.1:4242 L=57 S=0x00 I=2498 F=0x0000 T=1
> > Nov 27 23:56:10 badaboom kernel: Packet log: input REJECT eth0 PROTO=17
> > xxx.xxx.xxx.xxx:1482 224.0.0.1:4242 L=57 S=0x00 I=2507 F=0x0000 T=1
> > Nov 27 23:56:12 badaboom kernel: Packet log: input REJECT eth0 PROTO=17
> > xxx.xxx.xxx.xxx:1481 224.0.0.1:4242 L=57 S=0x00 I=2525 F=0x0000 T=1
> > Nov 27 23:56:23 badaboom kernel: Packet log: input REJECT eth0 PROTO=2
> > xxx.xxx.xxx.xxx:65535 224.0.0.1:65535 L=28 S=0xC0 I=36241 F=0x0000 T=1
> >
> > [jjans]$ nslookup 224.0.0.1
> > Name: ALL-SYSTEMS.MCAST.NET
> > Address: 224.0.0.1
> >
> > Is it a good idea to block this traffic, or should it be allowed thru the
> > firewall?
> >
>
> Multicasts to ALL-SYSTEMS multicast address (224.0.0.1) are used by ICMP
> router discovery [RFC 1256]. I don't like the idea of passing this traffic
> through a firewall and I don't know any case where this is necessary.
> Most often multicast traffic is generated for special purposes (e.g. by
> routing protocols), in most cases there's information contained you probably
> don't want to pass the fw.
> So block it.
>
> HTH,
>
> Enno
>
> [EMAIL PROTECTED]
> PGP: FB9B DA6D 6706 5A8D A361 F63C 6650 E4C8 3BBE 04E9
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
