I would like to create chain for Iptable which return URL and post and get from all packets.
I do not believe that netfilter/iptables is generally aware of application-level protocols like HTTP. There is some limited protocol dissection support that is used for connection tracking in some specific protocols (e.g. FTP), but that's about it. The way I see it, you have two options:
Redirect the packets that you want to inspect to userspace where you can have a helper process that will extract the information that you need. I am not aware of any existing application that will do that, however, so you may have to write it yourself.
Do the sane thing and just use a packet sniffer such as Wireshark or tcpdump, preferably with a capture filter that will only let HTTP traffic through. As a bonus, you can get a whole lot more information than just an HTTP request and a URL...
( 3 years later but I think useful for other people too )
barebone iptables are agnostic of application protocols, but there are iptables extensions
for example, see the extensions string and u32
Related
For learning purposes I'm implementing TCP (for now just RFC 793) but I have no
idea how to test it. Most TUN/TAP stuff on the internet are out of date (e.g.
Linux API calls no longer work) and just doesn't explain enough. In addition, I
feel like a creating a device and forwarding packages etc. are not the best way
for learning purposes. For example, I'd rather only override socket(),
listen(), connect(), accept(), send(), recv() etc. in a program rather
than forwarding all ethernet traffic to a device/program that does the
bookeeping for the whole system rather than for a single program.
I'm wondering if this is possible. If not, I'd like to know the simplest way to
test a TCP implementation on Linux.
Because I'm following RFC 793, it'd be great if I could have an IP (Internet
Protocol as mentioned in the RFC) API in my application. Is this possible or do
I have to mess with TUN/TAP stuff?
Thanks..
If we talk about research I strongly recommend you read Engineering with Logic: Rigorous Test-Oracle Specification and
Validation for TCP/IP and the Sockets API
It contains section about testing TCP/IP implementation:
"EXPERIMENTAL VALIDATION: TESTING INFRASTRUCTURE"
You could try setting up two peers, one using a RAW socket and the other a TCP socket.
If they can communicate and packets are really delivered/recovered the same way TCP does, you know that your custom implementation is successful.
C sockets
C RAW sockets
C TCP implementation
All you need is to intercept all tcp packets with bits (syn, ack, fin, etc.) your application has sent and to see if it works properly:
It could simply be done with wireshark or other sniffer. When testing you will see all tcp packets with bits you've sent.
In order you want to see linux system calls which your application are calling, you can use GDB or any other debugger.
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 want to restrict the daemons from opening certain ports, and i wish to achieve it at kernel level.
I came across an idea, i.e to write my own bind function and then redirect to the original bind function. But the user can bypass this by invoking the system call. Any suggestions?
Just a thought:
there's a chance that 'iptables' could do the work for you.
Using 'iptables' you can define a rule which will deny outgoing traffic from a port.
This solution may work for you if you can identify the deamon's traffic according to iptables options. It will not work for you if you can only identify the deamon's traffic according to its process id.
Why do we need root privileges when we use raw sockets ?
It's because you can spoof custom packets, which may interfere with inbound traffic. This too is also bad.
In short raw sockets is restricted to root because if it otherwise it would break other rules for networking that are in place.
A long standing rule is that you cannot bind on a port lower than 1024 without root's blessing. With raw sockets you can simulate a server on any port. (naturally being able to receive on this port is a different story you'd also have to sniff the network, but perhaps this could be done with a different machine.)
Opening a raw socket allows to read anything that is received in a given interface, so, basically, you can read any packet that is directed to any application - even if that application is owned by another user. That basically means that the user with this capability is able to read any and all communications of all users.
Firstly, I'm relatively new to network programming. I want to intercept and delay HTTP traffic before it gets to the server application. I've delved into libnetfilter_queue which gives me all the information I need to delay suitably, but at too low a level. I can delay traffic there, but unless I accept the IP datagrams almost immediately (so sending them up the stack when I want to delay them), they will get resent (when no ACK arrives), which isn't what I want.
I don't want or need to have to deal with TCP, just the payloads it delivers. So my question is how do I intercept traffic on a particular port before it reaches its destination, but after TCP has acknowledged and checked it?
Thanks
Edit: Hopefully it's obvious from the tag and libnetfilter_queue - this is for Linux
Hijack the connections through an HTTP proxy. Google up a good way to do this if you can't just set HTTP_PROXY on the client, or set up your filter running with the IP and port number of the current server, moving the real server to another IP.
So the actual TCP connections are between the client and you, then from you to the server. Then you don't have to deal with ACKs, because TCP always sees mission accomplished.
edit: I see the comments on the original already came up with this idea using iptables to redirect the traffic through your transparent proxy process on the same machine.
Well I've done what I suggested in my comment, and it works, even if it did feel a long-winded way of doing it.
The (or a) problem is that the web server now, understandably, thinks that every request comes from localhost. Really I would like this delay to be transparent to both client and server (except in time of course!). Is there anything I can do about this?
If not, what are the implications? Each HTTP session happens through a different port - is that enough for them to be separated completely as they should be? Presumably so considering it works when behind a NAT where the address for many sessions is the same.