Re: FB?

On 14 Mar 2019, at 19:17, Mike Hammett wrote: > I saw one article quoting Roland saying it was a route leak, but I > haven't seen any other sources that aren't just quoting Roland. That was the result of a miscommunication; a clarification has been issued, FYI.

Re: Seeking Feedback on Mitigation of New BGP-driven Attack

On 11 May 2019, at 11:29, Job Snijders wrote: > The paper contained new information for me, if I hope I summarize it > correctly: by combining AS_PATH poisoning and botnets, the botnet’s > firing power can be more precisely aimed at a specific target. That's my takeaway; it's utilizing illicit

Re: Proxying NetFlow traffic correctly

On Jun 7, 2017, at 06:32, Sami via NANOG mailto:nanog@nanog.org>> wrote: My goal is to centralize NetFlow traffic into a single machine and then proxy some flows to other destinations for further analysis Or nprobe, as was already mentioned.

Re: Did Internet Founders Actually Anticipate Paid,

On Sep 21, 2010, at 11:01 AM, George Bonser wrote: > If the ISPs are directly peering with the content provider at some IX, the > content provider gets what amounts to a free ride to the end user. The counterargument is that the end-user has *already paid* the transit feeds for said content.

Re: Using crypto auth for detecting corrupted IGP packets?

On Oct 1, 2010, at 11:07 AM, Manav Bhatia wrote: > Buffering for 4-6 hours worth of control traffic is HUGE! If 4-6 hours of *control-plane* traffic on a given device is 'HUGE!', for some reasonable modern value of 'HUGE!', then there's definitely a problem on the network in question. ;> --

Re: Using crypto auth for detecting corrupted IGP packets?

On Oct 1, 2010, at 1:01 PM, Manav Bhatia wrote: > In 6 hours you will have around 8000K BFD packets. Add OSPF, > RSVP, BGP, LACP (for lags), dot1AG, EFM and you would really get a > significant number of packets to buffer. Which isn't a 'HUGE!' amount of packets. ;> -

Request for participation - Arbor 2010 Worldwide Infrastructure Security Report.

Request for participation - Arbor 2010 Worldwide Infrastructure Security Report. - Folks, We're in the process of collecting feedback for the 2010 Worldwide Infrastructure Security Report (WWISR); this is the Sixth Edition of the report, and we'd really be grateful for your participatio

Re: Request for participation - Arbor 2010 Worldwide Infrastructure Security Report.

On Oct 5, 2010, at 1:27 AM, Scott Weeks wrote: > Why are we required to register to look at the survey? That's how it's set up by the biz folks who provide the funding and resources which allow us to conduct the survey, analyze the responses, and then write and publish the report free of char

Re: Definitive Guide to IPv6 adoption

On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote: > Then move on to the Internet which as with most things is where the most > cuurent if not helpful information resides. Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel & Smith's infrastructure s

Re: NTP Server

On Oct 25, 2010, at 3:48 AM, Matthew Petach wrote: > NTP can potentially be used as a DoS vector by your upstream clocks, if > you're not running your own. +1 Also, if you experience a network partition event for any reason (DDoS attack, backhoe attack, et. al.) which disrupts communications

Re: Register.com DNS outages

On Nov 13, 2010, at 11:11 PM, David Ulevitch wrote: > Does anyone have any updates they can share on the register.com outage that > has been happening since sometime yesterday? ---

Re: Blocking International DNS

On Nov 22, 2010, at 10:48 PM, Joe Abley wrote: > I guess if the manner of the interception was to send back SERVFAIL to DNS > clients whose queries were (in some sense) objectionable, the result would be > that the clients were not able to resolve the (in some sense) bad names. Quantifying th

Re: Network management software with high detailed traffic report

On Nov 26, 2010, at 1:36 PM, Sergey Voropaev wrote: > Our task - is to find such applications and report to management and > developers a problem. Also if we'll be aware about it we could configure > QoS. One place to start would be an open-source NetFlow collector/analyzer like nfdump/nfsen:

