Re: Network Security Requirements draft
>>>>> "sd" == Sean Donelan <[EMAIL PROTECTED]> writes: >> We (UUNET) have an internal document that we've been using for a few >> years as the basis for tests of security features of equipment to be >> connected to our backbone. We're interested in making it public so >> that it can be improved and so that others can use it. You can view >> the current draft at: sd> Its a nice draft. One issue, not with the draft, but in general on sd> network security is the lack of a transit network security architecture sd> description. The issue of how to deal with IP source routing in this sd> draft is what reminded me of this. sd> Rather than disabling IP Source Route as a global setting, I think you sd> want to scrutinize traffic passing between data and control or management sd> layers. Such as to a routing process or management interface. A source sd> routed packet in the data layer just takes an unusual path through the sd> network, but becomes a security risk if it hops into the control or sd> management layer. It would be nice to enable/block source routing (and sd> strip other IP options) on a per interface basis and drop packets with sd> unexpected options at any control or management interface. The document lists requirements that a device must satisfy in order to be considered for deployment into the public network. It doesn't talk about the required config of that device. The ability to examine and evaluate IP options at line rate is something that we're lacking at the moment. Given the hardware to do this, policy decisions such as the one you mention could then be made. The doc currently states "This option MUST be available on a per-interface basis." Perhaps going one step further, and requiring per-interface application of ACLs that are checked against the purported source address would be useful. There are two docs that are companions to this one, an implementation document that hasn't been written yet, and a policy document that is not of general use beyond our network. Hopefully, this requirements document will remain applicable for quite a while, with the implementation document tracking the current state of the art. I'm not going to open the control plane separation can'o'worms, nor am I going to step into the "LSR as a legitimately useful IP option" discussion. Given the tools that we're asking for in the doc, you can take whatever position that you and your company feel appropriate. ericb -- Eric Brandwine | There are two major products that come out of Berkeley: UUNetwork Security | LSD and BSD. We don't believe this to be a coincidence. [EMAIL PROTECTED] | +1 703 886 6038| - Jeremy S. Anderson Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E
Re: Worldcomm network question
>>>>> "b" == blitz <[EMAIL PROTECTED]> writes: b> For that and other reasons, Wcom will be bailed out, at taxpayer expense if b> necessary, for national security reasons. WorldCom still "runs" UUNET as well. We carry a significant portion of the backbone, and have many customers that have no other connections. With the bandwidth glut, I'm sure the core could survive the sudden lack of UUNET, but there's a lot of edges that would get unhappy. There's no way they'd let us go Chapter 7, even if we wanted to. ericb b> At 18:19 6/26/02 -0400, you wrote: >> Anyone have any ideas, speculation, or info on how adverse future of WCOM >> would play out for ISPs and such? Among other things, WCOM is the preferred >> provider of long-haul pipes for DoD.that can't be good!! -- Eric Brandwine | Microsoft treats security vulnerabilites as public UUNetwork Security | relations problems. [EMAIL PROTECTED] | +1 703 886 6038| - Bruce Schneier Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E
Re: How low can Worldcom stock go?
>>>>> "b" == blitz <[EMAIL PROTECTED]> writes: b> This is at least the second purge of that many bodies, maybe third...they b> just let 20k go a month or so ago.. Um When? Where? This will be the largest layoff so far. Ash Wednesday was much smaller than this. ericb -- Eric Brandwine | There is no memory with less satisfaction in it than the UUNetwork Security | memory of some temptaion we resisted. [EMAIL PROTECTED] | +1 703 886 6038| - James Branch Cabell Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E
Re: PacBell Security/Abuse Contact
>>>>> "db" == David Barak <[EMAIL PROTECTED]> writes: db> Regarding securiy issues, I'd suggest working with db> UUNet/Worldcom (or whatever AS701 is called lately). db> I've seen some of their folks work closely with db> aggrieved victims of DDOS attacks. I was going to say the same thing, but I'm probably not as believeable. ;) And it's UUNET. It'll remain UUNET until they turn off the last router. ericb -- Eric Brandwine | UNIX was never designed to keep people from doing stupid UUNetwork Security | things, because that policy would also keep them from [EMAIL PROTECTED] | doing clever things. +1 703 886 6038| - Doug Gwyn Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E
Re: Question re. SSH
>>>>> "ss" == Steve Sobol <[EMAIL PROTECTED]> writes: ss> Apologies in advance for any operational content this may contain. ss> I have a customer who wants to get a static ip with his dialup. He ss> uses SSH extensively and plans to do X11 forwarding, and if he ss> gets disconnected and redials and gets another IP the previous ss> sessions would be inaccessible. ss> I can do static IP but I want to try to save the guy a couple ss> bucks. :) ss> Would a static IP be required to make sure he doesn't lose those ss> X11 sessions after a disconnect? Required, but not sufficient. The TCP stack on each side must remain up continuously. If his TCP stack resets and he redials, the first packet he gets from the far end will be met with an RST, and tear down the connection. The easiest way to do this is to put the modem on a system different from the SSH endpoint (router, NAT, FW, whatever). If you are using a NAT or FW in between, it's critical that the state/translation tables not be flushed when the dial interface goes down/up. Of course, if you're running TCP or ssh keepalives (or ssh2 rekeying), and that happens when the link is down, your connection will go away anyway. The proper way to do this is with an X analog of screen. VNC is one possibility. VNC is free, and this would not require a static IP. Then again, we're talking dialup here. Your customer should do this a couple of times before he gets dead set on it. Even with LBX and compression on the SSH session, X over dialup is unpleasant. ericb -- Eric Brandwine | The Windows NT philosophy always chooses ease - both UUNetwork Security | ease of use and ease of development - over security. [EMAIL PROTECTED] | +1 703 886 6038| - Bruce Schneier Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E
Re: CEOlink
>>>>> "b" == batz <[EMAIL PROTECTED]> writes: b> This is a complicated issue. Maybe I'm off base, but Nanog is actually b> really good. Combined with Bugtraq, Incidents, and a virus alert service, b> Nanog plays a vital role. Their only limitation is that they are on the b> Internet. :) Exactly! That's why we need control plane separation. Run SNMP, SSH, telnet, and SNTP (Simple NANOG Transport Protocol) across the management network, so we're sure we have them when we need them. Actually, NANOG does great. Especially during Sept 11, information was disseminated, help was offered and accepted, and except for a couple of idiotic flames, the SNR was high. ARPA designed the thing to withstand nuclear blasts, and while this was not nuclear, it stood up well. ericb -- Eric Brandwine | Apart from hydrogen, the most common thing in the UUNetwork Security | universe is stupidity. [EMAIL PROTECTED] | +1 703 886 6038| - Harlan Ellison Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E
Re: Telco's write best practices for packet switching networks
>>>>> "rp" == Rob Pickering <[EMAIL PROTECTED]> writes: rp> --On 06 March 2002 15:04 + "Christopher L. Morrow" <[EMAIL PROTECTED]> rp> wrote: >> Eric's point was you deploy your fancy-dan mail server with ONLY 22 >> and 25 listening, rp> Um, that would be "ONLY port 25 listening" on it's public network rp> facing interface wouldn't it. rp> Why would you want to expose a management protocol like ssh to the rp> Internet? You wouldn't. Neither would I. I'll go poke fun at Chris. rp> OK so leaving ssh open is convenient, but if we are talking best rp> practice surely having your remote management protocols running on a rp> separate network, or at the very least filtering on a host basis so rp> that it's only listening to connects from your NOC has to be the way rp> to do this. Absolutely. It bothers me that as an ISP, we kinda have to run mail and dns servers. If there were two protocols I'd choose NOT to expose to the public network, they'd be it. I'd much rather expose ssh than bind or sendmail. ericb -- Eric Brandwine | Apart from hydrogen, the most common thing in the UUNetwork Security | universe is stupidity. [EMAIL PROTECTED] | +1 703 886 6038| - Harlan Ellison Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E
Re: Telco's write best practices for packet switching networks
>>>>> "rq" == Rob Quinn <[EMAIL PROTECTED]> writes: >> When you've got a deployed server, run by clueful people, dedicated to a >> single task, firewalls are not the way to go. rq> Probably. And I would certainly rate "clueful people" _far_ rq> above a firewall when it comes times to prioritize your security rq> needs and resources. Mind having a talk with my management? >> chose a resilient and flame tested daemon, and watch the patchlist for it. rq> You've never seen a security vendor come out with a patch or rq> workaround before an application vendor? Sure. Sometimes they come out with patches that wouldn't be needed if you didn't have the firewall ;) Stateful firewalls also suffer from state propagation problems. High bandwidth redundant links and firewalls don't get along well together. Some firewall packages will allow you to statelessly pass high bandwidth traffic (tcp,udp/53) in the DNS example, which helps with load management and failover. But then you're back to where you were without the firewall. Decent IDSes run on spanning ports against your uplinks, decent logging on packet filtering routers, etc will all give you the benefits of the firewall. In general, and IDS is a better IDS than a firewall, and so forth. The primay benefit of firewalls is simplicity of configuration, and the ability to allow outbound services without opening huge inbound holes (tcp,udp/53, tcp/20, udp > 1023, etc). This is generally not the case with deployed ISP servers. Finally, the "crunchy ouside" thing takes over way too often. Management is lulled into a happy place by the word "firewall", and even good security engineers get lazy. I realize that this is 100% a meat problem, but it's a problem either way. ericb -- Eric Brandwine | If people are good only because they fear punishment, UUNetwork Security | and hope for reward, then we are a sorry lot indeed. [EMAIL PROTECTED] | +1 703 886 6038| - Albert Einstein Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E
Re: Telco's write best practices for packet switching networks
>>>>> "rds" == Ron da Silva <[EMAIL PROTECTED]> writes: >> Cool, who has an OC-192 firewall on their control elements? What is >> a control element, is that the same as a router or is that a signaling >> gateway? rds> Hmm...gotta say it (again). Of course oc192/10ge firewalls are not rds> currently widely deployed (aka not a best practice), but they should be! rds> Of course, folks will argue that you have to pay a lot of extra $$ rds> to make that a reality...kind of like how auto makers argue that you rds> should pay a lot of extra $$ for the GPS receiver in your car (which rds> does not COST a lot of extra $$). Firewalls are good things for general purpose networks. When you've got a bunch of clueless employees, all using Windows shares, NFS, and all sorts of nasty protocols, a firewall is best practice. Rather than educate every single one of them as to the security implications of their actions, just insulate them, and do what you can behind the firewall. When you've got a deployed server, run by clueful people, dedicated to a single task, firewalls are not the way to go. You've got a DNS server. What are you going to do with a firewall? Permit tcp/53 and udp/53 from the appropriate net blocks. Where's the protection? Turn off unneeded services, chose a resilient and flame tested daemon, and watch the patchlist for it. ericb -- Eric Brandwine | It is hard to believe that a man is telling the truth UUNetwork Security | when you know that you would lie if you were in his [EMAIL PROTECTED] | place. +1 703 886 6038| - H. L. Mencken Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E
