Is DIVERT w/o forwarding feasible?

Is DIVERT w/o forwarding feasible?

[Yury Bokhoncovich]

Hello!

I need an advice for this topic: is diverting without forwarding feasible?

 At present time we've managed to work SSL-tunnels via our MAN-provider
for a few several protocols by well-known method "connect this app to
border gateway, it takes care all the rest" and with (essentially!)
forwarding disabled in the kernel at all. But this method fails to meet
challenge of deploying fully-functional VPN with transparent packet
crossing over the MAN. In principle situation can be easily resolved if
there's a way to divert packets to an program on the border gateway
without need to enable forwarding in the kernel.

 I.e. can I change this:
"if the kernel does not have forwarding enabled, or it doesn't know how to
forward the packet, the packet is dropped"
(sorry ,quote from HOWTO) to something like
"if the kernel does not have forwarding enabled AND NO SPECIAL DIVERT
RULES SPECIFIED, or it doesn't know how to forward the packet, the packet
is dropped" ?

-- 
WBR, Yury Bokhoncovich, Senior System Administrator, NOC of F1 Group.
Phone: +7 (3832) 106228, ext.140, E-mail: byg@center-f1.ru.
Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.

Re: Is DIVERT w/o forwarding feasible?

[Anders Fugmann]

Yury Bokhoncovich wrote:
> Hello!
> 
> I need an advice for this topic: is diverting without forwarding feasible?
> At present time we've managed to work SSL-tunnels via our MAN-provider
> for a few several protocols by well-known method "connect this app to
> border gateway, it takes care all the rest" and with (essentially!)
> forwarding disabled in the kernel at all. But this method fails to meet
> challenge of deploying fully-functional VPN with transparent packet
> crossing over the MAN. In principle situation can be easily resolved if
> there's a way to divert packets to an program on the border gateway
> without need to enable forwarding in the kernel.
Err, please explain why you do not want forwarding enabled. If this is 
because you want to control who accesses the internal network, and are 
afraid of ipspoofing, then VPN is the way to go.

You say that you have ssh-tunnels to the systems.
ssh supports a socks mode. This means that when the client ssh'es to the 
firewall, ssh can be set to act as a local socks server, tunneling all 
packets to the server, making them seem like they originate from the 
server itself. This works just like a VPN, and there is no need to setup 
alot of different tunneling rules. On the client a sock-client should be 
setup. As of today OpenSSH only supports SocksV4, which does not support 
udp packets. There are some simple patches on the net to enable socksV5, 
which does support udp packets to socks.

While talking of VPN's. Have you considered ipsec or other VPN systems?

> 
>  I.e. can I change this:
> "if the kernel does not have forwarding enabled, or it doesn't know how to
> forward the packet, the packet is dropped"
> (sorry ,quote from HOWTO) to something like
> "if the kernel does not have forwarding enabled AND NO SPECIAL DIVERT
> RULES SPECIFIED, or it doesn't know how to forward the packet, the packet
> is dropped" ?
Technically yes. But you would have to spend alot of time coding, and 
understading networking traffic. In essence what you want it to create a 
VPN module for netfilter to be installed on the server and some client 
program to encapsulate packets and send them to the server, which seems 
to me as re-inventing the wheel. (When there are Ferraris out there for 
free, why build your own skoda?)

Regards
Anders Fugmann


-- 
Author of FIAIF
Fiaif Is An Intelligent/Iptables Firewall
http://fiaif.fugmann.dhs.org

Re: Is DIVERT w/o forwarding feasible?

[Yury Bokhoncovich]

Hello!

On Wed, 11 Sep 2002, Anders Fugmann wrote:

> >
> > I need an advice for this topic: is diverting without forwarding feasible?

> Err, please explain why you do not want forwarding enabled. If this is

Because rule #1: "People makes mistakes". Disabled forwarding gives more
strict and reliable control under possible traffic. There are a few books
where this topic discussed (including O'Reilly's).

>
> You say that you have ssh-tunnels to the systems.
> ssh supports a socks mode. This means that when the client ssh'es to the
> firewall, ssh can be set to act as a local socks server, tunneling all
> packets to the server, making them seem like they originate from the
> server itself. This works just like a VPN, and there is no need to setup
> alot of different tunneling rules. On the client a sock-client should be

