Great Circle Associates Firewalls
(September 1996)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: RE: SYS Floods - solution-2
From: Ryan Russell/SYBASE <Ryan . Russell @ sybase . com>
Date: 16 Sep 96 15:22:57 EDT
To: David Schiffrin <dschiffrin @ sybase . com>
Cc: Todd Truitt <Todd . Truitt @ sybase . com>, firewalls <firewalls @ sybase . com>, "Todd.Truitt" <Todd . Truitt @ sybase . com>

Well, if it's a one-address-per-port type of box, it would
be fairly easy to set 4 bytes to a particular value at a fixed
offset into every packet..  If it breaks FTP because they're 
fooling with IP spoofing, then screw 'em.  (Actually, Log
'em, and go beat them with a stick.)

    Ryan

---------- Previous Message ----------
To: Todd.Truitt
cc: firewalls, Todd.Truitt
From: dschiffrin @ ucsd.edu (David Schiffrin) @ smtp
Date: 09/16/96 12:36:40 PM
Subject: RE: SYS Floods - solution-2

There are a few problems with this. Here are a few I've just come up with
off the top of my head.

1. I'm not aware of any term servers which could do this. (admittedly this
is a weak one)
2. unless your 'smart term server' is VERY smart(spendy) it will break
protocols like FTP (which passes IP and port _inside_ the packets)
3. some (many) ISP's and schools assign static IP's per user. (this probably
doesn't matter)

4. your objective could be achieved much much more easily by having the term
server filter and drop packets not from the IP address assigned. (and using
today's term servers)


Another problem is with your assumptions. Were I to launch such an attack,
I'd use compromised, fast connected machines with 'cron' not my own
traceable dialup. Most educational institutions have machines connected to
the net, which students in programming classes have plenty of access to, for
this sort of attack.

You seem to assume these are teenage miscreants rather than folks with a
serious economic incentive. I'm not sure that's reasonable. Surely today,
with the recent publishing of code, lots of wannabes will try it out, but
until we figure out a good way around it (perhaps a different way for TCP
buffers to be allocated ?) we're all vulnerable. If I secure the few
thousand dialup ports I can, I'm only a small bit more protected than I was.
The other few million out there are still wide open. I cannot imagine that
this could be universally enforced.

Just my $.02

-dave


At 07:27 PM 9/15/96 -0600, Todd Truitt wrote:
>
>
>
>OK.  The more I read some of the arguments against a cache/buffer
>firewall and the additional descriptions of the random yet
>extremely fast paced, well fast enough anyway, SYN attack generators,
>the more I agree that the solution must come from the source.  How
>can you stop the source?
>
>Well, using the following assumptions:
>
>1.  The  majority of these hacks come from dial-up ISPs.
>2.  The others come from the university arena.
>3.  Subscribers and students will sign contracts upon
> service installation/start-up that any abuse can
> and will be penalized.
>4.  The dial-up access is similar to the setup here, i.e. dial
> into a terminal server, which dynamically assigns an IP
> address from a pool: PPP-10 180.191.152.10 
>
>
>So, my idea is fairly simple.  Which means I'm ready to take my share
>of abuse after this one.  I have a feeling my lack of experience on
>the provider side is going to hurt me.
>
>Once the PPP/SLIP session has been initiated by any ISP user and an
>IP address has been dynamically assigned, all regular internet communication
>can begin.  Now, assume this isn't just any terminal server, but a smart one.
>By that I mean one which also acts as it's one proxy.  So, when the USER sends
>any packet through the phone line to the terminal server (TS) it uses, as it's 
>source address (SA-10) the one assigned to it; in this case 180.191.152.10. 
>The TS grabs the packet, sends it up the OSI stack, stripping all source  
>address information from it, plugs in another source address (SA-110), tics
>the RR option and sends the packet on it's way through the Internet.
>
>
>USER   Terminal Server   Internet
>_______________________________________________________________________________
>
>IP dynamically   TS has two pools of addresses.
>assigned from TS 1 pool for dial-up users' PCs.
>IP=180.191.152.10 2nd pool for Internet comm.
>   Pool for users: illegal.
>   Pool for Internet: legal
>   # of Pool 1 = # of Pool 2
>
>
>
>USER sends packet:
><PKT> -------------> TS strips illegal addr from
>   packet and places in legal one.
>   Tics RR option.  Sends packet
>   on it's way to dest addr.
>   <NewPKT>------------------------> Remote host receives
>         packet and replies.
>   TS maps dest addr of reply <---------<RPLY>
>   to matching illegal for users'
>   dial-up.
>   <legal ip> = <illegal ip>
>   SA-110 = SA-10 (PPP-10)
>   And sends it to user.
> <---------------<NewRPLY> 
>USER's PC processes 
>the packet normally.
>
>
>The TS never looks at the source address of the dial-up user because it
>knows that PPP-10, which is illegal, was assigned to virtual soXX. And
>any traffic from virtual soXX must have the IP addr PPP-10 since that is
>what was assigned to that virtual so.  Therefore,  it is impossible
>for the user to manipulate the source addr.  Another benefit to this will
>be the ability of the ISPs to assign illegal addrs to dial-up users and
>use their legal ones for internet usage.  By setting the RR option, all
>packets causing problems can be traced to the ISP which owns those addresses,
>thereby helping Internet debugging.  This idea came from another in this
>group, the overhead might be worth it.  Of course, all packet filters which
>filter out any packet with the options flag triggered will have to be
>altered.
>
>Now this will need a "smarter" access box....or at least one with a
>server (SPARC 10, say) hanging off the side keeping track of phone
>line connections and IP, legal and illegal, addresses.
>
>In this example, I've only used a legit user transaction.  However, it
>should be easy to see how this would work to defeat any user which
>is spoofing his address.  The crux is solved by the enhanced TS which
>keeps track of virtual serial interfaces, not IP addresses.
>
>
>BTW, NO, Evolving Systems does not make dial-up access boxes. 8^)
>
>
>Comments?
>
>--Todd
>
>
>
>_____________________________________________________________________________
>               R. Todd Truitt      Todd .
 Truitt @
 evolving .
 com 
>                         Evolving Systems, Inc. 
>
>
--------------------------------------------------------------------------------
"The devices of power and its minions are the same in all countries and in all 
ages.  It marks its victim; denounces it; and excites the public hatred, to 
conceal its own abuses and encroachments."  
     -- Senator Henry Clay, March 14, 1834.
David Schiffrin
dschiffrin @
 ucsd .
 edu





Indexed By Date Previous: Re: SYS Floods - solution-2
From: peter @ baileynm . com (Peter da Silva)
Next: Configuration checking
From: dnewman @ mcgraw-hill . com
Indexed By Thread Previous: Re: SYS Floods - solution-2
From: nsayer @ quack . kfu . com (Nick Sayer)
Next: Re: SYS Floods - solution-2
From: peter @ baileynm . com (Peter da Silva)

Google
 
Search Internet Search www.greatcircle.com