Re: pf rdr + netsed : reinject loop...
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 changedmaybe
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]
pf rdr + netsed : reinject loop...
Hello everyone, I need your help / insight here :)
My setup, 2 VMs, XP (WinXP) and BSD (FreeBSD 6.2)
[XP ,172.16.82.81 ] --- [172.16.82.81,em1 BSD A.B.C.D,em0] --- The Interweb
[Other_servers_galore]
A.B.C.D is a public IP.
[Other_servers_galore] represents all and any servers XP wants to talk to . I
really don't know either port or IP of these servers.
BSD is performing as gateway for XP , with NAT on em0 using pf.
I want to replace certain bytes (FOO) in TCP packets between XP and
[Other_servers_galore] for other bytes (BAR). Vlad Galu pointed out that
net/netsed can help with this (with overhead, i know, this is only a test ).
(Thanks again! )
so what I have setup :
1) pf.conf has :
ext_if=em0
int_if=em1
nat on $ext_if from $internal_net to any - ($ext_if)
rdr on $int_if proto tcp from 172.16.82.81 to any - 127.0.0.1 port 10101
-
2) I run netsed in transparent proxy mode as :
netsed tcp 10101 0 0 s/FOO/BAR
---
The traffic from XP gets redirected just fine to netsed, which replaces the
bytes just fine. BUT the changed packets (the output of netsed) get reinjected
somewhere so that the rdr hits them again, sending them back to netsed ad
infinitum. ( yes, i managed to hit a load of 700+ without anything ever leaving
BSD ...quite cool)
Now, netsed works just fine in that setup if I define the IP, eg :
pf.conf :
ext_if=em0
int_if=em1
nat on $ext_if from $internal_net to any - ($ext_if)
rdr on $int_if proto tcp from 172.16.82.81 to O.P.Q.R - 127.0.0.1 port 10101
netsed :
netsed tcp 10101 O.P.Q.R 0 s/FOO/BAR
traffic goes to the external server O.P.Q.R ... but this was just a proof of
concept, as I really can't tell the remote IPs in advance
How do I modify this setup so that netsed packets aren't caught again by pf's
rdr and sent back into netsed ? I'm happy to try other tools / setups...
thanks for your time and any help you can provide :)
B
_
{Beto|Norberto|Numard} Meijome
Great spirits have often encountered violent opposition from mediocre minds.
Albert Einstein
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]
Re: pf rdr + netsed : reinject loop...
On Fri, Aug 31, 2007 at 08:27:29PM +1000, Norberto Meijome wrote: rdr on $int_if proto tcp from 172.16.82.81 to any - 127.0.0.1 port 10101 netsed tcp 10101 0 0 s/FOO/BAR The traffic from XP gets redirected just fine to netsed, which replaces the bytes just fine. BUT the changed packets (the output of netsed) get reinjected somewhere so that the rdr hits them again, sending them back to netsed ad infinitum. ( yes, i managed to hit a load of 700+ without anything ever leaving BSD ...quite cool) I'm pretty sure the endless loop you describe does not pass through pf, except for the first iteration. In the first iteration, pf replaces the destination address with 127.0.0.1, and the packet goes to netsed. netsed changes the payload, but leaves the destination address (127.0.0.1 now). It sends the packet out, and since the destination address is 127.0.0.1, it sends it to itself. Hence the loop, which does not involve pf any further (i.e. there's no 'redirecting again' or such, AFAICT). rdr on $int_if proto tcp from 172.16.82.81 to O.P.Q.R - 127.0.0.1 port 10101 netsed tcp 10101 O.P.Q.R 0 s/FOO/BAR How do I modify this setup so that netsed packets aren't caught again by pf's rdr and sent back into netsed ? I'm happy to try other tools / setups... Two approaches are possible: a) You modify netsed so it will query pf about the original destination address (O.P.Q.R), and re-insert that before sending out its modified packet. The DIOCNATLOOK ioctl(2) call can be used for that, see pf(4) for details and e.g. the squid source (ports) for how it's used. b) Instead of replacing the destination address in pf with rdr, try leaving it as it is, but use route-to (lo0) to get the packet routed to the loopback interface. This would require netsed to listen on INADDR_ANY (or use a raw socket, I haven't checked its source code). Daniel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf rdr + netsed : reinject loop...
On Fri, 31 Aug 2007 13:13:12 +0200
Mel [EMAIL PROTECTED] wrote:
I think you're looking for tagging, for example:
rdr on $int_if proto tcp from 172.16.82.81 to any tag NETSED - 127.0.0.1
port
10101
Then you need to figure out how they come back and pass them through, for
example:
pass in on $int_if proto tcp tagged NETSED keep state
See pf.conf(5) for more info. The examples section has one for spamd
redirection.
Mel, i think you are right. Thanks, I just haven't had my brain switched on.
I'll read the documentation and reply back with a solution for the list.
thanks so much again! :)
B
_
{Beto|Norberto|Numard} Meijome
Do not take away the camels hump, you may be stopping him from being a camel.
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]
Re: pf rdr + netsed : reinject loop...
On Friday 31 August 2007 12:27:29 Norberto Meijome wrote: 1) pf.conf has : ext_if=em0 int_if=em1 nat on $ext_if from $internal_net to any - ($ext_if) rdr on $int_if proto tcp from 172.16.82.81 to any - 127.0.0.1 port 10101 - 2) I run netsed in transparent proxy mode as : netsed tcp 10101 0 0 s/FOO/BAR --- The traffic from XP gets redirected just fine to netsed, which replaces the bytes just fine. BUT the changed packets (the output of netsed) get reinjected somewhere so that the rdr hits them again, sending them back to netsed ad infinitum. ( yes, i managed to hit a load of 700+ without anything ever leaving BSD ...quite cool) I think you're looking for tagging, for example: rdr on $int_if proto tcp from 172.16.82.81 to any tag NETSED - 127.0.0.1 port 10101 Then you need to figure out how they come back and pass them through, for example: pass in on $int_if proto tcp tagged NETSED keep state See pf.conf(5) for more info. The examples section has one for spamd redirection. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf rdr + netsed : reinject loop...
On Fri, 31 Aug 2007 13:33:53 +0200 Daniel Hartmeier [EMAIL PROTECTED] wrote: On Fri, Aug 31, 2007 at 08:27:29PM +1000, Norberto Meijome wrote: rdr on $int_if proto tcp from 172.16.82.81 to any - 127.0.0.1 port 10101 netsed tcp 10101 0 0 s/FOO/BAR The traffic from XP gets redirected just fine to netsed, which replaces the bytes just fine. BUT the changed packets (the output of netsed) get reinjected somewhere so that the rdr hits them again, sending them back to netsed ad infinitum. ( yes, i managed to hit a load of 700+ without anything ever leaving BSD ...quite cool) I'm pretty sure the endless loop you describe does not pass through pf, except for the first iteration. In the first iteration, pf replaces the destination address with 127.0.0.1, and the packet goes to netsed. netsed changes the payload, but leaves the destination address (127.0.0.1 now). It sends the packet out, and since the destination address is 127.0.0.1, it sends it to itself. Hence the loop, which does not involve pf any further (i.e. there's no 'redirecting again' or such, AFAICT). I was just reaching the same conclusion after some strong coffee 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. Applying rule s/FOO/BAR... [*] Done 1 replacements, forwarding packet of size 466 (orig 466). [+] Caught client - server packet. [+] Got incoming connection from 127.0.0.1:53272 to 127.0.0.1:10101 [*] Forwarding connection to 127.0.0.1:10101 [*] Forwarding untouched packet of size 466. [+] Got incoming connection from 127.0.0.1:56367 to 127.0.0.1:10101 [*] Forwarding connection to 127.0.0.1:10101 [+] Caught client - server packet. [*] Forwarding untouched packet of size 466. [+] Got incoming connection from 127.0.0.1:50565 to 127.0.0.1:10101 [*] Forwarding connection to 127.0.0.1:10101 [+] Caught client - server packet. [*] Forwarding untouched packet of size 466. [+] Got incoming connection from 127.0.0.1:61660 to 127.0.0.1:10101 [*] Forwarding connection to 127.0.0.1:10101 [+] Caught client - server packet. [*] Forwarding untouched packet of size 466. [+] Got incoming connection from 127.0.0.1:51520 to 127.0.0.1:10101 [*] Forwarding connection to 127.0.0.1:10101 [+] Caught client - server packet. [*] Forwarding untouched packet of size 466. [+] Got incoming connection from 127.0.0.1:63554 to 127.0.0.1:10101 [*] Forwarding connection to 127.0.0.1:10101 [+] Caught client - server packet. [*] Forwarding untouched packet of size 466. --- From another run, sockstat -4 shows (starting from bottom, which seem to have the starting connections): root netsed 3201 3 tcp4 *:10101 *:* root netsed 3201 4 tcp4 127.0.0.1:10101 127.0.0.1:64110 root netsed 3201 5 tcp4 127.0.0.1:55906 127.0.0.1:10101 root netsed 3200 3 tcp4 *:10101 *:* root netsed 3200 4 tcp4 127.0.0.1:10101 127.0.0.1:57224 root netsed 3200 5 tcp4 127.0.0.1:64110 127.0.0.1:10101 root netsed 3199 3 tcp4 *:10101 *:* root netsed 3199 4 tcp4 127.0.0.1:10101 127.0.0.1:55434 root netsed 3199 5 tcp4 127.0.0.1:57224 127.0.0.1:10101 root netsed 3198 3 tcp4 *:10101 *:* root netsed 3198 4 tcp4 127.0.0.1:10101 127.0.0.1:64816 root netsed 3198 5 tcp4 127.0.0.1:55434 127.0.0.1:10101 root netsed 3197 3 tcp4 *:10101 *:* root netsed 3197 4 tcp4 127.0.0.1:10101 127.0.0.1:61595 root netsed 3197 5 tcp4 127.0.0.1:64816 127.0.0.1:10101 root netsed 3196 3 tcp4 *:10101 *:* root netsed 3196 4 tcp4 127.0.0.1:10101 127.0.0.1:58293 root netsed 3196 5 tcp4 127.0.0.1:61595 127.0.0.1:10101 root netsed 3195 3 tcp4 *:10101 *:* root netsed 3195 4 tcp4 127.0.0.1:10101 172.16.82.81:1179 root netsed 3195 5 tcp4 127.0.0.1:58293 127.0.0.1:10101 root netsed 3194 3 tcp4 *:10101 *:* root netsed 3194 4 tcp4 127.0.0.1:10101 127.0.0.1:53543 --- so it does seem that one netsed is feeding the other... This explains why using pf tags isn't helping here, probably for this reason I'm only now getting acquired in depth with PF (been using ipf and ipfw until now... ) , so i'm sure that's not
Re: pf rdr + netsed : reinject loop...
On Fri, 31 Aug 2007 13:33:53 +0200
Daniel Hartmeier [EMAIL PROTECTED] wrote:
b) Instead of replacing the destination address in pf with rdr, try
leaving it as it is, but use route-to (lo0) to get the packet routed to
the loopback interface. This would require netsed to listen on
INADDR_ANY (or use a raw socket, I haven't checked its source code).
Hi Daniel,
I tried this but i only managed to lock up the BSD VM a couple of times (not
even console access, so it was not just network affected). I am not sure if
i've done this correctly ..
pass in on $int_if route-to 127.0.0.1 proto tcp from 172.16.82.81 to O.P.Q.R
tag ROUTED keep state
is that ok ? ( tried also doing route-to 127.0.0.1 $external_addr with no
visible change.) I have logging enabled specifically on lo0 , but i dont see
any packets going through.
I am not entirely sure how netsed will pick up this packets. I've had netsed
listening on *:{port} and 127.0.0.1:{port} and it obviously didnt make any
difference. Could you point me to any reference / sample of what you mean?
thx again,
B
_
{Beto|Norberto|Numard} Meijome
I used to hate weddings; all the Grandmas would poke me and
say, You're next sonny! They stopped doing that when i
started to do it to them at funerals.
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]
Re: pf rdr + netsed : reinject loop...
On Friday 31 August 2007 15:10:15 Norberto Meijome wrote: On Fri, 31 Aug 2007 13:33:53 +0200 Daniel Hartmeier [EMAIL PROTECTED] wrote: On Fri, Aug 31, 2007 at 08:27:29PM +1000, Norberto Meijome wrote: rdr on $int_if proto tcp from 172.16.82.81 to any - 127.0.0.1 port 10101 netsed tcp 10101 0 0 s/FOO/BAR The traffic from XP gets redirected just fine to netsed, which replaces the bytes just fine. BUT the changed packets (the output of netsed) get reinjected somewhere so that the rdr hits them again, sending them back to netsed ad infinitum. ( yes, i managed to hit a load of 700+ without anything ever leaving BSD ...quite cool) I'm pretty sure the endless loop you describe does not pass through pf, except for the first iteration. In the first iteration, pf replaces the destination address with 127.0.0.1, and the packet goes to netsed. netsed changes the payload, but leaves the destination address (127.0.0.1 now). It sends the packet out, and since the destination address is 127.0.0.1, it sends it to itself. Hence the loop, which does not involve pf any further (i.e. there's no 'redirecting again' or such, AFAICT). I was just reaching the same conclusion after some strong coffee 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... -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf rdr + netsed : reinject loop...
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 changedmaybe 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
cheers,
B
_
{Beto|Norberto|Numard} Meijome
Ninety percent of the time things turn out worse than you thought they would.
The other ten percent of the time you had no right to expect that much.
Augustine
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]
Re: pf rdr + netsed : reinject loop...
On Friday 31 August 2007 19:12:42 Mel 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.
OK, I just tried to verify if rdr rewrites dest and indeed it does from
netsed's point of view (didn't know my machine could go to 100 load and
still catch SIGINT).
Now I wonder how ftp-proxy(8) ever gets the server address. Time to view
the source.
Ah, here we go:
/usr/src/contrib/pf/ftp-proxy/util.c:115:
/*
* Open the pf device and lookup the mapping pair to find
* the original address we were supposed to connect to.
*/
fd = open(/dev/pf, O_RDWR);
if (fd == -1) {
syslog(LOG_ERR, cannot open /dev/pf (%m));
exit(EX_UNAVAILABLE);
}
if (ioctl(fd, DIOCNATLOOK, natlook) == -1) {
syslog(LOG_INFO,
pf nat lookup failed %s:%hu (%m),
inet_ntoa(client_sa_ptr-sin_addr),
ntohs(client_sa_ptr-sin_port));
close(fd);
return(-1);
}
close(fd);
So, in short, netsed needs extra code to deal with pf (and probably others
since only a linux iptables example is listed in README) and the port
maintainer should add a warning that transparent proxy mode does not (yet)
work with pf/ipfw/ipf.
In addition you need write access to /dev/pf :)
--
Mel
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf rdr + netsed : reinject loop...
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. OK, I just tried to verify if rdr rewrites dest and indeed it does from netsed's point of view (didn't know my machine could go to 100 load and still catch SIGINT). Now I wonder how ftp-proxy(8) ever gets the server address. Time to view the source. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf rdr + netsed : reinject loop...
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 changedmaybe
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
--- orig/netsed.c 2007-08-31 21:51:51.0 +0200
+++ work/netsed.c 2007-08-31 21:51:31.0 +0200
@@ -11,6 +11,12 @@
#include ctype.h
#include stdlib.h
#include signal.h
+#ifdef USE_PF
+#include sys/ioctl.h
+#include net/if.h
+#include net/pfvar.h
+#include sysexits.h
+#endif
#define VERSION 0.01b
#define MAXRULES 50
@@ -254,11 +260,19 @@
signal(SIGCHLD,sig_chld);
// Am I bad coder?;
+ /* Yeah, comments should be useful and frequent and not in C++ format. */
while (1) {
struct sockaddr_in s;
int x,l=sizeof(struct sockaddr_in);
int conho,conpo;
+#ifdef USE_PF
+struct pfioc_natlook natlook;
+int fd;
+socklen_t clen; /* client length */
+struct sockaddr_in *client; /* client socket */
+#endif
+
usleep(1000); // Do not wanna select ;P
if ((csock=accept(lsock,(struct sockaddr*)s,l))=0) {
fcntl(csock,F_SETFL,O_NONBLOCK);
@@ -266,8 +280,51 @@
l=sizeof(struct sockaddr_in);
getsockname(csock,(struct sockaddr*)s,l);
printf( to %s:%d\n, inet_ntoa(s.sin_addr), ntohs(s.sin_port));
+ /* The logic here is that it receives an unmodified dest address,
+ * however that's not the case with pf. */
+#ifdef USE_PF
+ /* We also need the client peer to look up the nat in pf, blatantly
+ * borrowed from ftp-proxy(8). */
+ clen = sizeof(struct sockaddr_in);
+ client = (struct sockaddr_in *)malloc(clen);
+ getpeername(csock, (struct sockaddr *)client, clen);
+ memset((void *)natlook, 0, sizeof(natlook));
+ natlook.af = AF_INET;
+ natlook.saddr.addr32[0] = client-sin_addr.s_addr;
+ natlook.daddr.addr32[0] = s.sin_addr.s_addr;
+ natlook.proto = IPPROTO_TCP;
+ natlook.sport = client-sin_port;
+ natlook.dport = s.sin_port;
+ /* NOTE: It works with PF_OUT, even though rdr rule is on incoming
+ * traffic in my tests. More research into natlook.direction is needed
+ * here.
+ */
+ natlook.direction = PF_OUT;
+ /*
+ * Open the pf device and lookup the mapping pair to find
+ * the original address we were supposed to connect to.
+ */
+ fd = open(/dev/pf, O_RDWR);
+ if (fd == -1) {
+ printf(No permission to open /dev/pf, see ya\n);
+ exit(EX_UNAVAILABLE);
+ }
+
+ if (ioctl(fd, DIOCNATLOOK, natlook) == -1) {
+ printf(
+pf nat lookup failed %s:%hu\n,
+ inet_ntoa(client-sin_addr),
+ ntohs(client-sin_port));
+ close(fd);
+ exit(EX_UNAVAILABLE);
+ }
+ close(fd);
+
