All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH] RPC match and conntrack modules v2.1
@ 2003-01-10 22:47 Ian Latter
  2003-01-11  0:05 ` Harald Welte
  0 siblings, 1 reply; 7+ messages in thread
From: Ian Latter @ 2003-01-10 22:47 UTC (permalink / raw)
  To: Harald Welte; +Cc: netfilter-devel

Hi Harald,

> This is cool stuff.  Thanks a lot.  The kind of contribution I really
> like :)

Cool, thanks .. :-)  I think there will be a lot of embedded firewall
manufacturers that will enjoy this one ...


> Sorry, I didn't understand the part about the NAT module.  Are you
> saying that NAT support is not functional right now?
That's correct - there was no NAT built into record-rpc, not even in an
old API.  I wanted to make the module set complete by writing the 
corresponding NAT module(s) but I didn't get time.  I might be re-inspired
later in January if no one else picks it up -- the code should be almost
identical to the RSH work module that I wrote, because the connection
handling is quite similar ..... actually ... maybe it doesn't need a nat helper;
the connections are all initiated from the client to the server, and the
internal protocols aren't carrying payloads that need to be rewritten ... so
as long as the nat stuff handles "related" streams sanely, then its
probably ok ...
 
> See attached patch.  Mostly CodingStyle updates (you seem to like 8 spaces
> instead of tab), but also a minor fix:
Cool ... could you resent it as a "zip" attachment ... my mail software
decodes text attachments which will make all the tabs in your patch
spaces again ...
 
> - when unloading, only unregister up to ports_n_c ports
ok

> btw: I'd really love to see the large chunk of code in the switch
> statement of the match() function in ipt_rpc.c be split up in seperate
> functions (thus reducing indentation and improving readability).
possibly could be ... the gumby way might be to do udp and tcp
functions ... but a better way might be to pull out the rpc payload
stuff .... I can take a look at that.
 
> I don't know, but I think esp. in cases where you have lots of rpc
> activity (NFS?, I'm not an RPC expert) it might be wise to use a slab
> cache for the 'struct request_p' list items.
I have not done that before, is there  an example some place in the
existing modules?

> Please integrate my patch [and maybe consider my suggestions, that's of
> course up to you], test it and resubmit it.
hopefully be done by the end of the weekend/early next week.
 
> Thanks!
Thanks for taking a look at it, and providing feed back ...

 
> > Regards,
> > Ian Latter
> 
> -- 
> - Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
> 
===========================================================================
=
> "If this were a dictatorship, it'd be a heck of a lot easier, just so long
>  as I'm the dictator."  --  George W. Bush Dec 18, 2000


--
Ian Latter
Internet and Networking Security Officer
Macquarie University

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: [PATCH] RPC match and conntrack modules v2.1
@ 2003-01-13  1:57 Ian Latter
  0 siblings, 0 replies; 7+ messages in thread
From: Ian Latter @ 2003-01-13  1:57 UTC (permalink / raw)
  To: Harald Welte; +Cc: netfilter-devel



Fantastic ... thanks.



----- Original Message -----
>From: "Harald Welte" <laforge@gnumonks.org>
>To: "Ian Latter" <Ian.Latter@mq.edu.au>
>Subject:  Re: [PATCH] RPC match and conntrack modules v2.1
>Date: Mon, 13 Jan 2003 02:32:26 +0100
>
> On Sun, Jan 12, 2003 at 09:33:07PM +1100, Ian Latter wrote:
> > Hi Harald,
> > 
> >   I didn't get your gz attachment, but I reassembled your patch from
> > the mailling list archive.
> 
> sorry, I missed that attachment :(
> 
> >   I have done all bar the cache implementation.  
> 
> Thanks. let's consider the slab cache as optional optimization, if
> needed this can be changed later.
> 
> >   I have done a fair bit of work on its cleanliness since you last
> > saw it.
> 
> great.  I'll apply your patch to CVS now.
> 
> -- 
> - Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
> 
==========================================================================
==
> "If this were a dictatorship, it'd be a heck of a lot easier, just so long
>  as I'm the dictator."  --  George W. Bush Dec 18, 2000
> 

--
Ian Latter
Internet and Networking Security Officer
Macquarie University

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: [PATCH] RPC match and conntrack modules v2.1
@ 2003-01-12 10:33 Ian Latter
  2003-01-13  1:32 ` Harald Welte
  0 siblings, 1 reply; 7+ messages in thread