Re: Network management software with high detailed traffic report

On Nov 26, 2010, at 3:59 PM, Sergey Voropaev wrote: > I work on this way too. There ais no problem with netflow-sensor. But I can > not find good inexpensive collector for Windows which can collect data and do > graphic report. Open-source = free. And you should be using *NIX, anyways. Usin

Re: Network management software with high detailed traffic report

On Nov 26, 2010, at 9:26 PM, Sergey Voropaev wrote: > But corporate politic use only Windows servers and no any other OS in the > production. They obviously use IOS or JunOS or what-have-you on their routers and other networking gear - classify this server as a piece of infrastructure equipme

Re: Blocking International DNS

On Dec 2, 2010, at 10:10 AM, Randy Bush wrote: > we have a significant failure by the security community in that they keep > giving us hierarchic models, pgp being a notable exception. --- R

Re: CAP / WARN / iPAWS

On Dec 3, 2010, at 10:34 AM, Richard Barnes wrote: > So they will likely end up looking at some layer-2/3 aspects of the problem > as well. --- Roland Dobbins //

Re: Impact of Attacks and Outages

On Dec 6, 2010, at 7:53 AM, Glen Kent wrote: > Any help in this regard would be really appreciated. This 2009 report (and reports from previous years) may be of interest: The 2010 report is in process right now, FYI. Here're some additional presentations

Re: Over a decade of DDOS--any progress yet?

On Dec 6, 2010, at 2:50 PM, Sean Donelan wrote: > Other than buying lots of bandwidth and scrubber boxes, have any other DDOS > attack vectors been stopped or rendered useless during the last > decade? These .pdf presos pretty much express my view of the situation, though I do need to rev th

Re: Pointer for documentation on actually delivering IPv6

On Dec 6, 2010, at 6:43 PM, Chris Nicholls wrote: > I found the following very helpful, Hardest thing for me was nailing > DHCPv6-PD without an DHCP server :) This is the best/most complete work on IPv6 security to date, IMHO:

Re: Pointer for documentation on actually delivering IPv6

On Dec 6, 2010, at 10:49 PM, Jack Bates wrote: > So does NAT add to security? Yes; just not very much. It adds nothing which can't be added in another, better way, and it subtracts a great deal in terms of instantiating unnecessary DoSable stateful chokepoints in the network, not to mention b

Re: ipfix/netflow/sflow generator for Linux

On Dec 7, 2010, at 3:44 AM, Thomas York wrote: > fprobe doesn't work properly because it has the input and output interface > IDs as both 0. IIRC, this can be altered via a config change. --- Roland Dobbins //

Re: ipfix/netflow/sflow generator for Linux

