How to stop kernel TCP responses on a port

[Dale Mellor]

I want to do TCP with raw sockets. How can I filter away the kernel's
RST/ACK/SYN response messages when I want to do this myself?

[Leonardo Rodrigues]

you'll probably need to tweak the kernel itself for that. If you=20
wanna do all the 'dirty work', why not use UDP instead of TCP ??

I want to do TCP with raw sockets. How can I filter away the kern=

el's

RST/ACK/SYN response messages when I want to do this myself?

--=20


Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br

Minha armadilha de SPAM, N=C3=83O mandem email
***@solutti.com.br
My SPAMTRAP, do not email it



--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Dale Mellor]

Post by Dale Mellor
I want to do TCP with raw sockets. How can I filter away the kernel's
RST/ACK/SYN response messages when I want to do this myself?

On Thu, 2014-09-04 at 13:16 -0300, Leonardo Rodrigues wrote:
you'll probably need to tweak the kernel itself for that. If you
wanna do all the 'dirty work', why not use UDP instead of TCP ??

I need to tunnel TCP (specifically telnet) through a space link to a
spacecraft in orbit (don't worry, security exists in the link layer).
But of course I need the SYN/ACKs to come from the spacecraft itself
(rather than the ground-station PC) so I know when I can send commands
up. I'm going to try to use the iptables' QUEUE target and a user-space
packet filter, thinking that if I reject the incoming SYN it will be
dropped without further ado, and then I can synthesize a response later
with a raw socket.

Any thoughts people may have on this would likely be useful.

Thanks,
Dale

[Dale Mellor]

Post by Leonardo Rodrigues

I want to do TCP with raw sockets. How can I filter away the
kernel's
RST/ACK/SYN response messages when I want to do this myself?

you'll probably need to tweak the kernel itself for that. If you
wanna do all the 'dirty work', why not use UDP instead of TCP ??
I need to tunnel TCP (specifically telnet) through a space link to a
spacecraft in orbit (don't worry, security exists in the link layer).
But of course I need the SYN/ACKs to come from the spacecraft itself
(rather than the ground-station PC) so I know when I can send commands
up. I'm going to try to use the iptables' QUEUE target and a
user-space
packet filter, thinking that if I reject the incoming SYN it will be
dropped without further ado, and then I can synthesize a response later
with a raw socket.
Any thoughts people may have on this would likely be useful.

On Thu, 2014-09-04 at 22:06 -0700, Payam Chychi wrote:
Why would the syn-ack come from the ground pc and not the space station?
Are you proxying this? If so, there are other ways todo this ...



I thought this list had rules about not top-posting?

Anyway, the point is I don't want the syn-ack to come from the ground,
but the Linux kernel insists on sending it. That's what I want to
filter out, or otherwise stop.

In case I haven't been clear, the PC is the gateway to the spacecraft;
effectively, it _is_ the proxy. When a telnet client (on the ground)
connects to the gateway (on the ground), the gateway is responding to
the SYN when I don't want it to.

Dale

[Brad Campbell]

Post by Dale Mellor
Anyway, the point is I don't want the syn-ack to come from the ground,
but the Linux kernel insists on sending it. That's what I want to
filter out, or otherwise stop.

The kernel only does that if there is a piece of application code that
is bound to that socket.

Post by Dale Mellor
In case I haven't been clear, the PC is the gateway to the spacecraft;
effectively, it _is_ the proxy. When a telnet client (on the ground)
connects to the gateway (on the ground), the gateway is responding to
the SYN when I don't want it to.

Ok, so the ground station PC is acting as a proxy and you don't want
that. You want it to *route* the IP packets rather than be an
application level proxy.

So at the moment you are connecting to a socket that is bound in the
ground station PC. There is a piece of code there than binds and then
accepts the connection. Stop doing that and have iptables forward/nat
the packets instead.

If all that is incorrect, then you have not provided anywhere enough
information on the how's and why's.


--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Dale Mellor]

Post by Brad Campbell

Post by Dale Mellor
Anyway, the point is I don't want the syn-ack to come from the ground,
but the Linux kernel insists on sending it. That's what I want to
filter out, or otherwise stop.

The kernel only does that if there is a piece of application code that
is bound to that socket.

Post by Dale Mellor
In case I haven't been clear, the PC is the gateway to the spacecraft;
effectively, it _is_ the proxy. When a telnet client (on the ground)
connects to the gateway (on the ground), the gateway is responding to
the SYN when I don't want it to.

Ok, so the ground station PC is acting as a proxy and you don't want
that. You want it to *route* the IP packets rather than be an
application level proxy.
So at the moment you are connecting to a socket that is bound in the
ground station PC. There is a piece of code there than binds and then
accepts the connection. Stop doing that and have iptables forward/nat
the packets instead.
If all that is incorrect, then you have not provided anywhere enough
information on the how's and why's.

Thanks for all your thoughts. It is likely true I didn't give enough
information for you to fully understand my problem, but I didn't have
time to write an essay and there is only so much I'm allowed to
disclose.

Anyway, for information, my solution was to vector packets to my port in
the PREROUTING chain of the mangle table to target QUEUE, and then have
a user-land program feed the packet to the space link. This program
instructs the kernel to DROP the frame, and the kernel does not then
send any SYN-ACK or RST itself to the connecting client, which is what I
wanted to achieve.

Thanks again,
Dale