RE: Auto ACL blocker
Dionaea (nephentes successor) and Kippo (ssh honeypot) are a good start for the honeypot side. http://carnivore.it/ http://dionaea.carnivore.it/ http://code.google.com/p/kippo/ Watching the tty logs in kippo is great entertainment. Perfect way to collect the skiddies tools. As far as the automation of ACLs if you find a script out in the wild please share. I do know of the following SNORT to Cisco PIX perl script. Hope this helps. http://www.chaotic.org/guardian/ http://www.chaotic.org/guardian/scripts/pix-block.pl Regards, Ruben Guerra -Original Message- From: Brian R. Watters [mailto:brwatt...@absfoc.com] Sent: Tuesday, January 18, 2011 1:12 PM To: nanog@nanog.org Subject: Auto ACL blocker We are looking for the following solution. Honey pot that collects attacks against SSH/FTP and so on Said attacks are then sent to a master ACL on a edge Cisco router to block all traffic from these offenders .. Of course we would require a master whitelist as well as to not be blocked from our own networks. Any current solutions or ideas ?? -- BRW
RE: Level 3 Communications Issues Statement Concerning Comcast's Actions
I'd have to agree with Brian. There is no simple answer to this one... If the ultimate cause is the abuse of bandwidth, I can understand this... BUT if the underlying motive is to squash competition then shame on you! -Original Message- From: Rettke, Brian [mailto:brian.ret...@cableone.biz] Sent: Monday, November 29, 2010 4:41 PM To: Patrick W. Gilmore; NANOG list Subject: RE: Level 3 Communications Issues Statement Concerning Comcast's Actions Essentially, the question is who has to pay for the infrastructure to support the bandwidth requirements of all of these new and booming streaming ventures. I can understand both the side taken by Comcast, and the side of the content provider, but I don't think it's as simple as the slogans spewed out regarding Net Neutrality, which has become so misused and abused as a term that I don't think it has any credulous value remaining. I'm hoping that there is an eventual meeting of the minds wherein some sort of collaboration takes place. If this gets additional government regulations I fear no one will like the result. Sincerely, Brian A . Rettke RHCT, CCDP, CCNP, CCIP Network Engineer, CableONE Internet Services -Original Message- From: Patrick W. Gilmore [mailto:patr...@ianai.net] Sent: Monday, November 29, 2010 3:28 PM To: NANOG list Subject: Level 3 Communications Issues Statement Concerning Comcast's Actions http://www.marketwatch.com/story/level-3-communications-issues-statement-concerning-comcasts-actions-2010-11-29?reflink=MW_news_stmp I understand that politics is off-topic, but this policy affects operational aspects of the 'Net. Just to be clear, L3 is saying content providers should not have to pay to deliver content to broadband providers who have their own product which has content as well. I am certain all the content providers on this list are happy to hear L3's change of heart and will be applying for settlement free peering tomorrow. (L3 wouldn't want other providers to claim the Vyvx or CDN or other content services provided by L3 are competing and L3 is putting up a toll booth on the Internet, would they?) -- TTFN, patrick
RE: 2010.10.06 NANOG50 day 3, Wednesday morning notes
Thanks for the notes Matt! :) -Original Message- From: Matthew Petach [mailto:mpet...@netflight.com] Sent: Wednesday, October 06, 2010 10:54 AM To: nanog@nanog.org Subject: 2010.10.06 NANOG50 day 3, Wednesday morning notes Thanks to everyone for a wonderful conference--this wraps the last of NANOG50--see you all in Miami! Notes from this morning's session are posted at http://kestrel3.netflight.com/2010.10.06-NANOG50-morning-notes.txt sorry about the gaps, I kinda nodded off now and then--only got 2 hours of sleep last night. ^_^;; Apologies for typos, misspellings, etc. Thanks again for a wonderful conference!! :) Matt
RE: Facebook down!! Alert!
Passes Andrew the shotgun... Please kill all FB threads with it. :) The only thing I noticed being down last night is battle.net ;). Guess you know where my priorities are. Lol -Rg -Original Message- From: Andrew Kirch [mailto:trel...@trelane.net] Sent: Wednesday, October 06, 2010 3:39 PM To: nanog@nanog.org Subject: Re: Facebook down!! Alert! On 10/6/2010 4:33 PM, david raistrick wrote: so the majority defines operational now, huh? wow. nice to know that network service providers outnumber other companies these days... (of course, those service providers also make their money from facebook consumers) No, the majority does not define what operational means. Facebook is not a mission critical internet resource (such as a fiber cut, power loss at a peering point, DoS attack. Please let's end this thread (And others of its ilk here and now).
RE: RIP Justification
Tim hit the nail on the head. Maintaining statics on a large network would become a huge problem. Human error will eventually occur. The network scenario I am speaking of is DSL/Cable type setups, where a customer could move from router to router(DSLAM/CMTS) due to capacity re-combines. Utilizing a dynamic routing protocol makes these types of changes easier to digest. Using BGP would be overkill for most. Many small commercial customers to not want the complexity of BGP or want to spend money on extra resources (routers that actually support it) Sure for someone that needs to announce their own space or wants multi-homed connection def use BGP. -Ruben -Original Message- From: Tim Franklin [mailto:t...@pelican.org] Sent: Friday, October 01, 2010 6:19 AM To: nanog@nanog.org Subject: Re: RIP Justification Now, when traffic comes from head office destined for a site prefix, it hits the provider gear. That provider gear will need routing information to head to a particular site. If you wanted to use statics, you will need to fill out a form each time you add/remove a prefix for a site and the provider must manage that. Its called a 'pain in the arse'. Enter RIPv2. Or BGP. Why not?
Re: RIP Justification
I am with Scott on this one.. I took the initial question as a focus on the edge... not the CORE. RIP is perfect for the edge to commercial CPEs. Why would want to run OSPF/ISIS at the edge. I would hope that it would be common practice to not use RIP in the CORE peace -- Ruben Guerra - Sent from my Nokia N900 - Original message - Haha It's all good :) You are right about IS-IS being less resource intensive than OSPF, and that it scales better! On 30 September 2010 23:50, Jack Carrozzo j...@crepinc.commailto:j...@crepinc.com wrote: Both OSPF and IS-IS use Dijkstra. IS-IS isn't as widely used because of the ISO addressing. Atleast thats my take on it.. Sorry, my mistake. I'll go sit in my corner now... -Jack