Questions regarding routing in the stack

Questions regarding routing in the stack

[JC]

I was hoping someone could possibly shed some light into this or at
least point me to the right direction...

I am trying to develop a kernel module level solution for dynamic host
multihoming. This requires that I mangle packets from specific
applications running on the system right in the stack and basically
change the interface the packets are sent from (at least two
interfaces).

I understand that I need to register my mangling function with one of
the 5 netfilter hooks (the ROUTING one?), grab the interesting packets
and change..... something in the skbuff.

What really evades me is where/when does routing *exactly* happen. If
I know at which point it happens, I should tap right after it and
change the interface to the one I want. Or this whole idea could be
bad and I end up breaking something in the
packet and it gets dropped...

Of course, that needs to happen for both locally generated traffic and
incoming traffic, so that I link the incoming packets to the right
applications.

regards,
JC

Re: Questions regarding routing in the stack

[Carl Holtje ;021;vcsg6;]

On Thu, 21 Jul 2005, JC wrote:

> I was hoping someone could possibly shed some light into this or at
> least point me to the right direction...
>
> I am trying to develop a kernel module level solution for dynamic host
> multihoming. This requires that I mangle packets from specific
> applications running on the system right in the stack and basically
> change the interface the packets are sent from (at least two
> interfaces).
>
> I understand that I need to register my mangling function with one of
> the 5 netfilter hooks (the ROUTING one?), grab the interesting packets
> and change..... something in the skbuff.
>
> What really evades me is where/when does routing *exactly* happen. If
> I know at which point it happens, I should tap right after it and
> change the interface to the one I want. Or this whole idea could be
> bad and I end up breaking something in the
> packet and it gets dropped...

At some point, I found this and squirreled it away:

# .========================================================.
# | PACKET PROCESSING PATH                                 |
# +========================================================+
#
# Arriving Packets
# ==========================================================
# No.   | Table         | Chain         | Description
# ----------------------------------------------------------
# 1     |               |               | On the wire
# 2     |               |               | At interface
# 3     | Mangle        | PREROUTING    |
# 4     | NAT           | PREROUTING    |
# 5     |               |               | Routing descision
# 6     | Mangle        | INPUT         |
# 7     | Filter        | INPUT         |
# 8     |               |               | To application
#
# Departing Packets
# ==========================================================
# No.   | Table         | Chain         | Description
# ----------------------------------------------------------
# 1     |               |               | From Application
# 2     |               |               | Routing decision
# 3     | Mangle        | OUTPUT        |
# 4     | NAT           | OUTPUT        |
# 5     | Filter        | OUTPUT        |
# 6     | Mangle        | POSTROUTING   |
# 7     |               |               | At interface
# 8     |               |               | On the wire
#
# Forwarding Packets
# ==========================================================
# No.   | Table         | Chain         | Description
# ----------------------------------------------------------
# 1     |               |               | From Application
# 2     |               |               | Routing
# 3     | Mangle        | PREROUTING    |
# 4     | NAT           | PREROUTING    |
# 5     |               |               | Routing decision
# 6     | Mangle        | FORWARD       |
# 7     | Filter        | FORWARD       |
# 8     | Mangle        | POSTROUTING   |
# 9     | NAT           | POSTROUTING   |
# 10    |               |               | At interface
# 11    |               |               | On the wire


> Of course, that needs to happen for both locally generated traffic and
> incoming traffic, so that I link the incoming packets to the right
> applications.

Why does this sound like NAT, where you take data from one interface and
spit it out on another (receive is done the same way)?

Hope this helps..

- --

"There are 10 types of people in the world: Those who understand binary
and those that don't."

Re: Questions regarding routing in the stack

[JC]

The diagram is helpfull, thank you. I'll give it a thorough look...

> > Of course, that needs to happen for both locally generated traffic and
> > incoming traffic, so that I link the incoming packets to the right
> > applications.
>
> Why does this sound like NAT, where you take data from one interface and
> spit it out on another (receive is done the same way)?

It is a kind of NATing, just changing the IP/interface. The thing is
the rules are not static, they can change at a high rate. Definitely
not confident changing the rules with a script rewritting/reloading
the ruleset will not break it at some point. I am currently thinking
of writting a netfilter module of some sort that will handle this out.

Re: Questions regarding routing in the stack

[Jan Engelhardt]

