Re: abuse reporting tools
Inspired by this thread (and other recent similar ones about how hard it is to report abuse in the right format to the right people), I've decided I'm going to start work on the Perl module presumed by this gist ... https://gist.github.com/PWBENNETT/18970413677c5df79c6a Reporting network abuse should be *EASY*. Say it with me ... *EASY*. No promises, at this stage, but I thought some of you would like to know that this project is at least in the pre-planning stages. -- Paul W Bennett
Re: level3 issue in chicago
fyi: On 11/20/2014 02:42 AM, cool hand luke wrote: On 11/19/2014 07:29 PM, David Hubbard wrote: Appears to have been resolved after seven hours. My ticket just says: We isolated the routing issue and resolved it. The issue was due to a misconfiguration on one our core routers. Now that the issue is corrected, interestingly enough, my trace goes from Tampa to Chicago instead of Dallas. our issue was resolved around the same time but is apparently now occurring again, since 0638 utc -- routing issue affecting (for us) traffic on level3 between chicago, illinois, and cincinnati, ohio. i imagine it's affecting other locations as well. routing issue experienced from 06:37 - 11:02 utc. notes from level 3: 11/20/2014 11:30:19 GMT - After investigating the issue I found that this circuit was affected by an outage on our network. A non-service affecting maintenance had unintended results causing routing problems in the Chicago area. All traffic through the Chicago area was affected by this issue. If you have any additional destinations that are still seeing issues please contact us as soon as possible as the issue may not be completely resolved yet. /chl
Need Godaddy Contact
I have a question that Godaddy support will not answer. My son moved a word press site to Godaddy from another host. Apparently, unbeknowest to him, the original wordpress site was also the email host. The mail was moved from the old server to the new server but the email was never properly set up via the GoDaddy Cpanel Question for a Godaddy Guru. if we set up the email through the cpanel, will it erase any mail currently in the accounts on the linux wordpress machine, or even acknowledge that the exist email is there? Any help would be GREATLY appreciated and Thanks.. Larry
Re: Need Godaddy Contact
It won't do anything to another server. You won't get copies of messages transferred with DNS changes. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Nov 20, 2014 9:10 AM, Larry Krone la...@elucidations.net wrote: I have a question that Godaddy support will not answer. My son moved a word press site to Godaddy from another host. Apparently, unbeknowest to him, the original wordpress site was also the email host. The mail was moved from the old server to the new server but the email was never properly set up via the GoDaddy Cpanel Question for a Godaddy Guru. if we set up the email through the cpanel, will it erase any mail currently in the accounts on the linux wordpress machine, or even acknowledge that the exist email is there? Any help would be GREATLY appreciated and Thanks.. Larry
Re: Need Godaddy Contact
Larry Krone wrote: I have a question that Godaddy support will not answer. That actually seems odd - I've usually found them helpful. But that's neither here nor there. See below... My son moved a word press site to Godaddy from another host. Apparently, unbeknowest to him, the original wordpress site was also the email host. The mail was moved from the old server to the new server but the email was never properly set up via the GoDaddy Cpanel Question for a Godaddy Guru. if we set up the email through the cpanel, will it erase any mail currently in the accounts on the linux wordpress machine, or even acknowledge that the exist email is there? As previously noted, what you do on the GoDaddy site will have no effect on the other server (assuming it's not also on GoDaddy, of course). What will change things is propagation of DNS record changes. For a period, mail will flow to both the old and new server, until the new DNS records get everywhere. What I'd recommend is something like this: - check the expiration period for the old DNS record - monitor both sites for mail for at least the timeout on the old record; keep monitoring the old site until you're sure no more mail is getting there - maybe, put a .forward file on the old site to catch any mail that leads through (but only after you're sure the old site has the updated DNS record! - you can't use a physical IP address for forwarding to GoDaddy, because everything there is via virtual hosts) - transfer all mail from the old site to the new site (if you use IMAP, that's pretty easy, or tar up your mail directory) - then decommission the old site Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
DDOS, IDS, RTBH, and Rate limiting
Hello, folks! I'm author of fastnetmon, thank you for some PR for my toolkit :) I use this tool for similar type of attacks and we do analyze all traffic from uplinks ports using port mirroring. You can look at this network diagram: https://raw.githubusercontent.com/FastVPSEestiOu/fastnetmon/master/network_map.png I tried to use netflow many years ago but it's not accurate enough and not so fast enough and produce big overhead on middle class network routers. It's because I wrote this tool and do every packet analyze. It can detect attack in 2 seconds max and call BGP blackhole as quick as thought. It can detect three types of attacks: 1) Speed attack for certain IP (we ban every IP which exceed 1 Gbps) 2) Packet per second attack for certain IP (we ban every IP which exceed 100 000 ppps) 3) And flow flood (very useful mode in networks with big bandwidth/pps per client) FastNetMon can handle 2-3 million of packets per second and ~20Gbps on standard i7 2600 Linux box with Intel 82599 NIC. If you need any help or suggestions you can email me directly or ask via GitHub. Thank you! -- Sincerely yours, Pavel Odintsov
Re: Level3 rwhois broken
It's nice to see someone is using RWHOIS. Back when I wrote the RWHOIS daemon for HE I spoke with Mark Kosters (one of the authors of RFC 2167). I wish I still had the emails because at the time he was shocked anyone would create software for something that no one really uses. I seem to recall him calling it a waste of time ;-) That said... I'm seeing Level 3's RWHOIS down as well. And to be honest, they're probably not monitoring it. On Tue, Nov 18, 2014 at 11:53 PM, Suresh Ramasubramanian ops.li...@gmail.com wrote: Anybody? Makes it a pain to perform surgical spam blocking when this happens :) suresh@samwise 01:52:24 ~ $ telnet rwhois.level3.net 4321 Trying 209.244.1.179... ^C -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: DDOS, IDS, RTBH, and Rate limiting
On 21 Nov 2014, at 4:36, Pavel Odintsov wrote: I tried to use netflow many years ago but it's not accurate enough and not so fast enough and produce big overhead on middle class network routers. These statements are not supported by the facts. NetFlow (and other varieties of flow telemetry) has been used for many years for traffic engineering-related analysis, capacity planning, and security purposes. I've never seen the CPU utilization on even a modest mid-range router rise above single-digits, except once due to a bug (which was fixed quickly). Flow telemetry scales and provides invaluable edge-to-edge traceback information. NetFlow telemetry is accurate enough to be used for all the purposes noted above by network operators across the world, from the smallest to the largest networks in the world. There are several excellent open-source NetFlow analysis tools which allow folks to benefit from NetFlow analysis without spending a lot of money. Some of these projects have been maintained and enhanced for many years; their authors would not do that if NetFlow analytics weren't sufficient to needs. Packet-based analysis is certainly useful, but does not scale and does not provide traceback information. FastNetMon can handle 2-3 million of packets per second and ~20Gbps on standard i7 2600 Linux box with Intel 82599 NIC. See the comments above with regards to scale. This is inadequate for a network of any size, it does not provide traceback information, and it does not lend itself to broad deployment across a network of any size. I'm sure FastNetMon is a fine tool, and it's very good of you to spend the time and effort to develop it and to make it available. However, making demonstrably-inaccurate statements about other technologies which are in wide use by network operators and which have a proven track record in the field is probably not the best way to encourage folks to try FastNetMon. --- Roland Dobbins rdobb...@arbor.net
Re: Level3 rwhois broken
I put together a protocol framework in Node.js https://www.npmjs.org/package/rwhois Its still useful for some companies. On Thu, Nov 20, 2014 at 2:49 PM, Jeff Walter jwal...@weebly.com wrote: It's nice to see someone is using RWHOIS. Back when I wrote the RWHOIS daemon for HE I spoke with Mark Kosters (one of the authors of RFC 2167). I wish I still had the emails because at the time he was shocked anyone would create software for something that no one really uses. I seem to recall him calling it a waste of time ;-) That said... I'm seeing Level 3's RWHOIS down as well. And to be honest, they're probably not monitoring it. On Tue, Nov 18, 2014 at 11:53 PM, Suresh Ramasubramanian ops.li...@gmail.com wrote: Anybody? Makes it a pain to perform surgical spam blocking when this happens :) suresh@samwise 01:52:24 ~ $ telnet rwhois.level3.net 4321 Trying 209.244.1.179... ^C -- Suresh Ramasubramanian (ops.li...@gmail.com) -- eSited LLC (701) 390-9638
USA Power Grid compromised?
Am I the only Network Admin wondering how this can happen and why its still an issue if it was discovered in 2011? Now I never worked in the Energy field so I am in the dark (pun intended I guess) on how serious the Public utilities address these issues. They should have redundant systems so they can clean (reimage, etc) whatever is there and be done with it?? ref: NSA chief admits China could cripple U.S. power grid, financial networks http://www.zdnet.com/nsa-chief-admits-china-could-cripple-u-s-power-grid-financial-networks-736025/ http://abcnews.go.com/US/trojan-horse-bug-lurking-vital-us-computers-2011/story?id=26737476 -- Later, Joe
Anyone heard from Jared lately?
He generally provides same-day service on email, but... Hope all is well. Cheers, -- jra Moderator @ outages -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Anyone heard from Jared lately?
On Thu, Nov 20, 2014 at 06:07:09PM -0500, Jay Ashworth wrote: He generally provides same-day service on email, but... Hope all is well. Don't worry, he is alive and well. puck.nether.net is having some disk issues hene a backlog on email. - Job
Re: DDOS, IDS, RTBH, and Rate limiting
On 2014-11-20 23:59, Roland Dobbins wrote: On 21 Nov 2014, at 4:36, Pavel Odintsov wrote: I tried to use netflow many years ago but it's not accurate enough and not so fast enough and produce big overhead on middle class network routers. These statements are not supported by the facts. NetFlow (and other varieties of flow telemetry) has been used for many years for traffic engineering-related analysis, capacity planning, and security purposes. I've never seen the CPU utilization on even a modest mid-range router rise above single-digits, except once due to a bug (which was fixed quickly). Flow telemetry scales and provides invaluable edge-to-edge traceback information. NetFlow telemetry is accurate enough to be used for all the purposes noted above by network operators across the world, from the smallest to the largest networks in the world. There are several excellent open-source NetFlow analysis tools which allow folks to benefit from NetFlow analysis without spending a lot of money. Some of these projects have been maintained and enhanced for many years; their authors would not do that if NetFlow analytics weren't sufficient to needs. Packet-based analysis is certainly useful, but does not scale and does not provide traceback information. FastNetMon can handle 2-3 million of packets per second and ~20Gbps on standard i7 2600 Linux box with Intel 82599 NIC. See the comments above with regards to scale. This is inadequate for a network of any size, it does not provide traceback information, and it does not lend itself to broad deployment across a network of any size. I'm sure FastNetMon is a fine tool, and it's very good of you to spend the time and effort to develop it and to make it available. However, making demonstrably-inaccurate statements about other technologies which are in wide use by network operators and which have a proven track record in the field is probably not the best way to encourage folks to try FastNetMon. Netflow is stateful stuff, and just to run it on wirespeed, on hardware, you need to utilise significant part of TCAM, i am not talking that on some hardware it is just impossible to run it. So everything about netflow are built on assumption that hosting or ISP can run it. And based on some observations, majority of small/middle hosting providers are using minimal,just BGP capable L3 switch as core, and cheapest but reliable L2/L3 on aggregation, and both are capable in best case to run sampled sFlow. And last thing, from one of public papers, netflow delaying factors: 1. Flow record expiration 2. Exporting process • Typical delay: 15-60 sec. So for a small hosting(up to 10G), i believe, FastNetMon is best solution. Faster, and no significant investments to equipment. Bigger hosting providers might reuse their existing servers, segment the network, and implement inexpensive monitoring on aggregation switches without any additional cost again. Ah, and there is one more huge problem with netflow vs FastNetMon - netflow just by design cannot be adapted to run pattern matching, while it is trivial to patch FastNetMon for that, turning it to mini-IDS for free. --- Best regards, Denys
RE: Level3 rwhois broken
We decommissioned our rwhois server, but apparently we didn't get DNS cleaned up (which we'll do in the near future). The closest thing we have to that is our whois server rr.level3.net, or if that doesn't quite meet your needs, you can contact our security department at ab...@level3.net. Dave -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jeff Walter Sent: Thursday, November 20, 2014 2:50 PM To: Suresh Ramasubramanian Cc: nanog@nanog.org Subject: Re: Level3 rwhois broken It's nice to see someone is using RWHOIS. Back when I wrote the RWHOIS daemon for HE I spoke with Mark Kosters (one of the authors of RFC 2167). I wish I still had the emails because at the time he was shocked anyone would create software for something that no one really uses. I seem to recall him calling it a waste of time ;-) That said... I'm seeing Level 3's RWHOIS down as well. And to be honest, they're probably not monitoring it. On Tue, Nov 18, 2014 at 11:53 PM, Suresh Ramasubramanian ops.li...@gmail.com wrote: Anybody? Makes it a pain to perform surgical spam blocking when this happens :) suresh@samwise 01:52:24 ~ $ telnet rwhois.level3.net 4321 Trying 209.244.1.179... ^C -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Level3 rwhois broken
Works for me, thanks. I forgot exactly which IPs this was about right now though :) On Fri, 21 Nov 2014 at 05:12 Siegel, David david.sie...@level3.com wrote: We decommissioned our rwhois server, but apparently we didn't get DNS cleaned up (which we'll do in the near future). The closest thing we have to that is our whois server rr.level3.net, or if that doesn't quite meet your needs, you can contact our security department at ab...@level3.net. Dave -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jeff Walter Sent: Thursday, November 20, 2014 2:50 PM To: Suresh Ramasubramanian Cc: nanog@nanog.org Subject: Re: Level3 rwhois broken It's nice to see someone is using RWHOIS. Back when I wrote the RWHOIS daemon for HE I spoke with Mark Kosters (one of the authors of RFC 2167). I wish I still had the emails because at the time he was shocked anyone would create software for something that no one really uses. I seem to recall him calling it a waste of time ;-) That said... I'm seeing Level 3's RWHOIS down as well. And to be honest, they're probably not monitoring it. On Tue, Nov 18, 2014 at 11:53 PM, Suresh Ramasubramanian ops.li...@gmail.com wrote: Anybody? Makes it a pain to perform surgical spam blocking when this happens :) suresh@samwise 01:52:24 ~ $ telnet rwhois.level3.net 4321 Trying 209.244.1.179... ^C -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: DDOS, IDS, RTBH, and Rate limiting
On 21 Nov 2014, at 6:22, Denys Fedoryshchenko wrote: Netflow is stateful stuff, This is factually incorrect; NetFlow flows are unidirectional in nature, and in any event have no effect on processing of data-plane traffic. and just to run it on wirespeed, on hardware, you need to utilise significant part of TCAM, Again, this is factually incorrect. i am not talking that on some hardware it is just impossible to run it. This is also factually incorrect. Some platforms/linecards do not in fact support NetFlow (or other varieties of flow telemetry) due to hardware limitations. And last thing, from one of public papers, netflow delaying factors: 1. Flow record expiration This is tunable. • Typical delay: 15-60 sec. This is an entirely subjective assessment, and does not reflect operational realities. These are typically *maximum values* - and they are well within operationally-useful timeframes. Also, the effect of NetFlow cache size and resultant FIFOing of flow records is not taken into account, nor is the effect on flow termination and flow-record export of TCP FIN or RST flags denoting TCP traffic taken into account. So for a small hosting(up to 10G), i believe, FastNetMon is best solution. This is a gross over-generalization unsupported by facts. Many years of operational experience with NetFlow and other forms of flow telemetry by large numbers of network operators of all sizes and varieties contract this over-generalization. It is generally unwise to make sweeping statements regarding operational impact which are not borne out by significant operational experience in production networks. Faster, and no significant investments to equipment. This statement indicates a lack of understanding of opex costs, irrespective of capex costs. Bigger hosting providers might reuse their existing servers, segment the network, and implement inexpensive monitoring on aggregation switches without any additional cost again. This statement indicates a lack of operational experience in networks of even minimal scale. Ah, and there is one more huge problem with netflow vs FastNetMon - netflow just by design cannot be adapted to run pattern matching, while it is trivial to patch FastNetMon for that, turning it to mini-IDS for free. This statement betrays a lack of understanding of NetFlow-based (and other flow telemetry-based) detection and classification, as well as the undesirability and negative operational impact of stateful IDS/'IPS' deployments in production networks. You should also note that FastNetMon is far from unique; there are multiple other open-source tools which provide the same type of functionality, and none of them have replaced flow telemetry, either. Tools such as FastNetMon supplement flow telemetry, in situations in which such tools can be deployed. They do not begin to replace flow telemetry, and they are not inherently superior to flow telemetry. Again, I'm sure FastNetMon is a useful tool in many circumstances. But it would be a much better idea to define FastNetMon positively in terms of its own inherent value, rather than attempting to define it based upon factually incorrect negative 'comparisons' to other well-established, widely-used technologies which have demonstrable track records within the global operational community. --- Roland Dobbins rdobb...@arbor.net
Re: DDOS, IDS, RTBH, and Rate limiting
On 21 Nov 2014, at 9:19, Robert Duffy wrote: What open-source NetFlow analysis tools would you recommend for quickly detecting a DDoS attack? I generally recommend that folks get started with something like nfdump/nfsen or ntop. There are other, more sophisticated tools out there, but these allow one to get up and running quickly, and to gain valuable operational experience with which to evaluate more sophisticated tools, if they're needed. --- Roland Dobbins rdobb...@arbor.net
Re: DDOS, IDS, RTBH, and Rate limiting
I highly recommend pmacct and it's in-memory tables. Lightweight, easy to query and super fast. You can also easily run multiple aggregates of traffic to find what you are interested in, tag common interface types to easily filter traffic.. Or you can use pmacct to insert this into whatever database you want, AMQP or MongoDB.. My current favorite is using an IMT table for DoS detection and another for aggregates for interesting traffic types and querying this every X minutes and inserting it into ElasticSearch. Kibana makes the most powerful netflow dashboard ever. -- Tim On Nov 20, 2014 6:39 PM, Roland Dobbins rdobb...@arbor.net wrote: On 21 Nov 2014, at 9:19, Robert Duffy wrote: What open-source NetFlow analysis tools would you recommend for quickly detecting a DDoS attack? I generally recommend that folks get started with something like nfdump/nfsen or ntop. There are other, more sophisticated tools out there, but these allow one to get up and running quickly, and to gain valuable operational experience with which to evaluate more sophisticated tools, if they're needed. --- Roland Dobbins rdobb...@arbor.net
Re: Clueful Jive Communications Contact?
Sounds about on par with my experience so far. We have a client who uses jive and we manage their network and when this client opens tickets with jive, they get copy+pasted the exact same email every time telling the client to make sure sip alg is disabled, check firewall, etc. We have repeatedly told them that theres no filtering of outbound traffic and we've stated many times that all their recommendations are already in affect. We also ran into a similar adtran situation to yours, when the customer contacted Jive to open the first support ticket, Jive automatically started CC-ing the IT company who is a Jive reseller and doesn't have any staff familiar with cisco ios and insisted that they put in a adtran. The reseller came out and dismantled the network and I advised Jive we are applying QoS to standard VOIP ports in our base config but I told them if there is anything outside the normal sip and rtp ports to give it me to me to be added and they still haven't. At one point our client got real upset and Jive started monitoring the WAN link which is dedicated for their voice traffic only and then started telling the customer to call the ISP. The irony here is that I'm almost postivie that their perceived loss is just that when the link is fully utilized we obviously don't prioritize ICMP and also I have a hunch that they are using more ports than the typical ones in which case that traffic will suffer also because they will not tell me what traffic to prioritize. This support rep now refuses to proceed until the customer calls the ISP so we switched their voice traffic to another WAN link completely just to demonstrate at which point the support rep said they saw loss still at which point I explained that if we had the info necessary to QoS everything properly their traffic should be unaffected even when there is congestion. Which is more likely at fault: A) Having the exact same set of problems with 2 different diverse ISP's B) Their monitoring traffic being drop as expected, when link is congested and router is applying QoS exactly as it should and dropping the non prioritized traffic. Of course when some traffic is prioritized that automatically means non prioritized traffic is penalized. This is exactly how we want it. Needless to say, the client is frustrated because support is stuck at call isp and insist they see voice loss. Hopefully your experience is not quite as bad but I have to say that of all the different voice service providers we've worked with we've never spent as much time The contact who reached out to me was Michael Martinez ( mmarti...@getjive.com), he is a member of this list and appears to be a network engineer managing their core network. Hope this helps or if you are still evaluating Jive maybe this experience will help give you an idea of what to expect chris On Thu, Nov 20, 2014 at 9:07 PM, Sean Sinay smsi...@gmail.com wrote: Would also appreciate the clueful contact as I have the same experience with going through the normal support escalation. Primarily interested in the networking folk who are intimately familiar with the Adtran CPE they ship to customers. The 'Engineers' shipped two devices with no gateways configured.. On Sat, Nov 8, 2014 at 11:24 AM, chris tknch...@gmail.com wrote: Thanks to all replies off-list. Contact has been made with all the right people in the right places. It really is amazing to see how active the nanog community is and all the great players involved. Chris On Fri, Nov 7, 2014 at 6:24 PM, chris tknch...@gmail.com wrote: Sorry for the noise but If anyone from Jive Communications is on the list or if anyone has any clueful technical contacts please contact me offlist. I have a very frustrated mutual customer we provide network services to who utilizes Jive for their voice and we can see that there is intermittent reachability problems and all attempts to go through normal support with the information we have provided are going nowhere. Thanks chris
Re: DDOS, IDS, RTBH, and Rate limiting
What happens when someone spoofs legitimate hosts that your customers use? On Thu, Nov 20, 2014 at 3:36 PM, Pavel Odintsov pavel.odint...@gmail.com wrote: Hello, folks! I'm author of fastnetmon, thank you for some PR for my toolkit :) I use this tool for similar type of attacks and we do analyze all traffic from uplinks ports using port mirroring. You can look at this network diagram: https://raw.githubusercontent.com/FastVPSEestiOu/fastnetmon/master/network_map.png I tried to use netflow many years ago but it's not accurate enough and not so fast enough and produce big overhead on middle class network routers. It's because I wrote this tool and do every packet analyze. It can detect attack in 2 seconds max and call BGP blackhole as quick as thought. It can detect three types of attacks: 1) Speed attack for certain IP (we ban every IP which exceed 1 Gbps) 2) Packet per second attack for certain IP (we ban every IP which exceed 100 000 ppps) 3) And flow flood (very useful mode in networks with big bandwidth/pps per client) FastNetMon can handle 2-3 million of packets per second and ~20Gbps on standard i7 2600 Linux box with Intel 82599 NIC. If you need any help or suggestions you can email me directly or ask via GitHub. Thank you! -- Sincerely yours, Pavel Odintsov
Re: Clueful Jive Communications Contact?
Would also appreciate the clueful contact as I have the same experience with going through the normal support escalation. Primarily interested in the networking folk who are intimately familiar with the Adtran CPE they ship to customers. The 'Engineers' shipped two devices with no gateways configured.. On Sat, Nov 8, 2014 at 11:24 AM, chris tknch...@gmail.com wrote: Thanks to all replies off-list. Contact has been made with all the right people in the right places. It really is amazing to see how active the nanog community is and all the great players involved. Chris On Fri, Nov 7, 2014 at 6:24 PM, chris tknch...@gmail.com wrote: Sorry for the noise but If anyone from Jive Communications is on the list or if anyone has any clueful technical contacts please contact me offlist. I have a very frustrated mutual customer we provide network services to who utilizes Jive for their voice and we can see that there is intermittent reachability problems and all attempts to go through normal support with the information we have provided are going nowhere. Thanks chris
Re: DDOS, IDS, RTBH, and Rate limiting
Roland, you seem to have a lot of experience with these kinds of tools. What open-source NetFlow analysis tools would you recommend for quickly detecting a DDoS attack? On Thu, Nov 20, 2014 at 5:12 PM, Roland Dobbins rdobb...@arbor.net wrote: On 21 Nov 2014, at 6:22, Denys Fedoryshchenko wrote: Netflow is stateful stuff, This is factually incorrect; NetFlow flows are unidirectional in nature, and in any event have no effect on processing of data-plane traffic. and just to run it on wirespeed, on hardware, you need to utilise significant part of TCAM, Again, this is factually incorrect. i am not talking that on some hardware it is just impossible to run it. This is also factually incorrect. Some platforms/linecards do not in fact support NetFlow (or other varieties of flow telemetry) due to hardware limitations. And last thing, from one of public papers, netflow delaying factors: 1. Flow record expiration This is tunable. • Typical delay: 15-60 sec. This is an entirely subjective assessment, and does not reflect operational realities. These are typically *maximum values* - and they are well within operationally-useful timeframes. Also, the effect of NetFlow cache size and resultant FIFOing of flow records is not taken into account, nor is the effect on flow termination and flow-record export of TCP FIN or RST flags denoting TCP traffic taken into account. So for a small hosting(up to 10G), i believe, FastNetMon is best solution. This is a gross over-generalization unsupported by facts. Many years of operational experience with NetFlow and other forms of flow telemetry by large numbers of network operators of all sizes and varieties contract this over-generalization. It is generally unwise to make sweeping statements regarding operational impact which are not borne out by significant operational experience in production networks. Faster, and no significant investments to equipment. This statement indicates a lack of understanding of opex costs, irrespective of capex costs. Bigger hosting providers might reuse their existing servers, segment the network, and implement inexpensive monitoring on aggregation switches without any additional cost again. This statement indicates a lack of operational experience in networks of even minimal scale. Ah, and there is one more huge problem with netflow vs FastNetMon - netflow just by design cannot be adapted to run pattern matching, while it is trivial to patch FastNetMon for that, turning it to mini-IDS for free. This statement betrays a lack of understanding of NetFlow-based (and other flow telemetry-based) detection and classification, as well as the undesirability and negative operational impact of stateful IDS/'IPS' deployments in production networks. You should also note that FastNetMon is far from unique; there are multiple other open-source tools which provide the same type of functionality, and none of them have replaced flow telemetry, either. Tools such as FastNetMon supplement flow telemetry, in situations in which such tools can be deployed. They do not begin to replace flow telemetry, and they are not inherently superior to flow telemetry. Again, I'm sure FastNetMon is a useful tool in many circumstances. But it would be a much better idea to define FastNetMon positively in terms of its own inherent value, rather than attempting to define it based upon factually incorrect negative 'comparisons' to other well-established, widely-used technologies which have demonstrable track records within the global operational community. --- Roland Dobbins rdobb...@arbor.net -- Regards, Rob Robert Duffy eSecureData.com Inc. 1478 Hartley Ave. Coquitlam, BC V3K 7A1 T: (800) 620-1985 F: (800) 620-1986 This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal and or privileged information. Please contact the sender immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on the contents herein. Any communication received in error, or subsequent reply, should be deleted or destroyed.
Re: DDOS, IDS, RTBH, and Rate limiting
I've been using NTOP for couple of years. I'm mostly looking for something that can quickly detect DDoS attacks in a datacenter environment. Thanks for the suggestions. Ill check them out. On Thu, Nov 20, 2014 at 6:50 PM, Tim Jackson jackson@gmail.com wrote: I highly recommend pmacct and it's in-memory tables. Lightweight, easy to query and super fast. You can also easily run multiple aggregates of traffic to find what you are interested in, tag common interface types to easily filter traffic.. Or you can use pmacct to insert this into whatever database you want, AMQP or MongoDB.. My current favorite is using an IMT table for DoS detection and another for aggregates for interesting traffic types and querying this every X minutes and inserting it into ElasticSearch. Kibana makes the most powerful netflow dashboard ever. -- Tim On Nov 20, 2014 6:39 PM, Roland Dobbins rdobb...@arbor.net wrote: On 21 Nov 2014, at 9:19, Robert Duffy wrote: What open-source NetFlow analysis tools would you recommend for quickly detecting a DDoS attack? I generally recommend that folks get started with something like nfdump/nfsen or ntop. There are other, more sophisticated tools out there, but these allow one to get up and running quickly, and to gain valuable operational experience with which to evaluate more sophisticated tools, if they're needed. --- Roland Dobbins rdobb...@arbor.net -- Regards, Rob Robert Duffy eSecureData.com Inc. 1478 Hartley Ave. Coquitlam, BC V3K 7A1 T: (800) 620-1985 F: (800) 620-1986 This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal and or privileged information. Please contact the sender immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on the contents herein. Any communication received in error, or subsequent reply, should be deleted or destroyed.
Multi-homing with multiple ASNs
Greetings, We have recently added a second ISP (third if you count I2). Our first ISP is actually a private state network that peers with two Tier 1 providers. We own an AS number and our IP space but at the last minute learned our state network is advertising our network using two different ASNs (neither ours) so they can load balance their connections.If you hit the right looking glass server you can see our network advertised by three different ASNs.We were told by the new ISP that this is a problem but the state network says it is not. Looking for opinions and words of wisdom on this split advertising issue. Thanks curtis Curtis Parish Senior Network Engineer Middle Tennessee State University
Re: DDOS, IDS, RTBH, and Rate limiting
Netflow is stateful stuff, and just to run it on wirespeed, on hardware, you need to utilise significant part of TCAM, Cisco ASRs and MXs with inline jflow can do hundreds of K flows/second without affecting packet forwarding. i am not talking that on some hardware it is just impossible to run it. So everything about netflow are built on assumption that hosting or ISP can run it. And based on some observations, majority of small/middle hosting providers are using minimal,just BGP capable L3 switch as core, and cheapest but reliable L2/L3 on aggregation, and both are capable in best case to run sampled sFlow. Actually, sFlow from many vendors is pretty good (per your points about flow burstiness and delays), and is good enough for dDoS detection. Not for security forensics, or billing at 99.99% accuracy, but good enough for traffic visibility, peering analytics, and (d)DoS detection. snip So for a small hosting(up to 10G), i believe, FastNetMon is best solution. Faster, and no significant investments to equipment. Bigger hosting providers might reuse their existing servers, segment the network, and implement inexpensive monitoring on aggregation switches without any additional cost again. It can be useful to have a 10G network monitoring box of course... And with the right setup you can run FastNetMon or other tools in addition to generating flow that can be of use for other purposes as well... Ah, and there is one more huge problem with netflow vs FastNetMon - netflow just by design cannot be adapted to run pattern matching, while it is trivial to patch FastNetMon for that, turning it to mini-IDS for free. It's true, having a network tap can be useful for doing PCAP-y stuff. But taps can be difficult or at least time consuming for people to put in at scale. Even, we've seen, for folks with 10G networks. Often because they can get 90% of what they need for 4 different business purposes from just flow :) Best regards, Denys Avi Freedman| Your flow has something to show you; can you see it?| CEO, CloudHelix | (avi at cloudhelix dot com) | my name one word on skype |
Re: DDOS, IDS, RTBH, and Rate limiting
WANguard from andrisoft has worked well on this for us. It supports flow telemetry and mirrored ports both (We use flows strictly), and does what it says it does. No complaints. On 11/21/2014 午後 12:00, Robert Duffy wrote: I've been using NTOP for couple of years. I'm mostly looking for something that can quickly detect DDoS attacks in a datacenter environment. Thanks for the suggestions. Ill check them out. On Thu, Nov 20, 2014 at 6:50 PM, Tim Jackson jackson@gmail.com wrote: I highly recommend pmacct and it's in-memory tables. Lightweight, easy to query and super fast. You can also easily run multiple aggregates of traffic to find what you are interested in, tag common interface types to easily filter traffic.. Or you can use pmacct to insert this into whatever database you want, AMQP or MongoDB.. My current favorite is using an IMT table for DoS detection and another for aggregates for interesting traffic types and querying this every X minutes and inserting it into ElasticSearch. Kibana makes the most powerful netflow dashboard ever. -- Tim On Nov 20, 2014 6:39 PM, Roland Dobbins rdobb...@arbor.net wrote: On 21 Nov 2014, at 9:19, Robert Duffy wrote: What open-source NetFlow analysis tools would you recommend for quickly detecting a DDoS attack? I generally recommend that folks get started with something like nfdump/nfsen or ntop. There are other, more sophisticated tools out there, but these allow one to get up and running quickly, and to gain valuable operational experience with which to evaluate more sophisticated tools, if they're needed. --- Roland Dobbins rdobb...@arbor.net
Re: DDOS, IDS, RTBH, and Rate limiting
On 21 Nov 2014, at 12:08, Paul S. wrote: WANguard from andrisoft has worked well on this for us. I believe the thread was focusing on open-source tools. --- Roland Dobbins rdobb...@arbor.net
