I think you are talking about something that I always want to do and never have
time to modify the kernel. Here how it goes:
I want to create a firewall that allow people to ftp, telnet, gopher, mosaic (or
any other selected protocols) OUTWARD transparently:
"to work with all URLs"
without having to ftp, telnet to the gateway first. This will also allow
gopher, mosaic or any future applications to function transparently through the
firewall. This is what a firewall should do: prevent un-authorized access to
the internal network and allow people from the inside to go out and explore the
So how do I want the firewall to behave? First, as in a standard firewall
setup, you normally put the firewall between the internal network and the
internet (with 0, 1, 2, ...etc... routers, which is not relevant for this
discussion). The firewall has a default route to the internet and all the
internal hosts have a default route to the firewall. Since ip-forwarding,
source routing, ...etc... will be disable on the firewall, it will only process
packets that are sent to itself as a normal firewall should function. It will
handle all the gatwaying through application layer software telnet-gateway,
ftp-gateway, plug-gateway (from TIS's tool kits or similar packages). Here is
the kernel wizardy part:
If the firewall receive any packet from the internet not destined for it, it
seemly discard the packet. The fun part happens when the firewall receive a
packet from an internal network host (HOST-A) not destined for it (via default
routing). In a normal condition, a Unix host will either forward the packet or
send an ICMP Redirect, ...etc.... On the firewall however, all thoses are
disable. What need to do is that the kernel has to be modified to accept the
packet as destined for itself and process it normally. It will be allowed to
come up all the way to the application level (on the assumption that the
destination address of the packet is "understood" by the "modified" kernel as
that of the firewall). Eventually we will have a socket connection from HOSTA
<-> FIREWALL. When the whole connection get deliver to plug-gateway (in TIS's
firewall toolkit or any equivalent packages), it simply establish another socket
connection from the FIREWALL to the DESTINATION (specified on the original
packet which can be get from socket option system calls or any other wizardy
method). Plug-gateway will then simply forward packets received from one socket
connection to another.
How much works involved in modifying the kernel? I can't tell right now as I am
to busy to actively reading the kernel code at the moment. I guess a quick fix
would be to "disable" (more complex than simple disable) all the checking for
the destination address at the kernel level and let plug-gateway do the job.
There definitely will be other complications too.
Has anyone done such kernel wizardy in the past? Do you want a join effort?
Please e-mail me.
In message <9402171606 .
> Sun uses something called "itelnet" and "iftp" (they also have
> "iping", most useful). This apparently does the connection
> to the gateway and send the command to their proxy. This
> would probably be straightforward to implement for the TIS
> proxies, but is it so difficult to have users
> "telnet gateway.alsys.com" then connect to the proxy to
> get out?
> The default route won't work, because the firewall is not
> routing IP (otherwise it's not a firewall, it's a router).
> chuck yerkes
> chuck @
> > From mnejat @
com Thu Feb 17 10:53:18 1994
> > Date: Wed, 16 Feb 94 15:48:24 PST
> > From: mnejat @
com (Mehregan Nejat @rasht)
> > To: firewalls @
> > Subject: Allowing FTP and TELNET through firewall.
> > Precedence: bulk
> > Hello,
> > I need to let users at our site to do FTP and TELNET to outside world
> > without having them login to our firewall machine first. If I just add
> > a default route from lets say hosta to our firewall machine(i.e.
> > route add default firewall hosta 1) then I can ftp and telnet from hosta
> > to any host on Internet(assuming Internet hosts let me do that). Does this
> > scheme create a security hole in our Internal network? If so, what are
> > my alternatives?
> > Any help is appreciated,
> > Thanks,
> > --Mehregan Nejat