Hi,
I'm planning to write a small application proxy and I think it could be good
to protect it with syn-proxy, however this will create a lot of overhead on
the firewall.
client -tcp- syn-proxy -tcp- proxy -tcp- server
Has anyone ever thought to introduce a hook inside syn-proxy ?
A way for
On Thu, Sep 11, 2003 at 12:58:57PM +0200, Ed White wrote:
In the end will have syn-proxy to manage the tcp connection, while
application-proxy talk only with syn-proxy and can change the data, block the
connection or redirect (for example by hostname like apache vhost).
You can already do
On Thursday 11 September 2003 15:00, Daniel Hartmeier wrote:
Let pf do syn proxy in front of the userland http proxy. That means pf
will swallow syn floods and only pass fully established connections on
to the http proxy.
Or, if that's not what you meant, what did you mean? :)
The fact is
On Thu, 2003-09-11 at 23:00, Daniel Hartmeier wrote:
This can be done easily within the logic of the http proxy, just write
one that doesn't open the real server connection immediately, but parses
the the request first. This works for TCP protocols where the client
must first send a complete
On Thu, Sep 11, 2003 at 11:32:28PM +1000, Damien Miller wrote:
On Thu, 2003-09-11 at 23:00, Daniel Hartmeier wrote:
It would be cool if pf (some time in the future) had someway of passing
packets off to to a userspace inspection process before they were put
out on the wire or delivered
Can Erkin Acar wrote:
I have been dreaming of passing assambled streams through
the userland. I have not yet come up with a suitable design though.
I've been probably dreaming too, but I would love to have some kind of
scrub tcp that would reassemble the stream, before forwarding it.
That
So we gain:
1) only 2 tcp connection handled by syn-proxy:
client -tcp- syn-proxy -tcp- server
2) possibility to write filter for application protocol without handling the
connection (no sockets or other part to rewrite).
You have two options to get data from a TCP connection. You either
Daniel Hartmeier wrote:
On Thu, Sep 11, 2003 at 04:49:27PM +0200, Cedric Berger wrote:
3) somehow, a NAT rule is created to make that 2nd connection
originate from the
same socket as the first connection/packet.
*cough* embryonic state *cough*
Googling...
Ok, I see..
All you need
Now about the userland inspection. I wonder if it's not possible with just
what we've now, i.e a using a proxy, RDR and NAT:
1) the incoming connection is RDRed to the inspection proxy
2) the inspection proxy open a new socket / new UDP packet to the real
destination
3) somehow, a NAT
Mike Frantzen wrote:
I've been probably dreaming too, but I would love to have some kind of
scrub tcp that would reassemble the stream, before forwarding it.
That would allow me to easily bypass the PMTU problems for example,
without having to tweak all clients (Win2000 friends will send 1500
On Thu, Sep 11, 2003 at 07:37:44PM +0200, Ed White wrote:
P.P.S. I'm subscribed to the list !
Please do not write me in cc every time ;-)
You can't exorcise the habit, that's what procmail is for ;)
:0Whc: msgid.lock
| formail -D 65535 msgid.cache
:0a:
in-x-dupes
Daniel
11 matches
Mail list logo