On Dec 7, 2010, at 4:24 AM, Thomas York wrote: > It can, but then you are setting the input/output IDs statically. That would > work fine if your router only had 2 interfaces. With a probe of this type, northbound/southbound tagging is generally sufficient, in my experience (i.e., let's not ma

Re: ipfix/netflow/sflow generator for Linux

On Dec 7, 2010, at 8:27 PM, Thomas York wrote: > Yes, you can statically set it but that will drastically skew the data in > this environment. What are you attempting to do that northbound/southbound isn't Good Enough? --- R

Re: Over a decade of DDOS--any progress yet?

On Dec 8, 2010, at 11:26 AM, Sean Donelan wrote: > Other than trying to hide your real address, what can be done to prevent DDOS > in the first place. DDoS is just a symptom. The problem is botnets. Preventing hosts from becoming bots in the first place and taking down existing botnets is

Re: Over a decade of DDOS--any progress yet?

On Dec 8, 2010, at 11:52 AM, Adrian Chadd wrote: > The real problem is people. Well, yes - but short of mass bombardment, eliminating people doesn't scale very well, and is generally frowned upon. ;> --- Roland Dobbins //

Re: Over a decade of DDOS--any progress yet?

On Dec 8, 2010, at 5:58 PM, wrote: > actually, botnets are an artifact. claiming that the tool is the problem > might be a bit short sighted. with the evolution of Internet technologies > (IoT) i suspect botnet-like structures to become much more prevelent and > useful for things other than

Re: Over a decade of DDOS--any progress yet?

On Dec 8, 2010, at 7:28 PM, Arturo Servin wrote: > One big problem (IMHO) of DDoS is that sources (the host of botnets) > may be completely unaware that they are part of a DDoS. I do not mean the bot > machine, I mean the ISP connecting those. The technology exists to detect and classify

Re: Over a decade of DDOS--any progress yet?

On Dec 8, 2010, at 10:04 PM, Thomas Mangin wrote: > So IIMHO the best way is still a good router with some basic QOS to protect > BGP on the link. iACLs and GTSM are your friends. ;> --- Roland Dobbins //

Re: Over a decade of DDOS--any progress yet?

On Dec 8, 2010, at 10:10 PM, Thomas Mangin wrote: > Until this is sorted I believe flowspec will be a marginal solution. We're seeing a significant uptick in flowspec interest, actually, and S/RTBH has been around for ages. -

Re: Over a decade of DDOS--any progress yet?

On Dec 8, 2010, at 10:33 PM, Arturo Servin wrote: > If you have an URL would be good. You may wish to do a bit more research on the topic of DDoS in general, as the state of the art in detection/classification/traceback/mitigation is considerably advanced beyond what you've described.

Re: Over a decade of DDOS--any progress yet?

On Dec 8, 2010, at 10:36 PM, Thomas Mangin wrote: > If you are a smaller network, you need the filtering to be performed by your > transit provider, as your uplink will otherwise be congested. Actually, most DDoS attacks aren't link-flooding attacks - this hasn't been true for the last ~7 year

Re: Over a decade of DDOS--any progress yet?

On Dec 8, 2010, at 10:47 PM, Arturo Servin wrote: > But even for simple flood attacks, I still think that the target has > very few defence mechanisms, and those that exists require a complex > coordination with upstreams. This is demonstrably incorrect. ---

Re: Over a decade of DDOS--any progress yet?

On Dec 8, 2010, at 11:14 PM, Drew Weaver wrote: > I would say that > 99% of the attacks that we see are 'link fillers' with < > 1% being an application attack. Application-layer attacks aside, most packet-flooding attacks these days don't completely fill links, as there's no need for the attac

Re: Over a decade of DDOS--any progress yet?

On Dec 8, 2010, at 11:38 PM, Jack Bates wrote: > I think the difference here is scale. packet-flooding attacks often do > fill links; if the links drop to 155mb/s or below. I'm not saying that link-flooding attacks don't happen; they certainly do, and on very big links, sometimes. But in the

Re: Over a decade of DDOS--any progress yet?

On Dec 8, 2010, at 11:47 PM, Jay Coley wrote: > This has been our recent experience as well. I see a link-filling attacks with some regularity; but again, what I'm saying is simply that they aren't as prevalent as they used to be, because the attackers don't *need* to fill links in order to a

Re: Over a decade of DDOS--any progress yet?

On Dec 9, 2010, at 1:34 AM, Matthew Petach wrote: > There seems to be a trend of using larger-scale flooding, or other simple > types of attacks to get all the network people at an organization > rushing over to throw resources and energy at it. Concur, the more serious attackers use diversiona

Re: Over a decade of DDOS--any progress yet?

On Dec 9, 2010, at 2:19 AM, Chris Boyd wrote: > Your BGP peer router would need to have lots of memory for /32 or /64 routes > though. Any modern router can handle this. > Anyone heard of such a beast? Or is this how the stuff from places like > Arbor Networks do their thing? This can be do

Re: Start accepting longer prefixes as IPv4 depletes?

On Dec 9, 2010, at 2:10 AM, Mohacsi Janos wrote: > Do you think adopting LISP or similar architectures to reduce the problems > mentioned above? Yes. --- Roland Dobbins // Sell y

Re: Start accepting longer prefixes as IPv4 depletes?

On Dec 9, 2010, at 2:38 AM, Cameron Byrne wrote: > I still fail to see the value of LISP in a mature and sane IPv6 world. Abstraction of the global routing table away from direct dependence upon the underlying transport in use at a given endpoint network alone offers huge benefits for future

Re: [Operational] Internet Police

On Dec 10, 2010, at 1:19 AM, Michael Smith wrote: > "front lines of this "cyberwar"? Warfare isn't the correct metaphor. Espionage/covert action is the correct metaphor. --- Roland Dobbins //

Re: [Operational] Internet Police

On Dec 10, 2010, at 10:01 AM, Robert E. Seastrom wrote: > "cyber-intifada" was the proper trope, but so far it has failed to grow legs. The problem is that non-ironic use of the appellation 'cyber-' is generally inversely proportional to actual clue, so it should be avoided at all costs. ;>

Re: Over a decade of DDOS--any progress yet?

On Dec 11, 2010, at 5:51 AM, Joel Jaeggli wrote: > Paying for DOS mitigation you rarely if ever use is quite expensive. Some operators offer 'Clean Pipes' commercial DDoS mitigation services; they have various fee models, and they charge their end-customers for it. It's positioned as a form o

Re: Over a decade of DDOS--any progress yet?

On Dec 14, 2010, at 2:04 AM, Bill Bogstad wrote: > A single data point on current DDOS traffic levels. In the 2009 Arbor WWISR, the largest attack reported was 49gb/sec. We're currently wrapping up the 2010 WWISR, and the largest attack report was considerably larger. ---

Re: Over a decade of DDOS--any progress yet?

On Dec 14, 2010, at 2:40 AM, "Jeffrey Lyon" wrote: > The only larger ones that i've seen were in company's marketing collateral vs. > real life. Here's a link to last year's Report (previous editions may be downloaded, as well): The WWISR is the result o

Re: The tale of a single MAC

On Jan 2, 2011, at 10:33 AM, Graham Wooden wrote: > What are the odds, that HP would dup’d them and that both would eventually > end up at my shop? There may be some setting you're overlooking or a bug which needs an update to fix, or you may simply have purchased HP ProLiant *cases*, rather

Re: The tale of a single MAC

On Jan 3, 2011, at 10:31 AM, Lynda wrote: > My guess is that you'll never find it on Google, since it happened around > 1993-4 or so. I remember that there were several high-profile instances of duplicate MAC addresses being burnt into NICs during the 1990s - once every 2-3 years, IIRC. And

Re: NIST IPv6 document

On Jan 5, 2011, at 1:15 PM, Jeff Wheeler wrote: > I notice that this document, in its nearly 200 pages, makes only casual > mention of ARP/NDP table overflow attacks, which may be among > the first real DoS challenges production IPv6 networks, and equipmentvendors, > have to resolve. They als

Re: NIST IPv6 document

On Jan 5, 2011, at 4:39 PM, Dobbins, Roland wrote: > They also only make small mention of DNS- and broadcast-hinted scanning, and > none at all of routing-hinted scanning. I meant to include, ' . . . and the strain that this hinted scanning will place on the DNS and routin

Re: NIST IPv6 document

On Jan 5, 2011, at 7:21 PM, Jeff Wheeler wrote: > please explain why this is in any way better than operating the same LAN with > a subnet similar in size to its existing IPv4 subnets, e.g. a /120. Using /64s is insane because a) it's unnecessarily wasteful (no lectures on how large the space