OK. Thanks! It sounds interesting. Hm...though it's not so convenient as
"transparent" border gateway (and it lacks some extra work on WSs). There
are also such things as SMB and the kins.:(

SOCKS suck. They stink bad after work.:)

>
> While talking of VPN's. Have you considered ipsec or other VPN systems?
>
> >
> >  I.e. can I change this:
> > "if the kernel does not have forwarding enabled, or it doesn't know how to
> > forward the packet, the packet is dropped"
> > (sorry ,quote from HOWTO) to something like
> > "if the kernel does not have forwarding enabled AND NO SPECIAL DIVERT
> > RULES SPECIFIED, or it doesn't know how to forward the packet, the packet
> > is dropped" ?
> Technically yes. But you would have to spend alot of time coding, and
> understading networking traffic. In essence what you want it to create a
> VPN module for netfilter to be installed on the server and some client
> program to encapsulate packets and send them to the server, which seems
> to me as re-inventing the wheel. (When there are Ferraris out there for
> free, why build your own skoda?)

I didn't catch exactly what you mean as "skoda" but I should note that I
gonna combine the wheel and the skate to get something new ;). I just
gonna add a missed (IMHO) functionality (alike PVCs do). BTW, when
diving deep inside iptables I've felt de jevu: ghost of TLI.:-) And ole
good ipchain was more suitable to tweak packets as I want, right?8-)

OK, me and my colleague had already recognized that there is no out-of-box
solution yet. Alas and sigh but not too bad: we'd just to dig around
PREROUTING filter or so, right?8)

-- 
WBR, Yury Bokhoncovich, Senior System Administrator, NOC of F1 Group.
Phone: +7 (3832) 106228, ext.140, E-mail: byg@center-f1.ru.
Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.

Re: Is DIVERT w/o forwarding feasible?

[Anders Fugmann]

Yury Bokhoncovich wrote:
>>Err, please explain why you do not want forwarding enabled. If this is
> Because rule #1: "People makes mistakes". Disabled forwarding gives more
> strict and reliable control under possible traffic. There are a few books
> where this topic discussed (including O'Reilly's).
Rephrase - You make mistakes. Thats ok, but the system was designed to 
forward packets. If you dont want it, then live without it. And please 
dont refer to opinions stated in books. If you really want a "good ol'e 
classic", then Bjarne Stroustrup once said that one should never put a 
computer on the net - Not a vailable solution is it?

Compared to cars - You are saying that its dangerous to drive, and the 
only way to control this is to ban them - Don't go to the carmakers 
(this list) to ask for other solutions, when you already stated that you 
do not trust the cars.

-- 
Neo: 'Can you fly that thing?'
Trinity: 'Not yet'.
$ apt-get install pilot-prg-v212helicopter.

Re: Is DIVERT w/o forwarding feasible?

[Antony Stone]

On Wednesday 11 September 2002 2:39 pm, Yury Bokhoncovich wrote:

> > Err, please explain why you do not want forwarding enabled.
>
> Because rule #1: "People makes mistakes". Disabled forwarding gives more
> strict and reliable control under possible traffic.

People make mistakes.   Agreed.

But why does disabling forwarding in the kernel, and then providing some 
other mechanism for packets to get between the inside & outside, make 
mistakes any less likely ?   Surely there's still plenty of opportunities to 
make mistakes in whatever system you *do* set up to allow connectivity to the 
Internet, and if it's not as clear and standard as using netfilter, you might 
find it a lot less simple to locate and correct those mistakes ?

> > When there are Ferraris out there for
> > free, why build your own skoda?
>
> I didn't catch exactly what you mean as "skoda"

Try Skoda = Trabant.   Does that help :-) ?

> And ole good ipchain was more suitable to tweak packets as I want, right?8-)

ipchains is not stateful.   iptables is stateful.   Stateful inspection is 
regarded as a Good Thing(TM).   Therefore we now use iptables.

Antony.

-- 

Documentation is like sex:
when it's good, it's very very good;
when it's bad, it's still better than nothing.

Re: Is DIVERT w/o forwarding feasible?

[Yury Bokhoncovich]

Hello!

On Wed, 11 Sep 2002, Antony Stone wrote:

