Re: do bogon filters still help?
I haven't looked at RFC 3330, but another RFC reserves 192.0.2.0/24 for examples in documentation. In practice, this prefix is used for distributing fake null routes over BGP, so it's a rather strong NO. If you know which RFC it is, I'll update the reference table. Uhm, looks like I was mistaken. Each time the topic comes up, I confuse this with RFC 2606 (domain names). No such RFC exists for IPv4 addresses. I HAVE looked at RFC 3330 and I noticed the following text in it: 192.0.2.0/24 - This block is assigned as TEST-NET for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation. Addresses within this block should not appear on the public Internet. In fact the title of the RFC is Special-Use IPv4 Addresses so I'm not sure what you mean when you say that no such RFC exists for IPv4 addresses. --Michael Dillon
Cisco, haven't we learned anything? (technician reset)
In this (http://blogs.securiteam.com/wp-admin/post.php?action=editpost=207) recent Cisco advisory, the company alerts us to a security problem with Cisco MARS (Cisco Security Monitoring Analysis and Response System). The security issue is basically a user account on the system that will give you root when accessed. The account is: 1. Hidden. 2. Default. 3. With a pre-set password. In other words, this is a journey back 10 years when technicians would commonly have special keys (actual keys, electronics or passwords) to access a device if they have to troubleshoot it for anything, or say? the user lost his password. People used to trade these keys online and hidden accounts were a thing of common practice. Today people still trade commonly used default passwords but it is not as popular as it used to be, at least in the online world. On the other hand, the most common practice to hack routers today, is still to try and access the devices with the notoriously famous default login/password for Cisco devices: cisco/cisco. Cisco/cisco is the single most used default password of our time. It got more routers pwned than any exploit in history, and it still does. One would think that a company such as Cisco, especially with this history, would stay away from such ?default? accounts? but the fact that this account is hidden makes it something different. It makes it a backdoor. One much like those used by the Bad Guys. Now? if Cisco knowingly put it there, shame on them. If somebody put it there without their knowledge? well, shame on them. This is indeed a vulnerability, as in a weakness. It is not however a software coding bug that may result in say? a buffer overflow. It is a part of the design of the system. Cisco disclosing this is very nice and commendable, but perhaps they should also let us know whether this was indeed a backdoor somebody put in their system or if it was part of the design? I love eastereggs. I just don?t like surprises in system privileges or backdoors, especially not in a security monitoring and response product. I very much doubt it was anything else but a part of the design but that should be admitted to. As the advisory states: No other Cisco products are currently known to be affected by this vulnerability. Okay, but how about other vulnerabilities of this type? Are there any more backdoors to other Cisco products? If not, why wouldn?t they just come out and say that? ?There are NO other such backdoors in our products?. I?d even be happy with: ?To our knowledge, there are no other vulnerabilities of this type in our products.? This is not a bug. One can never be sure ALL bugs are eliminated ? however hard one may try. One CAN admit to having no such features in other products, though. Once again we fall upon re-naming of a feature as a bug or a bug as a feature to make the problem sound less severe. IN this case, the judgement is plain and simple: If Cisco were Bad Guys, this is a backdoor. As Cisco are Good Guys, this is a technician reset. Terminology? What?s the difference? The difference is that Cisco are not Bad Guys. If they disclosure a problem they should do it fully, because as a client, I am now concerned. This reminds me of Ciscogate but not for obvious reasons. That was a bad event for everybody involved. It reminds me of the very issue Mike Lynn discussed: Remote exploitation for Cisco is possible, while so far Cisco disclosed all these problems as DoS vulnerabilities. I am not saying Cisco did that on purpose, but in THIS case they CAN set my mind at ease. Why don?t they? Gadi.
Re: Cisco, haven't we learned anything? (technician reset)
On Thu, 12 Jan 2006, Gadi Evron wrote: In this (http://blogs.securiteam.com/wp-admin/post.php?action=editpost=207) recent Cisco advisory, the company alerts us to a security problem with Cisco MARS (Cisco Security Monitoring Analysis and Response System). The security issue is basically a user account on the system that will give you root when accessed. ... Now? if Cisco knowingly put it there, shame on them. If somebody put it there without their knowledge? well, shame on them. Cisco acquired Protego in Dec 2004 and thereby acquired MARS: http://www.infoworld.com/article/04/12/20/HNciscoprotego_1.html Cisco didn't put it in there - they bought the bug for $65M. :-) Okay, but how about other vulnerabilities of this type? Are there any more backdoors to other Cisco products? If not, why wouldn?t they just come out and say that? ?There are NO other such backdoors in our products?. I am sure there are more. The previous one I remember was with their Riverhead purchase: http://www.cisco.com/en/US/products/products_security_advisory09186a008037d0c5.shtml and before that was: http://www.cisco.com/en/US/products/products_security_advisory09186a00802119c8.shtml but I don't know which company was purchased to introduce that one. I think Cisco just doesn't check the product closely enough and trusts the RD coders and doesn't introduce an external security QA to the product being purchased. -Hank
Re: do bogon filters still help?
Florian Weimer wrote: * Pim van Pelt: Hi, here's a member of 'the folks at bit.nl'. Just a quick note to say that we have been sourcing IPv4 packets from 192.88.99.1 at a rate of 2.000 to 10.000 packets per second since early 2003, so I'm guessing we have sent some 750.000 billion packets by now. And this is just so wrong. You should use an address you own as a source address. Otherwise, packets tend to get dropped by filters. Wouldn't you expect to see packets return from the same address you send them to? ICMP and stateful firewalls work much better that way. Our 6to4 relay also soucres packets from 192.88.99.1, it seems to work best that way. Don't filter 192.88.99.1 in any direction unless you want to break 6to4. If you want to limit your exposure you could allow only proto 41 and icmp packets and not break it. If you have native IPv6 on your network you could run a local 6to4 relay for your customers and filter 192.88.99.0/24 to/from your peers. - Kevin
Re: Cisco, haven't we learned anything? (technician reset)
Very good points, BTW. And these are certainly factors which, I'm sure, other companies are also susceptible. :-) - ferg -- Hank Nussbacher [EMAIL PROTECTED] wrote: [re: http://www.cisco.com/en/US/products/products_security_advisory09186a00805e3234.shtml] [snip] Cisco acquired Protego in Dec 2004 and thereby acquired MARS: http://www.infoworld.com/article/04/12/20/HNciscoprotego_1.html Cisco didn't put it in there - they bought the bug for $65M. :-) [snip] I think Cisco just doesn't check the product closely enough and trusts the RD coders and doesn't introduce an external security QA to the product being purchased. -Hank -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: do bogon filters still help?
On Thu, 12 Jan 2006, Kevin Loch wrote: If you have native IPv6 on your network you could run a local 6to4 relay for your customers and filter 192.88.99.0/24 to/from your peers. This is only true if you're absolutely, positively sure that no one in your network needs to use 6to4. Otherwise, packets coming from other native networks, encapsulated by their relays with src=192.88.99.1 coming towards your 6to4-using customers would get blocked. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Cisco, haven't we learned anything? (technician reset)
Hi, NANOGers. ] On the other hand, the most common practice to hack routers today, is ] still to try and access the devices with the notoriously famous default ] login/password for Cisco devices: cisco/cisco. This is NOT a default password in the IOS. The use of cisco as the access and enable passwords is a common practice by users, but it isn't bundled in the IOS. I've heard it began in training classes, where students were taught to use cisco as the passwords. Oh, and for those of you who think it mad leet to use c1sc0 as your access and enable passwords, the miscreants are on to that as well. ;) We've seen large, massively peered and backbone routers owned through this same technique. We've even seen folks who have switched to Juniper, yet continue to use cisco as the login and password. :( The nice thing about cooking up blame is that there is always enough to serve everyone. Thanks, Rob. -- Rob Thomas Team Cymru http://www.cymru.com/ ASSERT(coffee != empty);
Re: Cisco, haven't we learned anything? (technician reset)
Hi, Matthew. ] Cisco Router and Security Device Manager (SDM) is installed on this device. ] This feature requires the one-time use of the username cisco ] with the password cisco. Interesting. Is it limited to one-time use? Are the network login services (SSH, telnet, et al.) prevented from using this login and password? Thanks! Rob. -- Rob Thomas Team Cymru http://www.cymru.com/ ASSERT(coffee != empty);
Re: do bogon filters still help?
On Thu, Jan 12, 2006 at 04:08:00AM +0100, Daniel Roesen wrote: ... Otherwise, packets tend to get dropped by filters. By which ones? Folks with too much time feeding their paranoia, or is there any actual realistic attack to prevent by filtering packets with source 192.88.99.1? ... As Bill pointed out, filters that contain too much actually harm the network - longer than actual attacks, perhaps. I have no quantitative evidence to say more, and perhaps it's one of those opinion things. [Currently trying to fix a problem with same.] -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: Cisco, haven't we learned anything? (technician reset)
On Thu, Jan 12, 2006 at 10:53:32AM -0600, Rob Thomas wrote: Hi, Matthew. ] Cisco Router and Security Device Manager (SDM) is installed on this device. ] This feature requires the one-time use of the username cisco ] with the password cisco. Interesting. Is it limited to one-time use? Are the network login services (SSH, telnet, et al.) prevented from using this login and password? I know the AP350 comes with a default Cisco/Cisco account.. (as opposed to doing a nvram/config clear and it only lets you login on console). problem is with cisco each product group controls how they ship their system, so the Aironet teams don't quite seem to get this IMHO. That doesn't mean your 76k/GSR/CRS-1 will have Cisco/Cisco, but your aironet products sure may. - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Is my router owned? How would I know?
Hi, NANOGers. You all know how I love a good segue... ;) How can you tell if your router has been owned? In general the configuration will be modified. This is why we advocate using rancid (or something akin to it) as both a configuration backup tool AND an early warning tool. If you have a router running BGP, it also pays to peer with it externally. You can use a private ASN and rackspace with a buddy. You can use this peering to detect announcements you don't expect or necessarily condone. How else can you tell? Here are some tips: If there is a new user account, or if the enable and access passwords have changed, look out! The miscreants love to scan and find routers with cisco as the access and enable passwords. They know that other miscreants are doing the same thing. In fact this is even more widespread thanks to a module found in rBot and rxBot. Yes, even bots are scanning for routers now. If there are new or changed ACLs, look out! The miscreants love to use routers as IRC bounces. To avoid detection by IRC server proxy monitors, the miscreants will block access to the router (generally all access, sometimes just TCP 23) from those proxy monitors using ACLs. If there are new or changed SNMP RW community strings, look out! One of the tricks they employ is to leave a SNMP RW community backdoor. Is this to avoid the actions of we good folk? No, it's usually employed in the case where a compromised router is stolen from one miscreant by another. If the banner has changed, look out! As with the ACLs, this is a method by which the miscreants attempt to fool any proxy monitors. The most common banner we see identifies the router as a FreeBSD box. If tunnels suddenly appear on the router, look out! Chaining together lots of routers is also common now. This provides obfuscation and sometimes encryption. Most of the changes are based on templates. Consider this bundled clue, where the prowess of the template user isn't at all a factor. Use the flows. :) Thanks, Rob. -- Rob Thomas Team Cymru http://www.cymru.com/ ASSERT(coffee != empty);
EUSecWest papers and CanSecWest CFP
url: http://eusecwest.com url: http://cansecwest.com (CanSecWest Call For Papers attached below) EUSecWest/core06 Conference --- Announcing the final selection of papers for the EUSecWest conference in London, U.K. on Feb. 20/21 at the Victoria Park Plaza Hotel. The following topics will be covered: Javier Burroni Carlos Sarraute - Core Security Technologies Analyzing OS fingerprints using Neural Networks and Statistical Machinery van Hauser - thc Attacking the IPv6 protocol suite Yuji Ukai - eeye Exploiting Real-Time OS Based Embedded Systems Using the JTAG Emulator Nguyen Anh Quynh - Keio University XEBEK: A Next Generation Honeypot Monitoring System Fred Raynal - EADS Malicious Crypto Cesar Cerrudo - Argeniss Windows Local Shellcode Injection Andrew Cushman - Microsoft Microsoft Security Fundamentals Shreeraj Shah - Net Square Advanced Web Hacking - Attacks Defense Justin Clarke - Ernst Young LLP Practical Automated Web Application Attack Techniques Andy Davis - IRM PLC ColdFusion Security Tim Hurman - Pentest Ltd. ARMed combat: the fight for personal security Raffael Marty - ArcSight A Visual Approach to Security Event Management Michael Boman - KPMG Singapore Network Security Monitoring: Theory and Practice Jim DeLeskie Danny McPherson - Teleglobe, Arbor Networks Protecting the Infrastructure Andrea Barisani - Inverse Path Lessons in Open Source Security: The Tale of a 0-Day Incident We would also like to announce the final list of Security Masters Dojo courses that will be offered on February 16th and 17th at the Victoria Park Plaza Hotel. Seats are available for all courses, but course registration is limited to only ten students each. We are considering adding additional course sessions on Feb 23/24 if demand warrants it. The hands-on courses offered will be: Gerardo Richarte - Core Security Technologies Assembly for Exploit Writing Marty Roesch - Sourcefire Advanced IDS Deployment and Optimization Maximillian Dornseif Thorsten Holtz - Aachen University Advanced Honeypot Tactics Philippe Biondi - EADS Mastering the Network with SCAPY Renaud Deraison Nicolas Pouvesle - Tenable Network Security Vulnerability Scanning: Advanced Nessus Usage Laurent Oudot Nico Fischbach - rstack, COLT telecom Applied network security and advanced anomaly detection using state-of-the art honeypots and netflow/NIDS Cédric Blancher - EADS Practical 802.11 WiFi (In)Security Adam Laurie Martin Herfurt Marcel Holtmann - trifinite Bluetooth Technology Security Vendors Presentations for the Elevator Focus Groups will be announced shortly. Registration: --- Seats are available but limited for EUSecWest, and registration is open at: https://eusecwest.com/register.html Security Masters Dojo/London registration is now open at: https://eusecwest.com/courses.html Contact [EMAIL PROTECTED] for registration support or corporate sponsorship inquiries. * CanSecWest/core06 CALL FOR PAPERS VANCOUVER, Canada -- The seventh annual CanSecWest applied technical security conference - where the eminent figures in the international security industry will get together share best practices and technology - will be held in downtown Vancouver at the the Mariott Renaissance Harbourside on April 3-7, 2006. The most significant new discoveries about computer network hack attacks and defenses, commercial security solutions, and pragmatic real world security experience will be presented in a series of informative tutorials. The CanSecWest meeting provides international researchers a relaxed, comfortable environment to learn from informative tutorials on key developments in security technology, and collaborate and socialize with their peers in one of the world's most scenic cities - a short drive away from one of North America's top skiing areas. In addition to the usual one hour tutorials, panel sessions and highly entertaining 5 minute lightning talks, this conference will also feature a new session called Elevator Focus Groups. Featuring several short sessions, these commercial presentations will showcase new, significantly used, or dramatically innovative new products in the information security realm. Each selected vendor will have a short 10 minute presentation (elevator pitch), after which 10 minutes of audience QA and interactive discussion amongst the expert security practitioners attending will follow. In this session both the audience and the vendors can get valuable feedback from world leading experts and the attendees can get user evaluations and learn from sharing experiences and real world security applications about practical uses of the products - the focus group. Hence the name: Elevator Focus Groups. The CanSecWest conference will also
Re: Cisco, haven't we learned anything? (technician reset)
Just as an offshoot discussion, what's the state-of-the-art for AAA services? We use an modified tacacs server for multi-factor authentication, and are moving towards a model that supports single-use/rapid expiration passwords, with strict control over when and how local/emergency authentication can be used. I'd be interested in that discussion, on or offlist. - billn On Thu, 12 Jan 2006, Rob Thomas wrote: Hi, NANOGers. ] On the other hand, the most common practice to hack routers today, is ] still to try and access the devices with the notoriously famous default ] login/password for Cisco devices: cisco/cisco. This is NOT a default password in the IOS. The use of cisco as the access and enable passwords is a common practice by users, but it isn't bundled in the IOS. I've heard it began in training classes, where students were taught to use cisco as the passwords. Oh, and for those of you who think it mad leet to use c1sc0 as your access and enable passwords, the miscreants are on to that as well. ;) We've seen large, massively peered and backbone routers owned through this same technique. We've even seen folks who have switched to Juniper, yet continue to use cisco as the login and password. :( The nice thing about cooking up blame is that there is always enough to serve everyone. Thanks, Rob. -- Rob Thomas Team Cymru http://www.cymru.com/ ASSERT(coffee != empty);
Re: Cisco, haven't we learned anything? (technician reset)
On Thu, Jan 12, 2006 at 10:53:32AM -0600, Rob Thomas wrote: Hi, Matthew. ] Cisco Router and Security Device Manager (SDM) is installed on this device. ] This feature requires the one-time use of the username cisco ] with the password cisco. Interesting. Is it limited to one-time use? Are the network login services (SSH, telnet, et al.) prevented from using this login and password? No. No. (It's nothing special -- it doesn't do anything you couldn't configure manually on a pre-SDM device if you wanted.) -- Brett
Re: Cisco, haven't we learned anything? (technician reset)
I've been pretty happy with Cisco ACS - fairly solid, good reporting, once set up it seems to Just Work. John On Thu, Jan 12, 2006 at 11:00:10AM -0800, Bill Nash wrote: Just as an offshoot discussion, what's the state-of-the-art for AAA services? We use an modified tacacs server for multi-factor authentication, and are moving towards a model that supports single-use/rapid expiration passwords, with strict control over when and how local/emergency authentication can be used. I'd be interested in that discussion, on or offlist. - billn On Thu, 12 Jan 2006, Rob Thomas wrote: Hi, NANOGers. ] On the other hand, the most common practice to hack routers today, is ] still to try and access the devices with the notoriously famous default ] login/password for Cisco devices: cisco/cisco. This is NOT a default password in the IOS. The use of cisco as the access and enable passwords is a common practice by users, but it isn't bundled in the IOS. I've heard it began in training classes, where students were taught to use cisco as the passwords. Oh, and for those of you who think it mad leet to use c1sc0 as your access and enable passwords, the miscreants are on to that as well. ;) We've seen large, massively peered and backbone routers owned through this same technique. We've even seen folks who have switched to Juniper, yet continue to use cisco as the login and password. :( The nice thing about cooking up blame is that there is always enough to serve everyone. Thanks, Rob. -- Rob Thomas Team Cymru http://www.cymru.com/ ASSERT(coffee != empty);
RE: Is my router owned? How would I know?
Here are some other new things (Cisco IOS specific): Login Security Enhancements. The Cisco IOS Login Enhancements feature allows users to better secure their Cisco IOS devices when creating a virtual connection, such as Telnet, secure shell (SSH), or HTTP. Thus, users can help slow down dictionary attacks and help protect their router from a possible denial-of-service (DoS) attack. http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_ guide09186a00801d1cb3.html Configuration Change Notification and Logging. Releases of Cisco IOS software prior to 12.3(4)T/12.2(25)S lack the ability to track the origin of changes to the running configuration. The only way to determine if a Cisco IOS software configuration has been changed is to pull the running and startup configurations offline and do a line-by-line comparison. This comparison will identify all the changes that have occurred between the two configurations, but it will not specify the sequence in which the changes occurred or the person responsible for the changes. The Configuration Change Notification and Logging (Configuration Logging) feature allows the tracking of configuration changes entered on a per-session and per-user basis by implementing a configuration log. The configuration log will track each configuration command that is applied, who applied the command, the parser return code for that command, and the time that the command was applied. This feature also adds a notification mechanism that sends asynchronous notifications to registered applications whenever the configuration log changes. http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_ guide09186a00801d1e81.html And then there is 'security passwords min-length'. If you set this to 6 more more, it would knock out 'cisco' as a possible password on the router. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Thomas Sent: Thursday, January 12, 2006 10:19 AM To: NANOG Subject: Is my router owned? How would I know? Hi, NANOGers. You all know how I love a good segue... ;) How can you tell if your router has been owned? In general the configuration will be modified. This is why we advocate using rancid (or something akin to it) as both a configuration backup tool AND an early warning tool. If you have a router running BGP, it also pays to peer with it externally. You can use a private ASN and rackspace with a buddy. You can use this peering to detect announcements you don't expect or necessarily condone. How else can you tell? Here are some tips: If there is a new user account, or if the enable and access passwords have changed, look out! The miscreants love to scan and find routers with cisco as the access and enable passwords. They know that other miscreants are doing the same thing. In fact this is even more widespread thanks to a module found in rBot and rxBot. Yes, even bots are scanning for routers now. If there are new or changed ACLs, look out! The miscreants love to use routers as IRC bounces. To avoid detection by IRC server proxy monitors, the miscreants will block access to the router (generally all access, sometimes just TCP 23) from those proxy monitors using ACLs. If there are new or changed SNMP RW community strings, look out! One of the tricks they employ is to leave a SNMP RW community backdoor. Is this to avoid the actions of we good folk? No, it's usually employed in the case where a compromised router is stolen from one miscreant by another. If the banner has changed, look out! As with the ACLs, this is a method by which the miscreants attempt to fool any proxy monitors. The most common banner we see identifies the router as a FreeBSD box. If tunnels suddenly appear on the router, look out! Chaining together lots of routers is also common now. This provides obfuscation and sometimes encryption. Most of the changes are based on templates. Consider this bundled clue, where the prowess of the template user isn't at all a factor. Use the flows. :) Thanks, Rob. -- Rob Thomas Team Cymru http://www.cymru.com/ ASSERT(coffee != empty);
Re: Is my router owned? How would I know?
On Thu, 12 Jan 2006, Rob Thomas wrote: If there is a new user account, or if the enable and access passwords have changed, look out! The miscreants love to scan and find routers with cisco as the access and enable passwords. I thought everyone sensible put ACLs on vtys. Guess I was wrong. -Dan
Re: Cisco, haven't we learned anything? (technician reset)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yo Rob! On Thu, 12 Jan 2006, Rob Thomas wrote: This is NOT a default password in the IOS. Uh, wrong. Check out the doc for the Cisco AIR-AP1220. Ver 12.01T1 RGDS GARY - --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDxrGB8KZibdeR3qURAvHaAJ0Q7Lt6rkj+jQNqnsMdpJX+DfldywCgidbI qX+Hm/+94o/W4F5sN6NRuzU= =EfCd -END PGP SIGNATURE-
Re: Cisco, haven't we learned anything? (technician reset)
On Thu, Jan 12, 2006 at 10:53:32AM -0600, Rob Thomas wrote: Hi, Matthew. ] Cisco Router and Security Device Manager (SDM) is installed on this device. ] This feature requires the one-time use of the username cisco ] with the password cisco. Interesting. Is it limited to one-time use? Are the network login services (SSH, telnet, et al.) prevented from using this login and password? I know the AP350 comes with a default Cisco/Cisco account.. (as opposed to doing a nvram/config clear and it only lets you login on console). problem is with cisco each product group controls how they ship their system, so the Aironet teams don't quite seem to get this IMHO. That doesn't mean your 76k/GSR/CRS-1 will have Cisco/Cisco, but your aironet products sure may. No, but it means that there is no centralized standard on how to implement authentication which is troubling. That means that your GSR _could_ come with such a feature. -M - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
BLS FastAccess internal tech needed
Please contact me offlist at [EMAIL PROTECTED], or via the telephone number in my duh.org contacts. The support IVR and agents are ... less than helpful. (Your new SMTP port filters put in today in the Atlanta market are a step in the right direction, but they are configured incorrectly: They block outbound connections to port 25, which is good -- but they are also blocking *inbound* connections to a local SMTP receiver, which protects nothing and simply annoys those of us who have a clue.) -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: EUSecWest papers and CanSecWest CFP
is this a classic case of commercial abuse?
Re: Is my router owned? How would I know?
Configuration Change Notification and Logging. Releases of Cisco IOS software prior to 12.3(4)T/12.2(25)S lack the ability to track the So no 76k(*)/GSR software, or any other platform specific releases. Seems like a bit of a challenge to template this across ones network. for the three nanog readers who are unaware of what most of us use http://www.shrubbery.net/rancid/ randy
Re: Is my router owned? How would I know?
On Thu, 12 Jan 2006, Rob Thomas wrote: If there are new or changed SNMP RW community strings, look out! If you have any SNMP v1/v2 RW communities what so ever, you're likely to be owned, at least if they're common to several units in your network and you don't limit what part of the tree the RW communities can access. Seems like a common attack vector is to send SNMP WRITE and upload the router configuration to a hacked tftp server, and then iterate thru the network as a lot of people have a single SNMP WRITE community in their network. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Is my router owned? How would I know?
If there is a new user account, or if the enable and access passwords have changed, look out! The miscreants love to scan and find routers with cisco as the access and enable passwords. I thought everyone sensible put ACLs on vtys. Guess I was wrong. I've seen ACL-less VTYs because someone copied a config from a router with fewer VTYs. 8-(
Re: Is my router owned? How would I know?
If there is a new user account, or if the enable and access passwords have changed, look out! The miscreants love to scan and find routers with cisco as the access and enable passwords. I thought everyone sensible put ACLs on vtys. Guess I was wrong. I've seen ACL-less VTYs because someone copied a config from a router with fewer VTYs. 8-( Yes, but these are clue problems, not router operating system problems. The OS problem is when they leave a device with a default backdoor because they want to make it easy for their customers. It's almost like the cheaper the box the less secure and the consideration seems to be that an unsavvy folk is buying the cheaper boxen so it needs to be easy. If you look at the maintenance and surveillance networks of a few large tier1's, you'll find this dummy gear on those networks since they are cheap and generalte no revenue. My last M/S design was dual rail 2XXX, 1600's for firewalls and frame terminations, which handled console and monitoring for the cost of an ethernet port and 15K per facility. For the use, the capex matches as well as the reliability. If we accept the clue problem as the solution, I think we accept the fact that we condone the vendor not having secure solutions. That may be fine for our new colleague the 'security engineer', but it's not good for the Internet as a whole and it distracts us from the work of making it work. Offering tutorials at NANOG is a great effort towards the clue issue, but maybe we should offer vendors tutorials on the inverse? -M
Re: Cisco, haven't we learned anything? (technician reset)
This reminds me of Ciscogate but not for obvious reasons. That was a bad event for everybody involved. It reminds me of the very issue Mike Lynn discussed: Remote exploitation for Cisco is possible, while so far Cisco disclosed all these problems as DoS vulnerabilities. I am not saying Cisco did that on purpose, but in THIS case they CAN set my mind at ease. Why don?t they? I did not change my mind, but to be fair, I have to add: After writing this I’ve been made aware that this product was from a company Cisco bought not so long ago. This very same issue happened before (and more than once)... in one recent example with another company Cisco bought named Riverhead. It is true Cisco's PSIRT is one of the best to work with among vendors, even Mike Lynn said that Cisco PSIRT are some of the more decent people he worked with - I've never had a problem with PSIRT. It is also true that Cisco can't find out about these until after they buy the companies, still, Cisco f*cked up, more than just once or twice, and we call it. This kind of a so-called vulnerability should not happen, or be disclosed, continually, in this particular fashion. Checking into new investments security-wise, especially with security products and external QA may help solve such issues in the future. Gadi.
Re: Cisco, haven't we learned anything? (technician reset)
On Fri, 2006-01-13 at 01:30:52 +0200, Gadi Evron proclaimed... Checking into new investments security-wise, especially with security products and external QA may help solve such issues in the future. Thank you for this interruption. We now returned to our scheduled programming, already in progress.
Re: Cisco, haven't we learned anything? (technician reset)
[ SNIP ] It is true Cisco's PSIRT is one of the best to work with among vendors, even Mike Lynn said that Cisco PSIRT are some of the more decent people he worked with - I've never had a problem with PSIRT. PSIRT is great. After marketing and legal approval. This is why they can't possibly have responsible disclosure. :-) Ok, that's bait. -M
Re: Cisco, haven't we learned anything? (technician reset)
Rob Thomas wrote: Hi, NANOGers. ] On the other hand, the most common practice to hack routers today, is ] still to try and access the devices with the notoriously famous default ] login/password for Cisco devices: cisco/cisco. This is NOT a default password in the IOS. The use of cisco as the access and enable passwords is a common practice by users, but it isn't bundled in the IOS. I've heard it began in training classes, where students were taught to use cisco as the passwords. Actually, and fairly recently, this IS a default password in IOS. New out-of-box 28xx series routers have cisco/cisco installed as the default password with privilege 15 (full access). This is a recent development. To be fair, the box also has a huge default login banner urging the user to delete that username/password pair. But we all know how much attention is paid to huge, verbose banners, disclaimers, click-to-agree dialog boxes, etc. -- Jay Hennigan - CCIE #7880 - Network Administration - [EMAIL PROTECTED] NetLojix Communications, Inc. - http://www.netlojix.com/ WestNet: Connecting you to the planet. 805 884-6323
Re: Cisco, haven't we learned anything? (technician reset)
Actually, and fairly recently, this IS a default password in IOS. New out-of-box 28xx series routers have cisco/cisco installed as the default password with privilege 15 (full access). This is a recent development. This is hardly only cisco's problem. Most office routers I've dealt with also come with default username/password and on occasions when I dealt with existing installation those passwords have rarely been changed. What should really be done (BCP for manufactures ???) is have default password based on unit's serial number. Since most routers provide this information (i.e. its preset on the chip's eprom) I don't understand why its so hard to just create simple function as part of software to use this data if the password is not otherwise set. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Cisco, haven't we learned anything? (technician reset)
william(at)elan.net wrote: Actually, and fairly recently, this IS a default password in IOS. New out-of-box 28xx series routers have cisco/cisco installed as the default password with privilege 15 (full access). This is a recent development. This is hardly only cisco's problem. Most office routers I've dealt with also come with default username/password and on occasions when I dealt with existing installation those passwords have rarely been changed. True. However I much prefer the old way that Cisco did it. No default passwords on the box at all. But, no remote administration at all until a password was set on the console. Now, there is a default cisco/cisco. Newbie admin creates a new user/pass, tests thinks it's secure, fails to remove the default, game over. What should really be done (BCP for manufactures ???) is have default password based on unit's serial number. Since most routers provide this information (i.e. its preset on the chip's eprom) I don't understand why its so hard to just create simple function as part of software to use this data if the password is not otherwise set. The old-school Cisco way works for me. Default is no password if you have physical access, but no remote access. -- Jay Hennigan - CCIE #7880 - Network Administration - [EMAIL PROTECTED] NetLojix Communications, Inc. - http://www.netlojix.com/ WestNet: Connecting you to the planet. 805 884-6323
Re: Cisco, haven't we learned anything? (technician reset)y
Actually, and fairly recently, this IS a default password in IOS. New out-of-box 28xx series routers have cisco/cisco installed as the default password with privilege 15 (full access). This is a recent development. This is hardly only cisco's problem. Most office routers I've dealt with also come with default username/password and on occasions when I dealt with existing installation those passwords have rarely been changed. What should really be done (BCP for manufactures ???) is have default password based on unit's serial number. Since most routers provide this information (i.e. its preset on the chip's eprom) I don't understand why its so hard to just create simple function as part of software to use this data if the password is not otherwise set. Ex: Thot's how a Netscreen 5 works after a reset. The password is the serial # if I remember correctly. -M
Re: Cisco, haven't we learned anything? (technician reset)
On Thu, 12 Jan 2006, Jay Hennigan wrote: What should really be done (BCP for manufactures ???) is have default password based on unit's serial number. Since most routers provide this information (i.e. its preset on the chip's eprom) I don't understand why its so hard to just create simple function as part of software to use this data if the password is not otherwise set. The old-school Cisco way works for me. Default is no password if you have physical access, but no remote access. That works too and is most secure way. But its often enough that small offices would not have person who can fix the system and its not always possible to get network guy to come in right a way. It is good for those cases to be able to ask somebody onsite to just look at the back and dictate the serial# by phone. -- William Leibzon Elan Networks [EMAIL PROTECTED]
NANOG List Statistics
Good Evening, We are now ready to release our first of monthly list statistics. They are available at: http://www.nanog.org/liststats.html I'd like to offer a huge thanks to the staff at Merit for putting this all together: Dale Fay, Sue Joiner, Brad Robertson, and Jeff Tomaszewski I'd also like to thank the Steering Committee and Mail Admin Committee. We hope they are useful and of interest to the community as a whole! All comments can be directed to [EMAIL PROTECTED] Regards, Chris Malayter NANOG - Mail list Administration Committee
Re: Cisco, haven't we learned anything? (technician reset)y
In message [EMAIL PROTECTED], Martin Hannigan writes: Actually, and fairly recently, this IS a default password in IOS. New out-of-box 28xx series routers have cisco/cisco installed as the default password with privilege 15 (full access). This is a recent development. This is hardly only cisco's problem. Most office routers I've dealt with also come with default username/password and on occasions when I dealt with existing installation those passwords have rarely been changed. What should really be done (BCP for manufactures ???) is have default password based on unit's serial number. Since most routers provide this information (i.e. its preset on the chip's eprom) I don't understand why its so hard to just create simple function as part of software to use this data if the password is not otherwise set. Ex: Thot's how a Netscreen 5 works after a reset. The password is the serial # if I remember correctly. How much entropy is there in a such a serial number? Little enough that it can be brute-forced by someone who knows the pattern? Using some function of the serial number and a vendor-known secret key is better -- until, of course, that secret leaks. (Anyone remember how telephone credit card number verification worked before they could do full real-time validation? The Phone Company took a 10-digit phone number and calculated four extra digits, based on that year's secret. Guess how well that secret was kept) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: Cisco, haven't we learned anything? (technician reset)y
On Thu, 2006-01-12 at 21:05:52 -0500, Steven M. Bellovin proclaimed... How much entropy is there in a such a serial number? Little enough that it can be brute-forced by someone who knows the pattern? Using some function of the serial number and a vendor-known secret key is better -- until, of course, that secret leaks. (Anyone remember how telephone credit card number verification worked before they could do full real-time validation? The Phone Company took a 10-digit phone number and calculated four extra digits, based on that year's secret. Guess how well that secret was kept) Hi Steven, I believe the Netscreen default password of a serial number can only be entered over the console (and possibly modem/aux) port(s).
Re: Cisco, haven't we learned anything? (technician reset)y
On Thu, 2006-01-12 at 21:05:52 -0500, Steven M. Bellovin proclaimed... How much entropy is there in a such a serial number? Little enough that it can be brute-forced by someone who knows the pattern? Using some function of the serial number and a vendor-known secret key is better -- until, of course, that secret leaks. (Anyone remember how telephone credit card number verification worked before they could do full real-time validation? The Phone Company took a 10-digit phone number and calculated four extra digits, based on that year's secret. Guess how well that secret was kept) Hi Steven, I believe the Netscreen default password of a serial number can only be entered over the console (and possibly modem/aux) port(s). Yes. Sorry, I left that out. -M
Re: Cisco, haven't we learned anything? (technician reset)y
In message [EMAIL PROTECTED], eric writes: On Thu, 2006-01-12 at 21:05:52 -0500, Steven M. Bellovin proclaimed... How much entropy is there in a such a serial number? Little enough that it can be brute-forced by someone who knows the pattern? Using some function of the serial number and a vendor-known secret key is better -- until, of course, that secret leaks. (Anyone remember how telephone credit card number verification worked before they could do full real-time validation? The Phone Company took a 10-digit phone number and calculated four extra digits, based on that year's secret. Guess how well that secret was kept) Hi Steven, I believe the Netscreen default password of a serial number can only be entered over the console (and possibly modem/aux) port(s). That works for me. But note William Leibzon's issue: That works too and is most secure way. But its often enough that small offices would not have person who can fix the system and its not always possible to get network guy to come in right a way. It is good for those cases to be able to ask somebody onsite to just look at the back and dictate the serial# by phone. If you have physical access, the root password matters a lot less (and if it's the serial number, the local attacker can just peer at the back). If you need secure remote access -- well, it's not easy with clueless local administrators. But there's much less excuse for clueless developers, like the ones who created the login/password pair that started this thread -- credentials that, according to one posting, are acceptable for remote access. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: Is my router owned? How would I know?
On Thu, 12 Jan 2006, Martin Hannigan wrote: If we accept the clue problem as the solution, I think we accept the fact that we condone the vendor not having secure solutions. That may be fine for our new colleague the 'security vendors should always, or be beatten about the head/shoulders when not, put out secure products... always. engineer', but it's not good for the Internet as a whole and it distracts us from the work of making it work. how is it better for security engineers? it's hell, every 3rd month a new 'default passwd' often on a 'security' device :( talk about stupid :( Offering tutorials at NANOG is a great effort towards the clue issue, but maybe we should offer vendors tutorials on the inverse? Some vendors have asked and received this sort of thing, does huwei (which I butchered the spelling of) want one? (or need one?) how about netgear and their lovely NTP issue? or checkpoint or ... there are quite a few vendors out there, some even attend NANOG. If they listened to their customers I suspect they'd hear: I want a secure platform! quite loudly.
Re: BLS FastAccess internal tech needed
On 1/13/06, Todd Vierling [EMAIL PROTECTED] wrote: (Your new SMTP port filters put in today in the Atlanta market are a step in the right direction, but they are configured incorrectly: They block outbound connections to port 25, which is good -- but they are also blocking *inbound* connections to a local SMTP receiver, which protects nothing and simply annoys those of us who have a clue.) What they're *trying* to do is actually quite sensible, and beats spammers trying to do asymmetric routing / source address spoofing type stuff I guess what they actually should do is filtering inbound connections FROM port 25 to any port. Thread starting from http://www.merit.edu/mail.archives/nanog/2005-01/msg00127.html for example And an example of how people get bitten without doing that .. What Hank thought: http://www.cctec.com/maillists/nanog/current/msg03171.html Actual issue: http://www.cctec.com/maillists/nanog/current/msg03232.html (which is what it turned out to be .. unidirectional port 25 filtering and a customer - nigerian spammer rather - who was sending out packets through a satellite interface but with Hank's IP as the source IP) srs -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: BLS FastAccess internal tech needed
RFC2827/BCP38? - ferg -- Suresh Ramasubramanian [EMAIL PROTECTED] wrote: [snip] What they're *trying* to do is actually quite sensible, and beats spammers trying to do asymmetric routing / source address spoofing type stuff [snip] -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: BLS FastAccess internal tech needed
On Fri, 13 Jan 2006, Fergie wrote: RFC2827/BCP38? not exactly... though most likely 2827 would have helped. Our abuse folks called it 'fantasy mail' ... Spammer signs up for 'fast' link with someone, uses a farm of juno dial (or netzero or... you get the point) accounts to make a large number of machines dial out and start sending email as the dial-up IP out the 'fast' link. This was painful for a while, radius applied filters fix it now. - ferg -- Suresh Ramasubramanian [EMAIL PROTECTED] wrote: [snip] What they're *trying* to do is actually quite sensible, and beats spammers trying to do asymmetric routing / source address spoofing type stuff [snip] -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: BLS FastAccess internal tech needed
In message [EMAIL PROTECTED], Fergie writes : RFC2827/BCP38? The problem is that an ISP can do all the source filtering it wants, but if it only blocks SYNs to port 25 all it takes is one unfiltered dial-up to spoof that ISP's addresses. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: BLS FastAccess internal tech needed
This is why AAA is so important. :-) - ferg -- Steven M. Bellovin [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Fergie writes : RFC2827/BCP38? The problem is that an ISP can do all the source filtering it wants, but if it only blocks SYNs to port 25 all it takes is one unfiltered dial-up to spoof that ISP's addresses. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: BLS FastAccess internal tech needed
On Fri, 13 Jan 2006, Suresh Ramasubramanian wrote: (Your new SMTP port filters put in today in the Atlanta market are a step in the right direction, but they are configured incorrectly: They block outbound connections to port 25, which is good -- but they are also blocking *inbound* connections to a local SMTP receiver, which protects nothing and simply annoys those of us who have a clue.) What they're *trying* to do is actually quite sensible, and beats spammers trying to do asymmetric routing / source address spoofing type stuff I guess what they actually should do is filtering inbound connections FROM port 25 to any port. That's why I said that it is misconfigured. The inbound packet filter has the wrong matching criterion. -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
