libpcap is used for package capturing. As I understand, it can capture the network packages from all ports. And it can capture the package data in link layer (such as ethernet frame).
This looks a little confusing to me, because it seems impossible to intercept all network traffic (from all ports) by just using the socket API in Unix-like system. Moreover, socket API seems unable to get the information in link layer (such as the header of Ethernet frame).
Is it true that libpcap is implemented by socket API? If not, which OS-level API is used to implement it?
libpcap is not part of the sockets API. On Linux PF_PACKET is used, which is an evolution of the BSD mechanism. On other operating systems there are other mechanisms (DLPI, Windows requires a DLL).
The capture on any interface mechanism is a Linux specific mechanism, and the capture mechanism occurs above the layer of the network interface.
The capture mechanism inside the kernel either has an explicit call out to a kernel packet filter, or is inserted by adjusting the plumbing (SVR4).
Is it true that libpcap is implemented by socket API?
If you're on Linux or IRIX, it is true. If you're on another flavor of UN*X, it is not true.
If not, which OS-level API is used to implement it?
On *BSD, OS X, AIX, and Solaris 11 and later: BPF.
On earlier versions of Solaris, and on HP-UX: STREAMS+DLPI.
it seems impossible to intercept all network traffic (from all ports) by just using the socket API in Unix-like system
On Linux, if you open a PF_PACKET socket, and don't bind it to a particular interface, packets from all interfaces are delivered to the socket.
socket API seems unable to get the information in link layer
You have to use the right type of socket, namely a PF_PACKET socket on Linux or a PF_RAW socket with a protocol of RAWPROTO_SNOOP on IRIX. Other UN*Xes don't have socket types for packet capture, and use other mechanisms.
On Linux, access to the raw packets needed by libpcap is done using a PF_PACKET socket.
See http://man7.org/linux/man-pages/man7/packet.7.html
It's implemented by inserting a driver into the network stack.
Normally, applications use kernel-level TCP stack. Instead of using default kernel-level implementation, by using your own implementation of TCP/IP stack processing in user-space, you can be bypass the kernel.
more readings
"zero copy networking" vs "kernel bypass"?
according to that StackOverflow post pcap is also doing kernel Bypass
Related
I learned the hard way that modern Windows machines do not permit sending TCP data over raw sockets after trying to perform the TCP handshake myself in Python. And yet Scapy, a Python library, is able to do it seemingly just fine. Other libraries, like Npcap and WinPcap, also seem to be able to send raw TCP data just fine on Windows. How is this possible? What are these libraries doing under the hood that enables them to bypass this limitation?
WinPcap (the windows implementation of libpcap) authors say in their website:
WinPcap consists of a driver that extends the operating system to provide low-level network access and a library that is used to easily access low-level network layers.
So the answer to your question would be: in windows, the implementation of libpcap (which is what Scapy uses according to their site) uses a driver to get access to the low-level networking stuff
I have several Linux applications which uses sockets (UDP/TCP IP).
I want (need, no matter why) to secure the connection with my own secure protocol without changing those applications.
I thought about changing the Linux kernel socket implementation, so I can use my secure protocol sockets, without changing those applications.
So, Is it possible to change the Linux kernel sockets, so when using send or receive sockets function, the inner Linux implementation will by mine ?
And how can I do it ? which kernel module do I need to change ?
I'm searching for help and an opinion-advice for a network project, in which I'm working lately. This requires a Linux machine to be a passive network appliance.
Network packets come in from one network interface and come out from another interface ( net--eth0-->Linux PC--eth1-->net) without making any modifications on data.
The application, which is going to run on the Linux system, will change only the order of the packets. It is going to be a "silly" network emulator application.
The first implementation was made with RAW sockets, where read() is called every time a packet arrives to user space and write() is called when an Ethernet packet should be sent down to the NIC.
I would like to know if there is a more practical and direct way than RAW sockets, bypassing Linux's network stack.
If what you want is to bypass the kernel, DPDK in Linux and NetMap in FreeBSD are options to do just that.
Indeed this can be done in dpdk in Linux. There are l3fw and l2fwd sample applications in the examples folder of the dpdk tree, which may inspire you. Also consider using vpp, a fd.io project hosted by Linux Foundation, which can use dpdk.
Rami Rosen
My goal is to monitor sockets and relate them to the applications that created them.
I am aware of netstat, ss, lsof and so on and that they can list all sockets with their application.
And I also know that I can parse /proc/net/tcp to get the sockets and relate them to the applications with /proc/(PID), which is exactly what these tools do or they use netlink sockets.
My researches brought me to an article which explains how to get all sockets from the kernel with netlink via the inet_diag protocol. The user space program sets up a netlink socket of the inet_diag type and sends a request to the kernel. The response consists of several messages which contain the sockets and additional related information.
This is really neat, but unfortunately the kernel sends this information only once per request. So I have to "poll" continuously.
Further researches brought me to another article which monitors IP changes of interfaces with netlink route sockets continuously. The socket is bound to a multicast group and then messages are read from it in an endless loop.
So I investigated if there is the same possibility with the inet_diag sockets. Unfortunately I am not really able to understand kernel code. But as far as I can tell there are no multicast groups for this socket family.
At this point I am stuck and I need to know if this approach is somehow feasible or somebody knows any other hints.
You can try dtrace if every tools you mentioned can't meet your requirement.
You can use kprobe kernel module to hook all connect system call，whichi monitor sockets and relate them to the applications that created them
just like Elkeid，Elkeid Driver hooks kernel functions via Kprobe, providing rich and accurate data collection capabilities, including kernel-level process execve probing, privilege escalation monitoring, network audition, and much more. The Driver treats Container-based monitoring as a first-class citizen as Host-based data collection by supporting Linux Namespace. Compare to User Space agents on the market, Elkeid provides more comprehensive information with massive performance improvement.
I am writing a linux kernel module for some tunnelling activity. The module will get packets from the networking stack and perform some operations on it. What is the best possible way to inject packets into the stack from the bottom(emulate ethernet packet arrival on wire) so that the packet traverses the entire receive path and is delivered to my module.
My module uses the kernel br_handle_frame_hook hook to get the packet which means that it cannot co-reside with the linux native bridge module. Any ideas will be appreciated.
Consider using NetFilter
http://www.phrack.org/issues.html?issue=61&id=13
TAP would be great, if you're working in user space, which you're not
I believe that TAP device is what you are looking for - a nice way to send/receive Ethernet packets from user-space
I recommend tap like #raber before me. I also recommend reading this excelet tutorial: http://backreference.org/2010/03/26/tuntap-interface-tutorial/ .
You asked whether you can make the tap non-programatically and then replay traffic into it. The answer is yes. Look for the 'persistency' options (which b.t.w. can also be done programatically with a short tool you can write yourself if you prefer not to download tools that can already do it). You may also want/need to define the user that may use the tap (or otherwise just sudo your operations).