Re: NIST IPv6 document

On Jan 6, 2011, at 1:02 AM, TJ wrote: > if you are permitting external hosts the ability to scan your internal > network in an unrestricted > fashion DCN aside, how precisely does one define 'internal network' in, say, the context of the production network of a broadband access SP, or hostin

Re: NIST IPv6 document

On Jan 6, 2011, at 1:14 AM, Jeff Wheeler wrote: > A stateful firewall on every router interface has been suggested already on > this thread. It is unrealistic. It isn't just unrealistic, it's highly undesirable, since it represents an huge DoS state vector. --

Re: NIST IPv6 document

On Jan 6, 2011, at 8:57 AM, Joe Greco wrote: > The switch from IPv4 to IPv6 itself is such a change; it renders random > trolling through IP space much less productive. And renders hinted trolling far more productive/necessary, invariably leading to increased strain on already-brittle/-overloa

Re: Problems with removing NAT from a network

On Jan 6, 2011, at 9:38 AM, ML wrote: > At least not without some painful rebuilds of criticals systems which have > these IPs deeply embedded in their configs. They shouldn't be using IP addresses in configs, they should be using DNS names. Time to bite the bullet and get this fixed prior to

Re: NIST IPv6 document

On Jan 6, 2011, at 10:08 AM, Joe Greco wrote: > Packing everything densely is an obvious problem with IPv4; we learned early > on that having a 48-bit (32 address, 16 port) space to scan made > port-scanning easy, attractive, productive, and commonplace. I don't believe that host-/port-scanning