> On Wednesday 11 September 2002 2:39 pm, Yury Bokhoncovich wrote:
>
> > > Err, please explain why you do not want forwarding enabled.
> >
> > Because rule #1: "People makes mistakes". Disabled forwarding gives more
> > strict and reliable control under possible traffic.
>
> People make mistakes.   Agreed.
>
> But why does disabling forwarding in the kernel, and then providing some
> other mechanism for packets to get between the inside & outside, make
> mistakes any less likely ?   Surely there's still plenty of opportunities to
> make mistakes in whatever system you *do* set up to allow connectivity to the
> Internet, and if it's not as clear and standard as using netfilter, you might
> find it a lot less simple to locate and correct those mistakes ?

I do not intent to connect insiders to Internet as is through a router:
there are various proxies to do this. I gonna use Internet as communicaton
media to deliver traffic on different parts of our internal network (just
like 2W copper dedicated line or FO-link we have already) 'cos such media
is cheap and easy to get (in my case, of course).:-)

Agreed that to get Internet access a router is easiest and simplest
way, that's what iptables is for.:)

Understand that there is no out-of-box solution to do my intention yet.
Question: Should I go to the dev list or the PREROUTING/QUEUE features
save my life? I.e. is it possible to tweak iptables rules w/o hacks in
code? 8)

>
> > > When there are Ferraris out there for
> > > free, why build your own skoda?
> >
> > I didn't catch exactly what you mean as "skoda"
>
> Try Skoda = Trabant.   Does that help :-) ?
Ah. Gotcha. But I need Hummer, not Ferrari and, of course, not Trabant.
'cos that Ferrari cannot ride without roads. Hummer can do this.
Understandable analogy?8)

> regarded as a Good Thing(TM).   Therefore we now use iptables.
understand.

-- 
WBR, Yury Bokhoncovich, Senior System Administrator, NOC of F1 Group.
Phone: +7 (3832) 106228, ext.140, E-mail: byg@center-f1.ru.
Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.

using iptables to filter nimda. code red virus

[Joe de Vera Jr.]

hello fellas,

can i make use of the iptables scripting to disable the access pages... for
example for code red it access /default.ida page while in nimda /root.exe
and cmd.exe

is there a way to dis allow this..

thanks

Joe

Re: using iptables to filter nimda. code red virus

[Martijn Klingens]

On Thursday 12 September 2002 01:50, Joe de Vera Jr. wrote:
> can i make use of the iptables scripting to disable the access pages... for
> example for code red it access /default.ida page while in nimda /root.exe
> and cmd.exe
>
> is there a way to dis allow this..

Yes, use a transparent proxy like Squid or the Apache proxy module and setup 
the ACLs.

Netfilter only handles the layers 3 and 4 of the OSI model (and partly 2), but 
not the application-layers that you need.
-- 
Martijn

Re: using iptables to filter nimda. code red virus

[Antony Stone]

On Thursday 12 September 2002 12:50 am, Joe de Vera Jr. wrote:

> hello fellas,
>
> can i make use of the iptables scripting to disable the access pages... for
> example for code red it access /default.ida page while in nimda /root.exe
> and cmd.exe
>
> is there a way to dis allow this..

You are asking for a content filter, and iptables is a packet filter.   
Different things.

Try:
1. Blocking access in your httpd.conf file of your web server
2. Using a transparent proxy such as Apache to filter out things you don't 
want.
3. Hogwash.

Antony.

-- 

Documentation is like sex:
when it's good, it's very very good;
when it's bad, it's still better than nothing.

Filtering Nimda, Code Red and Code Red II

[Joe de Vera Jr.]

hello fellas,

can i make use of the iptables scripting to disable the access pages... for
example for code red it access /default.ida page while in nimda /root.exe
and cmd.exe

is there a way to dis allow this..

thanks

Joe

Re: Filtering Nimda, Code Red and Code Red II

[Anders Fugmann]

Joe de Vera Jr. wrote:
> hello fellas,
> 
> can i make use of the iptables scripting to disable the access pages... for
> example for code red it access /default.ida page while in nimda /root.exe
> and cmd.exe
To some extention yes. You should use the 'string' match and patch your 
kernel to support it, but it may not work in all cases.
The best way to stop it is to configure your webserver to disallow any 
requests  with the specified string. The webserver knows of the http 
protocol, iptables does not.

