[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::seal

Title:SEAL
Moderator:GALVIA::SMITH
Created:Mon Mar 21 1994
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1989
Total number of notes:8209

1793.0. "How do they do that?" by VFOVAX::WILLIAMS () Wed Feb 12 1997 11:06

I have a question about UNIX firewall applications (S.E.A.L., etc):
Can someone explain how these apps prevent spoofing using a secondary
network interface?  Assuming the machine has multiple IP interface devices,
se0 and se1, on different rails.  At the TCP layer, how can you guarantee
that data arrived on a specific interface device?  TCP doesn't know 
about packets; it's possible that the data presented to TCP on a given
connection could be arriving on both interfaces.  For example, 
interface se0 could be 10.9.8.7 and se1 could be 10.9.5.12, 
but packets addressed to 10.9.5.12 could arrive via se0.  Anyone
knowing both IP interface addresses could attack on one rail, masquerading
as a valid user on the second rail.  How do you modify the stack
to prevent this scenario?   I'm curious how to add this filtering
at the IP and TCP layers.

Regards,
Bob Williams

T.RTitleUserPersonal
Name
DateLines
1793.1QUICHE::PITTAlph a ha is better than no VAX!Wed Feb 12 1997 12:4111
The applications cannot do this.

The AltaVista Firewall for UNIX product used to patch this functionality into
the UNIX kernel, but as of V4.0 it is included as part of the Digital UNIX
product.  Basically if the functionality is turned on with the ifconfig filter 
keyword, then the kernel builds tables of permitted and denied source addresses
on a per interface basis from the file /etc/ifaccess.conf.  Then as a packet
arrives, the very first thing that is done is a source address check - if it's
wrong, the packet is logged and dropped.

T
1793.2How we did that!GALVIA::SMITHWed Feb 12 1997 13:2925
    In short, IP filtering is not done at the TCP layer but instead
    at the IP layer, first thing.  After the packet has been checked
    for basic validity (header checksum test), the source address is
    checked via a filter table for the given interface.  In other
    words, each interface on the system has a unique filter table.
    Using your example above, the interface se0 could be told to
    accept packets with a source address of 10.9.8.*, and se1 to
    accept packets with 10.9.5.* (assuming an 8-bit mask).  In the
    specific case of the firewall, the inward-facing interface could
    be on network 10.1.1.*, in which case its filter will say to
    accept *only* packets with a source address in that range.  If,
    behind the firewall, there is another network (behind a router
    or something), this is added to the ACCEPT list as well.  All
    other source addresses are deemed invalid.  On the outward-facing
    side, all packets are accepted EXCEPT those with a source address
    in use on the internal network.  Hence, it is impossible for an
    external host to spoof the firewall into thinking its packets
    arrived on the internal interface.  If you have any other questions
    on this, please send them via email as I don't often get a chance
    to read notes.  My email address is [email protected].
    (I'm using Mark Smiths account at the moment because I'm in his
    office).
    
    						Dermot Tynan