Re: NIST IPv6 document

On Jan 6, 2011, at 10:42 AM, George Bonser wrote: > It will be a problem if people learn they can DoS routers by doing it by > maxing out the neighbor table. I understand this - that's a completely separate issue from the supposed benefits of sparse addressing for endpoint host security. > I

Re: NIST IPv6 document

On Jan 6, 2011, at 11:16 AM, George Bonser wrote: > I thought the entire notion of actually getting to a host was orthogonal to > the discussion as that wasn't the point. It wasn't about > exploitation of anything on the host, the discussion was about the act of > scanning a network itself bei

Re: NIST IPv6 document

On Jan 6, 2011, at 11:21 AM, Jeff Kell wrote: > I hesitate to write anything off to impossibility, having witnessed the 8 to > 16 to 32 to 64-bit processor progression :) Indeed; how quickly we forget, eh? ;> > And the "depth" of infrastructure at which you can decide the traffic is > bogus i

Re: ARIN and the RPKI (was Re: AltDB?)

On Jan 6, 2011, at 11:16 AM, Randy Bush wrote: > actually, the formal rpki-based origin-validation stuff is measured to take > *less* cpu, a lot less, than ACLs On the platforms which really matter in terms of rPKI, ACLs are handled in hardware, so this is pretty much a wash. Concur on all t

Re: NIST IPv6 document

On Jan 6, 2011, at 12:17 PM, Joe Greco wrote: > If you don't understand the value of such an increase in magnitude, I can count as well as you can, I assure you. > I invite you to switch all your ssh keys to 56 bit. The difference is that if someone compromises/brute-forces one of my ssh keys,

Re: NIST IPv6 document

On Jan 6, 2011, at 12:54 PM, Joe Greco wrote: > Generally speaking, security professionals prefer for there to be more > roadblocks rather than fewer. The soi-disant security 'professionals' who espouse layering unnecessary multiple, inefficient, illogical, and iatrogenic roadblocks in pref

Re: NIST IPv6 document

On Jan 6, 2011, at 1:26 PM, Joe Greco wrote: > A bunch of very smart people have worked on IPv6 for a very long time, and > justification for /64's was hashed out at extended length > over the period of years. Very smart people can and do come up with bad ideas, and IPv6 is a textbook example

Re: NIST IPv6 document

On Jan 6, 2011, at 2:03 PM, Matthew Petach wrote: > I think what people are trying to say is that it doesn't matter whether or > not your host is easily findable or not, if I can trivially take out your > upstream router. That's part of it - the other part is that the host will be found, irresp

Re: NIST IPv6 document

