I have seen the SYN flooding packet source code.
But in there, there are nothing about making ethernet packet.
Why source code doesn't manipulate the ethernet header. Why just TCP (It should be manipulated), and IP (It should be also) are manipulated?
If ethernet header is not manipulated, the kernel make the ethernet header's source address with attacker's mac address automatically.
So victim can know source mac address, but not IP address (because of randomize IP address when sending SYN packet to victim).
mac address only valid inside same lan, and will be changed through gateways. So there is no way the victim can know source mac.
But your gateway can know the source mac, since it is your gateway, it is very easy to track you down even if you change your source mac.
So it is meaningless to change your source mac.
Related
I receive a UDP packet using recvmsg(2). I would like to know if it is from the local machine or not.
I can use IP_PKTINFO with recvmsg to get the interface the packet was received on. When the packet was sent to a loopback address this is the loopback interface, which is great. When the packet was sent to an address of some other network interface, it comes back as that interface whether the packet was locally generated or not, which is not so great.
I can check if the source address of the packet is an address of the local machine, but if reverse path filtering is disabled then it could have that address and still be from another machine, and I can't assume that it isn't. Also, this would be a race between when I receive the packet and when I check what the local addresses are.
The system is Linux. C or C++. The process doing this has CAP_NET_ADMIN. How do I determine if the received packet is from the local machine or not?
I want to send a packet to another machine but with a different MAC address in the ethernet header. For this I am using raw sockets in C and creating my own ethernet header so that I can set the source MAC as desired. The trouble is that I am not sure what destination MAC address to fill in the header. I know the IP of the destination machine but not the MAC. Even if I knew, I don't want to hardcode this MAC.
One option I see is that my machine would know the MAC in its ARP table and I could read it and get the MAC address and fill it in. But doing this before sending each packet is overhead. I could read it once and keep using but what if some day the destination machine gets replaced. The admin would assign the same IP address to the new machine but the MAC address would be different. Probably when the new machine boots up, it would send a Gratuitous ARP and my machine would update its ARP table. But my program wouldn't know this. My program would keep sending packets with old MAC.
I feel I am missing something very basic. Thoughts?
What you are seeing here is the same problem that everyone faces, who tries to implement a network stack.
You have several options:
If the packet is a reply packet, then just use the MAC address of the from address
You can maintain an own arp-table and send a arp request if the entry in your table is missing or outdated. Parse arp replies and update your table accordingly. Packets to be sent without a valid arp table entry have to be queued. This is the most elegant, but also a very demanding option.
You can simply send the packet to the MAC of your local router. It will forward the packet to the correct host specified in the IP header. If your local router employs protocols like vrrp, hsrp or gblp, then the MAC address is always the same and doesn't change, even if your router is replaced.
You can read the MAC address from /proc/net/arp or with ioctl(SIOCGARP, ...);, but the entry for the IP you are looking for might not be present, if your host hasn't tried to communicate with it recently. You could, of course, send a dummy packet with sendto(); to that host before reading the arp table.
If you describe in more detail what you are planning to do, the suggestions might get better.
You can set the MAC address for the device with SIOCSIFHWADDR ioctl request. The manual for netdevice is a good starting point for this.
Please don't criticise the solution. It's not my design and yes, it sucks.
On a computer running Linux, and using C, we need to verify that a TCP connection made to a process is from the same machine. Doing it by IP address is problematic since the OS is generating two IP addresses and the process only knows one. Anyway, verifying by IP address is a bit poor.
We want to do the verification by comparing the "remote" MAC address to the local MAC address. We already get the local MAC address. All I need to know is how to get the "remote" MAC address. It's in the packet that gets sent when forming the connection (and in all subsequent ones too). How do we drag it out of the ethernet layer?
Before anyone says this again, I KNOW you cannot get the MAC address of the remote host if it's not on the same subnet/LAN. That's fine. Presumably we'll get something like 00:00:00:00:00:00 and since that is different to the local MAC address it will be different - just what we want.
--
So, to summarise, we have a TCP connection socket fd, we've received a data packet, how do we then find the MAC address of the remote host, the MAC address that was in the packet's header?
If I understand correctly, you are not trying to tell remote machines apart, but to use the idea that the source and destination MAC would match on traffic sent from a machine to itself in order to allow only local traffic.
This seems rather roundabout, and has been pointed out, insecure.
A somewhat better idea might be to have the TCP client listen only on the loopback interface (127.0.0.1) and not on INADDR_ANY. Or go a step further and use a unix-domain socket instead of a TCP one (a common method used by X servers today to prevent the possibility of remote connections)
The MAC address of a live same-subnet TCP connection will almost certainly be in the ARP cache.
On Linux, you could examine the ARP cache by looking in /proc/net/arp. Here is what it looks like on my Ubuntu box:
aix#aix:~$ cat /proc/net/arp
IP address HW type Flags HW address Mask Device
10.0.0.32 0x1 0x2 00:1e:4f:f5:be:dc * eth0
10.10.10.1 0x1 0x2 00:1f:6c:3e:02:e3 * eth0
There's probably some callable API that you could use to get to the same data if you're averse to parsing the pseudo-file.
How about configuring a firewall (internal or external) to block or MAC-filter external traffic on the port in question?
A loopback connection (whether it's over the loopback interface or some other interface) it not routed over any ethernet device and therefore does not have a MAC address associated with it.
I suggest you just use getsockname and getpeername to get the local and remote IP address and compare that they are equal. That will work without any a priori knowledge of the configured IP addresses of your system.
Further, if you want to be IPv4/v6 agnostic, you could use getnameinfo with the NI_NUMERIC flag to convert both addresses to numeric string representations and strcmp them.
I have started coding a packet injector and read up a bit on what one has to do. One thing I'm wondering though is when I create the IP header the h_source and h_dest fields should contain the mac address of the sender and receiver. Do I have to do this and is there a quick way to find out the mac address of the destination? Let's say I craft a ICMP ping packet or some arbitrary TCP packet. Would be nice to just be able to say "send it to 192.168.0.10 from 192.168.0.1" and not having to care about the mac addresses. I guess the kernel normaly fills this in but letting it interfere here would not allow me complete control over the packet.
I'm afraid you've got that wrong, IP has no knowledge of the MAC adress, only the ethernet layer knows that. That's why you need the ARP protocol to determine which mac adress to send an IP packet to. Normally, you know which subnet you belong to, if your destination IP is local, you ARP for the MAC and send it diretly (this is usually done at a much lower level though). If it's not on your local subnet, you ARP for the gateway IP and send it there instead, which will forward it somehow.
The only source and destination present in the IP header are the source and destination IP addresses.
HTH.
EDIT:
For clarification. When sending via the gateway, the IP packet is normally not touched (except TTL, and, because of that, the checksum). There are situations where the IP packet must be fragmented, but that's a different issue. The point is the source and destination addresses remain the same, it's only on the layer below where we're actually saying it should be sent via some gateway or router.
Yes, you will need to fill this in. You can use ARP to determine the MAC address of a given IP address: http://en.wikipedia.org/wiki/Address_Resolution_Protocol
I have a need for some C or C++ code, compilable under Linux, to be able to take a list of IP addresses of some arbitrary number of remote hosts machines and obtain a ethernet MAC address for each one. These host machines may be on the same subnet or they could be on a different subnet behind a router. Its OK if the MAC address of some or all of the remote hosts is the address of the interface on the router. Ultimately, I want to hand off the IP address and MAC address to an FPGA who will use these pieces of information to format and send UDP/IP packets over ethernet to the hosts. Obviously, the FPGA will also be given its own MAC address and IP address to fill in the source MAC and source IP addresses in the packets.
Is there some code I can be pointed to that can create and broadcast ARP packets to these remote machines and receive back the ARP response packets such that the destination MAC addresses can be extracted?
Part of what you want to do requires some raw socket programming.
http://mixter.void.ru/rawip.html
The source for the linux arp command will give the rest of what you need. Here's a link:
http://www.comp.nus.edu.sg/~cs4236/readings/out/html/arp_8c-source.html
I recommend looking into arping which is doing a somewhat identical job. It takes IPs and MACs and tries to receive additional informationen. Or justs pings them.
http://freshmeat.net/projects/arping/