By providing the 4tuple ip/port dst/src it makes guessing easier. As for
production vs non-production I suspect we have a mix I did not even
begin to audit them. I few spot checks is all I had time for. I would
welcome any assistence in auditing vulnerable looking glass/route
servers and would per
Hmm. Interesting.
I am (here is SFO area) DSL customer and DialUp customer. But I never
received a notification from my provider(s), possible with free CD,
explaining me (if I am a homewife, not an engineer, of course) what to do
and how to prevent a problems. We have a lot of room for improvemen
>
> In the US, the Security Update CD is shipped directly from the Microsoft
> contractor to the end-user. Of course, if the postal service, delivery
> service or contractor is corrupt; what you receive could be intercepted
> and replaced enroute.
You do not need to kill a postman -:). Just write
It depends... if you use FreeBSD with port system, for example - it is safe
enough (esp. if make a pause between 'make' and 'make install' in a few days
or a week. and read mail lists about possible problems).
> dowloading opensource software is safe? -CP
If you ever read SNMP specs, you can realize, that there is not any C or C++
SNMP implementation without such problem. So, rule number 1 is _never
expose SNMP to Internet, and be careful to filter out any inbound packets,
forwarded to your SNMP ports.
It is easy to predict next SNMP problem in n
On Wed, 21 Apr 2004, Michel Py wrote:
> > Aditya wrote
> > I sure hope there are no asymmetric paths on the Internet
> > that will bite you when you turn on strict RPF on your
> > peering interfaces
> > Seriously, if you do turn RPF on on peering interfaces,
> > please let your peers know (plea f
On Wed, Apr 21, 2004 at 04:21:51PM -0700, Lane Patterson <[EMAIL PROTECTED]> wrote:
> While I agree that publicly open route-views routers should not allow
> display of "sho ip bgp nei" information, this is only giving away 4-tuple
> info regarding non-production BGP sessions, right? So folks co
JK> Date: Wed, 21 Apr 2004 20:51:23 -0500
JK> From: John Kristoff
JK> I would say the risk is due to implementation. If the
JK> vendor's gear vomits quicker due to a resource consumption
JK> issue in handling MD5, is this really a problem with MD5?
Theoretically MD5 and IPSec sound great. Ope
On Wed, 21 Apr 2004 21:00:55 +0100 (IST)
Paul Jakma <[EMAIL PROTECTED]> wrote:
> risk of crypto DoS than compared to the simple BGP TCP MD5 hack. The
> risk is due to MD5, not IPSec :).
I would say the risk is due to implementation. If the vendor's gear
vomits quicker due to a resource consump
ARIN and NANOG are very pleased to announce our third joint meeting, to be
held this fall in Reston, VA. NANOG meets Mon.-Wed., Oct. 17-19, and ARIN
Wed.-Fri., Oct. 20-22. Plan to join us - it's a great opportunity to
help determine IP allocation policy for U.S. networks. ARIN is truly a
'ground
--On Wednesday, April 21, 2004 3:55 PM -0700 Henry Linneweh
<[EMAIL PROTECTED]> wrote:
http://www.internetnews.com/infra/article.php/3343561
For people still in a panic
Does anybody have a tinfoil hat I can borrow so that I may join in the
festivities?
-J
--
Jeff Workman | [EMAIL PROTECTED]
Lane Patterson wrote:
> While I agree that publicly open route-views routers should not allow
> display of "sho ip bgp nei" information, this is only giving away 4-tuple
> info regarding non-production BGP sessions, right? So folks could
> potentially flap the route-views sessions, but this will
Paul Jakma wrote:
> On Wed, 21 Apr 2004, Iljitsch van Beijnum wrote:
>
> > On 21-apr-04, at 21:17, Paul Jakma wrote:
> >
> > > > I'm not recommending this for "small" peers as the crypto DoS risk
> > > > is worse than what happens when the attack is executed
> > > > successfully.
> >
> > > Why wo
Although "show ip bgp nei" command is by far the easiest way to
get the BGP peer information and should not be enabled on any production
BGP peering routers that allow non-trusted or public connectivity it is
not the only way to get the information; anyone who does not do inbound
SNMP filt
While I agree that publicly open route-views routers should not allow display of "sho
ip bgp nei" information, this is only giving away 4-tuple info regarding
non-production BGP sessions, right? So folks could potentially flap the route-views
sessions, but this will not affect any production r
On Tue, 20 Apr 2004, John Brown (CV) wrote:
> On the other hand, SPRINT was willing and able to take MD5
> session info right away. WAY TO GO SPRINT.
Just to add my $0.02, I had very quick responses from HE.net; they called
me about 5 minutes after I emailed noc@ and we both recorded then ent
On 21-apr-04, at 21:18, Todd Vierling wrote:
[*] I must admit one thing, for instance: This "Advisory" was a
problem
for NetBSD, but not because its port allocation scheme was crappy. It
so
happened that NetBSD wasn't properly validating the sequence number to
be
within the window. "Oops."
Y
http://www.internetnews.com/infra/article.php/3343561
For people still in a panic
-Henry
On Wed, 21 Apr 2004, Iljitsch van Beijnum wrote:
> On 21-apr-04, at 21:17, Paul Jakma wrote:
>
> > > I'm not recommending this for "small" peers as the crypto DoS risk
> > > is worse than what happens when the attack is executed
> > > successfully.
>
> > Why would MD5 be more of a crypto DoS ri
On 21-apr-04, at 21:17, Paul Jakma wrote:
I'm not recommending this for "small" peers as the crypto DoS risk
is worse than what happens when the attack is executed
successfully.
Why would MD5 be more of a crypto DoS risk with IPSec AH headers than
with bgp tcp-md5?
Beats me. But why do you bring
On Apr 21, 2004, at 3:14 PM, Paul Jakma wrote:
On Tue, 20 Apr 2004, Patrick W.Gilmore wrote:
try not to include text after your sig. some people set their mailers
to strip sigs from replies.
Wasn't that important.
[...]
Which is only 28 hours at 10kpps:
1042284544/(10*1000)/3600 = 28.95234
b
On Wed, 21 Apr 2004, Pete Kruckenberg wrote:
: Interesting that Cisco uses random port selection with
: SNMP (http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml,
: see the Detail selection) but not with TCP.
:
: Too bad that TCP ports aren't randomized even with the
: "fixed" IOS v
On Wed, 21 Apr 2004, Iljitsch van Beijnum wrote:
> I'm not recommending this for "small" peers as the crypto DoS risk
> is worse than what happens when the attack is executed
> successfully.
Why would MD5 be more of a crypto DoS risk with IPSec AH headers than
with bgp tcp-md5?
regards,
--
Pau
On Tue, 20 Apr 2004, Patrick W.Gilmore wrote:
> (Someone check my math. :)
try not to include text after your sig. some people set their mailers
to strip sigs from replies.
> Sequence numbers are 32 bits. Since the miscreant only needs to
> guess once every 14 bits, you get:
> 2^32 / 2^14 =
On Wed, 21 Apr 2004 [EMAIL PROTECTED] wrote:
> On Mon, Apr 19, 2004 at 04:33:49PM -0400, Paul Khavkine wrote:
> > Anyone doing ad blocking with Squid cache engine out there ?
> This is what I've been using with Squid:
> http://adzapper.sourceforge.net/
Adzapper works very well, and is highly
>> James wrote:
>> now the question is... would this also affect single-hop
>> bgp sessions? my understanding would be no, as single-hops
>> require ttl set to 1.
> Simon Lockhart wrote:
> All it requires is for the TTL to be 1 (or 0, I can't
> remember which) when it's received. Just launch you
> Aditya wrote
> I sure hope there are no asymmetric paths on the Internet
> that will bite you when you turn on strict RPF on your
> peering interfaces
> Seriously, if you do turn RPF on on peering interfaces,
> please let your peers know (plea from circa 1999)
Ah, I was waiting for someone to
On Tue Apr 20, 2004 at 02:54:16PM -0400, James wrote:
> now the question is... would this also affect single-hop bgp sessions?
> my understanding would be no, as single-hops require ttl set to 1.
All it requires is for the TTL to be 1 (or 0, I can't remember which)
when it's received. Just launch
E.B. Dreger wrote:
PG> Date: Wed, 21 Apr 2004 07:45:36 +0100
PG> From: Peter Galbavy
PG> E.B. Dreger wrote:
PG> > I don't think we're even that far along. If I'm reading FreeBSD
PG> > 4.9 and NetBSD 1.6.2 source correctly,
PG> >
PG> > /usr/src/sys/netinet/in_pcb.c
PG>
PG> Should have stretched as
Doug White writes:
> It would be nearly impossible for computer software makers to provide
> against any type of attack by those so inclined. The result is that
> they are reactive rather than pro-active.
That's not the point. The difference in degree of security between
Windows and Mac OS X is
Interesting that Cisco uses random port selection with
SNMP (http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml,
see the Detail selection) but not with TCP.
Too bad that TCP ports aren't randomized even with the
"fixed" IOS versions. Would seem that as long as you're
implementing
On Wed, 21 Apr 2004, Robert E. Seastrom wrote:
>
> "Christopher L. Morrow" <[EMAIL PROTECTED]> writes:
>
> > there is the issue of changing the keys during operations without
> > impacting the network, eh? Having to bounce every bgp session in your
> > network can be pretty darned painful... if y
> On Wed, 21 Apr 2004 07:35:27 -0700, "Michel Py" <[EMAIL PROTECTED]> said:
> Insist that the peer uses "ip verify unicast reverse-path" on all
> interfaces, or similar command for other vendors.
I sure hope there are no asymmetric paths on the Internet that will
bite you when you turn on strict
IvB> Date: Wed, 21 Apr 2004 15:09:15 +0200
IvB> From: Iljitsch van Beijnum
IvB> [T]he filters I listed in my earlier message simply filter
IvB> RSTs to/from the BGP port without looking at the address
IvB> fields [...] the BGP hold timer takes care of business here
IvB> anyway [...]
Interesting
> If you have a fully redundant internal BGP, and are running all
> 12.2S/12.3/12.2T, then you can rather safely do the internal BGP
> passwords without a customer notice, expecting no session drop but
> knowing if one did you'd have routes via a second BGP reflector
> anyway.
Just an FYI, w
> David Luyer wrote:
> 98 of the first 100 did not reset. Today,
> I did another 12 and only one failed.
Thanks for the feedback.
> If you have a fully redundant internal BGP, and are running
> all 12.2S/12.3/12.2T, then you can rather safely do the
> internal BGP passwords without a customer no
On Mon, Apr 19, 2004 at 04:33:49PM -0400, Paul Khavkine wrote:
> Anyone doing ad blocking with Squid cache engine out there ?
This is what I've been using with Squid:
http://adzapper.sourceforge.net/
--
Edward S. Marshall <[EMAIL PROTECTED]>
http://esm.logic.net/
Felix qui potuit rerum co
On Wed, 21 Apr 2004, David Luyer wrote:
: > You missed the "(assuming the attacker can accurately guess both
: > ports)" part.
: A significant number of BGP sessions will be with a source
: port of 11000, 11001 or 11002; BGP sessions are generally
: quite stable and Cisco routers start the sourc
"Christopher L. Morrow" <[EMAIL PROTECTED]> writes:
> there is the issue of changing the keys during operations without
> impacting the network, eh? Having to bounce every bgp session in your
> network can be pretty darned painful... if you change the key(s) of
> course. If you don't you might a
On Wed, Apr 21, 2004 at 11:11:57AM -0400, Patrick W.Gilmore wrote:
>
> On Apr 21, 2004, at 10:38 AM, Jared Mauch wrote:
>
> >On Wed, Apr 21, 2004 at 10:19:10AM -0400, Patrick W.Gilmore wrote:
> >>
> >>>Yes, it generates more work to update the database,
> >>>but OTOH it provides the LIII enginee
We do prefix-filter all our peers, both customer and transit. We also
use as-path filters. It does seem to help us avoid insertion of invalid
routes and other issues (especially since some people we peer with don't
do the same on their side).
As far as stability and process problems, we're too
All,
Xspedius (formerly e.spire/ACSI) is in the process of converting BGP
connections to MD5. We have already done so with both of our transit
providers and we're working on contacting customers that we do BGP with.
If anyone is a customer of Xspedius and wants to convert to MD5, please
email m
On 2004-04-21-10:35:27, Michel Py <[EMAIL PROTECTED]>
quoted me out of order as saying:
> > Which begs the question, what is one to do, shy of
> > moving (private) peering/transit/customer /31's and
> > /30's into non-routable IP space, which opens up an
> > entirely new can of worms?
>
> Insist
On Apr 21, 2004, at 10:38 AM, Jared Mauch wrote:
On Wed, Apr 21, 2004 at 10:19:10AM -0400, Patrick W.Gilmore wrote:
Yes, it generates more work to update the database,
but OTOH it provides the LIII engineer with a lot more to
troubleshoot
issues. Is it simply not worth the work at your scale?
Ex
> Patrick W.Gilmore wrote:
> And when that process involves customers calling to ask
> why they can't get to XXX web site (no pun intended -
> I'm sure no one would filter a pr0n site :), it is much
> more than "a bitch", it is a CLM/CEM.
But you're missing something fundamental here: for non-tie
On Wed, Apr 21, 2004 at 10:19:10AM -0400, Patrick W.Gilmore wrote:
>
> On Apr 21, 2004, at 3:56 AM, Michel Py wrote:
>
> >>Christopher L. Morrow wrote:
> >>For pure: "Don't blow me up with prefixes" just limit the
> >>maximum-prefix to some # over your expected peer's list.
> >
> >Please allow m
> Adam Rothschild wrote:
> Which begs the question, what is one to do, shy of
> moving (private) peering/transit/customer /31's and
> /30's into non-routable IP space, which opens up an
> entirely new can of worms?
Insist that the peer uses "ip verify unicast reverse-path" on all
interfaces, or s
On Apr 21, 2004, at 3:56 AM, Michel Py wrote:
Christopher L. Morrow wrote:
For pure: "Don't blow me up with prefixes" just limit the
maximum-prefix to some # over your expected peer's list.
Please allow me to try to make my point again: you store the expected
peer maximum-prefix somewhere in your
On 21-apr-04, at 15:21, Daniel Roesen wrote:
As you didn't specify where to apply these filters, I guessed on the
edges. I would have never thought that someone would really suggest
to deliberately break RST for valid BGP sessions.
Try me. :-) But don't forget the borders, those are more importa
On Wed, Apr 21, 2004 at 03:09:15PM +0200, Iljitsch van Beijnum wrote:
> >> The good part here is that filtering RSTs should still work.
>
> > It doesn't. The RST are then being sent by the authorized sender and
> > your edge anti-spoof filtering for RST doesn't help a single
> > millimeter.
>
>
On 21-apr-04, at 14:38, Daniel Roesen wrote:
So the attacker sends a spoofed SYN to router A, and router A sends an
RST to router B and router B terminates the BGP session.
Correct.
The good part here is that filtering RSTs should still work.
It doesn't. The RST are then being sent by the autho
On Wed, Apr 21, 2004 at 02:10:05PM +0200, Iljitsch van Beijnum wrote:
> > "The issue described in this advisory is the practicability of
> > resetting an established TCP connection by sending suitable TCP
> > packets with the RST (Reset) or SYN (Synchronise) flags set."
>
> And:
>
> "It is also
On Wed, 21 Apr 2004, Daniel Roesen wrote:
> > > > The general ignorance to the fact that SYN works as well is
> > > astonishing. :-)
> > What are you talking about?
> http://www.uniras.gov.uk/vuls/2004/236929/index.htm
> First paragraph of the summary:
> "The issue described in this advisory
PS> Date: Wed, 21 Apr 2004 14:23:38 +0300 (EEST)
PS> From: Pekka Savola
PS> > But that doesn't push the short-term cost onto other networks.
PS>
PS> Not sure what you're saying. You don't need to deploy
PS> anti-spoofing filters everywhere. It needs to be done by
I was being sarcastic wrt net
On Wed, Apr 21, 2004 at 01:23:54PM +0200, Iljitsch van Beijnum wrote:
>
> On Wed, 21 Apr 2004, Daniel Roesen wrote:
>
> > > access-list 123 deny tcp any any eq bgp rst log-input
> > > access-list 123 deny tcp any eq bgp any rst log-input
>
> > > Unfortunately, not all vendors are able to lo
On Wed, 21 Apr 2004, E.B. Dreger wrote:
> DH> Date: Wed, 21 Apr 2004 02:01:56 -0700 (PDT)
> DH> From: Dan Hollis
>
> DH> Wouldnt anti-spoofing filters largely eliminate the need for
> DH> all this panic about MD5?
>
> But that doesn't push the short-term cost onto other networks.
Not sure what
On Wed, 21 Apr 2004, Daniel Roesen wrote:
> > access-list 123 deny tcp any any eq bgp rst log-input
> > access-list 123 deny tcp any eq bgp any rst log-input
> > Unfortunately, not all vendors are able to look at the RST bit when
> > filtering...
> The general ignorance to the fact that SYN
On Wed, Apr 21, 2004 at 01:00:07PM +0200, Iljitsch van Beijnum wrote:
> > All things considered, I think MD5 authentication will lower the bar
> > for attackers, not raise it. I'm sure code optimizations could fix
> > things to some degree, but that's just not the case today.
>
> > Which begs th
DH> Date: Wed, 21 Apr 2004 02:01:56 -0700 (PDT)
DH> From: Dan Hollis
DH> Wouldnt anti-spoofing filters largely eliminate the need for
DH> all this panic about MD5?
But that doesn't push the short-term cost onto other networks.
Eddy
--
EverQuick Internet - http://www.everquick.net/
A division
ASR> Date: Wed, 21 Apr 2004 06:44:14 -0400
ASR> From: Adam Rothschild
ASR> [T]he TTL hack sounds great on paper, but isn't exactly easy
ASR> to implement when you consider that vendor J and others
ASR> can't filter based upon TTL... yet.
This is more appropriate for cisco-nsp, where it's alread
On 21-apr-04, at 12:44, Adam Rothschild wrote:
All things considered, I think MD5 authentication will lower the bar
for attackers, not raise it. I'm sure code optimizations could fix
things to some degree, but that's just not the case today.
Which begs the question, what is one to do,
How about:
On 2004-04-20-23:09:31, David Luyer <[EMAIL PROTECTED]> wrote:
[...]
> Answering another poster's concern about DoS risk... TCP MD5 is not
> a significant DoS risk as you only MD5 once the source, destination,
> sequence, etc are valid - ie. you only MD5 a packet which would
> already have broken
> Wouldnt anti-spoofing filters largely eliminate the need for all this
> panic about MD5?
egress filtering, yes...
but not everyone does this and thats what poses the panic i guess :(
ingress filtering... largely yes, but no? consider the scenario:
someone runs traceroute to you (Joe ISP) do
http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml
This one seems much worse than the TCP RST problem.
--
Mikael Abrahamssonemail: [EMAIL PROTECTED]
On Tue, 20 Apr 2004, Rodney Joffe wrote:
> The only network engineer who may NOT have been aware of the building
> BGP vulnerability issue over the last week has to be the engineer who is
> currently on his annual vacation in Mauritius, and who refuses to take
> his Blackberry, Palm, or Satellite
It's not the general case, however...
Some looking glass CGIs (in some cases, into production routers)
permit "sh ip bgp nei " -- try typing "sum" and then "nei x.x.x.x"
into the "show ip bgp" box on a looking glass CGI, or using the
command on a route server with CLI access.
This gives you:
Lo
On 21-apr-04, at 9:56, Michel Py wrote:
For pure: "Don't blow me up with prefixes" just limit the
maximum-prefix to some # over your expected peer's list.
Please allow me to try to make my point again: you store the expected
peer maximum-prefix somewhere in your management system. I do
understan
Michael,
> > David Luyer wrote:
> > Have done around 100 of these in the past 24 hours. It's
> > not related to platform AFAIK - we've successfully done
> > the changes on a lowly 2651 and 3620 without outages, but
> > a 7200 with older IOS did have an outage.
>
> Given the context, I assume tha
Christopher / David,
> Christopher L. Morrow wrote:
> if you mean resetting sessions to change keys I believe
> it's more code dependent than anythingn else.
That was my point: I thought that changing keys without resetting the
session was tied to a specific version of the "S" train that I have
PG> Date: Wed, 21 Apr 2004 07:45:36 +0100
PG> From: Peter Galbavy
PG> E.B. Dreger wrote:
PG> > I don't think we're even that far along. If I'm reading FreeBSD
PG> > 4.9 and NetBSD 1.6.2 source correctly,
PG> >
PG> > /usr/src/sys/netinet/in_pcb.c
PG>
PG> Should have stretched as far as OpenBSD th
Michael Py wrote:
> Christopher / Patrick,
>
> > Christopher L. Morrow wrote:
> > I wasn't clear and for that I'm sorry. Except in the later
> > code trains, or until the recent past (1 year or so) changing
> > the BGP MD5 auth bits required the session to be reset.
>
> Then I'm the one sorry be
71 matches
Mail list logo