On Jan 6, 2011, at 2:42 PM, Joel Jaeggli wrote: > icmp6 rate limiting both reciept and origination is not rocket science. But it's *considerably* more complex and has far more potential implications than ICMP rate-limiting in IPv4 (which in and of itself is more complex and has more implicati

Re: NIST IPv6 document

On Jan 6, 2011, at 1:51 PM, Joe Greco wrote: > There are numerous parallels between physical and electronic security. > Let's just concede that for a moment. I can't, and here's why: 1. In the physical world, attackers run a substantial risk of being caught, and of tangible, severe penalt

Re: NIST IPv6 document

On Jan 6, 2011, at 9:29 PM, Joe Greco wrote: > Sorry, but I see this as not grasping a fundamental security concept. I see it as avoiding a common security misconception. > Making a host harder to find (or more specifically to address from remote) is > a worthwhile goal. As I've stated repeat

Re: NIST IPv6 document

On Jan 6, 2011, at 11:28 PM, wrote: > Playing devil's advocate for a moment... I don't see this as devil's advocacy, since I've said a) we're already hosed (i.e., what you said) and b), we're going to get even more hosed with IPv6. ;> -

Re: NIST IPv6 document

On Jan 6, 2011, at 11:48 PM, Jack Bates wrote: > It is not the intentional that we should fear, but the unintentional. This is the single largest issue with IPv6 and the whole ND mess in a nutshell - unintentional DoS becomes much more likely. --

Re: NIST IPv6 document

On Jan 7, 2011, at 1:20 AM, Owen DeLong wrote: > You are mistaken... Host scanning followed by port sweeps is a very common > threat and still widely practiced in IPv4. I know it's common and widely-practiced. My point is that if the host is security properly, this doesn't matter; and that if

Re: NIST IPv6 document

On Jan 7, 2011, at 4:14 PM, Mark Smith wrote: > Doesn't this risk already exist in IPv4? There are various vendor knobs/features to ameliorate ARP-level issues in switching gear. Those same knobs aren't viable in IPv6 due to the way ND/NS work, and as you mention, the ND stuff is layer-3-ro

Re: Problems with removing NAT from a network

On Jan 7, 2011, at 4:02 PM, Owen DeLong wrote: > No, it hasn't always been a Bad Idea. Yes, it has. There're lots of issues with embedding IP addresses directly into apps and so forth which have nothing to do with NAT.

Re: NIST IPv6 document

On Jan 7, 2011, at 9:30 PM, TJ wrote: > Today (IPv4) they may not, but many recommendations for tomorrow (IPv6) are > to use discrete network allocations for your infrastructure (loopbacks and > PtP links, specifically) and to filter traffic destined to those at your > edges ... Actually, this

Re: NIST IPv6 document

On Jan 7, 2011, at 9:23 PM, Tim Chown wrote: > The main operational problem we see is denial of service caused by > unintentional IPv6 RAs from hosts. Which is a whole other can of IPv6 worms, heh. ;> Roland Dobbins //

Re: IPv6 - real vs theoretical problems

On Jan 8, 2011, at 3:29 AM, Deepak Jain wrote: > There are now years of security dogma that says NAT is a good thing, Actually, this isn't the case. There's some *security theater* dogma which makes totally unsupported claims about the supposed security benefits of NAT, but that's not quite

Re: IPv6 - real vs theoretical problems

On Jan 8, 2011, at 5:44 AM, Owen DeLong wrote: > You say dogma, I say mythology. Concur 100%. > Stateful inspection provides security. To clarify, stateful inspection only provides security in a context where there's state to inspect - i.e., at the southernmost end of access networks, direct

Re: NIST IPv6 document

On Jan 8, 2011, at 4:28 AM, Mark Smith wrote: > The problem is that somebody on the Internet > could send 1000s of UDP packets (i.e. an offlink traffic source) towards > destinations that don't exist on the target subnet. I meant to type 'ND-triggering stuff', concur 100%. ---

Re: IPv6 - real vs theoretical problems