-- 
Author of FIAIF
FIAIF is an Intelligen/Iptables Firewall
http://fiaif.fugmann.dhs.org

Re: Filtering Nimda, Code Red and Code Red II

[Maciej Soltysiak]

> > can i make use of the iptables scripting to disable the access pages... for
> > example for code red it access /default.ida page while in nimda /root.exe
> > and cmd.exe
The short answer is no. Netfilter is a packet filter, it works on 3rd and
4th layer, You need a 5th layer application, like a proxy.

There are extensions to web browsers to prevent all those types of
attacks. Try www.ngsec.biz for information on modules to IIS and Apache
(yes, Apache also).

Also check out hogwash.

Regards,
Maciej Soltysiak

Re: Filtering Nimda, Code Red and Code Red II

[Antony Stone]

On Wednesday 11 September 2002 11:42 am, Maciej Soltysiak wrote:

> The short answer is no. Netfilter is a packet filter, it works on 3rd and
> 4th layer, You need a 5th layer application, like a proxy.

You're going to confuse people between OSI & TCP models if you say things 
like that around here :-)

Folks: don't try looking up the 5th layer of the TCP networking model :-)

Antony.

-- 

Never write it in Perl if you can do it in Awk.
Never do it in Awk if sed can handle it.
Never use sed when tr can do the job.
Never invoke tr when cat is sufficient.
Avoid using cat whenever possible.

Re: Filtering Nimda, Code Red and Code Red II

[Ramin Alidousti]

On Wed, Sep 11, 2002 at 01:48:04PM +0100, Antony Stone wrote:

> On Wednesday 11 September 2002 11:42 am, Maciej Soltysiak wrote:
> 
> > The short answer is no. Netfilter is a packet filter, it works on 3rd and
> > 4th layer, You need a 5th layer application, like a proxy.
> 
> Folks: don't try looking up the 5th layer of the TCP networking model :-)

What's wrong with his statement? As Maciej said the 5th layer of the IP model
is the application layer:

                 --------------
      layer 5   |  application |
                 --------------
      layer 4   |  TCP / UDP   |
                 --------------
      layer 3   |      IP      |
                 --------------
      layer 2   |  data link   |
                 --------------
      layer 1   |   physical   |
                 --------------

How many real networks do you know using the exact 7 layer OSI model?

Ramin

> Antony.

Re: Filtering Nimda, Code Red and Code Red II

[Roy Sigurd Karlsbakk]

> > Folks: don't try looking up the 5th layer of the TCP networking model :-)
>
> What's wrong with his statement? As Maciej said the 5th layer of the IP
> model is the application layer:
>
>                  --------------
>       layer 5   |  application |
>                  --------------
>       layer 4   |  TCP / UDP   |
>                  --------------
>       layer 3   |      IP      |
>                  --------------
>       layer 2   |  data link   |
>                  --------------
>       layer 1   |   physical   |
>                  --------------


You don't have any separate data link and physical layers in the IP model, as 
far as I remember. It's a 4-layer model, and goes something like this

+-------------+
| Application |
+-------------+
| Transport   |
+-------------+
| Network     |
+-------------+
| Physical    |
+-------------+

roy
-- 
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356

Computers are like air conditioners.
They stop working when you open Windows.

Re: Filtering Nimda, Code Red and Code Red II

[Ramin Alidousti]

On Wed, Sep 11, 2002 at 04:08:26PM +0200, Roy Sigurd Karlsbakk wrote:

> > > Folks: don't try looking up the 5th layer of the TCP networking model :-)
> >
> > What's wrong with his statement? As Maciej said the 5th layer of the IP
> > model is the application layer:
> >
> >                  --------------
> >       layer 5   |  application |
> >                  --------------
> >       layer 4   |  TCP / UDP   |
> >                  --------------
> >       layer 3   |      IP      |
> >                  --------------
> >       layer 2   |  data link   |
> >                  --------------
> >       layer 1   |   physical   |
> >                  --------------
> 
> 
> You don't have any separate data link and physical layers in the IP model, as 
> far as I remember. It's a 4-layer model, and goes something like this
> 
> +-------------+
> | Application |
> +-------------+
> | Transport   |
> +-------------+
> | Network     |
> +-------------+
> | Physical    |
> +-------------+

