Cable/DSL (Was Re: Free NAT)

[Siglite <siglite () criticalstop com>]

Just a note of interest I pulled out of the
<counterrant>stuff</counterrant> was the volume of vulnerability scans on
cable modems and such.  I see on average five a day on my DSL connection.
For a while, Bell Atlantic had a mis-configuration that allowed me to
sniff all the traffic on my class C network. (yes, I saw a boatload of
passwords go by)  I saw these scanners ripping through these dsl class C
networks at the rates of about five to ten a day.  

This should bring about a general awareness of a serious VPN
vulnerability.  If our users at home are compromised, and they have vpn
access, now so does the black-hat. 

For about a week I sniffed for connections on port 259 (firewall-1
control port) from anywhere to anywhere on these Bell Atlantic dsl
subnets.  I counted five dsl users on my class C network alone that were
routinely connecting through thier firewalls to thier corporate lans.  For
the black hats, these vpn users become prime targets.  

As a result of what I saw, I began offering my time to security audit
any user's home machine(s) that would be connecting through my firewalls.
At the least, the security community should be aware of these issues.  I
think several cable modem providers and dsl providers actually bridge a
lot of thier traffic.  This obviously should raise some very serious red
flags about remote users and VPN's over these connections.



/*-----------------------------------*/
/* I live with FEAR every day.       */
/* But, sometimes, she lets me RACE. */
/*-----------------------------------*/

KT Morgan
Network Engineer
Checkpoint Firewall-1 CCSA/CCSE
Microsoft MCP
Software Systems Group, Inc

On Wed, 8 Sep 1999, Robert Graham wrote:

> Ooh, now you've done it, triggering my pet-peeve. Time for you to suffer:
>
> <counterrant>
> While I don't particularly like NATs, most the disadvantages listed in
> http://www.ietf.org/internet-drafts/draft-iab-nat-implications-04.txt I would
> describe as advantages, starting with "NATs break the flexible End-to-End model
> of the Internet".
>
> I remember fondly an IETF meeting back in the early 1990s where the dire fate
> of the Internet address space depletion was discussed. This was the same
> meeting that SNMPv2 was introduced. I say "fondly" because I was really amused
> by the whole thing, namely that engineers really couldn't see the forest for
> the trees.
>
> In SNMPv2, authentication required a fixed network-layer address in the agent.
> SNMPv2 was designed to include AppleTalk, which refuses to give fixed
> network-layer addresses to end-nodes (it enforces the use of something similar
> to DHCP). QED: SNMPv2 only works on AppleTalk in theory, not practice (and it
> failed on TCP/IP in practice too, but that's a different story). 
>
> Likewise, the discussion of address-space depletion assumed that we never be
> able to renumber IP addresses. One of the reasons was that too many protocols
> (like SNMPv2) relied too heavily on fixed IP address, and that it would be
> impossible to reassign all existing addresses.
>
> The thing is, engineers get a thought into their head and assume that this is
> the way the world works. In that case, it was that every device had to have a
> fixed, unchanging, manually set IP address. Any proposed solutions that broke
> that rule were quickly discarded for much the same reason that engineers hate
> NAT/proxies today: it breaks people's fundamental assumptions of how the net
> should work.
>
> However, the concept of a fixed IP address WAS broken. For example, most
> websites use "non-portable" IP addresses, and in fact change their IP address
> rather regularly. DHCP, private addresses, and even NAT have likewise altered
> the model. The problem is not that NAT breaks authentication schemes based on
> IP addresses, the problem is that authentication schemes based themselves on IP
> addresses in the first place.
>
> Similarly, end-nodes have no real need to be "raw" on the Internet: they really
> should be behind a NAT/proxy/firewall. Anybody that has put BlackICE Defender
> (the personal intrusion detection product from my company) on their cable-modem
> @Home sees that they get scanned by hackers 10 times per day (Trojan probes,
> IMAP probes, web-server /cgi-bin scans, etc.)
>
> There is a similar document (I don't have the link off hand) that criticizes
> the aweful new trend of using HTTP as the "transport" for application (example:
> it breaks the ability of firewalls to filter them). Likewise, this document is
> only valid if you stick to the "old-school" of thought. In particular, the
> old-school of firewalls filtering by ports has already become obsolete.
>
> IPv6 is a great solution for the old-school, but merely a good solution for the
> new-school. The "network address" of "http://www.example.com/foo/bar"; has long
> ago supplanted addresses like 192.0.2.154, and IPv6 won't substantially change
> that fact.
> </counterrant>
>
> Rob.
>
> --- Carl Brewer <carl () bl echidna id au> wrote:
> > I'm not coming down on Robert here!
> >
> > <rant>
> > It's a shame that M$ are providing NAT, which even they know
> > is a bad technology (it was a M$ employee that wrote the IETF
> > case against NAT), and not IPv6.  Please don't lose focus!  NAT
> > is a short-term ugly broken hack, push your vendor(s) for IPv6
> > support!
> >
> > http://www.ietf.org/internet-drafts/draft-iab-nat-implications-04.txt
> > http://www.ietf.org/internet-drafts-ietf-iab-case-for-ipv6-04.txt
> >
> > If you're using, or worse, planning to use, NAT and you haven't 
> > read the above two documents, read them :)
> > </rant>
> >
> > Carl
>
>
> ===
> Robert Graham
> "Anxiously awaiting the millenium so I can start programming
> dates with 2-digits again."
> __________________________________________________
> Do You Yahoo!?
> Bid and sell for free at http://auctions.yahoo.com