On Jan 8, 2011, at 8:54 AM, William Herrin wrote: > I presume you don't intend us to conclude that a bastion host firewall > provides no security benefit to the equipment it > protects. If it's protecting workstations, yes, it has some positive security value - but not due to NAT. If it's ina

Re: IPv6 - real vs theoretical problems

On Jan 9, 2011, at 12:11 AM, Sam Stickland wrote: > Why do you say there is zero state at the server, but the not at the client? Because every incoming connection to the server is unsolicited - therefore, there's no pre-existing state to evaluate. -

Re: Is NAT can provide some kind of protection?

On Mar 21, 2007, at 5:41 AM, Tarig Ahmed wrote: > Security guy told me is not correct to assign public ip to a server, it > should have private ip for security reasons. He's wrong. > Is it true that NAT can provide more security? No, it makes things worse from an availability perspective. S

Re: Is NAT can provide some kind of protection?

On Jan 13, 2011, at 12:02 AM, Justin Scott wrote: > The PCI-DSS comes to mind for those who deal with credit card transactions. Luckily, there are ways to 'comply' with the PCI-DSS security theater regime without placing the availability and overall security of one's public-facing servers at

Re: Is NAT can provide some kind of protection?

On Jan 13, 2011, at 9:59 AM, Jack Bates wrote: > The proxy capabilities of the firewall are additional security measures on > top of the NAT (and definitely should be deployed for their higher security > value). Not in front of servers, they shouldn't - because they have a negative security v

Re: And so it ends...

On Feb 3, 2011, at 9:35 PM, Scott Howard wrote: > 102/8 AfriNIC2011-02whois.afrinic.net ALLOCATED > 103/8 APNIC 2011-02whois.apnic.net ALLOCATED > 104/8 ARIN 2011-02whois.arin.netALLOCATED > 179/8 LACNIC 2011-02whois.lacnic.net ALLOCATED > 185/8

Re: ddos attacks

On Dec 19, 2013, at 3:53 PM, Tore Anderson wrote: > So in order for an Anti-DDoS appliance to be functional the network needs to > be able to withstand the DDoS on its own. How terribly useful. Due to the nature of network infrastructure devices and TCP/IP, it's quite necessary that they them

Re: ddos attacks

On Dec 19, 2013, at 8:40 PM, Nick Hilliard wrote: > Many hosting profiles don't require this sort of anti-DDoS kit. My post had nothing to do with 'anti-DDoS kit'. > I'm sure mitigation boxes like this serve well in many situations if the cost > / benefit justifies the expenditure, but as wi

Re: ddos attacks

On Dec 19, 2013, at 10:40 PM, Nick Hilliard wrote: > hmm, re-reading it, your post was contextually ambiguous and I read it in a > different way to the way that apparently you meant. It was quite clear what was meant, even without looking at the linked presentation, which clarified matters ev

Re: ddos attacks

On Dec 19, 2013, at 6:12 AM, cb.list6 wrote: > I am strongly considering having my upstreams to simply rate limit ipv4 UDP. QoS is a very poor mechanism for remediating DDoS attacks. It ensures that programmatically-generated attack traffic will 'squeeze out' legitimate traffic. > During an

Re: ddos attacks

On Dec 20, 2013, at 4:39 AM, cb.list6 wrote: > Not answering any of that. But thanks for asking. I wasn't asking those questions in order to elicit information from you, but rather as food for thought as you work through these issues. > I think ipv4 udp is just going to become operationally

Re: ddos attacks

On Dec 20, 2013, at 3:27 PM, Saku Ytti wrote: > c) ACL/RPF in significant portion of access ports in whole world >- i'm guessing significant portion of access ports are on autopilot with > no one to change their configs, so probably not practical. d) The current state of affairs pers

Re: NSA able to compromise Cisco, Juniper, Huawei switches

On Dec 30, 2013, at 5:06 PM, Saku Ytti wrote: > The quality of this data is too damn low. The #1 way that Cisco routers and switches are compromised is brute-forcing against an unsecured management plane, with username 'cisco' and password 'cisco. The #1 way that Juniper and switches are com