Yes. What it meant (IMO) is that IP doen't care about the layers below it.
It can be plugged into any LAN/WAN structure. But in the lowest layer in
your ASCII art there is still the seperation of the physical properties of
your medium (like electrical or optical properties) and link layer data
transfer (like framing, encoding, ...). Another reason for me to believe that
IP is at the third layer is the terminologies like "layer three switching",
L2TP ...

Ramin

> 
> roy
> -- 
> Roy Sigurd Karlsbakk, Datavaktmester
> ProntoTV AS - http://www.pronto.tv/
> Tel: +47 9801 3356
> 
> Computers are like air conditioners.
> They stop working when you open Windows.

Re: Filtering Nimda, Code Red and Code Red II

[Antony Stone]

On Wednesday 11 September 2002 3:40 pm, Ramin Alidousti wrote:

> On Wed, Sep 11, 2002 at 04:08:26PM +0200, Roy Sigurd Karlsbakk wrote:
> > > > Folks: don't try looking up the 5th layer of the TCP networking model
> > > > :-)
> > >
> > > What's wrong with his statement? As Maciej said the 5th layer of the IP
> > > model is the application layer:
> >
> > You don't have any separate data link and physical layers in the IP
> > model, as far as I remember. It's a 4-layer model, and goes something
> > like this
> >
> > | Application |
> > | Transport   |
> > | Network     |
> > | Physical    |
>
> Yes. What it meant (IMO) is that IP doen't care about the layers below it.
> It can be plugged into any LAN/WAN structure. But in the lowest layer in
> your ASCII art there is still the seperation of the physical properties of
> your medium (like electrical or optical properties) and link layer data
> transfer (like framing, encoding, ...). Another reason for me to believe
> that IP is at the third layer is the terminologies like "layer three
> switching", L2TP ...

That's correct, and that terminology refers to the 7-layer OSI networking 
model, where the Application layer is layer 7.   Agreed, hardly anyone knows 
what layers 5 and 6 are for in that model, but it's still a 7-layer model all 
the same.

There is no 5-layer networking model as far as I'm aware.

Antony.

-- 

Normal people think "if it ain't broke, don't fix it".
Engineers think "if it ain't broke, it doesn't have enough features yet".

Re: Filtering Nimda, Code Red and Code Red II

[Antony Stone]

On Wednesday 11 September 2002 2:59 pm, Ramin Alidousti wrote:

> On Wed, Sep 11, 2002 at 01:48:04PM +0100, Antony Stone wrote:
>
> > Folks: don't try looking up the 5th layer of the TCP networking model :-)
>
> What's wrong with his statement? As Maciej said the 5th layer of the IP
> model is the application layer:
>
>                  --------------
>       layer 5   |  application |
>                  --------------
>       layer 4   |  TCP / UDP   |
>                  --------------
>       layer 3   |      IP      |
>                  --------------
>       layer 2   |  data link   |
>                  --------------
>       layer 1   |   physical   |
>                  --------------

I've never seen that diagram anywhere before.   It doesn't correspond to the 
TCP model, where layer 4 is the Application layer (Data link and Physical are 
combined into layer 1), and it doesn't correspond to the OSI model, where 
layer 7 is the Application layer (layer 5 is the Session layer and 6 is the 
Presentation layer).

> How many real networks do you know using the exact 7 layer OSI model?

I don't know - I hardly ever operate above the Transport layer myself :-)

The point I'm making is that in neither of the two standard networking 
models, the de facto TCP model, or the de jure OSI model, is layer 5 called 
Application.

I'd be fascinated to see a reference for that diagram of yours above - or is 
it the Alidousti Network Model ?

Antony.

-- 

It is also possible that putting the birds in a laboratory setting
inadvertently renders them relatively incompetent.

 - Daniel C Dennett

Re: Filtering Nimda, Code Red and Code Red II

[Martijn Klingens]

On Wednesday 11 September 2002 11:21, Anders Fugmann wrote:
> Joe de Vera Jr. wrote:
> > hello fellas,
> >
> > can i make use of the iptables scripting to disable the access pages...
> > for example for code red it access /default.ida page while in nimda
> > /root.exe and cmd.exe
>
> To some extention yes. You should use the 'string' match and patch your
> kernel to support it, but it may not work in all cases.
> The best way to stop it is to configure your webserver to disallow any
> requests  with the specified string. The webserver knows of the http
> protocol, iptables does not.

