Re: Probes on Port 135 and 445 continue

From: Moe Trin (ibuprofin_at_painkiller.example.tld)
Date: 10/15/04

  • Next message: Moe Trin: "Re: Probes on Port 135 and 445 continue" 
    Date: Thu, 14 Oct 2004 20:59:59 -0500

    In article <MPG.1bd77f4f737578f398985a@news-server.columbus.rr.com>,
    Leythos wrote:

    >Yep, I've seen entire corporate installations take down due to lax
    >security measures, seen entire plants stop because of a person bringing
    >in a infection from a FTP server on their home computer.....

    All to often, unfortunately. And several times I've seen this occur
    because one of the executives let his kid use the computer at work to
    download. How does that get corrected? It doesn't. Most executives
    don't need a computer - yet they tend to have the latest greatest
    monster system for prestige purposes, and don't even know how to turn
    the damn thing on - that's what secretaries are for I guess.

    >It's good that you have a setup, but there really is no need for public
    >IP's on every device in a network, only the outward facing systems need
    >them.

    apparently you missed my statement where I made that point. So, just
    think how many addresses a place like Ford Motor Company could save. In
    case you're not aware, they have 19.0.0.0/8, 128.5.0.0/16, 130.249.0.0/8
    and 136.1.0.0 - 136.140.255.255 among other addresses.

    >> >> How do you propose that they fund the effort
    >> >> to change all of the un-needed public IPs to RFC1918.
    >
    >I don't, and don't have to worry about it. Since NAT won't be going away
    >I don't see a problem.

    I don't think the status quo is going away either.

    >While OSU has at least three /16's (I'll take your word), I don't see
    >that it makes any real difference - EDU's were what started all of this
    >for the most part. They can have a /8 for all I care. Just because they
    >have a bunch of public IP's doesn't mean that their internal devices are
    >all using public IP's.

    I could be wrong, but as far as I know, the only /8 allocated to a single
    .edu was 36.0.0.0/8, and that was returned to IANA in 1993. They now make
    do with 4 /16s plus one more for SLAC. MERIT has the 35.0.0.0/8 block, but
    my understanding is that an aggregation of the networks of a number of
    universities.

    As far as holding public IP blocks, in non public situations, look at
    51.0.0.0/8 (Department of Social Security of UK) which is apparently
    not advertising routes, and is reported to be internally used. They
    don't seem to want to renumber their hosts to RFC1918 because of the
    immense hassle it's going to be. Do a google search for the address -
    the subject has been discussed recently. Likewise, although the US and
    UK military have a number of identifiable public blocks, they are unlikely
    to have that many hosts publicly reachable.

    >I did a review of a large hospital in LA, more than 800 nodes in the
    >main building, VLANS, VPN's, etc.... Multiple locations in the city, and
    >many connections to off-campus sites.

    800 nodes isn't that large. Scottsdale Memorial Hospital (Scottsdale is
    a neighboring city to Phoenix, and has a population of around 220k) has
    several times that, and they're far from being the large hospital in
    the metro area. Their primary campus seems to be less than 1/16th of a
    square mile (40 acres). And yes, they have a public /16, a lot of which
    is inaccessible.

    >Their infrastructure was based on a private address scheme where only
    >outward facing systems that provided external services got exposed
    >through the firewalls - there was not a single public IP being use on
    >any internal system.

    That's excellent - and relatively rare because RFC1597 (the predecessor
    to RFC1918) is only dated March 1994. There has to be planning to use the
    non-public addresses, and if it's decided to change after the network has
    been set up, it becomes a non-trivial matter as I'm sure you are aware.

    >I'll stick with blocking the ports until we get secure systems by
    >default.

    Port blocking is about the only way to go, along with standard filtering
    rules about not letting packets out unless they have an address from one
    of _your_ public blocks, and not letting anything in that claims to come
    from an internal address, but is coming from your upstream. But that has
    _nothing_ to do with NAT. As far as 'secure systems by default' go,
    I'm not expecting those very soon at all.

            Old guy

  • Next message: Moe Trin: "Re: Probes on Port 135 and 445 continue"