On Fri, 31 Aug 2007 22:09:42 +0200
Mel <[EMAIL PROTECTED]> wrote:
> On Friday 31 August 2007 18:27:26 Norberto Meijome wrote:
> > On Fri, 31 Aug 2007 17:40:06 +0200
> >
> > Mel <[EMAIL PROTECTED]> wrote:
> > > > netsed's output is (part ) :
> > > > ---
> > > > Script started on Fri Aug 31 07:52:12 2007
> > > > [EMAIL PROTECTED] /usr/home/luser]# netsed tcp 10101 0 0 s/FOO/BAR
> > > > netsed 0.01b by Michal Zalewski <[EMAIL PROTECTED]>
> > > > [*] Parsing rule s/FOO/BAR ...
> > > > [+] Loaded 1 rules...
> > > > [+] Listening on port 10101/tcp.
> > > > [+] Using dynamic (transparent proxy) forwarding.
> > > >
> > > > [+] Got incoming connection from 172.16.82.81:1178 to 127.0.0.1:10101
> > > > [*] Forwarding connection to 127.0.0.1:10101
> > > > [+] Got incoming connection from 127.0.0.1:51337 to 127.0.0.1:10101
> > > > [*] Forwarding connection to 127.0.0.1:10101
> > > > [+] Caught client -> server packet.
> > >
> > > I think you need to figure out what this 'transparent proxy mode' of
> > > netsed does, cause it should under no circumstances forward to itself...
> >
> > it simply forwards the packet to the dst_ip:dst_port it originally had.
> > But, as Daniel H pointed out, those packets had been rewritten by pf's rdr
> > to go TO netsed's ip:port .... hence netsed wont change anything. It works
> > fine in non-proxy mode, but as I said in my first msg, that is not an
> > option for me.
> >
> > So the obvious question is how to get the packets to netsed's IP:PORT
> > without having the packet's original destination IP/PORT changed....maybe
> > incorporating the netsed code into a socks5-compatible server (in my case,
> > the app that generates the packets understands SOCKS). Alas, I am drawing a
> > blank here atm.
> >
> > Otherwise, i can only think that a new netgraph node would perform better
> > than my current pf + netsed approach....
>
> Figured I'd take a shot at it and it works:
> # ./netsed tcp 10101 0 0 s/boo/GET/
> netsed 0.01b by Michal Zalewski <[EMAIL PROTECTED]>
> [*] Parsing rule s/boo/GET/...
> [+] Loaded 1 rules...
> [+] Listening on port 10101/tcp.
> [+] Using dynamic (transparent proxy) forwarding.
> [+] Got incoming connection from 11.22.33.44:27712 to 127.0.0.1:10101
> [*] Forwarding connection to 55.66.77.88:80
> [+] Caught client -> server packet.
>
> Renamed the ip's to protect the innocent, but that's all. I typed boo /
> HTTP/1.0 and got back a solid page of html.
> Patch inlined below sig. I'm surprised no one ever caught up on this, seeing
> the makefile is last modified in 2005 :)
>
Mel,
Thanks so very much for putting this together. It works a charm. I may put
together some BSD specific documentation for this port, and possible add some
build-time options to the port.
Also, if memory serves me right, ipfw's divert may not be modifying the packets
: i have used ipfw diver with the tcpmss daemon and there were no issues - of
course, it may be that tcpmss checked with ipfw's table to see what change had
been done, in which case netsed should support it too.
Humbled again, grateful and proud of OSS,
B
_________________________
{Beto|Norberto|Numard} Meijome
"I've dirtied my hands writing poetry, for the sake of seduction; that is, for
the sake of a useful cause."
Dostoevsky
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
