Re: 128.0.0.0/16 configured as martians in some routers
* Alex Le Heux: The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space. Would someone please clarify the impact? Will it result in a blackhole, or will the entire announcement be suppressed? I suspect the latter, given what we see and what Chris Adams has reported. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Re: 128.0.0.0/16 configured as martians in some routers
On Tuesday, December 06, 2011 04:50:46 PM Florian Weimer wrote: Would someone please clarify the impact? Will it result in a blackhole, or will the entire announcement be suppressed? I suspect the latter, given what we see and what Chris Adams has reported. This is what we see on Cisco IOS and IOS XR boxes: lab#sh ip bgp 128.0.0.0 BGP routing table entry for 128.0.0.0/21, version 260804693 Paths: (2 available, best #1, table default) Advertised to update-groups: 2 3491 3257 1103 12654 61.11.xxx.yy (metric 34400) from 61.11.xxx.zz (61.11.xxx.zz) Origin IGP, metric 0, localpref 100, valid, internal, best Community: 24218:1 Originator: 61.11.xxx.yy, Cluster list: 0.0.0.2 3491 3257 1103 12654 61.11.xxx.yy (metric 34400) from 61.11.xxx.ww (61.11.xxx.ww) Origin IGP, metric 0, localpref 100, valid, internal Community: 24218:1 Originator: 61.11.xxx.yy, Cluster list: 0.0.0.2 lab# RP/0/RSP0/CPU0:lab#sh route 128.0.0.0 Tue Dec 6 17:09:13.439 MYT Routing entry for 128.0.0.0/21 Known via bgp 24218, distance 200, metric 0 Tag 3491, type internal Installed Dec 4 20:00:33.089 for 1d21h Routing Descriptor Blocks 61.11.xxx.yy, from 61.11.yyy.zz Route metric is 0 No advertising protos. RP/0/RSP0/CPU0:lab# This is what we see on an unfixed Juniper: tinka@lab# run show route 128.0.0.0 inet.0: 384214 destinations, 768288 routes (384212 active, 0 holddown, 4 hidden) Restart Complete + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 20w2d 13:21:14 Discard [edit] tinka@lab# tinka@lab# run show route 128.0.0.0/21 inet.0: 384218 destinations, 768296 routes (384216 active, 0 holddown, 4 hidden) Restart Complete [edit] tinka@lab# ti...@edge-gw-1-sin-pip.sg# run show route 128.0.0.0/21 hidden inet.0: 384224 destinations, 768308 routes (384222 active, 0 holddown, 4 hidden) Restart Complete + = Active Route, - = Last Active, * = Both 128.0.0.0/21[BGP/170] 1d 21:17:54, MED 0, localpref 100, from 61.11.xxx.ww AS path: 3491 3257 1103 12654 I to 124.158.xxx.uu via ge-0/0/0.0, Push 16052 to 124.158.xxx.vv via ge-0/0/0.0, Push 16017 to 124.158.xxx.ww via ge-0/1/0.0, Push 16052 to 124.158.xxx.xx via ge-0/1/0.0, Push 16017 [BGP/170] 1d 21:17:54, MED 0, localpref 100, from 61.11.xxx.zz AS path: 3491 3257 1103 12654 I to 124.158.xxx.uu via ge-0/0/0.0, Push 16052 to 124.158.xxx.vv via ge-0/0/0.0, Push 16017 to 124.158.xxx.ww via ge-0/1/0.0, Push 16052 to 124.158.xxx.xx via ge-0/1/0.0, Push 16017 [edit] ti...@edge-gw-1-sin-pip.sg# tinka@lab# run show route 128.0.0.0/21 hidden extensive | match State State: Hidden Martian Int Ext State: Hidden Martian Int Ext [edit] tinka@lab# tinka@lab# run show interfaces terse snip ... fxp1upup fxp1.0 upup inet 10.0.0.1/8 10.0.0.4/8 128.0.0.1/2 128.0.0.4/2 inet6fe80::200:ff:fe00:4/64 fec0::a:0:0:4/64 tnp 0x4 snip ... [edit] tinka@lab# This is what we see on a Cisco router which lives behind an unfixed Juniper router that is peering externally: lab#sh ip bgp 128.0.0.0 % Network not in table lab# So our deduction - if a Juniper router is in the data path, it will blackhole traffic destined to this address. If a Juniper is in the control plane path, it will filter this prefix and not send it to the rest of the network. Either way, you're screwed :-). Cheers, Mark. signature.asc Description: This is a digitally signed message part.
Re: HP IPv6 RA Guard
I think of RA Guard as a Layer-2 stability feature, rather than a security feature. You're correct that it is unable to deal with RA crafted in a fragmented packet on the majority (if not all) of implementations. The issue of rogue RA exists on every network, regardless of whether or not the IT group has deployed IPv6 or is aware of the IPv6 traffic on that network. Windows ICS is the most common accidental cause of rogue RA on a LAN. On Mon, Dec 5, 2011 at 10:35 PM, Daniel Espejel daniel.unam.i...@gmail.com wrote: So,still assuming the fact that attackers will use the same traditional ipv4 methods to alter the correct functioning over a network?...Well, maybe. Toda's IPv6 expertise for some network andmins and security experts is minimal. So most trainning and understanding before implementing its a good idea. For example, the RA-Guard method has a significant vulnerability: It's not designed to identify a complex IPv6-many extension headers formed packet (F. Gont - 6Networks). Some other security oriented mechanisms may fail because of the low IPv6 compliance. Regards. -- Daniel Espejel Pérez Técnico Académico D.G.T.I.C. - U.N.A.M. GT-IPv6 CLARA / GT-IPv6 U.N.A.M. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: On Working Remotely
Beware the office with an Internet connection too: http://xkcd.com/862/ Don't forget to 'mouseover' the graphic. Joe William Herrin b...@herrin.us wrote on 12/05/2011 11:20:04 PM: 3. Beware tracking hours. Try to select work which is goal and deadline based. Your supervisor won't see you in your seat; he can only judge your performance on what you actually accomplish. When I teleworked, I found myself taking breaks to mow the lawn, ride a bike on a nice day or tinker with a personal server. Tracking hours under such circumstances is almost impossibly hard. Measuring progress towards a goal is less so.
New on RIPE Labs: The Curious Case of 128.0/16
Dear colleagues, Related to the discussion about 128.0/16, we did some measurements. The details can be found on RIPE Labs: https://labs.ripe.net/Members/emileaben/the-curious-case-of-128.0-16 Kind regards, Mirjam Kuehne RIPE NCC
Re: New on RIPE Labs: The Curious Case of 128.0/16
Once upon a time, Mirjam Kuehne m...@ripe.net said: Dear colleagues, Related to the discussion about 128.0/16, we did some measurements. The details can be found on RIPE Labs: https://labs.ripe.net/Members/emileaben/the-curious-case-of-128.0-16 Kind regards, Mirjam Kuehne RIPE NCC Using RIPE's traceroute web interface, I can see that Sprint is filtering 128.0.0.0/16: from 128.0.0.1 traceroute to 216.180.54.1 (216.180.54.1), 30 hops max, 40 byte packets 1 gw.nik-guest.nikrtr.ripe.net (193.0.0.234) 0.803 ms 1.005 ms 1.061 ms 2 ams16-core-1.gigabiteth8-1-0.swip.net (195.69.145.139) 0.551 ms 0.466 ms 0.641 ms 3 ams-core-1.tengige0-0-0-6.tele2.net (130.244.49.198) 3.378 ms 3.467 ms 3.624 ms 4 nyc9-core-1.pos8-0-0.tele2.net (130.244.218.214) 76.618 ms 76.683 ms 76.746 ms 5 * * * from 193.0.0.232 traceroute to 216.180.54.1 (216.180.54.1), 30 hops max, 40 byte packets 1 gw.nik-guest.nikrtr.ripe.net (193.0.0.234) 0.466 ms 0.514 ms 0.608 ms 2 ams16-core-1.gigabiteth8-1-0.swip.net (195.69.145.139) 0.684 ms 0.581 ms 0.563 ms 3 ams-core-1.tengige0-0-0-6.tele2.net (130.244.49.198) 3.890 ms 3.919 ms 3.912 ms 4 nyc9-core-1.pos8-0-0.tele2.net (130.244.218.214) 76.292 ms 76.317 ms 76.304 ms 5 144.223.26.73 (144.223.26.73) 76.639 ms 76.475 ms 76.511 ms (and on to my IP) I believe that Sprint is using Cisco, not Juniper. This is either a manual filter or there is another (unidentified) issue with some Cisco configurations. I've opened a ticket with Sprint, although I don't know how far it will go, since I'm getting a MySQL syntax error trying to view the ticket in their web interface (somebody must not understand SQL injection security issues). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: New on RIPE Labs: The Curious Case of 128.0/16
On 12/6/2011 9:38 AM, Chris Adams wrote: I believe that Sprint is using Cisco, not Juniper. This is either a manual filter or there is another (unidentified) issue with some Cisco configurations. People are less likely to read an RFC changing the reserved addresses. Even people who didn't filter unassigned addressing, might filter RFC reserved addressing. The fact that it's built into some routers automatically kind of makes the point. Jack
Mexico City IP/Ethernet/Wave/Fiber/Colo/IXP etc...
I'm looking for connectivity options in the Mexico City area. Initial impressions suggest Mexico has a fairly closed market. That being said: Who offers good IP/BGP connectivity in and around Mexico City?Who offers good Ethernet connectivity in and around Mexico City?Who offers wave/fiber services in and around Mexico City.Where are the colo/IXPs located? Feedback on or off-list appreciated. I'm not looking for a salesman. Thanks, -- Tim:
Re: 128.0.0.0/16 configured as martians in some routers
On 12/6/11 00:50 , Florian Weimer wrote: * Alex Le Heux: The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space. Would someone please clarify the impact? Will it result in a blackhole, or will the entire announcement be suppressed? I suspect the latter, given what we see and what Chris Adams has reported. http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/routing-configuring-martian-addresses.html
Writable SNMP
For a few years now I been wondering why more networks do not use writable SNMP. Most automation solutions actually script a login to the various equipment. This comes with extra code for different vendors, different prompts and any quirk that the developer is aware of and constant patches as new ones come up. Writable SNMP seems like an easier way to deal with scripted configuration changes as well as information gathering. Admittedly, you will have to deal with proprietary mibs and reformat the data once it's returned. Most people consider it insecure, but in reality it's no worse than any other management protocol. Yes I know netconf is better, but in most circles I'd have problems explaining what netconf is, why it's better and that I'm not making it up. So I'll take what I can get.
Re: Writable SNMP
On Dec 6, 2011, at 11:07 AM, Keegan Holley wrote: For a few years now I been wondering why more networks do not use writable SNMP. Most automation solutions actually script a login to the various equipment. This comes with extra code for different vendors, different prompts and any quirk that the developer is aware of and constant patches as new ones come up. Writable SNMP seems like an easier way to deal with scripted configuration changes as well as information gathering. Admittedly, you will have to deal with proprietary mibs and reformat the data once it's returned. Most people consider it insecure, but in reality it's no worse than any other management protocol. Yes I know netconf is better, but in most circles I'd have problems explaining what netconf is, why it's better and that I'm not making it up. So I'll take what I can get. Some of the problems is the bulk nature of some config changes (or transactional nature on those that support atomic operations) have been harder to automate. Anyone that has spent any quantity of time with ASN.1 generally would agree. I recall some bay networks gear you could only program with the proper OID as the cli was basically a SNMP-SET operation on the device. The errors/feedback tends to be very poor over SNMP as well as you may need to walk/revisit a large number of elements to make things happen properly. Have you had a good experience with using SNMP-Write? I have not. - Jared
Re: Writable SNMP
On Tue, Dec 6, 2011 at 11:16 AM, Jared Mauch ja...@puck.nether.net wrote: On Dec 6, 2011, at 11:07 AM, Keegan Holley wrote: For a few years now I been wondering why more networks do not use writable SNMP. Most automation solutions actually script a login to the various equipment. This comes with extra code for different vendors, different prompts and any quirk that the developer is aware of and constant patches as new ones come up. Writable SNMP seems like an easier way to deal with scripted configuration changes as well as information gathering. Admittedly, you will have to deal with proprietary mibs and reformat the data once it's returned. Most people consider it insecure, but in reality it's no worse than any other management protocol. Yes I know netconf is better, but in most circles I'd have problems explaining what netconf is, why it's better and that I'm not making it up. So I'll take what I can get. Some of the problems is the bulk nature of some config changes (or transactional nature on those that support atomic operations) have been harder to automate. Anyone that has spent any quantity of time with ASN.1 generally would agree. I recall some bay networks gear you could only program with the proper OID as the cli was basically a SNMP-SET operation on the device. yea... same with cascade devices... icky things (both bay and cascade!) The errors/feedback tends to be very poor over SNMP as well as you may need to walk/revisit a large number of elements to make things happen properly. fun story/fact, you can send an snmp write to the broadcast address of a network of NT (at least, probably also post-nt versions of the OS) machines, and set their default-ttl to some arbitrary number. Your network is too chatty... not anymore! now your internet is 5 hops across! Have you had a good experience with using SNMP-Write? I have not. long ago, in a network far away (not on the interwebs) we used snmp write to trigger a tftp config load. It worked nicely... I'm fairly certain I'd not do this on an internet connected network today though. Also, who tests snmp WRITE in their code? at scale? for daily operations tasks? ... (didn't the snmp incident in 2002 teach us something?) -chris
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
On Mon, 05 Dec 2011 22:14:48 PST, andrew.wallace said: Using fruitful language and acting like a child isn't going to see you taken seriously. No, he *does* want fruitful language - one that produces results. I think you meant some other word instead. As far as acting like a child, I'm reasonably sure that if CNet was doing the same thing to the good name of your consulting company, you'd react similarly. - Forwarded message from Fyodor fyo...@insecure.org On the other hand, just being Fyodor is sufficient to get him taken seriously. pgp8hMOapTAam.pgp Description: PGP signature
RE: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
Not that anyone cares but personally, I'm happy fyodor posted this and I'm forwarding it to anyone that I think might use download.com. I think it's crap anyone changes anyone's code like that -Original Message- From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Sent: Tuesday, December 06, 2011 11:48 AM To: andrew.wallace Cc: fyo...@insecure.org; nanog@nanog.org Subject: Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] On Mon, 05 Dec 2011 22:14:48 PST, andrew.wallace said: Using fruitful language and acting like a child isn't going to see you taken seriously. No, he *does* want fruitful language - one that produces results. I think you meant some other word instead. As far as acting like a child, I'm reasonably sure that if CNet was doing the same thing to the good name of your consulting company, you'd react similarly. - Forwarded message from Fyodor fyo...@insecure.org On the other hand, just being Fyodor is sufficient to get him taken seriously.
RE: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmapwith malware!]
Maybe it's just me, but I would think that simply getting them listed on stopbadware.org and other similar sites would probably have much more of an effect. The bad publicity can cause them to change tactics, but it takes some time. I've seen much quicker results from blacklisting on Google and other search engines. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 -Original Message- From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Sent: Tuesday, December 06, 2011 11:48 AM To: andrew.wallace Cc: fyo...@insecure.org; nanog@nanog.org Subject: Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmapwith malware!] On Mon, 05 Dec 2011 22:14:48 PST, andrew.wallace said: Using fruitful language and acting like a child isn't going to see you taken seriously. No, he *does* want fruitful language - one that produces results. I think you meant some other word instead. As far as acting like a child, I'm reasonably sure that if CNet was doing the same thing to the good name of your consulting company, you'd react similarly. - Forwarded message from Fyodor fyo...@insecure.org On the other hand, just being Fyodor is sufficient to get him taken seriously.
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmapwith malware!]
http://krebsonsecurity.com/2011/12/download-com-bundling-toolbars-trojans/ Its already getting some press... He could always send them a Cease and Desist letter like Wireshark had to do -Kyle On Tue, Dec 6, 2011 at 9:00 AM, Eric Tykwinski eric-l...@truenet.comwrote: Maybe it's just me, but I would think that simply getting them listed on stopbadware.org and other similar sites would probably have much more of an effect. The bad publicity can cause them to change tactics, but it takes some time. I've seen much quicker results from blacklisting on Google and other search engines. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 -Original Message- From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Sent: Tuesday, December 06, 2011 11:48 AM To: andrew.wallace Cc: fyo...@insecure.org; nanog@nanog.org Subject: Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmapwith malware!] On Mon, 05 Dec 2011 22:14:48 PST, andrew.wallace said: Using fruitful language and acting like a child isn't going to see you taken seriously. No, he *does* want fruitful language - one that produces results. I think you meant some other word instead. As far as acting like a child, I'm reasonably sure that if CNet was doing the same thing to the good name of your consulting company, you'd react similarly. - Forwarded message from Fyodor fyo...@insecure.org On the other hand, just being Fyodor is sufficient to get him taken seriously.
Re: Writable SNMP
On Dec 6, 2011, at 11:28 AM, Christopher Morrow wrote: long ago, in a network far away (not on the interwebs) we used snmp write to trigger a tftp config load. It worked nicely... I'm fairly certain I'd not do this on an internet connected network today though. Many vendors have poor TFTP implementations, such that any additional latency creates very slow transfer rates. This is why things like the RCPD were done, and others use FTP/HTTP even. I am not sure if you can tell it to trigger some protocol other than TFTP in IOS. As someone who has moved large configs around in the past (1-16MB in cases) transfer speeds do matter. Also, who tests snmp WRITE in their code? at scale? for daily operations tasks? ... (didn't the snmp incident in 2002 teach us something?) This is also a whole other interesting problem. Part of it is lack of exposure to it. Part of it is ease of operation. Many people still telnet over when they should use ssh. (feedback is more immediate if you are not in the VTY ACL for example). People revert to what they are comfortable with. Some it's scripts, others its typing configure or conf t and hitting ? a lot. There's no reason one can't program a device with SNMP, the main issue IMHO has always been what I dubbed config drift. You have your desired configuration and variances that happen over time. If you don't force a 'wr mem' or similar event after you trigger a 'copy tftp run' operation, you may have troubles that are not apparent if there is a power failure or other lossage. The boot-time parser doesn't interpret SNMP, it parses text. This and other reasons have made people fail-safe to using the language most easily interpreted by the device. - Jared
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmapwith malware!]
On 12/6/11 12:00 PM, Eric Tykwinski wrote: Maybe it's just me, but I would think that simply getting them listed on stopbadware.org and other similar sites would probably have much more of an effect. The bad publicity can cause them to change tactics, but it takes some time. I've seen much quicker results from blacklisting on Google and other search engines. I've reported it as a malware site via Firefox. Have you? But the whole site should be scanned for other/similar malware, and blocked accordingly. Probably a harder problem, as it gives different downloads depending on browser and OS.
Re: Writable SNMP
On Tue, 6 Dec 2011, Jared Mauch wrote: I recall some bay networks gear you could only program with the proper OID as the cli was basically a SNMP-SET operation on the device. The mere mention of Bay Networks and Site Manager (read: Site Mangler or Site Damager) is enough to get my blood pressure up a few points, and I haven't touched that stuff since probably 1999 or 2000. The CLI was quite horrible, and their somewhat IOS-like command shell (BCC) was not much better. Have you had a good experience with using SNMP-Write? I have not. The most I've done using SNMP SETs is backed up configurations from network devices at my old job. That part worked (and works) very well, but I never tried pushing config changes out to devices that way. jms
Re: Writable SNMP
On Tue, Dec 06, 2011 at 12:15:35PM -0500, Mauch, Jared wrote: Also, who tests snmp WRITE in their code? at scale? for daily operations tasks? ... (didn't the snmp incident in 2002 teach us something?) There's no reason one can't program a device with SNMP, the main issue IMHO There is one good reason. Every vendor seem to assign a junior intern to maintanining SNMP code, so you are interfacing with your router via a very suspect interface. -dorian
RE: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
-Original Message- From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] - Forwarded message from Fyodor fyo...@insecure.org On the other hand, just being Fyodor is sufficient to get him taken seriously. --- bka...@ford.com wrote: --- From: Kain, Rebecca (.) bka...@ford.com Not that anyone cares but personally, I'm happy fyodor posted this and I'm forwarding it to anyone that I think might use download.com. I think it's crap anyone changes anyone's code like that --- I used to use download.com a lot. I trusted them. I told friends they were trustworthy. What Valdis said. That's all it took for me to stop using them and to tell everyone I know to stop. Hope someone at download.com is listening. scott
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmapwith malware!]
On Dec 6, 2011, at 12:34 31PM, William Allen Simpson wrote: On 12/6/11 12:00 PM, Eric Tykwinski wrote: Maybe it's just me, but I would think that simply getting them listed on stopbadware.org and other similar sites would probably have much more of an effect. The bad publicity can cause them to change tactics, but it takes some time. I've seen much quicker results from blacklisting on Google and other search engines. I've reported it as a malware site via Firefox. Have you? But the whole site should be scanned for other/similar malware, and blocked accordingly. Probably a harder problem, as it gives different downloads depending on browser and OS. Per the Krebs on Security link that Kyle just posted (and beat me to it), the installer is already flagged as malware by a number of different scanners. --Steve Bellovin, https://www.cs.columbia.edu/~smb
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
On Tue, Dec 6, 2011 at 4:48 PM, valdis.kletni...@vt.edu wrote: On the other hand, just being Fyodor is sufficient to get him taken seriously. It could be argued that Nmap is malware, and such software has already been called to be made illegal. If I was Cnet, I would stop distributing his software altogether. Link: http://nmap.org/book/legal-issues.html Andrew
Re: Writable SNMP
Yes, Site Mangler. Do not stir that nest. Thar be dragons. -Blake On Tue, Dec 6, 2011 at 11:35, Justin M. Streiner strei...@cluebyfour.orgwrote: On Tue, 6 Dec 2011, Jared Mauch wrote: I recall some bay networks gear you could only program with the proper OID as the cli was basically a SNMP-SET operation on the device. The mere mention of Bay Networks and Site Manager (read: Site Mangler or Site Damager) is enough to get my blood pressure up a few points, and I haven't touched that stuff since probably 1999 or 2000. The CLI was quite horrible, and their somewhat IOS-like command shell (BCC) was not much better. Have you had a good experience with using SNMP-Write? I have not. The most I've done using SNMP SETs is backed up configurations from network devices at my old job. That part worked (and works) very well, but I never tried pushing config changes out to devices that way. jms
RE: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
It could be argued that Nmap is malware, and such software has already been called to be made illegal. If I was Cnet, I would stop distributing his software altogether. Link: http://nmap.org/book/legal-issues.html It could. But making such an argument calls the arguer's grasp of reality into question. Nmap is a tool, like any other. It has no more ethical value than a nail gun or a hammer. In the hands of an engineer, it is a valuable addition to a toolkit. In the hands of an attacker, it can become a weapon. If it could be argued that Nmap is malware, then it could be argued that hammers are weapons; therefore, we should call on Home Depot to stop carrying these deadly instruments with all due alacrity - or at least have governments step in and create licensing programs for hand tools. Nathan Eisenberg
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
On Dec 6, 2011, at 10:30 AM, andrew.wallace wrote: On Tue, Dec 6, 2011 at 4:48 PM, valdis.kletni...@vt.edu wrote: On the other hand, just being Fyodor is sufficient to get him taken seriously. It could be argued that Nmap is malware, and such software has already been called to be made illegal. If I was Cnet, I would stop distributing his software altogether. Link: http://nmap.org/book/legal-issues.html Andrew That's a stretch. Malware generally, IMHO, means software which does something other than what it claims to do. I don't believe that nmap does anything other than what it claims. I understand you may not like the idea of having such a tool available to users of your network. Personally, I'd rather that the users had access to such a tool than live without it myself. Kind of a double-edged sword, I know, but, nmap is a tool. In and of itself, neither bad nor good. Malice is in the intent of the user. This distinguishes it from malware in that with malware, malice is in the intent of the author and not the user. Malware, once installed, does what its author wants it to do regardless of the intent of the user. Sure, you can do things with nmap that are at best antisocial and at worst potentially illegal. I can do things with a Bowie Knife that are as well. However, used properly in the right context, both can be very useful tools. I don't think we should outlaw either one. Then again, I'm rather liberal in that regard. I believe that we should not ban something if it has both legitimate and nefarious uses, but, rather, should only ban those things which pose a public hazard and have no legitimate use. I suspect that he would rather Cnet stop distributing his software altogether than do what they are doing. I appreciate the warning and have stopped using CNET as a result. Owen
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
I'm pretty sure nmap is the exact opposite of Malware. It's an essential information security tool. Fyodor, Reach out to the Free Software Foundation and EFF. They may not be able to help directly, but I'm sure that they could put you in touch with some pro bono legal experts that could give you the right advice on how to act. As mentioned, both Lessig, and Eben Moglen, would be good starting points. On Tue, Dec 6, 2011 at 1:30 PM, andrew.wallace andrew.wall...@rocketmail.com wrote: On Tue, Dec 6, 2011 at 4:48 PM, valdis.kletni...@vt.edu wrote: On the other hand, just being Fyodor is sufficient to get him taken seriously. It could be argued that Nmap is malware, and such software has already been called to be made illegal. If I was Cnet, I would stop distributing his software altogether. Link: http://nmap.org/book/legal-issues.html Andrew -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
RE: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
Having seen the previous owner of my house's cabinet building skills, and living with them, I'm all for licensing! -Original Message- From: Nathan Eisenberg [mailto:nat...@atlasnetworks.us] Sent: Tuesday, December 06, 2011 1:55 PM To: nanog@nanog.org Subject: RE: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] It could be argued that Nmap is malware, and such software has already been called to be made illegal. If I was Cnet, I would stop distributing his software altogether. Link: http://nmap.org/book/legal-issues.html It could. But making such an argument calls the arguer's grasp of reality into question. Nmap is a tool, like any other. It has no more ethical value than a nail gun or a hammer. In the hands of an engineer, it is a valuable addition to a toolkit. In the hands of an attacker, it can become a weapon. If it could be argued that Nmap is malware, then it could be argued that hammers are weapons; therefore, we should call on Home Depot to stop carrying these deadly instruments with all due alacrity - or at least have governments step in and create licensing programs for hand tools. Nathan Eisenberg
Re: New on RIPE Labs: The Curious Case of 128.0/16
On Tue, Dec 06, 2011 at 09:38:31AM -0600, Chris Adams wrote: Using RIPE's traceroute web interface, I can see that Sprint is filtering 128.0.0.0/16: I believe that Sprint is using Cisco, not Juniper. This is either a manual filter or there is another (unidentified) issue with some Cisco configurations. I've been getting spam from NTT for several days in that range; a Sprint-based traceroute: 2 sl-gw28-nyc-15-1-3-28-ts0.sprintlink.net (160.81.237.61) 10.880 ms 10.604 ms 9.359 ms 3 sl-crs1-nyc-0-6-3-0.sprintlink.net (144.232.3.188) 10.345 ms 10.559 ms 11.802 ms 4 144.232.4.87 (144.232.4.87) 9.178 ms 7.928 ms 144.232.4.91 (144.232.4.91) 9.304 ms 5 xe-0-2-0-2.r06.nycmny01.us.bb.gin.ntt.net (129.250.8.73) 8.841 ms 9.977 ms 7.947 ms 6 ae-2.r22.nycmny01.us.bb.gin.ntt.net (129.250.4.174) 11.497 ms 10.610 ms 11.682 ms 7 ae-4.r21.sttlwa01.us.bb.gin.ntt.net (129.250.2.51) 85.541 ms 86.744 ms 84.994 ms 8 ae-0.r20.sttlwa01.us.bb.gin.ntt.net (129.250.2.53) 88.498 ms 87.313 ms 88.387 ms 9 ae-3.r20.snjsca04.us.bb.gin.ntt.net (129.250.3.53) 95.862 ms 96.692 ms 96.558 ms 10 ae-2.r20.mlpsca01.us.bb.gin.ntt.net (129.250.5.6) 97.193 ms 96.742 ms 97.046 ms 11 * * * 12 ae-0.r01.mlpsca01.us.wh.verio.net (129.250.26.170) 98.053 ms 97.402 ms 95.332 ms 13 ge-26.a0410i.mlpsca01.us.wh.verio.net (204.202.1.226) 99.151 ms 99.001 ms 96.926 ms 14 ca1-lam00092.vwh.net (192.217.122.217) 95.274 ms 97.104 ms 96.247 ms 15 arnmarkt.org (128.121.86.33) 90.872 ms 91.109 ms 91.995 ms -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York
vrf address familiy upgrade
I was wondering if anyone has had experience with the vrf cli upgrade command that upgrades an existing V4 only VRf to a multi-protocol vrf? command: (config)# vrf upgrade-cli multi-af-mode My issue is that it fails to upgrade the my, one of the pre-requisites is that the vrf must exist, it does?? thanx as always, Mike
Re: Writable SNMP
On Tue, Dec 6, 2011 at 11:07 AM, Keegan Holley keegan.hol...@sungard.com wrote: For a few years now I been wondering why more networks do not use writable SNMP. Most automation solutions actually script a login to the various I've spent enough time writing code to deal with SNMP (our own stack, not using Net-SNMP or friends) to have a more in-depth understanding of SNMP's pitfalls than most people. It is TERRIBLE and should be totally gutted and replaced with something more sane, less likely to have bugs, etc. There is a good reason why many major bugs have popped up over the years allowing devices to be crashed with crafted SNMP packets -- it's honestly not that easy to get right, especially if you really implement every possible encoding so some random customer with a brain-damaged SNMP client stack won't come crying to you that his client won't work. Juniper does not support writing via SNMP. I am glad. Hopefully that is the first step toward not supporting SNMP at all. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: get IP address on login
- Original Message - From: Bob Rasmussen r...@anzio.com On my OSR5 test system, I see SSH_CLIENT and SSH_CONNECTION set in the environment upon login. Does that help? These are set by the SSH daemon, only if you're running an SSH connection. If you're not, you should be :-) Well, on a disconnected internal system, telnet's probably ok; there's a way to get it in telnet as well, but you have to do some guessing. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
GPON Vendors
Hello NANOG, Due to unforeseen circumstances we need to consider alternative vendors for our GPON system, moving away from Motorola. We wanted to throw out a line and find out what other networks have deployed and what experiences they have had positive or negative with them. Thanks in advance for any replies. Josh Hoppes Network Engineer Cedar Falls Utilities
Re: Writable SNMP
On Tue, 6 Dec 2011, Jeff Wheeler wrote: On Tue, Dec 6, 2011 at 11:07 AM, Keegan Holley keegan.hol...@sungard.com wrote: For a few years now I been wondering why more networks do not use writable SNMP. Most automation solutions actually script a login to the various ... Juniper does not support writing via SNMP. I am glad. Hopefully that is the first step toward not supporting SNMP at all. So what are the alternatives these days then for automation or batch operations? clogin etc from shrubbery's rancid? Net::Appliance::Session ... ? . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263.
Re: Writable SNMP
On Tue, Dec 6, 2011 at 12:15 PM, Jared Mauch ja...@puck.nether.net wrote: On Dec 6, 2011, at 11:28 AM, Christopher Morrow wrote: long ago, in a network far away (not on the interwebs) we used snmp write to trigger a tftp config load. It worked nicely... I'm fairly certain I'd not do this on an internet connected network today though. Many vendors have poor TFTP implementations, such that any additional latency creates very slow transfer rates. This is why things like the RCPD were done, and others use FTP/HTTP even. I am not sure if you can tell it to trigger some protocol other than TFTP in IOS. agreed, I did say 'long time ago' :) (like before 2000 long time ago) I get the impression we could have said copy http:// instead of tftp though. (if it were supported at the time, http I mean) As someone who has moved large configs around in the past (1-16MB in cases) transfer speeds do matter. agreed Also, who tests snmp WRITE in their code? at scale? for daily operations tasks? ... (didn't the snmp incident in 2002 teach us something?) This is also a whole other interesting problem. Part of it is lack of exposure to it. Part of it is ease of operation. Many people still telnet over when they should use ssh. (feedback is more immediate if you are not in the VTY ACL for example). People revert to what they are comfortable with. Some it's scripts, others its typing configure or conf t and hitting ? a lot. There's no reason one can't program a device with SNMP, the main issue IMHO has always been what I dubbed config drift. You have your desired configuration and variances that happen over time. If you don't force a 'wr mem' or similar event after you trigger a 'copy tftp run' operation, you may have troubles that are not apparent if there is a power failure or other lossage. The boot-time parser doesn't interpret SNMP, it parses text. This and other reasons have made people fail-safe to using the language most easily interpreted by the device. Yup, I think the OP was maybe getting at: Why can't I snmp configure my cisco/juniper/alteon device? I took that to mean (probably naively?) that they also would validate configs and update drift out of the configuration. You CAN force a 'wr mem' via snmp as well, of course (in cisco world).
Re: Writable SNMP
On Tue, Dec 6, 2011 at 11:49 AM, Keegan Holley keegan.hol...@sungard.com wrote: 2011/12/6 Christopher Morrow morrowc.li...@gmail.com On Tue, Dec 6, 2011 at 11:16 AM, Jared Mauch ja...@puck.nether.net wrote: On Dec 6, 2011, at 11:07 AM, Keegan Holley wrote: For a few years now I been wondering why more networks do not use writable SNMP. Most automation solutions actually script a login to the various equipment. This comes with extra code for different vendors, different prompts and any quirk that the developer is aware of and constant patches as new ones come up. Writable SNMP seems like an easier way to deal with scripted configuration changes as well as information gathering. Admittedly, you will have to deal with proprietary mibs and reformat the data once it's returned. Most people consider it insecure, but in reality it's no worse than any other management protocol. Yes I know netconf is better, but in most circles I'd have problems explaining what netconf is, why it's better and that I'm not making it up. So I'll take what I can get. Some of the problems is the bulk nature of some config changes (or transactional nature on those that support atomic operations) have been harder to automate. Anyone that has spent any quantity of time with ASN.1 generally would agree. I recall some bay networks gear you could only program with the proper OID as the cli was basically a SNMP-SET operation on the device. yea... same with cascade devices... icky things (both bay and cascade!) The errors/feedback tends to be very poor over SNMP as well as you may need to walk/revisit a large number of elements to make things happen properly. fun story/fact, you can send an snmp write to the broadcast address of a network of NT (at least, probably also post-nt versions of the OS) machines, and set their default-ttl to some arbitrary number. Your network is too chatty... not anymore! now your internet is 5 hops across! Let's leave the legacy boxes out of this. Remember that SNMP bug that could keel over a cisco router? I forget the details other than the guy who wrote c code at black hat to kill routers after cisco refused to patch. Have you had a good experience with using SNMP-Write? I have not. long ago, in a network far away (not on the interwebs) we used snmp write to trigger a tftp config load. It worked nicely... I'm fairly certain I'd not do this on an internet connected network today though. I can see the other comments about interactive commands and bulk read/writes, but what's the harm of doing it on internet connected boxes vs. non-internet boxes. Just about everyone uses snmp reads in the interwebs I think the general feeling is that snmp is udp so it's spoofable and your perimeter acls will never be 100% (or rather, are you willing to risk them not being 100%?) and as such filters it at their edges and hopefully on each platform. You'd secure it the same way you'd secure readable SNMP I assume. read is 'painful', write can be downright deadly (to your SLAs). Also, who tests snmp WRITE in their code? at scale? for daily operations tasks? lol, that could be a problem. yea, I bet the number of people that test, at scale/operations-pace, snmp WRITE is countable on a single hand. ... (didn't the snmp incident in 2002 teach us something?) Please elaborate. http://www.cisco.com/warp/public/707/cisco-sa-20010227-ios-snmp-ilmi.shtml oh, 2001... memory lag :(
Re: Writable SNMP
On Tue, Dec 6, 2011 at 12:39 PM, Dorian Kim dor...@blackrose.org wrote: On Tue, Dec 06, 2011 at 12:15:35PM -0500, Mauch, Jared wrote: Also, who tests snmp WRITE in their code? at scale? for daily operations tasks? ... (didn't the snmp incident in 2002 teach us something?) There's no reason one can't program a device with SNMP, the main issue IMHO There is one good reason. Every vendor seem to assign a junior intern to maintanining SNMP code, so you are interfacing with your router via a very suspect interface. this is exactly my 'testing' commment... and you thought bgp bugs were painful :)
Re: Writable SNMP
On Tue, Dec 6, 2011 at 2:56 PM, Jethro R Binks jethro.bi...@strath.ac.uk wrote: So what are the alternatives these days then for automation or batch operations? clogin etc from shrubbery's rancid? Net::Appliance::Session netconf!
Re: Writable SNMP
In a message written on Tue, Dec 06, 2011 at 11:16:02AM -0500, Jared Mauch wrote: Anyone that has spent any quantity of time with ASN.1 generally would agree. SNMP has two fatal flaws for large scale write based configuration. ASN.1 was basically obsolete before it was written. It was designed to be a compact data transfer format in the days of 56k lines, and is nothing but annoying in practice. Hard to write, hard to debug, hard to understand to save a little bandwidth which no longer matters. (Note, there is apparently an XML version of ASN.1 which may or may not make things better, but I have never seen a single bit of gear anywhere that implemented it.) But then on top of ASN.1, the transaction model is all wrong. No way to group writes together (e.g. commit a series of changes at once). One RTT incurred for each write/read-back (for verification, since it's UDP). If you try and configure a device with SNMP over a 500ms link it might take longer than the lifespan of the gear! :) Jared also makes a good point about the device not reading SNMP on boot, it reads a text file, and being able to alter that directly makes more sense. Lastly, let's not forget that at most vendors SNMP seems to be a low priority item. How many years was it after we had IPv6 BGP before there was an IPv6 BGP MIB actually implemented? I actually would submit SNMP was never the right tool for the job, just the tool we had. Even today where it's most popular use is to poll interfaces for statistics it would be easier on the device, programmer, and operator to make one tcp connection, send a list of things to poll, and get back a blob of text. I hesitate to say XML + Restful, becuse I think it need not be that specific solution, but that is a solution that meets the criteria. The only thing SNMP has going for it at this point in time is inertia. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpBA6toPALUf.pgp Description: PGP signature
Re: Writable SNMP
From: Jeff Wheeler j...@inconcepts.biz Juniper does not support writing via SNMP. I am glad. Hopefully that is the first step toward not supporting SNMP at all. If I recall correctly, wasn't the old FORE CLI implemented via localhost SNMP? I liked using them, but that's a special case... David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: Writable SNMP
What SNMP does have for it is it is lightweight (to some extent) vs XML that can get quite bulky, and certainly is the case when trying to do many interfaces at once. I have seen better precision with snmp vs cli interaction/tcp based interaction. snmpbulkwalk has been my cruel mistress for several years... But does provide the detail/accuracy most days. Also keep in mind most hardware only pulls or pushes counters every 5s anyways... Jared Mauch On Dec 6, 2011, at 2:13 PM, Leo Bicknell bickn...@ufp.org wrote: I actually would submit SNMP was never the right tool for the job, just the tool we had. Even today where it's most popular use is to poll interfaces for statistics it would be easier on the device, programmer, and operator to make one tcp connection, send a list of things to poll, and get back a blob of text. I hesitate to say XML + Restful, becuse I think it need not be that specific solution, but that is a solution that meets the criteria. The only thing SNMP has going for it at this point in time is inertia.
CMDB on the cheap...
Any recommendations for CMDB software on the cheap? Building out nodes at a few commercial co-los and a number of non-commercial (member) spaces. thanks, brian -- Brian Stengel KINBER Director of Operations bsten...@kinber.org M: 412.398.2333 GV: 412.254.3481 Skype: brian_stengel KINBER - Keystone Initiative for Network Based Education and Research - www.kinber.org PennREN - Pennsylvania's Research and Education Network
RE: Flapping POS Interface on Frame-relay between a Juniper and Cisco
Did Jeff's suggestion work? : interface POS0/0/0 : frame-relay intf-type dce If so, please let the list know, so when someone comes across this thread while searching for the fix they can figure it out without having to email the list. If it didn't help contact me off-line and I will be happy to troubleshoot it with you. scott From: Righa Shake [righa.sh...@gmail.com] Sent: Saturday, November 19, 2011 11:11 AM To: af...@afnog.org Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco Hi, Am having a problem that is buffling. I recently changed a POS link encapsulation from PPP to Frame-relay. Since that time the POS interface keeps resetting from time to time. On my BGP session am receiving cease notifications from my upstream provider. The setup is such that we have a cisco on one end and a Juniper on the other. interface POS0/0/0 mtu 4474 no ip address no ip unreachables encapsulation frame-relay logging event link-status crc 32 pos scramble-atm frame-relay lmi-type ansi end ROUTERshow run int pos0/0/0.101 Building configuration... ! interface POS0/0/0.101 point-to-point ip address X.X.X.X 255.255.255.252 frame-relay interface-dlci 101 end ROUTER#show int pos0/0/0 POS0/0/0 is up, line protocol is up Hardware is SPA-2XOC12-POS MTU 4474 bytes, BW 622000 Kbit/sec, DLY 100 usec, reliability 255/255, txload 6/255, rxload 38/255 Encapsulation FRAME-RELAY, crc 32, loopback not set Keepalive set (10 sec) Scramble enabled LMI enq sent 81981, LMI stat recvd 77480, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE segmentation inactive FR SVC disabled, LAPF state down Broadcast queue 0/256, broadcasts sent/dropped 26/0, interface broadcasts 0 Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters 1w2d Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 94336000 bits/sec, 13151 packets/sec 5 minute output rate 1647 bits/sec, 7049 packets/sec 12211574207 packets input, 10967607038364 bytes, 0 no buffer Received 0 broadcasts (0 IP multicasts) 6970870 runts, 2179 giants, 0 throttles 0 parity 892493293 input errors, 882184781 CRC, 0 frame, 0 overrun, 0 ignored, 3335463 abort 6379191154 packets output, 1614018181446 bytes, 0 underruns 0 output errors, 0 applique, 4 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions Any assistance on this will be greatly appreciated. --- js...@briworks.com wrote: From: Jeff Saxe js...@briworks.com I believe this is the explanation for your flapping: a PPP link is intended to go between two routers over, for instance, a private leased line, so both of the devices are peers, neither one particularly special. Frame-relay, by contrast, was originally designed so that your router was an end user device and its directly-connected partner device was not your other router, which you control, but the frame carrier's frame-relay switch. Your router was a DTE device, and their switch, which was in a more important position in control of the frame-relay NBMA cloud, was the DCE device. Your router then slaved to the frame switch via LMI signaling, so that the upstream switch instructed you which DLCIs existed and were up at the moment. So if you connect up two routers with frame-relay encap and each thinks it is the DTE, and neither one is taking the role of the frame switch, then when you bring them up, they will initially optimistically think their DLCIs are up and working, and the routing protocol and traffic will come up... but both of them will be waiting for the frame switch to send them LMI indicating that their idea of the DLCI up/down status is correct. When a couple minutes go by and they don't hear the responses to their LMI enquiries, they will bring all the DLCI's down. I thought they would then stay down forever, i.e., not flap, but maybe you are shutting / no shutting the POS circuit to try again. Anyway, I believe the very simple fix is interface POS0/0/0 frame-relay intf-type dce So this will turn your Cisco side of the circuit into DCE mode, and if the Juniper side stays in DTE mode (the default, so probably not listed in the config), then the LMI should start behaving between the two. And yes, as Jay Hennigan suggested, you might need to use encap frame-relay ietf to be compatible with non-Cisco gear, or you might need to adjust the frame-relay lmi-type -- one type sends the LMI on DLCI number 0, one of them on DLCI 1023, whatever. I think you'll need to adjust the two ends until you see LMI enquiries both sent and received; right now the show interface from the Cisco
Re: Flapping POS Interface on Frame-relay between a Juniper and Cisco
Internet Edge and Defense in Depth
Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the defense in depth concept. Is anyone collapsing all Internet edge functions into one device? Regards, David This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
Re: CMDB on the cheap...
Everyone I know has either paid through the nose or written one from scratch. No good open source projects that worked out. Most people couldn't build well from scratch. I have been a couple of places that did, it was man-year of senior grade guy effort range. On Tue, Dec 6, 2011 at 1:01 PM, Brian Stengel bsten...@kinber.org wrote: Any recommendations for CMDB software on the cheap? Building out nodes at a few commercial co-los and a number of non-commercial (member) spaces. thanks, brian -- Brian Stengel KINBER Director of Operations bsten...@kinber.org M: 412.398.2333 GV: 412.254.3481 Skype: brian_stengel KINBER - Keystone Initiative for Network Based Education and Research - www.kinber.org PennREN - Pennsylvania's Research and Education Network -- -george william herbert george.herb...@gmail.com
Re: Flapping POS Interface on Frame-relay between a Juniper and Cisco
The mismatch problem of DCE/DTE should definitely indicate that your PVCs aren't up. But that shouldn't result in the high quantity of CRC errors in the interface counters. That should just result in your LMI enquiry count increasing with LMI response sitting at zero. I have to say I've never tried running frame-relay on a SONET interface. And if you're only using a single PVC there, I'd certainly love to know WHY you're doing that! :) But setting one side to DCE so that it'll respond to LMI will certainly make the frame-relay (L2) portion of things operate properly. But if you have something else occurring causing the CRCs along the way, then that's not really going to help at all! Did anything else coincide with you changing the encapsulation? Scott On 12/6/11 4:05 PM, Scott Weeks wrote: Did Jeff's suggestion work? : interface POS0/0/0 : frame-relay intf-type dce If so, please let the list know, so when someone comes across this thread while searching for the fix they can figure it out without having to email the list. If it didn't help contact me off-line and I will be happy to troubleshoot it with you. scott From: Righa Shake [righa.sh...@gmail.com] Sent: Saturday, November 19, 2011 11:11 AM To: af...@afnog.org Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco Hi, Am having a problem that is buffling. I recently changed a POS link encapsulation from PPP to Frame-relay. Since that time the POS interface keeps resetting from time to time. On my BGP session am receiving cease notifications from my upstream provider. The setup is such that we have a cisco on one end and a Juniper on the other. interface POS0/0/0 mtu 4474 no ip address no ip unreachables encapsulation frame-relay logging event link-status crc 32 pos scramble-atm frame-relay lmi-type ansi end ROUTERshow run int pos0/0/0.101 Building configuration... ! interface POS0/0/0.101 point-to-point ip address X.X.X.X 255.255.255.252 frame-relay interface-dlci 101 end ROUTER#show int pos0/0/0 POS0/0/0 is up, line protocol is up Hardware is SPA-2XOC12-POS MTU 4474 bytes, BW 622000 Kbit/sec, DLY 100 usec, reliability 255/255, txload 6/255, rxload 38/255 Encapsulation FRAME-RELAY, crc 32, loopback not set Keepalive set (10 sec) Scramble enabled LMI enq sent 81981, LMI stat recvd 77480, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE segmentation inactive FR SVC disabled, LAPF state down Broadcast queue 0/256, broadcasts sent/dropped 26/0, interface broadcasts 0 Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters 1w2d Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 94336000 bits/sec, 13151 packets/sec 5 minute output rate 1647 bits/sec, 7049 packets/sec 12211574207 packets input, 10967607038364 bytes, 0 no buffer Received 0 broadcasts (0 IP multicasts) 6970870 runts, 2179 giants, 0 throttles 0 parity 892493293 input errors, 882184781 CRC, 0 frame, 0 overrun, 0 ignored, 3335463 abort 6379191154 packets output, 1614018181446 bytes, 0 underruns 0 output errors, 0 applique, 4 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions Any assistance on this will be greatly appreciated. --- js...@briworks.com wrote: From: Jeff Saxe js...@briworks.com I believe this is the explanation for your flapping: a PPP link is intended to go between two routers over, for instance, a private leased line, so both of the devices are peers, neither one particularly special. Frame-relay, by contrast, was originally designed so that your router was an end user device and its directly-connected partner device was not your other router, which you control, but the frame carrier's frame-relay switch. Your router was a DTE device, and their switch, which was in a more important position in control of the frame-relay NBMA cloud, was the DCE device. Your router then slaved to the frame switch via LMI signaling, so that the upstream switch instructed you which DLCIs existed and were up at the moment. So if you connect up two routers with frame-relay encap and each thinks it is the DTE, and neither one is taking the role of the frame switch, then when you bring them up, they will initially optimistically think their DLCIs are up and working, and the routing protocol and traffic will come up... but both of them will be waiting for the frame switch to send them LMI indicating that their idea of the DLCI up/down status is correct. When a couple minutes go by and they don't hear the
Re: Internet Edge and Defense in Depth
I personally have not seen it done in large environments. Hardware isn't there yet. I've seen it done in small business environments. Not a fan of the idea. -Hammer- I was a normal American nerd -Jack Herer On 12/06/2011 03:16 PM, Holmes,David A wrote: Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the defense in depth concept. Is anyone collapsing all Internet edge functions into one device? Regards, David This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
Re: Internet Edge and Defense in Depth
I have seen at quite a few of our customers locations, starting out with a lofty goal of putting everything in a single box (UTM) and turning every single option on. In ~ 30% of the firms who do so it works out ok (not great, but it works). In the majority, the customer winds up turning features off one by one, and moving those to another system. Jim On Dec 6, 2011, at 1:25 PM, -Hammer- wrote: I personally have not seen it done in large environments. Hardware isn't there yet. I've seen it done in small business environments. Not a fan of the idea. -Hammer- I was a normal American nerd -Jack Herer On 12/06/2011 03:16 PM, Holmes,David A wrote: Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the defense in depth concept. Is anyone collapsing all Internet edge functions into one device? Regards, David This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
Re: Internet Edge and Defense in Depth
They're proposing that so you buy their device, not renew support on your existing ones :-D Personally we just went through this w/ Palo Alto Networks. We bought a handful of their all-in-one firewalls simply for their web-filtering functionality (replacing Bluecoats). They pitched repetitively that we should replace all of our firewalls with just their box and collapse it. I must say, from a support perspective, the concept of this box does web filtering, and that box handles the firewall of our public facing servers is worth it's weight in gold. Web filtering alone can get stupid complex if you let it. Do you really want to troubleshoot an inbound web server issue while trying to sort through rules like Jeff is allowed to get to Facebook, Marketing can get to Twitter, HR can see everything, oh wait here's the DMZ rules. Boxes are cheap in an environment where staffing is lean. In SoHo, and smaller SMBs I could see it being different... we're on the larger of the medium business / small Enterprise side of the fence. David. On Tue, Dec 6, 2011 at 4:16 PM, Holmes,David A dhol...@mwdh2o.com wrote: Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the defense in depth concept. Is anyone collapsing all Internet edge functions into one device? Regards, David This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
Re: CMDB on the cheap...
On Tue, Dec 6, 2011 at 1:16 PM, George Herbert george.herb...@gmail.com wrote: Everyone I know has either paid through the nose or written one from scratch. No good open source projects that worked out. Most people couldn't build well from scratch. I have been a couple of places that did, it was man-year of senior grade guy effort range. And 10-20% (or more) of an FTE in support. New devices need to be onboarded, new OS versions make subtle changes in the code, etc. The upside is that they can be powerful tools to automate mass config changes, and along with config parsing code, they can be powerful tools to standardize networks. Elle Janet Plato
Re: Internet Edge and Defense in Depth
I would argue that collapsing all of your policy evaluation and routing for a size/zone/area/whatever into one box is actually somewhat detrimental to stability (and consequently, security to a certain extent). Cramming every little feature under the sun into one appliance makes for great glossy brochures and Powerpoint decks, but I just don't think it's practical. Take a LAMP hosting operation for example. Which will scale the furthest to handle the most amount of traffic and stateful sessions: iptables and snort on each multi-core server, or one massive central box with some interface hardware and Cavium Octeons. If built properly, my money's on the distributed setup. Cheers, jof
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
On Tue, 06 Dec 2011 10:30:20 PST, andrew.wallace said: It could be argued that Nmap is malware, and such software has already been called to be made illegal. Called by whom, other than yourself? pgpXRyBlKEIYx.pgp Description: PGP signature
Re: Internet Edge and Defense in Depth
On Tue, 6 Dec 2011, Holmes,David A wrote: Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the defense in depth concept. Is anyone collapsing all Internet edge functions into one device? As others have said, this could make sense at the smaller end of the scale (SOHO, branch offices, small shops, etc), but I haven't see an all-in-one box that scales up to the traffic loads or handles things like routing protcools especially well in a large network. The marketing folks will often dance around the issue of throughput dropping as services or modules are turned on, but that's a big problem. I'm perfectly happy having border routers sitting at my borders, doing the routing, and firewalls elsewhere, doing the firewalling :) Another thing to remember is that existing router manufacturers have gotten pretty good (a few exceptions aside) at building pretty stable routing implementations. All-in-one box manufacturers that claim to be able to handle IPv6, BGP, OSPF(v2/v3), etc are basically starting out from scratch and don't have the benefit of the 10+ years of experience that Cisco/Juniper/et al have in building routers. jms
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
On Tue, Dec 6, 2011 at 4:45 PM, valdis.kletni...@vt.edu wrote: On Tue, 06 Dec 2011 10:30:20 PST, andrew.wallace said: It could be argued that Nmap is malware, and such software has already been called to be made illegal. Called by whom, other than yourself? Germany? http://www.schneier.com/blog/archives/2007/08/new_german_hack.html -- Dan Collins
RE: GPON Vendors
Here at Blue Ridge InternetWorks we evaluated a few vendors (a couple of years ago) and are extremely happy with our choice of Calix E7. The engineering is top-notch, optical components are good quality, boot time is very fast, decent GUI (not perfect, but improves with each software release), software upgrades have been (knock wood) seamless every time, etc. And the E7 line is easy to use -- I hear tell that the C7 line had a horrible CLI and cryptic GUI and was powerful-but-demanding, but the E7 just acts like a big Ethernet switch with VLANs, customer-side rate-limiting, and a little bit of DHCP snooping, security, and multicast processing. And their tech support, both pre-sales and on-demand, have been responsive and very helpful every time I've called on them. I don't think they are cheap, and we wish they made an ONT model with many Ethernet ports but no POTS and RF video, but that's just a product mix suggestion. Overall we are really happy, and it's easy to deploy and making us actual money. We have a rather small network, with a 2-slot (thin) E7 chassis. They also have a 20-slot large chassis. Only reservations I would have about it: - Currently runs only RSTP, but not MST. So difficult to load-balance redundant links into our switching core. I don't remember if MST is on the planned feature list. - Currently no true IPv6 support. You can hand off IPv6 over a straight transparent LAN connection, but you can't use the DHCP snooping / IP source verify features, which they have in v4, to ensure that a customer must use DHCPv6 to get their address and then cannot impersonate another customer with a manual IPv6 address. Calix says full IPv6 support is planned. - We had a few 711GX ONTs that developed optical transceiver failures in the field. It could be something that we did, but it seemed to me that it was just a bad batch of components in that specific product, since the 710GX and 711GE and 716GE's were all fine. All were replaced under warranty just fine, so no complaints other than customer downtime and our time to repair. Feel free to ping me off-list for any other questions. Jeff Saxe blue ridge internetworks 321 east main st • suite 200 charlottesville va 22902 434.817.0707 x 2024 www.briworks.com Central Virginia’s technology authority since 2000. From: Josh V. Hoppes [jhop...@cfunet.net] Sent: Tuesday, December 06, 2011 2:52 PM To: nanog@nanog.org Subject: GPON Vendors Hello NANOG, Due to unforeseen circumstances we need to consider alternative vendors for our GPON system, moving away from Motorola. We wanted to throw out a line and find out what other networks have deployed and what experiences they have had positive or negative with them. Thanks in advance for any replies. Josh Hoppes Network Engineer Cedar Falls Utilities
Re: GPON Vendors
We have a Calix C7 as well as some E7-2's in a few markets for a little over a year. We only deal with GPON/AE deployments and the C7 worked to get us started but the E7 is definitely more purpose built for ethernet fiber services. Just started several major build-outs which pushed us to re-evaluate vendors and after looking at a few other vendors we ended up going back to the Calix E7 platform. Due to price and features vs other vendors. We have three E7-20's that we're turning up. I would agree with Jeff's positives. They are starting to roll out indoor ONT's which will shave some cost off of the ONT Battery for the CPE. - They do only support RSTP now, not MST but in our deployment we have 2 x 10 GE LAG ports on two separate line switching cards. MST will be coming in a future release. - True IPv6 support is coming next year - Quite a few other new features coming in the next year that we're excited to see. Feel free to ping me off-list if you have any other questions. Nick Colton Director of Network Operations ALLO Communications On Tue, Dec 6, 2011 at 12:52 PM, Josh V. Hoppes jhop...@cfunet.net wrote: Hello NANOG, Due to unforeseen circumstances we need to consider alternative vendors for our GPON system, moving away from Motorola. We wanted to throw out a line and find out what other networks have deployed and what experiences they have had positive or negative with them. Thanks in advance for any replies. Josh Hoppes Network Engineer Cedar Falls Utilities
Re: Writable SNMP
On Tue, 06 Dec 2011 14:18:52 EST, Jeff Wheeler said: I've spent enough time writing code to deal with SNMP (our own stack, not using Net-SNMP or friends) to have a more in-depth understanding of SNMP's pitfalls than most people. It is TERRIBLE and should be totally gutted and replaced with something more sane, less likely to have bugs, etc. A number of years ago, I pointed out that the official rfc-index.txt listed the publication date of RFC1442 as April 1, 1993 rather than April 1993. Draw your own conclusions. ;) pgpZdYaRL81Jg.pgp Description: PGP signature
Re: Internet Edge and Defense in Depth
On 12/06/2011 11:16 AM, Holmes,David A wrote: Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the defense in depth concept. Is anyone collapsing all Internet edge functions into one device? Regards, David Yikes... single point of failure. I really dislike the notion that all the security comes down to a single potentially compromisable point. Our security functions like IPS run separate to centralised logging, etc. etc. so that if someone does happen to break in to a particular point there are still further things they need to try to compromise before they can have their wicked way, or whatever it is they want to do. Sure the economies of a centralised box and the convenience are probably tempting, and it's better than nothing, but I can't picture it actually being an improvement over split out functions. Paul
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
On 6 Dec 2011, at 22:07, Dan Collins wrote: On Tue, Dec 6, 2011 at 4:45 PM, valdis.kletni...@vt.edu wrote: On Tue, 06 Dec 2011 10:30:20 PST, andrew.wallace said: It could be argued that Nmap is malware, and such software has already been called to be made illegal. Called by whom, other than yourself? Germany? http://www.schneier.com/blog/archives/2007/08/new_german_hack.html -- Dan Collins There's a big difference between hacking tools and malware. Edward Dore Freethought Internet
Re: Internet Edge and Defense in Depth
To echo what James has already said.. I would say it's possible on the low/medium size enterprise network market. With that stated 70-80% of the time it's not designed correctly or a vendor issue pops up causing them to disable the feature. Careful planning must be done ahead of time. When looking at the spec sheets you can't look at the numbers and take them for face value. In most cases those numbers were achieved when *only* running that specific feature. So if a vendor claims 90meg of IPS throughput, 500meg of firewall throughput and 100meg of UTM. Chances are that 90meg of IPS traffic will take the box to it's knees. So if you're planning using the data sheet numbers you've most likely already failed. Plan carefully, test throughly, and in the end..you still may hit a bug or unexpected show stopper. I'd rather use the best tool for the job rather than jam everything into once box so I can share a chassis... Just my two cents, -Tim Eberhard On Tue, Dec 6, 2011 at 3:32 PM, JAMES MCMURRY j...@miltonsecurity.com wrote: I have seen at quite a few of our customers locations, starting out with a lofty goal of putting everything in a single box (UTM) and turning every single option on. In ~ 30% of the firms who do so it works out ok (not great, but it works). In the majority, the customer winds up turning features off one by one, and moving those to another system. Jim On Dec 6, 2011, at 1:25 PM, -Hammer- wrote: I personally have not seen it done in large environments. Hardware isn't there yet. I've seen it done in small business environments. Not a fan of the idea. -Hammer- I was a normal American nerd -Jack Herer On 12/06/2011 03:16 PM, Holmes,David A wrote: Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the defense in depth concept. Is anyone collapsing all Internet edge functions into one device? Regards, David This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
Re: Internet Edge and Defense in Depth
On Tue, 6 Dec 2011, Holmes,David A wrote: Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the defense in depth concept. Is anyone collapsing all Internet edge functions into one device? Hi David. A principle of network firewall design has long been that you want to minimise services (proxy, etc) running there as they can be a vector for attack against the firewall itself. In the end this is about risk analysis. In most cases I would recommend against loading the firewall with additional functionality, for a variety of reasons. In some cases it may make sense to do so. This is completely separate to whether servers should even have a firewall or IPS in front of them. That's another (interesting) discussion :) Cheers, Rob -- Email: rob...@timetraveller.org Linux counter ID #16440 IRC: Solver (OFTC Freenode) Web: http://www.practicalsysadmin.com Director, Software in the Public Interest (http://spi-inc.org/) Free Open Source: The revolution that quietly changed the world One ought not to believe anything, save that which can be proven by nature and the force of reason -- Frederick II (26 December 1194 – 13 December 1250)
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
On 12/6/2011 13:30, andrew.wallace wrote: It could be argued that Nmap is malware, and such software has already been called to be made illegal. If I was Cnet, I would stop distributing his software altogether. Link: http://nmap.org/book/legal-issues.html If this is not trolling and you actually believe this, just wow. Nmap is just a tool, and any tool can be misused by people for criminal acts. It's really no different than a gun in that regard. Both are incredibly useful things in the right hands, mere tools to further security. However in the wrong hands they can be used to commit crimes and break other peoples security. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net
Re: GPON Vendors
Another vote for Calix here, but we started with Occam B-series gear (DSL+POTS) and kept buying their gear into the GPON times. Calix bought them.. so the vote is for Calix, even though I haven't used their C or E series gear. I do a fair amount of scripting for various tasks and have been fairly happy with their EPS ring protection.. not exactly like running [M|R]STP, but really quite resilient, at any rate. Their software is all running on a Linux core, has a decent (but not great) Cisco-ish CLI, and a very good web-UI. It seems like they're focusing more on the web-UI than the CLI, these days, but both are built on the same internals. We use B-6322 GPON blades (and quite a few of them, adding more on a daily basis..) and mainly their 12 blade chassis'. These chassis only have an option for -48VDC power, but are very well built overall, and the software is getting better on every new release. I expect we're nearing a sort of magic period of time when the Calix engineers and the Occam engineers are on the same page and really making progress, copying the best features from each platform onto the other. It seems to be showing in the early OccamOS 7.x releases, I can't speak for the C/E OS', I've never used them. -- Jonathan Towne On Tue, Dec 06, 2011 at 07:52:20PM +, Josh V. Hoppes scribbled: # Hello NANOG, # # Due to unforeseen circumstances we need to consider alternative vendors for our GPON system, moving away from Motorola. We wanted to throw out a line and find out what other networks have deployed and what experiences they have had positive or negative with them. Thanks in advance for any replies. # # Josh Hoppes # Network Engineer # Cedar Falls Utilities # # #
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
A trojan can be used for good if in the right hands as a remote access tool for business use. Andrew From: Bryan Fields br...@bryanfields.net To: nanog@nanog.org nanog@nanog.org Sent: Tuesday, December 6, 2011 11:24 PM Subject: Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] On 12/6/2011 13:30, andrew.wallace wrote: It could be argued that Nmap is malware, and such software has already been called to be made illegal. If I was Cnet, I would stop distributing his software altogether. Link: http://nmap.org/book/legal-issues.html If this is not trolling and you actually believe this, just wow. Nmap is just a tool, and any tool can be misused by people for criminal acts. It's really no different than a gun in that regard. Both are incredibly useful things in the right hands, mere tools to further security. However in the wrong hands they can be used to commit crimes and break other peoples security. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
I can't believe this... Andrew, please check the dictionary second definition of Trojan before proceeding. A remote access tool is ssh, VNC and others and these are definitely not trojans. Get a grip. Trojan Horse noun noun Greek Mythology a hollow wooden statue of a horse in which the Greeks concealed themselves in order to enter Troy. • (also Trojan horse) figurative a person or thing intended secretly to undermine or bring about the downfall of an enemy or opponent : the rebels may use this peace accord as a Trojan horse to try and take over. • (also Trojan horse) Computing a program designed to breach the security of a computer system while ostensibly performing some innocuous function. Tom On Dec 6, 2011, at 6:49 PM, andrew.wallace wrote: A trojan can be used for good if in the right hands as a remote access tool for business use. Andrew From: Bryan Fields br...@bryanfields.net To: nanog@nanog.org nanog@nanog.org Sent: Tuesday, December 6, 2011 11:24 PM Subject: Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] On 12/6/2011 13:30, andrew.wallace wrote: It could be argued that Nmap is malware, and such software has already been called to be made illegal. If I was Cnet, I would stop distributing his software altogether. Link: http://nmap.org/book/legal-issues.html If this is not trolling and you actually believe this, just wow. Nmap is just a tool, and any tool can be misused by people for criminal acts. It's really no different than a gun in that regard. Both are incredibly useful things in the right hands, mere tools to further security. However in the wrong hands they can be used to commit crimes and break other peoples security. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
On Tue, 06 Dec 2011 17:07:47 EST, Dan Collins said: On Tue, Dec 6, 2011 at 4:45 PM, valdis.kletni...@vt.edu wrote: On Tue, 06 Dec 2011 10:30:20 PST, andrew.wallace said: It could be argued that Nmap is malware, and such software has already been called to be made illegal. Called by whom, other than yourself? Germany? http://www.schneier.com/blog/archives/2007/08/new_german_hack.html I rest my case. ;) Anybody know if they ever fixed their law? pgpPCtIipxZZJ.pgp Description: PGP signature
Re: Internet Edge and Defense in Depth
On Dec 7, 2011, at 6:20 AM, Robert Brockway wrote: This is completely separate to whether servers should even have a firewall or IPS in front of them. That's another (interesting) discussion :) http://www.nanog.org/meetings/nanog48/presentations/Monday/Kaeo_FilterTrend_ISPSec_N48.pdf http://www.ausnog.net/images/ausnog-05/presentations/7-2-stateofdanger.pdf --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
Hi, valdis.kletni...@vt.edu wrote on Mi, 2011-12-07 at 00:59+0100: On Tue, 06 Dec 2011 17:07:47 EST, Dan Collins said: On Tue, Dec 6, 2011 at 4:45 PM, valdis.kletni...@vt.edu wrote: On Tue, 06 Dec 2011 10:30:20 PST, andrew.wallace said: It could be argued that Nmap is malware, and such software has already been called to be made illegal. Called by whom, other than yourself? Germany? http://www.schneier.com/blog/archives/2007/08/new_german_hack.html I rest my case. ;) Anybody know if they ever fixed their law? not really. There have been some highest court decisions regarding this law saying the criminal liability depends on the intention someone produces or owns such tools - German jurisprudence is much more than the wording of the written law (though we have a lot of written laws, including many very strange ones). ;-) De facto, everybody in the industry continues to use dual use tools without fear of punishment and I am not aware of any dubious court decisions - the law was created for clearly illegal uses of such tools. Nontheless, as said by others, hacker tools != malware. Regards, Malte -- Malte von dem Hagen Head of Network Engineering Operations --- Host Europe GmbH - http://www.hosteurope.de Welserstraße 14 - 51149 Köln - Germany Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*) HRB 28495 Amtsgericht Köln - USt-IdNr.: DE187370678 Geschäftsführer: Patrick Pulvermüller, Thomas Vollrath (*) 0,14 EUR/Min. aus dem dt. Festnetz; maximal 0,42 EUR/Min. aus den dt. Mobilfunknetzen signature.asc Description: OpenPGP digital signature
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
On Tue, 06 Dec 2011 15:49:29 PST, andrew.wallace said: A trojan can be used for good if in the right hands as a remote access tool for business use. Best troll line since n3td3v got banned from full-disclosure. Well played, I've been outclassed, I'm outta here. pgpISZBNqu43g.pgp Description: PGP signature
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
On 12/06/2011 05:03 PM, valdis.kletni...@vt.edu wrote: On Tue, 06 Dec 2011 15:49:29 PST, andrew.wallace said: A trojan can be used for good if in the right hands as a remote access tool for business use. Best troll line since n3td3v got banned from full-disclosure. Well played, I've been outclassed, I'm outta here. I had assumed that he meant this in terms of red light districts. Mike
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
- Original Message - From: valdis.kletni...@vt.edu To: nanog@nanog.org Sent: Tuesday, December 06, 2011 3:03 PM Subject: Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] On Tue, 06 Dec 2011 15:49:29 PST, andrew.wallace said: A trojan can be used for good if in the right hands as a remote access tool for business use. Best troll line since n3td3v got banned from full-disclosure. Well played, I've been outclassed, I'm outta here. Maybe andrew's been reading http://wikileaks.org/the-spyfiles.html ?
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
Carrier IQ does not qualify as a good use of a Trojan and comes about as close to your definition as I can think of. No, a Trojan is malware. Any software which operates without the knowledge or consent of the user to engage in operations the user would not reasonably expect is not being used for good, no matter how well intentioned. Owen On Dec 6, 2011, at 3:49 PM, andrew.wallace wrote: A trojan can be used for good if in the right hands as a remote access tool for business use. Andrew From: Bryan Fields br...@bryanfields.net To: nanog@nanog.org nanog@nanog.org Sent: Tuesday, December 6, 2011 11:24 PM Subject: Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!] On 12/6/2011 13:30, andrew.wallace wrote: It could be argued that Nmap is malware, and such software has already been called to be made illegal. If I was Cnet, I would stop distributing his software altogether. Link: http://nmap.org/book/legal-issues.html If this is not trolling and you actually believe this, just wow. Nmap is just a tool, and any tool can be misused by people for criminal acts. It's really no different than a gun in that regard. Both are incredibly useful things in the right hands, mere tools to further security. However in the wrong hands they can be used to commit crimes and break other peoples security. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
On Tue, 06 Dec 2011 17:09:54 PST, Michael Thomas said: On 12/06/2011 05:03 PM, valdis.kletni...@vt.edu wrote: On Tue, 06 Dec 2011 15:49:29 PST, andrew.wallace said: A trojan can be used for good if in the right hands as a remote access tool for business use. I had assumed that he meant this in terms of red light districts. But then it's not exactly remote access, is it? pgpiMjY267vvV.pgp Description: PGP signature
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
On Tue, 06 Dec 2011 18:10:14 PST, Owen DeLong said: No, a Trojan is malware. Any software which operates without the knowledge or consent of the user to engage in operations the user would not reasonably expect is not being used for good, no matter how well intentioned. Strictly speaking, it's without the knowledge or consent of the *owner*. Especially in corporate environments, owner != user. pgpB47kaJkymm.pgp Description: PGP signature
Re: GPON Vendors
On Wednesday, December 07, 2011 03:52:20 AM Josh V. Hoppes wrote: Due to unforeseen circumstances we need to consider alternative vendors for our GPON system, moving away from Motorola. We wanted to throw out a line and find out what other networks have deployed and what experiences they have had positive or negative with them. Thanks in advance for any replies. We're using Huawei for this. It's a stable system, and they do this quite well. Watch out for the EMS though; it's great for management and provisioning, but customer migration is not supported (yet). The ONU that ships from Huawei is also not terribly good as a clever CPE. So if you're thinking of doing interesting things, suggest you use their ONU as a bridge and have something else terminating the PPPoE/DHCP sessions. Otherwise, I'd certainly recommend looking at Huawei for this. We've been reasonably happy using them for our FTTH and IPTv deployment. Cheers, Mark. signature.asc Description: This is a digitally signed message part.
Re: HP IPv6 RA Guard
Well, as a stability feature may work if better understanding of the internet protocols is given to all the network specialist (almost a paradox, all those documents are free to be checked for all the people). Of course, the problem with the rogue IPv6 packets and malformed packets will exists as long as IPv6 is being deployed wide spread, and the proposed mechanisms on how to deal with those problems is, as it seems, a passion for some guys, and a job for other ones, but always thinking on the Internet growth is the main focus of those whom participate actively to reach that objective. For Rogue V6's maybe some ACLs could work, but increases complexity. Maybe some mechanisms in the receiving nodes could work too, but requires a lot of computer resources and in that situations the LoWPAN will suffer its own success; so actually a solution should be adequate to each situation. BR On 06/12/11 07:46, Ray Soucy wrote: I think of RA Guard as a Layer-2 stability feature, rather than a security feature. You're correct that it is unable to deal with RA crafted in a fragmented packet on the majority (if not all) of implementations. The issue of rogue RA exists on every network, regardless of whether or not the IT group has deployed IPv6 or is aware of the IPv6 traffic on that network. Windows ICS is the most common accidental cause of rogue RA on a LAN. On Mon, Dec 5, 2011 at 10:35 PM, Daniel Espejel daniel.unam.i...@gmail.com wrote: So,still assuming the fact that attackers will use the same traditional ipv4 methods to alter the correct functioning over a network?...Well, maybe. Toda's IPv6 expertise for some network andmins and security experts is minimal. So most trainning and understanding before implementing its a good idea. For example, the RA-Guard method has a significant vulnerability: It's not designed to identify a complex IPv6-many extension headers formed packet (F. Gont - 6Networks). Some other security oriented mechanisms may fail because of the low IPv6 compliance. Regards. -- Daniel Espejel Pérez Técnico Académico D.G.T.I.C. - U.N.A.M. GT-IPv6 CLARA / GT-IPv6 U.N.A.M. -- Daniel Espejel Pérez Técnico Académico D.G.T.I.C. - U.N.A.M. GT-IPv6 CLARA / GT-IPv6 U.N.A.M.
Re: GPON Vendors
On Wednesday, December 07, 2011 06:18:07 AM Jeff Saxe wrote: - Currently runs only RSTP, but not MST. So difficult to load-balance redundant links into our switching core. I don't remember if MST is on the planned feature list. We run LACP either to the same or different routers depending on a few internal factors. For LACP to different routers, we use MC-LAG. Don't want to have to deal with Spamming Tree :-). - Currently no true IPv6 support. You can hand off IPv6 over a straight transparent LAN connection, but you can't use the DHCP snooping / IP source verify features, which they have in v4, to ensure that a customer must use DHCPv6 to get their address and then cannot impersonate another customer with a manual IPv6 address. Calix says full IPv6 support is planned. Same problem on the Huawei, too. Full support is planned for mid-to-late 2013. Of course, that puts a dent in our plans. - We had a few 711GX ONTs that developed optical transceiver failures in the field. It could be something that we did, but it seemed to me that it was just a bad batch of components in that specific product, since the 710GX and 711GE and 716GE's were all fine. All were replaced under warranty just fine, so no complaints other than customer downtime and our time to repair. We've found that the Huawei works well with other vendor optics too. Cisco, Juniper, OEM's. All good. Of course, for 10Gbps uplinks, the SFP+ units are bought from Huawei. We have some SPF+ modules from Cisco and their OEM's, but haven't tried them on the Huawei. Experience suggests it would work, but they're quite premium that we always need them for the Cisco's anyway :-). Mark. signature.asc Description: This is a digitally signed message part.
Re: Internet Edge and Defense in Depth
We've been fairly against centralizing functions, even though marketing scripts suggest it is worth doing. Not security-related per se, but for smaller PoP's, we'll collapse P/PE functions into a single box. As others have mentioned, this makes sense when scale is small. But on a large scale, we've not been one to buy into multi- chassis-type arrangements. With boxes getting smaller and more powerful due to Ethernet being the implicitly agreed- upon medium, it's still cheaper (and more resilient) to buy smaller boxes and distribute services than take one large one and stick them all in there. I'm hoping the OP can draw a parallel for their own situation, if this is useful. Cheers, Mark. signature.asc Description: This is a digitally signed message part.
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
On Mon, Dec 05, 2011 at 10:14:48PM -0800, andrew.wallace wrote: Using fruitful language and acting like a child isn't going to see you taken seriously. I'm sorry that my language offended you. But if you ever spend more than 14 years creating free software as a gift to the community, only to have it used as bait by a giant corporation to infect your users with malware, then you may understand my rage. The good news is that many users are sick and tired of having their machines hijacked by malware. Especially by CNET Download.Com, which still says on their own adware policy page: In your letters, user reviews, and polls, you told us bundled adware was unacceptable--no matter how harmless it might be. We want you to know what you're getting when you download from CNET Download.com, and no other download site can promise that. --http://www.cnet.com/2723-13403_1-461-16.html Um, what people WANT when they download Nmap is Nmap itself. Not to have their searches redirected to Bing and their home page changed to Microsoft's MSN. Speaking of which, Microsoft emailed me today. They said that they didn't know they were sponsoring CNET to trojan open source software, and that they have stopped doing it. But the trojan installer uses your Internet connection to obtain more special offers from CNET, and they immediately switched to installing a Babylon toolbar and search engine redirect instead. Then CNET removed that and are now promoting their own techtracker tool. Apparently the heat is so high that even malware vendors are refusing to have any more part in CNET's antics! But if CNET isn't stopped, the malware vendors will come crawling back eventually and CNET will be there to receive them. There have been dozens of news articles in the last day and hundreds of outraged comments on blogs, Twitter, Facebook, etc. In the midst of all this terrible PR, Download.com went in last night and quietly switched their Nmap downloads back to our real installer. At least for now. But that isn't enough--they are still infecting the installers for thousands of other packages! For example, they have currently infected the installer for a children's coloring book app: http://download.cnet.com/Kea-Coloring-Book/3000-2102_4-10360620.html Have they no shame at all??! I've created a page with the situation background, links to the news articles, and the latest updates: http://insecure.org/news/download-com-fiasco.html Feel free to share it. Together, I hope we can get Download.Com to apologize and cease this reprehensible behavior! Cheers, Fyodor
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
Fyodor wrote: On Mon, Dec 05, 2011 at 10:14:48PM -0800, andrew.wallace wrote: Using fruitful language and acting like a child isn't going to see you taken seriously. I'm sorry that my language offended you. But if you ever spend more than 14 years creating free software as a gift to the community, only to have it used as bait by a giant corporation to infect your users with malware, then you may understand my rage. The good news is that many users are sick and tired of having their machines hijacked by malware. Especially by CNET Download.Com, which still says on their own adware policy page: In your letters, user reviews, and polls, you told us bundled adware was unacceptable--no matter how harmless it might be. We want you to know what you're getting when you download from CNET Download.com, and no other download site can promise that. --http://www.cnet.com/2723-13403_1-461-16.html Um, what people WANT when they download Nmap is Nmap itself. Not to have their searches redirected to Bing and their home page changed to Microsoft's MSN. Speaking of which, Microsoft emailed me today. They said that they didn't know they were sponsoring CNET to trojan open source software, and that they have stopped doing it. But the trojan installer uses your Internet connection to obtain more special offers from CNET, and they immediately switched to installing a Babylon toolbar and search engine redirect instead. Then CNET removed that and are now promoting their own techtracker tool. Apparently the heat is so high that even malware vendors are refusing to have any more part in CNET's antics! But if CNET isn't stopped, the malware vendors will come crawling back eventually and CNET will be there to receive them. There have been dozens of news articles in the last day and hundreds of outraged comments on blogs, Twitter, Facebook, etc. In the midst of all this terrible PR, Download.com went in last night and quietly switched their Nmap downloads back to our real installer. At least for now. But that isn't enough--they are still infecting the installers for thousands of other packages! For example, they have currently infected the installer for a children's coloring book app: http://download.cnet.com/Kea-Coloring-Book/3000-2102_4-10360620.html Have they no shame at all??! I've created a page with the situation background, links to the news articles, and the latest updates: http://insecure.org/news/download-com-fiasco.html Feel free to share it. Together, I hope we can get Download.Com to apologize and cease this reprehensible behavior! Cheers, Fyodor No, there's no shame when money's involved. Do Unto Others as they would do unto you...sue the fsck out of them. --Michael
Re: Writable SNMP
On Tue, 6 Dec 2011 11:07:44 -0500, Keegan Holley keegan.hol...@sungard.com said: KH Admittedly, you will have to deal with proprietary mibs and reformat KH the data once it's returned. That's the nail in the coffin of just about every configuration protocol. Until multiple vendors implement a common model, no technology is going to work. SNMP certainly suffered from multiple vendors doing different things in their private MIBs while also implementing the standard MIBs is a standard way. You could probably get two vendors (X and Y) to agree that all devices have N interfaces with M-bit counters to represent traffic. The problem, especially with configuration, comes when vendor X uses virtual interfaces (eth0:1) to model interfaces with multiple addresses and vendor Y uses a single interface identifier with a sub-tail to list all the addresses assigned to the interface. Now this problem is at least solvable, given enough code, to take a configuration set from one device and covert it to the other, which in part is the goal of netconf: to enable a language that will hopefully allow a transformation process to succeed and thus bring about the holy grail of a singular management protocol. But in the end, every problem will still end up in the odd case where vendor X produces a config set with 2 rows and vendor Y produces a config set with 3 rows and no magical transformation can possibly get from point A to point B because the data models simply don't align. At all. When the internals aren't compatable, there isn't a data model to be written. No matter if it's in txt, SMIv2, XML, yang or moon dust. And hence the reason homogeneous networks with rdist distributed config files were born. -- Wes Hardaker
Re: Writable SNMP
On Tue, 6 Dec 2011 12:39:34 -0500, Dorian Kim dor...@blackrose.org said: DK There is one good reason. Every vendor seem to assign a junior intern to DK maintanining SNMP code, so you are interfacing with your router via a very DK suspect interface. The marking folks believed that when X dollars had to be spent, most folks would rather buy a box where .99X was spent on a new spiffy routing feature rather than on a manageable device. To change that, people need to start writing RFPs very very differently so that more points (dollars) are given to boxes that have consistent, standardized management interfaces rather than to boxes with new feature Z. Unfortunately, I don't have high hopes for that as institutions don't make money from having manageable networks. They make money from having fast and furious networks and that's what drives industry progress. [note: I'm not saying this is right or wrong; just that it's true. I could argue, and have, both sides quite effectively] -- Wes Hardaker
Re: Internet Edge and Defense in Depth
On Wednesday, December 07, 2011 11:58:59 AM Mark Tinka wrote: But on a large scale, we've not been one to buy into multi- chassis-type arrangements. s/multi-chassis-type/logical routers. Mark. signature.asc Description: This is a digitally signed message part.
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
On Dec 6, 2011, at 6:20 PM, valdis.kletni...@vt.edu valdis.kletni...@vt.edu wrote: On Tue, 06 Dec 2011 18:10:14 PST, Owen DeLong said: No, a Trojan is malware. Any software which operates without the knowledge or consent of the user to engage in operations the user would not reasonably expect is not being used for good, no matter how well intentioned. Strictly speaking, it's without the knowledge or consent of the *owner*. Especially in corporate environments, owner != user. I would argue that the superset applies in a proper definition here. Software which operates with the knowledge and consent of the owner, but, not the knowledge or consent of the end-user is still, IMHO, nefarious at best. Owen
Re: GPON Vendors
In any such vendor choice, I'd say make sure that they have workable IPv6 before making any major investments. Otherwise, you've got a dead-end platform that won't serve you very well for very many years. Owen On Dec 6, 2011, at 7:25 PM, Mark Tinka wrote: On Wednesday, December 07, 2011 03:52:20 AM Josh V. Hoppes wrote: Due to unforeseen circumstances we need to consider alternative vendors for our GPON system, moving away from Motorola. We wanted to throw out a line and find out what other networks have deployed and what experiences they have had positive or negative with them. Thanks in advance for any replies. We're using Huawei for this. It's a stable system, and they do this quite well. Watch out for the EMS though; it's great for management and provisioning, but customer migration is not supported (yet). The ONU that ships from Huawei is also not terribly good as a clever CPE. So if you're thinking of doing interesting things, suggest you use their ONU as a bridge and have something else terminating the PPPoE/DHCP sessions. Otherwise, I'd certainly recommend looking at Huawei for this. We've been reasonably happy using them for our FTTH and IPTv deployment. Cheers, Mark.
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
Amused thought, may have no basis in law Could he send their hosting company a take-down order for the download.com site? /Amused thought On Dec 6, 2011, at 8:53 PM, Michael Painter wrote: Fyodor wrote: On Mon, Dec 05, 2011 at 10:14:48PM -0800, andrew.wallace wrote: Using fruitful language and acting like a child isn't going to see you taken seriously. I'm sorry that my language offended you. But if you ever spend more than 14 years creating free software as a gift to the community, only to have it used as bait by a giant corporation to infect your users with malware, then you may understand my rage. The good news is that many users are sick and tired of having their machines hijacked by malware. Especially by CNET Download.Com, which still says on their own adware policy page: In your letters, user reviews, and polls, you told us bundled adware was unacceptable--no matter how harmless it might be. We want you to know what you're getting when you download from CNET Download.com, and no other download site can promise that. --http://www.cnet.com/2723-13403_1-461-16.html Um, what people WANT when they download Nmap is Nmap itself. Not to have their searches redirected to Bing and their home page changed to Microsoft's MSN. Speaking of which, Microsoft emailed me today. They said that they didn't know they were sponsoring CNET to trojan open source software, and that they have stopped doing it. But the trojan installer uses your Internet connection to obtain more special offers from CNET, and they immediately switched to installing a Babylon toolbar and search engine redirect instead. Then CNET removed that and are now promoting their own techtracker tool. Apparently the heat is so high that even malware vendors are refusing to have any more part in CNET's antics! But if CNET isn't stopped, the malware vendors will come crawling back eventually and CNET will be there to receive them. There have been dozens of news articles in the last day and hundreds of outraged comments on blogs, Twitter, Facebook, etc. In the midst of all this terrible PR, Download.com went in last night and quietly switched their Nmap downloads back to our real installer. At least for now. But that isn't enough--they are still infecting the installers for thousands of other packages! For example, they have currently infected the installer for a children's coloring book app: http://download.cnet.com/Kea-Coloring-Book/3000-2102_4-10360620.html Have they no shame at all??! I've created a page with the situation background, links to the news articles, and the latest updates: http://insecure.org/news/download-com-fiasco.html Feel free to share it. Together, I hope we can get Download.Com to apologize and cease this reprehensible behavior! Cheers, Fyodor No, there's no shame when money's involved. Do Unto Others as they would do unto you...sue the fsck out of them. --Michael
Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]
On Dec 7, 2011, at 2:47 AM, Owen DeLong wrote: Amused thought, may have no basis in law Could he send their hosting company a take-down order for the download.com site? /Amused thought Might be feasible to take over the domain if SOPA were passed :) I am glad that CBS Interactive/CNET has started to see the light, here is hoping there will be subsequent corrective actions taken. - Jared
