RE: Cable/DSL (Was Re: Free NAT)

["Lee (Lockdown) Hughes" <lee () polestar co uk>]

layer 2 Bridging is real bad if there are no layer 2 mac address filters in
place. They should be either do full layer 3 routing to you dsl port by
subnetting the class C, or using bridging with mac address filtering.

so, on a dsl bridge network, the filter would look like this..

User    <-->    DHCP Server
User    <-->    External Gateway

all other broadcast and unicast blocked at dsl access point.

Again, if the DSL access device supports upper layer filtering at
the IP layer, then this can avoid the kind of problem all together.

telco's should'nt really be using layer 2 switching unless they are
combining it with a layer 3 routing first (MPLS springs to mind, or
tag switching). I think your going to see a lot more situations like this
where inexperinced telco's are using bridging cause it lot simpler to
understand. I guess this proves that IP network's arn't like you average
run of the mill telephone network (SS7 springs to mind!). You'll find that
most large telco's don't hire new staff to roll out solutions like this, 
but either contract in compaines like cisco etc etc, or just load the
existing telephone architechs with extra duties (which is really really
bad!).
There all going through a very steep learning curve, which most long
established ISP engineers went through earily on.

It's also wise to use static routing from the core network to the stubs,
as this is a lot easier to use this if you know for a fact that the stubs
will never become subnetted or have other ip networks latched on the
end of them.

Cheers,
Lee
'If I owned the cables, things would be different!'
Hughes


> -----Original Message-----
> From: Siglite [SMTP:siglite () criticalstop com]
> Sent: Friday, September 10, 1999 2:37 AM
> To:   firewall-wizards () nfr net
> Subject:      Cable/DSL (Was Re: Free NAT)
>
>
> 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