I'm doing an exercise ARP sniffing.
I want to simulate a attack like Man in The Middle.
I had been sending arp to change way packet to Attacker PC.
But I don't know How to forwarding this packet I receive from A to B.
How I do it? Can I do it with LibIPQ, or Libnet.
Recomend to read this post:
Spoofing the ARP Table of Remote Computers on a LAN
http://www.codeproject.com/KB/IP/winarpspoof.aspx
http://www.codeguru.com/cpp/i-n/network/basicnetworkoperations/article.php/c6861
and need view this proyect SharpPcap.
and not forget read: Can you use ARP-Poisoning (spoofing) to apply simulated external effects?
Salute.
Related
I need to write a proxy server in C language on Linux (Ubuntu 20.04). The purpose of this proxy server is as follows. There're illogical governmental barriers in accessing the free internet. Some are:
Name resolution: I ping telegram.org and many other sites which the government doesn't want me to access. I ask 8.8.8.8 to resolve the name, but they response of behalf of the server that the IP may be resolved to 10.10.34.35!
Let's concentrate on this one, because when this is solved many other problems will be solved too. For this, I need to setup such a configuration:
A server outside of my country is required. I prepared it. It's a VPS. Let's call it RS (Remote Server).
A local proxy server is required. Let's call it PS. PS runs on the local machine (client) and knows RS's IP. I need it to gather all requests going to be sent through the only NIC available on client, process them, scramble them, and send them to RS in a way to be hidden from the government.
The server-side program should be running on RS on a specific port to get the packet, unscramble it, and send it to the internet on behalf of the client. After receiving the response from the internet, it should send it back to the client via the PS.
PS will deliver the response to the client application which originates the request. Of course this happens after it will unscramble and will find the original response from the internet.
This is the design and some parts is remained gloomy for me. Since I'm not an expert in network programming context, I'm going to ask my questions in the parts I'm getting into trouble or are not clear for me.
Now, I'm in part 2. See whether I'm right. There're two types of sockets, a RAW socket and a stream socket. A RAW socket is opened this way:
socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
And a stream socket is opened this way:
socket(AF_INET, SOCK_STREAM, 0);
For RAW sockets, we use sockaddr_ll and for stream sockets we use sockaddr_in. May I use stream sockets between client applications and PS? I think not, because I need the whole RAW packet. I should know the protocol and maybe some other info of the packet, because the whole packet should be retrieved transparently in RS. For example, I should know whether it has been a ping packet (ICMP) or a web request (TCP). For this, I need to have packet header in PS. So I can't use a stream socket, because it doesn't contain the packet header. But until now, I've used RAW sockets for interfaces and have not written a proxy server to receive RAW packets. Is it possible? In another words, I've the following questions to go to next step:
Can a RAW socket be bound to localhost:port instead of an interface so that it may receive all low-level packets containing packet headers (RAW packets)?
I may define a proxy server for browser. But can I put the whole system behind the proxy server so that packets of other apps like PING may route automatically via it?
Do I really need RAW sockets in PS? Can't I change the design to suffice the data I got from the packets payload?
Maybe I'm wrong in some of the concepts and will appreciate your guidance.
Thank you
Can a RAW socket be bound to localhost:port instead of an interface so that it may receive all low-level packets containing packet headers (RAW packets)?
No, it doesn't make sense. Raw packets don't have port numbers so how would it know which socket to go to?
It looks like you are trying to write a VPN. You can do this on Linux by creating a fake network interface called a "tun interface". You create a tun interface, and whenever Linux tries to send a packet through the interface, instead of going to a network cable, it goes to your program! Then you can do whatever you like with the packet. Of course, it works both ways - you can send packets from your program back to Linux through the tun interface, and Linux will act like they just arrived on a network cable.
Then, you can set up your routing table so that all traffic goes to the tun interface, except for traffic to the VPN server ("RS"), which goes to your real ethernet/wifi interface. Otherwise you'd have an endless loop where your VPN program PS tried to send packets to RS but they just went back to PS.
I have a scenario where multiple clients connect to a TCP server. When any of the clients sends a packet to the server, the server is supposed to have a retransmission timer and keep sending that packet to another server until it receives a reply. How do I go about setting up this retransmission mechanism? I'm doing this on Linux in C.
If you use a TCP socket, retransmit will happen automatically. Admittedly, if you want more control, you'll need to use UDP and handle the retransmit yourself.
I'm guessing this is an assignment. I had something similar where our channel was purposefully being corrupted.
I would suggest you follow something similar.
Send packet.
start a timer.
if an ACK (acknowledgment) is not received within a certain amount of time, then go back to step 1.
IIRC, the location of the files that contain these TCP config parameters are distro-dependent. They are in different folders on Red Hat and Ubuntu.
libpcap can only read the packets, how can I change it?
Basically I want to register a callback function that operates on all incoming packets,
how can this be done?
What kind of traffic is this? How do you want to modify it? What OS?
On linux, you may be able to use iptables to have the kernel modify the packets for you.
If that can't do what you want (i.e., you need to get the packets into user space), you could look at netfilter_queue. Or as a simpler alternative, use an iptables REDIRECT rule to send all the packets to a single port, and write an application to listen on that port.
I am using libpcap to capture GRE packets and forward now, I think the efficiency is not very good.
so I decide to do forwarding with netfilter, but I am new for this. Could someone gives me one
simple example to capture IP or GRE packets with netfilter? thanks!
It's not clear what you're trying to accomplish. Are you trying to capture the packets for analysis (like wireshark or tcpdump), or forward traffic through a GRE tunnel?
If you're trying to capture traffic for analysis, using netfilter doesn't make much sense. It's probably possible, using something like the QUEUE target to pass packets to userspace, but I doubt you'd get better performance than using libpcap with suitable BPF rules.
If you're trying to forward traffic through a GRE tunnel, the normal way to do that is to set up a gre tunnel interface; do man ip and look at the "tunnel" section. The tunnel interface (e.g. gre0) is a normal network interface that the system's routing table can send packets to.
I have an application bound to eth0, sending UDP packets on port A to 255.255.255.255. At the same time, I have a UDP server bound to eth0, 0.0.0.0 and port A.
What I want to do is to make sure that the server won't receive messages generated by the application (handled purely in software by the kernel) but it will receive messages generated by other hosts in the network.
I can't change the payload of UDP packets nor add any headers to it.
I've already implemented a solution using RTNETLINK to fetch all IP addresses of the machine I'm sitting on (and filter basing on address from recvfrom()), but I'm wondering if there might be a simpler and cleaner solution.
EDIT: I thought about something like tagging the skb - the tag would disappear after leaving a physical interface, but wouldn't if it's just routed in the software.
Any ideas?
If you can patch your Linux kernel, you could use a setsockopt() option for choosing if you want to loopback the broadcast packets you're sending or not.
This patch reuse the IP_MULTICAST_LOOP option exactly for this purpose.
Also, instead of "messing" with the IP_MULTICAST_LOOP option, you could easily add your own setsockopt() option, maybe called IP_BROADCAST_NO_LOOP. This would guarantee that you're not changing the behavior for any other application.
You can compute a checksum or CRC (better) over the payload and filter against this.
You can do this at the firewall level by dropping packets to broadcast address port A with source address of the eth0.