Re: NSA able to compromise Cisco, Juniper, Huawei switches

On Dec 30, 2013, at 6:18 PM, Saku Ytti wrote: > I welcome the short-term havok and damage of such disclose if it would be > anywhere near the magnitude implied, it would create pressure to change > things. This is the type of change we're likely to see, IMHO:

Re: NSA able to compromise Cisco, Juniper, Huawei switches

On Dec 30, 2013, at 8:07 PM, Ray Soucy wrote: > I hope Cisco, Juniper, and others respond quickly with updated images for all > platforms affected before the details leak. During my time at Cisco, I was involved deeply enough with various platform teams as well as PSIRT, etc., to assert with

Re: NSA able to compromise Cisco, Juniper, Huawei switches

On Dec 30, 2013, at 10:44 PM, wrote: > What percentage of Cisco gear that supports a CALEA lawful intercept mode is > installed in situations where CALEA doesn't apply, and thus there's a high > likelyhood that said support is misconfigured and abusable without being > noticed? AFAIK, it m

Re: NSA able to compromise Cisco, Juniper, Huawei switches

On Dec 30, 2013, at 11:03 PM, Dobbins, Roland wrote: > AFAIK, it must be explicitly enabled in order to be functional. It isn't the > sort of thing which is enabled by default, nor can it be enabled without > making explicit configuration changes. It's also possible th

Re: NSA able to compromise Cisco, Juniper, Huawei switches

On Dec 30, 2013, at 11:16 PM, Enno Rey wrote: > at least back in 2007 it could be enabled/configured by SNMP RW access [see > slide 43 of the presentation referenced in this post > http://www.insinuator.net/2013/07/snmp-reflected-amplification-ddos-attacks/] > so knowing the term "private" mi

Re: NSA able to compromise Cisco, Juniper, Huawei switches

On Dec 30, 2013, at 11:18 PM, Sam Moats wrote: > This might be an interesting example of it's (mis)use. > http://en.wikipedia.org/wiki/Greek_wiretapping_case_2004%E2%80%932005 That's one of the cases I know about; it was utilized via Ericsson gear. -

Re: NSA able to compromise Cisco, Juniper, Huawei switches

On Dec 30, 2013, at 11:28 PM, Marco Teixeira wrote: > i just wanted to say that any network professional that puts any equipment > into production without securing it against the kind of > issues mentioned so far (cisco/cisco, snmp private, etc) is negligent and > should be fired on the spot.

Re: NSA able to compromise Cisco, Juniper, Huawei switches

On Dec 31, 2013, at 12:00 AM, Ray Soucy wrote: > So this isn't an issue of the NSA working with Cisco and Juniper to include > back doors, it's an issue of the NSA modifying those releases after the fact > though BIOS implants. Yes, I see this now, thanks. AFAICT, the Cisco boxes listed are

Re: NSA able to compromise Cisco, Juniper, Huawei switches

On Dec 31, 2013, at 9:41 AM, Randy Bush wrote: > you may want to read the more complete, well let's say extensive Thanks, Randy - now I see the JunOS stuff in there for J-series and M-series. --- Roland Dobbins //

Re: NSA able to compromise Cisco, Juniper, Huawei switches

On Dec 31, 2013, at 10:16 AM, Blake Dunlap wrote: > The cynic in me says that cisco switch/router gear isn't part of that report > on clandestine backdoors, because they don't need said clandestine backdoors > to access them... T-series is in there, too. It's also important to keep in mind t

Re: NSA able to compromise Cisco, Juniper, Huawei switches

On Dec 31, 2013, at 10:59 AM, Randy Bush wrote: > assumptions that the TAO folk have been taking a long much-deserved > sabbatical are probably naive Indeed; that is my point. These documents allege that the capabilities in question were present five years ago, which is an eternity in tech-t

<    1   2   3   4   5   6   >