From: Ian Latter @ 2003-01-12 10:33 UTC (permalink / raw)
  To: Harald Welte; +Cc: netfilter-devel

Hi Harald,

  I didn't get your gz attachment, but I reassembled your patch from
the mailling list archive.

  I have done all bar the cache implementation.  You may be  right
about its usage (and hence its performance) but I'm not sure -- if
NFS only does one RPC lookup per procedure then the ls data will
be a packet per file in the expectation, not the decision making 
process, which will put it out of my hands ... I don't have the gear
to test that particular scenario on hand.
  I would like to apply the cache stuff, but it looked a little challenging
for the time I had available.  I am also interested in combining the 
tcp and udp modules into a single module.
  I have done a fair bit of work on its cleanliness since you last
saw it.

  The file is on the ftp server -- it applies cleanly to 2.4.20.  I think
you'll be much happier with that implementation (v2.2).

  11572 Jan 12 21:08 pom-rpc-030112-01.tgz
  afd50da3f913ba860b69c74030b0a056  pom-rpc-030112-01.tgz


Let me know how you find it ...



----- Original Message -----
>From: "Harald Welte" <laforge@gnumonks.org>
>To: "Ian Latter" <Ian.Latter@mq.edu.au>
>Subject:  Re: [PATCH] RPC match and conntrack modules v2.1
>Date: Sat, 11 Jan 2003 01:05:55 +0100
>
> On Sat, Jan 11, 2003 at 09:47:01AM +1100, Ian Latter wrote:
> 
> > Cool, thanks .. :-)  I think there will be a lot of embedded firewall
> > manufacturers that will enjoy this one ...
> 
> agreed :)
> 
> > That's correct - there was no NAT built into record-rpc, not even in an
> > old API.  I wanted to make the module set complete by writing the 
> > corresponding NAT module(s) but I didn't get time.  I might be re-inspired
> > later in January if no one else picks it up -- the code should be almost
> > identical to the RSH work module that I wrote, because the connection
> > handling is quite similar ..... actually ... maybe it doesn't need a
> > nat helper; the connections are all initiated from the client to the
> > server, and the internal protocols aren't carrying payloads that need
> > to be rewritten ... so as long as the nat stuff handles "related"
> > streams sanely, then its probably ok ...
> 
> no problem, let's just ignore NAT for now.
> 
> > > See attached patch.  Mostly CodingStyle updates (you seem to like 8 spaces
> > > instead of tab), but also a minor fix:
> > Cool ... could you resent it as a "zip" attachment ... my mail software
> > decodes text attachments which will make all the tabs in your patch
> > spaces again ...
> 
> well, here it is as .gz again.  Strange mailclient you must be using...
> 
> > > btw: I'd really love to see the large chunk of code in the switch
> > > statement of the match() function in ipt_rpc.c be split up in seperate
> > > functions (thus reducing indentation and improving readability).
> > possibly could be ... the gumby way might be to do udp and tcp
> > functions ... but a better way might be to pull out the rpc payload
> > stuff .... I can take a look at that.
> 
> thanks.
> 
> > > I don't know, but I think esp. in cases where you have lots of rpc
> > > activity (NFS?, I'm not an RPC expert) it might be wise to use a slab
> > > cache for the 'struct request_p' list items.
> > I have not done that before, is there  an example some place in the
> > existing modules?
> 
> yes, it's done in ip_conntrack_core. see kmem_cache_create /
> kmem_cache_alloc / and related functions.   The idea is for the memory
> management to keep a pool of memory chunks of the requested size around,
> in case they are heavily allocated / deallocated.  We do this with
> struct sk_buff, struct ip_conntrack.
> 
> I'm not sure whether it's worth the effort in the rpc case... But if I'm
> not mistaken in NFSv2, every single file in an 'ls' is a seperate RPC
> request/reply, isn't it?
> 
> > > Please integrate my patch [and maybe consider my suggestions, that's of
> > > course up to you], test it and resubmit it.
> > hopefully be done by the end of the weekend/early next week.
> 
> no problem, I'll be off over the wekend anyway.
> 
> > > Thanks!
> > Thanks for taking a look at it, and providing feed back ...
> 
> You're welcome.
> > --
> > Ian Latter
> 
> -- 
> - Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
> 
===========================================================================
=
> "If this were a dictatorship, it'd be a heck of a lot easier, just so long
>  as I'm the dictator."  --  George W. Bush Dec 18, 2000
> 

--
Ian Latter
Internet and Networking Security Officer
Macquarie University

^ permalink raw reply	[flat|nested] 7+ messages in thread
* [PATCH] RPC match and conntrack modules v2.1
@ 2003-01-10  8:26 Ian Latter
  2003-01-10 13:45 ` Harald Welte
  0 siblings, 1 reply; 7+ messages in thread
From: Ian Latter @ 2003-01-10  8:26 UTC (permalink / raw)
  To: netfilter-devel; +Cc: marcelo.lima

Hello all,

  I too had too much Xmas idle time and for some reason I couldn't get
enough coding done ... too long between programming sessions, me 
thinks.

  I have uploaded, to the ftp.netfilter.org site, a copy of the new patch-
o-matic ready code.  Let me know what you think of it ... I don't have a
lot of need for RPC traffic filtering, but when I realised that the Linux
kernel filtering for RPCs was limited to the old "record-rpc" modules, I
had to upgrade them ... I wanted some of that CheckPoint functionality
in my favourite filtering API  :oP

  The new modules will allow filtering on RPC procedures (by name or
number).  The intended usage of these modules would be with a ruleset 
like;

    # New session from client to server (rpc portmapper get)
    -A PREROUTING -t nat -i eth0 -p udp -m rpc --rpcs 100002
           -s ${client} --sport 0:1023 -d ${server} --dport 111
           -j ACCEPT

    # Continued session from client to client (port mapper answer)
    -A PREROUTING -t nat -i eth1 -m state -p udp
           -s ${server} --sport 111 -d ${client} --dport 0:1023
           --state ESTABLISHED -j ACCEPT

    # New session from client to server (procedure call)
    -A PREROUTING -t nat -i eth0 -m state -p udp
          -s ${client} --sport 0:65535
          -d ${server} --dport 32000:34000
          --state ESTABLISHED,RELATED -j ACCEPT

    # Continued session from client to server (procedure response)
    -A PREROUTING -t nat -i eth1 -m state -p udp
           -s ${server} --sport 32000:34000
           -d ${client} --dport 0:65535
           --state ESTABLISHED -j ACCEPT


  Which would allow rusers to execute from client to server;

     user@client# rusers $server


Note that if that first rule was without the --rpcs option;
    -A PREROUTING -t nat -i eth0 -p udp -m rpc
           -s ${client} --sport 0:1023 -d ${server} --dport 111
           -j ACCEPT

... then it would behave like the existing oldnat module; simply
"recording" RPC get commands via the portmapper, and letting
them through from the same host when they're a complete
procedure call.


Also note that I've updated the module for newnat, and it compiles
cleanly against 2.4.20.  I was half tempted to author the NAT module
to go with the conntrack and match, but this code has taken too 
much time already.


0f759135c2b2aae5bc39b3ed0f633749  pom-rpc-030110-01.tgz
11371 bytes size

  Comments welcome and appreciated.


Regards,


--
Ian Latter
Internet and Networking Security Officer
Macquarie University

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2003-01-13  1:57 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-10 22:47 [PATCH] RPC match and conntrack modules v2.1 Ian Latter
2003-01-11  0:05 ` Harald Welte
  -- strict thread matches above, loose matches on Subject: below --
2003-01-13  1:57 Ian Latter
2003-01-12 10:33 Ian Latter
2003-01-13  1:32 ` Harald Welte
2003-01-10  8:26 Ian Latter
2003-01-10 13:45 ` Harald Welte

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.