>At some point, I found this and squirreled it away:

http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png
this one is just as good ;)



Jan Engelhardt
-- 

Re: Questions regarding routing in the stack

[Donald Murray]

On 7/21/05, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
*SNIP*
> 
> http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png
> this one is just as good ;)
> 
> 
> 
> Jan Engelhardt
> --
> 
> 

Just as good? It's awesome.

I'm sending all my ASCII diagrams to the shredder.

Re: Questions regarding routing in the stack

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 22 Jul 2005, Donald Murray wrote:

> On 7/21/05, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> *SNIP*
>>
>> http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png
>> this one is just as good ;)
>>
>>
>>
>> Jan Engelhardt
>> --
>>
>>
>
> Just as good? It's awesome.
>
> I'm sending all my ASCII diagrams to the shredder.
>
>

bummer us folks that have been around awhile prefer ascii, and hate 
web/html based mail, scourge of the net...point and click is fer windows 
and browsing on the toy OS....



Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFC4Y7Mst+vzJSwZikRAlACAJ9ZtQ9BcUVIs68vvNnX1LFOu2yLxQCfYwpG
x1vItV/db06m1IXk1GH2jjA=
=suVX
-----END PGP SIGNATURE-----

Re: Questions regarding routing in the stack

[Jan Engelhardt]

>> > http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png
>> Just as good? It's awesome.
>> I'm sending all my ASCII diagrams to the shredder.
>
> bummer us folks that have been around awhile prefer ascii, and hate web/html
> based mail, scourge of the net...point and click is fer windows and browsing on
> the toy OS....

png is not html. and for anything else, you can use some bmp2txt.
it is not point&click either. I have a ton of xterms open and graphics is
only done when required. I doubt you can display such a detailed flow chart
in 80x25.


Jan Engelhardt
-- 

Re: Questions regarding routing in the stack

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 23 Jul 2005, Jan Engelhardt wrote:

>>>> http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png
>>> Just as good? It's awesome.
>>> I'm sending all my ASCII diagrams to the shredder.
>>
>> bummer us folks that have been around awhile prefer ascii, and hate web/html
>> based mail, scourge of the net...point and click is fer windows and browsing on
>> the toy OS....
>
> png is not html. and for anything else, you can use some bmp2txt.
> it is not point&click either. I have a ton of xterms open and graphics is
> only done when required. I doubt you can display such a detailed flow chart
> in 80x25.
>

though I recall a few recent sploits on the *nix side that would be 
crafted wth png files, no?

Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFC4sPBst+vzJSwZikRAmhZAJ4yFqI2L9ZasNTlx9n9Ep5IZPpsGwCg1P3+
3nTA9/Pt3gBTqSJ+Kkj8tsE=
=IiPD
-----END PGP SIGNATURE-----

Re: Questions regarding routing in the stack

[Jan Engelhardt]

>
> though I recall a few recent sploits on the *nix side that would be crafted wth
> png files, no?

You did update, did not you?


Jan Engelhardt
-- 

Re: Questions regarding routing in the stack

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 24 Jul 2005, Jan Engelhardt wrote:

>>
>> though I recall a few recent sploits on the *nix side that would be crafted wth
>> png files, no?
>
> You did update, did not you?
>


oh, yes, of course, but, was that a one timer or repeat?  Snedmail/ftp 
used to be things like bind that had to be watched daily, now days it is 
openssh/openssl and others, and if yer in the M$ world, yer updating 
things that the *nix workd learned ten yearts bask with rcp and such.  So, 
these are not fix once and forget kinds of issues.

e-mail was meant to push text, plain and simple, what makes things complex 
tends to make things not function ass we as or even at all like they were 
intended.  And html and ports 80/443 are the scourge of security admins 
these days, everything gets pushed over those ports and is near impossible 
to control in any reasonable manner.  besides, some of the poorer mua's 
folks use and use in public lists like this tend to push html in ishy ways 
that makes my reading pleasure not...those folks I just tend to not read, 
and perhaps miss something that might be interesting or inportant, but, I 
just don't have the time to wsate trying to fix the crap that those mua's 
pushout...

Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFC43j1st+vzJSwZikRArrbAJ9c4PQSqftT4ONEIJElzdBiiUtzhgCgqBD2
sXVrHrG3nXPK+UFOBSVr+xA=
=7jSn
-----END PGP SIGNATURE-----