Alternatively, use a reverse proxy server. Squid can perfectly do this 
filtering in reverse proxy mode. Microsoft's ISA Server does the same thing, 
but integrates it with a packet-filtering firewall in one big package (not 
necessarily a better package though! :)
-- 
Martijn

Re: Filtering Nimda, Code Red and Code Red II

[Fabrice MARIE]

On Thursday 12 September 2002 07:52, Joe de Vera Jr. wrote:
> hello fellas,
> can i make use of the iptables scripting to disable the access pages... for
> example for code red it access /default.ida page while in nimda /root.exe
> and cmd.exe
> is there a way to dis allow this..
> thanks
> Joe

Hello,

you really shouldn't use iptables for such purpose as there is no clean
and proper way to it in iptables. iptables is a packet filter. What you
need is an filtering application proxy, in your case a filtering HTTP proxy.
Read-on the mailing archive, and the iptables FAQ if you want to know
the full details.

Have a nice day,

Fabrice.
--
Fabrice MARIE
Senior R&D Engineer
Celestix Networks
http://www.celestix.com/

"Silly hacker, root is for administrators"
       -Unknown

Re: Filtering Nimda, Code Red and Code Red II

[Antony Stone]

On Thursday 12 September 2002 12:52 am, Joe de Vera Jr. wrote:

> hello fellas,
>
> can i make use of the iptables scripting to disable the access pages... for
> example for code red it access /default.ida page while in nimda /root.exe
> and cmd.exe
>
> is there a way to dis allow this..

You'd be better off doing this in your apache httpd.conf (or whatever server 
you happen to be using).

Netfilter is not really a content filter.

Antony.

-- 

Anyone that's normal doesn't really achieve much.

 - Mark Blair, Australian rocket engineer

Re: Filtering Nimda, Code Red and Code Red II

[Torge Szczepanek]

Am Don, 2002-09-12 um 01.52 schrieb Joe de Vera Jr.:
> can i make use of the iptables scripting to disable the access pages... for
> example for code red it access /default.ida page while in nimda /root.exe
> and cmd.exe
> 
> is there a way to dis allow this..

Compile in String Matching support.

Then do the following:

IPTABLES="/usr/sbin/iptables"

$IPTABLES -A INPUT -p tcp -i eth0 --dport 80 -m string \
               --string "/default.ida" -m state --state ESTABLISHED \
                       -j REJECT --reject-with tcp-reset

$IPTABLES -A INPUT -p tcp -i eth0 --dport 80 -m string \
               --string "/cmd.exe" -m state --state ESTABLISHED \
                       -j REJECT --reject-with tcp-reset
   
On a router/firewall replace INPUT by FORWARD and also adjust the -i and
or -o parameter.

Re: Filtering Nimda, Code Red and Code Red II

[Jozsef Kadlecsik]

On 12 Sep 2002, Torge Szczepanek wrote:

> Compile in String Matching support.
>
> Then do the following:
>
> IPTABLES="/usr/sbin/iptables"
>
> $IPTABLES -A INPUT -p tcp -i eth0 --dport 80 -m string \
>                --string "/default.ida" -m state --state ESTABLISHED \
>                        -j REJECT --reject-with tcp-reset
>
> $IPTABLES -A INPUT -p tcp -i eth0 --dport 80 -m string \
>                --string "/cmd.exe" -m state --state ESTABLISHED \
>                        -j REJECT --reject-with tcp-reset
>
> On a router/firewall replace INPUT by FORWARD and also adjust the -i and
> or -o parameter.

Please note that following this advice, the connection still will be alive
on the webserver. You might even encounter traffic as the server tries to
communicate with the client.

netfilter/iptables is a packet filtering solution and not a content
filter.

Regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Is DIVERT w/o forwarding feasible?

[Yury Bokhoncovich]

Hello!

We had found what we look for: TINC. JFYI.

On Wed, 11 Sep 2002, Anders Fugmann wrote:

> > I need an advice for this topic: is diverting without forwarding feasible?

> Technically yes. But you would have to spend alot of time coding, and 

-- 
WBR, Yury Bokhoncovich, Senior System Administrator, NOC of F1 Group.
Phone: +7 (3832) 106228, ext.140, E-mail: byg@center-f1.ru.
Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.