I am searching for a TCP traffic generator. The problem is that I do not simply want to send TCP traffic as it can be done with e.g. Iperf. I want to be able to configure the flags and other header fields and I want to react on incoming packets e.g. a TCP SYN.
So for example I want to send a TCP FIN packet if a TCP SYN arrives.
I prefer Linux tools but it would be also ok if the tool only runs under other OS.
I have looked into hping3, it looks promising. But I would like to look into other tools before choosing it.
SendIP can generate TCP packets, with options to manipulate SYN/FIN bits as well as other fields.
This sort of question really belongs on Server Fault.
Related
I want to test how the netfilter/ip6tables firewall handles some IPv6-related stuff like tiny/overlapped fragments, type 0 routing headers, excessive HPH options etc. For this I wanted to use Scapy to craft my own packets, but apparently Scapy using raw sockets means bypassing iptables. Is there another way of achieving my goal and how would I go about it? Some library I could use to make my own packets, which iptables can act on?
Run your packet injection program from a VM, and inspect the network connected to that VM.
Scapy is useful for such odd tasks. Sometimes what you want to do is just as easily done by writing small programs using the normal C APIs (including raw sockets in some cases, or TCP connections with odd options set). In many cases, a trivial TCP or UDP client in any high level language such as Python will do.
I'm trying to write a TCP transparent proxy to run on Linux.
I want to, upon receipt of an incoming connection, initiate a corresponding outgoing connection, but only accept (SYN|ACK) the incoming connection if the outgoing connection is successful.
TCP_DEFERRED_ACCEPT doesn't do what I want -- it always sends a SYN|ACK.
The question is: how do I accept TCP connections, but defer the SYN|ACK, with the Linux sockets API?
You can do that with Linux, but not via the socket API. You would use the NFQUEUE target which allows you to redirect some packets to userspace and decide their fate from within your program.
Obiously, you'd still have to parse the packet in userspace, but searching for a few TCP flags should not be that hard and not require a complete TCP stack. And this way Linux still does the whole network job.
In your case, it would seem possible that you both use NFQUEUE and classical sockets API. The first will give you early decisions, the latter TCP stream data access. Although I never tried it.
See https://home.regit.org/netfilter-en/using-nfqueue-and-libnetfilter_queue/ for instance.
For my application, I need to intercept certain TCP/IP packets and route them to a different device over a custom communications link (not Ethernet). I need all the TCP control packets and the full headers. I have figured out how to obtain these using a raw socket via socket(PF_PACKET, SOCK_RAW, htons(ETH_P_IP)); This works well and allows me to attach filters to just see the TCP port I'm interested in.
However, Linux also sees these packets. By default, it sends a RST when it receives a packet to a TCP port number it doesn't know about. That's no good as I plan to send back a response myself later. If I open up a second "normal" socket on that same port using socket(PF_INET, SOCK_STREAM, 0); and listen() on it, Linux then sends ACK to incoming TCP packets. Neither of these options is what I want. I want it to do nothing with these packets so I can handle everything myself. How can I accomplish this?
I would like to do the same thing. My reason is from a security perspective… I am wanting to construct a Tarpit application. I intent to forward TCP traffic from certain source IPs to the Tarpit. The Tarpit must receive the ACK. It will reply with a SYN/ACK of its own. I do not want the kernel to respond. Hence, a raw socket will not work (because the supplied TCP packets are teed), I need to also implement a Divert socket. That's about all I know so far… have not yet implemented.
I am running some security tests which require the use of a non-standard TCP socket, to generate a behaviour that a normal TCP stack would not follow. I use a raw socket to generate such traffic.
When the reply from the other end point is received, the TCP connection is unknown to the kernel and issues a RESET. To prevent this from happening, the normal solution is to define an iptables rule that drops all outgoing RESET (e.g. iptables -A OUTPUT -p tcp -dport 50000 --tcp-flags RST RST -j DROP).
However, in my particular case, RESET is also a valid segment to generate during the testing. What I need is a way to filter out all segments from that connection so the kernel TCP stack is not involved and yet have access to all the segments in my raw socket.
Any ideas how can I achieve this? Is this possible with iptables?
Thanks in advance
Luis
Trying to use the host's IP address and fighting Linux's TCP/IP stack is calling for trouble.
Instead, I would use a separate IP address, route that to a tun device and get the raw IP packets from the tun device instead of using a raw socket (some sample code to interface a tun device is available from http://www.secdev.org/projects/tuntap_udp/). That way the Linux TCP/IP stack won't get in your way (except for routing puposes).
After sending some tcp data by any method (mine is below)
DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream());
outToServer.writeBytes(string);
How can I verify in JAVA that TCP data is sent successfully? OR is there any way of reading the ACK received (from tcpserver) ?
You cannot. Operating systems typically does not expose this to applications.
If you need to know whether data has made it to the other end, you need to implement acks at your application protocol, not at the transport level that TCP concerns itself with.
I always use Wireshark to debug TCP apps. It is a TCP tracing tool that shows you the individual packets with their acks, retransmits etc.
It is not in code, but it does allow you to double check the behavior of your app.
Check wireshark.