From owner-freebsd-security Tue Nov 16 20:25:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from mta2.snfc21.pbi.net (mta2.snfc21.pbi.net [206.13.28.123]) by hub.freebsd.org (Postfix) with ESMTP id B2AA314F7B for ; Tue, 16 Nov 1999 20:25:09 -0800 (PST) (envelope-from madscientist@thegrid.net) Received: from remus ([63.193.246.169]) by mta2.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with SMTP id <0FLB001KSQU7PK@mta2.snfc21.pbi.net> for freebsd-security@freebsd.org; Tue, 16 Nov 1999 20:22:57 -0800 (PST) Date: Tue, 16 Nov 1999 20:20:46 -0800 From: The Mad Scientist Subject: Re: Tracing Spoofed Packets In-reply-to: <199911170408.UAA20089@gndrsh.dnsmgr.net> X-Sender: i289861@mail.thegrid.net To: freebsd-security@freebsd.org Message-id: <4.1.19991116201529.00962920@mail.thegrid.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-type: text/plain; charset="us-ascii" References: <4.1.19991116182120.0094d280@mail.thegrid.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 08:08 PM 11/16/99 -0800, you wrote: >> I doubt it, but is there ANY way to trace spoofed packets coming in from >> the Internet? I've been getting these packets showing up at my boarder >> router pretty regularly for the past few days now: > >First step is to complain to your peering ISP on this boarder router, >they should be dropping all RFC1918 src or dst addressed packets at >their boarder. They probably have an internal leak, or one of their >customers does. I'll give that a try. I'm just a Pac Bell dsl customer so I'm not expecting too much from them. >The only way of tracking these down is getting good cooperation from the >technical people you are connected to on this link and having them search >their boarders for the source, then instituting correct AS policy and >dropping these things like they already should be. > >Many people have long used a poor filter list for this, simply filtering >for dst only, current best practice is to filter on either src or dst >being in RFC1918 space (and a few others too, like unless you support >mcast peering with your adjacent AS's you should drop src or dst 224/12 >as well, and don't forget to filter 127/8, etc, etc... :-) All taken care of at the boarder. :-) Even filtering for dest only, this one should have been dropped (dest was 10.0.1.2).... I'm not running any routing protocols, so I have no idea how my isp's router got the idea that it should send me packets for 10.0.1.2. >> Nov 15 19:47:43 wormhole /kernel: icmp-response bandwidth limit 284/100 >> ppsNov 15 19:57:06 wormhole /kernel: ipfw: 400 Deny ICMP:3.13 10.1.6.6 >> 10.0.1.2 in >> via ed0 >> Nov 15 19:57:37 wormhole last message repeated 36 times >> Nov 15 19:59:38 wormhole last message repeated 175 times >> Nov 15 20:00:53 wormhole last message repeated 96 times >> >> This goes on for about two hours. The logs don't show anything else >> abnormal from what I can discern. I don't see any performance hit or >> bandwidth drop, so it doesn't really bother me. I'd just like to figure >> out what's going on. >> Thanks in advance, >> -Dean > > >-- >Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message