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.
Follow-Ups:
|
|
