On Tue, 6 Mar 2007, Mikael Abrahamsson wrote:
Customer gets hacked, one of their boxen starts spewing traffic with spoofed
addresses. The way I understand your solution is to automatically shut their
port and disrupt all their traffic, and have them call customer support to
get any further.
Disabling their port and punting them to customer support is
NOT a cost
efficient way of dealing with the problems, at least not in
the market I
am in.
It's like the car rental business. If you want to provide cars to people
without a drivers license, then your customer support people
On Tue, 6 Mar 2007, Mikael Abrahamsson wrote:
Also, all the examples you give implies a BGP transit customer. I am
imagining all kinds of customers, from colo customers where I am their
default gateway, to residential customers where it's the same way.
I tried to give examples upstream of a
On Tue, 6 Mar 2007, Sean Donelan wrote:
Isn't this true of everything (bad source addresses, worms, abuse, etc).
Does hiding/ignoring the problem just makes it worse because there is no
incentive to fix the problem while it is still a small problem? If it
isn't important enough to bother the
On Tue, 06 Mar 2007 21:54:06 +0100, Mikael Abrahamsson said:
So instead I just drop their spoofed traffic and if they call and say that
their line is slow, I'll just say it's full and they can themselves track
down the offending machine and shut it off to solve the problem.
This doesn't
On Tue, 6 Mar 2007, [EMAIL PROTECTED] wrote:
On Tue, 06 Mar 2007 21:54:06 +0100, Mikael Abrahamsson said:
So instead I just drop their spoofed traffic and if they call and say that
their line is slow, I'll just say it's full and they can themselves track
down the offending machine and shut it
http://www.completewhois.com/hijacked/files/203.27.251.0.txt
http://www.completewhois.com/hijacked/index.htm
This can proof the opposite.
Malware comes from redirected allocated blocks, not from bogons.
I don't think this is proof. The haphazard way that BCP38 and ingress
prefix
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Chris L. Morrow
Sent: Thursday, March 01, 2007 6:23 AM
To: Jon Lewis
Cc: Eric Ortega; nanog@merit.edu
Subject: Where are static bogon filters appropriate? was:
96.2.0.0/16 Bogons
On Thu, 1
On Sun, 4 Mar 2007 07:46:12 -0800
Barry Greene (bgreene) [EMAIL PROTECTED] wrote:
To 'globally' monitor, we have
http://www.cymru.com/BGP/robbgp-bogon.html and
http://www.cymru.com/BGP/asnbogusrep.html and
http://www.cidr-report.org/ and http://www.routeviews.org/ and
On 3/2/07, Roland Dobbins [EMAIL PROTECTED] wrote:
No one has done the digging required to answer any of these
questions, unfortunately.
Can you get a valid answer to this based on the existence of BCP38?
What I mean is, if your upstream is filtering bogons, you can't get a
good read on the
On Sun, 4 Mar 2007, Mikael Abrahamsson wrote:
Instead of dropping packets with unallocated sources addresses, perhaps
backbones should shutdown interfaces they receive packets from unallocated
address space. Would this be more effective at both stopping the sources
of unallocated addresses;
On Thu, Mar 01, 2007 at 07:16:37AM -0800, Peter Thoenen wrote:
[Thoenen seems to have clipped the attribution]
Perhaps,
bogon acls are helpful when they are configured on backbone, but not
everywhere.
And if ever major backbones (read tier 2/3) would do so all us little
guys
On Fri, 2 Mar 2007, Daniel Senie wrote:
How do you know, if you're the one being attacked and you have no idea if the
originating network or their immediate upstream implemented BCP38? Shall we
just discard ingress filtering? If few attacks are using it today, should we
declare it no longer
http://www.completewhois.com/hijacked/files/203.27.251.0.txt
http://www.completewhois.com/hijacked/index.htm
This can proof the opposite.
Malware comes from redirected allocated blocks, not from bogons.
Kind regards
Peter and Karin
Sean Donelan wrote:
On Fri, 2 Mar 2007, Daniel Senie
Well Steve, it's like this: There are (a) security experts,
(b) security
experts, and (c) guys that spend their day making things
usable in spite of
what the rest of the net throws in their AS's direction.
You're an example of
one, I'm an example of another, and the advocates of
On Mar 2, 2007, at 12:55 AM, [EMAIL PROTECTED] wrote:
One might argue that if a company is not capable of
setting a policy and managing that policy, then you
should not implement the policy at all.
I think this really goes to the heart of the matter - the inability/
unwillingness to
I think this really goes to the heart of the matter - the inability/
unwillingness to prioritize and allocate resources to properly
implement 'good neighbor' policies which are not perceived as having
any financial benefit to the organization.
So, can this sort of activity somehow be
Roland Dobbins [EMAIL PROTECTED] writes:
On Mar 1, 2007, at 1:10 PM, Chris L. Morrow wrote:
So... again, are bogon filters 'in the core' useful? (call 'core' some
network not yours)
Antispoofing is 'static' and therefore brittle in nature, people
change jobs, etc. - so, we shouldn't do
On Mar 2, 2007, at 4:12 AM, Robert E. Seastrom wrote:
uRPF isn't always adequate for all antispoofing cases, as you know.
What about iACLs?
bogon
filtering by end sites is the sort of thing that is recommended by
experts for whom security is an end in and of itself, rather than
a
On Fri, 02 Mar 2007 08:55:42 GMT, [EMAIL PROTECTED] said:
one, I'm an example of another, and the advocates of static bogon filters
are
important word alert -- ^^
policy and management of that policy. Bogon filters are
an example of a policy
No, the SP can't be the 'Internet
firewall' for customers,
They can if the SP supplies and manages the CPE device. Nowadays, a lot
of functionality could potentially be provided in a CPE device. Hardware
cost and hardware capabilities are no longer barriers to doing this.
There is still
On Mar 2, 2007, at 7:31 AM, [EMAIL PROTECTED] wrote:
Sometimes, network operators have to take the bull
by the horns and develop their own systems to do a job that vendors
simply don't understand.
Concur - but it seems that many seem to be looking for someone else
to do this for them (or,
On Fri, 2 Mar 2007, Roland Dobbins wrote:
Sometimes, network operators have to take the bull
by the horns and develop their own systems to do a job that vendors
simply don't understand.
Concur - but it seems that many seem to be looking for someone else to do
this for them (or, perhaps, the
Cc: NANOG
Subject: Re: Where are static bogon filters appropriate? was: 96.2.0.0/16
Bogons
On Fri, 2 Mar 2007, Roland Dobbins wrote:
Sometimes, network operators have to take the bull
by the horns and develop their own systems to do a job that vendors
simply don't understand.
Concur
On Fri, 2 Mar 2007 15:37:01 -0600
Eric Ortega [EMAIL PROTECTED] wrote:
I think Sean raises a good point. I guess the larger picture is what
are we trying to protect and what are trying to protect that from.
Bingo.
The problem isn't with security people, it's with security people
who use
--- [EMAIL PROTECTED] wrote:--
I think this really goes to the heart of the matter - the inability/
unwillingness to prioritize and allocate resources to properly
implement 'good neighbor' policies which are not perceived as having
any financial benefit to the
On Mar 2, 2007, at 1:18 PM, Sean Donelan wrote:
How much of a problem is traffic from unallocated addresses?
Backbone operators probably have NetFlow data which they could mine
to find out.
On the other hand, how much of a problem is obsolete bogon filters
causing
everytime IANA
Speaking of bogons and more practical daily operation issues, perhaps
you guys can help reaching the fine folks at AS7643 or maybe their
upstream provider can be kind enough to filter out the following:
BGP routing table entry for 123.0.0.0/8, version 14613827
Paths: (1 available, best #1, not
On Thu, 1 Mar 2007, Jon Lewis wrote:
On Wed, 28 Feb 2007, Eric Ortega wrote:
I'd like to thank the group for the responses and help with this issue. I
find it ironic that Randy's study actually uses 96 space.
The amazing/sad thing is that people have been facing and fixing the same
On Thu, 1 Mar 2007, Chris L. Morrow wrote:
So, where are static bogon filters appropriate? (loaded question perhaps)
I ask because just about every 'security expert' and 'security whitepaper'
or 'security suggestions' has some portion that speaks to why it's a
grand idea to have
On Mar 1, 2007, at 6:22 AM, Chris L. Morrow wrote:
So, where are static bogon filters appropriate?
#define static
Obviously, one's bogon filters (both for iACLs and for prefix-lists
or whatever other mechanism one uses to filter the route
announcements one accepts) must be dynamic
Jon Lewis wrote:
On Thu, 1 Mar 2007, Chris L. Morrow wrote:
So, where are static bogon filters appropriate? (loaded question
perhaps)
I ask because just about every 'security expert' and 'security
whitepaper'
or 'security suggestions' has some portion that speaks to why it's a
grand idea
Perhaps,
bogon acls are helpful when they are configured on backbone, but not
everywhere.
And if ever major backbones (read tier 2/3) would do so all us little
guys wouldn't have to (yet for some reason I keep getting the odd hit
in my acl logs from bogon space daily).
Yes I know they
On Thu, 1 Mar 2007, Jon Lewis wrote:
On Thu, 1 Mar 2007, Chris L. Morrow wrote:
So, where are static bogon filters appropriate? (loaded question perhaps)
I ask because just about every 'security expert' and 'security whitepaper'
or 'security suggestions' has some portion that speaks to
On Thu, 1 Mar 2007, Roland Dobbins wrote:
On Mar 1, 2007, at 6:22 AM, Chris L. Morrow wrote:
So, where are static bogon filters appropriate?
#define static
Obviously, one's bogon filters (both for iACLs and for prefix-lists
or whatever other mechanism one uses to filter the route
On Thu, 1 Mar 2007, Chris L. Morrow wrote:
ah-ha! but seriously, is this something an NSP/ISP should be doing? or is
this an enterprise function? or MSSP function? Are there standard tools
available to notify folks when changes occur? (aside from: go check
iana.org website or golly traffic's
Hey, Chris.
ah-ha! but seriously, is this something an NSP/ISP should be doing?
or is
this an enterprise function? or MSSP function? Are there standard
tools
available to notify folks when changes occur? (aside from: go check
iana.org website or golly traffic's not flowing anymore)
We
On Thu, 1 Mar 2007, Jon Lewis wrote:
Such updates get posted to various places like nanog, cisco-nsp, probably
other -nsp lists, and such...but for the large number of ASNs not
represented at all on those lists, I don't know how they're supposed to
get notified every time a bogon ceases to
On Thu, 1 Mar 2007, Chris L. Morrow wrote:
The challenge for folks on the far side of this problem
(69box.atlantech.net for instance or midco) is finding a way to get this
adjusted.
69box.atlantic.net
So... again, are bogon filters 'in the core' useful? (call 'core' some
network not yours)
On Thu, 1 Mar 2007, Chris L. Morrow wrote:
So... again, are bogon filters 'in the core' useful? (call 'core' some
network not yours) The cisco auto-secure feature sure showed some fun
effects for this too, eh?
We managed to fix that mis-application in later releases, but it has
human
On Mar 1, 2007, at 11:33 AM, Chris L. Morrow wrote:
I absolutely agree, but without some tool or process to follow...
we get
stuck acls/filters and no idea that there is a problem until it's
far into
the problem :(
There are canonical email lists on which these changes are announced,
On Mar 1, 2007, at 1:10 PM, Chris L. Morrow wrote:
So... again, are bogon filters 'in the core' useful? (call 'core' some
network not yours)
Antispoofing is 'static' and therefore brittle in nature, people
change jobs, etc. - so, we shouldn't do antispoofing, either?
Enterprises
On Thu, 01 Mar 2007 14:22:37 + (GMT)
Chris L. Morrow [EMAIL PROTECTED] wrote:
On Thu, 1 Mar 2007, Jon Lewis wrote:
On Wed, 28 Feb 2007, Eric Ortega wrote:
I'd like to thank the group for the responses and help with this
issue. I find it ironic that Randy's study actually uses
On Thu, 01 Mar 2007 21:08:59 EST, Steven M. Bellovin said:
On Thu, 01 Mar 2007 14:22:37 + (GMT) Chris L. Morrow [EMAIL
PROTECTED] wrote:
So, where are static bogon filters appropriate? (loaded question
perhaps) I ask because just about every 'security expert' and
'security whitepaper'
On Thu, Mar 01, 2007, Roland Dobbins wrote:
On Mar 1, 2007, at 1:10 PM, Chris L. Morrow wrote:
So... again, are bogon filters 'in the core' useful? (call 'core' some
network not yours)
Antispoofing is 'static' and therefore brittle in nature, people
change jobs, etc. - so, we
45 matches
Mail list logo
