I can target a client IP address on my router like:-
iptables -I INPUT -s 123.456.7.89 -j DROP
Is it possible to target the IP of the access point the client device is connecting through instead (or the SSID since each access point has it's own).
I've been looking at the match flag but can't find anything there. Thanks.
The only way is to filter by mac address, but it's not so easy.
Please spend some times with this picture:
Using the MAC module extension for iptables from here
The side effect explained here occurs when the netfilter code is
enabled in the kernel, the IP packet is routed and the out device for
that packet is a logical bridge device. The side effect is encountered
when filtering on the MAC source in the iptables FORWARD chains.
As should be clear from earlier sections, the traversal of the
iptables FORWARD chains is postponed until the packet is in the bridge
code. This is done so we can filter on the bridge port out device.
This has a side effect on the MAC source address, because the IP code
will have changed the MAC source address to the MAC address of the
bridge device.
It is therefore impossible, in the iptables FORWARD chains, to filter
on the MAC source address of the computer sending the packet in
question to the bridge/router. If you really need to filter on this
MAC source address, you should do it in the nat PREROUTING chain.
Agreed, very ugly, but making it possible to filter on the real MAC
source address in the FORWARD chains would involve a very dirty hack
and is probably not worth it.
Related
My rental server doesn't allow me to remote on via SSH, despite assuring me that everything is setup. How do I override RST packets on a Chromebook without using Python?
If I understand correctly, you want to drop TCP reset packets.
This blog post explains how to get a root shell and add an iptables rule.
Instead of the rule given in the article to get SSH access, try this rule:
iptables -I INPUT -p tcp --tcp-flags RST -j DROP
(Disclaimer: I don't know anything about chromebooks except that they run Linux.)
I want to find the MAC address of a device. Example: Plug a network cable from my linux mashine to the target device, send some command, receive MAC.
The best solution I have now is to connect a router to the device, wait for it to give out a dhcp lease, connect to the router via ssh and read out the lease table.
I understand that dhcp servers wait for a request from the device and then give out a lease but I would like to actively send some request to the device and get the MAC from the answer directly.
The biggest problem seems to be that without running a dhcp server I can't communicate with the device. Can this be done through a lower layer? Maybe an ARP request?
Thanks!
Ping the other device first and the run the command
arp -a
You can see the MAC address of the device you just pinged.
If you don't know the MAC address of a device the only way to communicate with it is via some sort of broadcast. This implies that there is some software active on the host listening for such a broadcast that will reply. This is how hosts (using ARP) resolve MAC addresses on the local network from an IP address. ARP won't work for you unless you know the IP address.
If you just have a device with no protocol support you're stuck.
If you're using linux, there is wireshark (or the CLI version tshark):
sudo apt-get install tshark
sudo tshark -i eth0
You will see every packet your laptop or the attached device is sending over that ethernet interface. Assuming the device is powered on, you will probably see the MAC address you are looking for somewhere in all of the low level network protocol spew. If you aren't getting much spew, try re-plugging the ethernet cable. (Sorry; I came here looking for a better answer myself)
We solved this by listening for packets from the target mashine and extracting the mac address from the first packet we get.
Thanks for all the answers though!
Running on a Linux system, getting UDP packets from another computer address to let's say 192.168.0.2 from another address let's say 192.168.166.66, I can see the UDP packets coming in with tcpdump. However, if I use netcat I don't actually receive the packets.
If I create an interface on 192.168.166.XXX network, then netcat is able to receive the packets no problem.
What basic networking concept am I missing? Why do I need to have an interface on the network of the sending IP when I can see with tcpdump that they are being delivered correctly?
tcpdump per default puts the interface into promiscious mode, which lets you see all the packets arriving at your network interface. But, your operating system only processes packets destined for the local system, e.g. either having the local or a broadcast address as destination.
The final solution to this problem was to disable Reverse Path Forwarding (RPF) on the interface. There are security implications here, but after careful review this was the correct path forward in this particular case.
RPF was turned off by modifying /etc/sysctl.conf:
net.ipv4.conf.eth0.rp_filter=0
Some more information on RPF:
Wikipedia - Reverse path forwarding
Linux kernel rp_filter settings
we have little network devices which are shipped with IP address 0.0.0.1 to ensure that they never collide with any other device in their new environment (thus none of the 10.x.x.x, 172.16.x.x or 192.168.x.x ranges) until configuration. DHCP is no solution since there might be no DHCP server in the field.
The devices would listen to UDP broadcasts and answer with broadcasts until they are given their new IP address this way.
This worked fine with Windows XP - but sucks with Windows 7: the config program does not receive the answer packets from the devices which still have 0.0.0.1. Wireshark sees the packets, then they are dumped by the system.
Question: Is there any reason (RFC?) that actually prohibits using this address in a local environment? Or is it just MS that was overcautious? Where can I read why they treat this address "invalid"? Which ranges are really "invalid" now, too?
Any idea of a workaround on the PC side (Win 7)?
I know that it is not recommended to use 0.xxx addresses for work places, but for this very reason - having a not-used address - it works perfectly.
Edit: there is a device out there called "Netburner" which might have faced the similar issue, according to their forum. See: http://forum.embeddedethernet.com/viewtopic.php?f=5&t=612&p=2198 Does - by coincidence - anybody know some background information?
It sounds as if your configuration application is listening for broadcast packets on all network interfaces and expecting to receive packets from foreign subnets.
That should not work - the OS should only pass-on broadcast packets from the subnets each network interface is on, not from all subnets on the same physical (e.g. Ethernet) segment. I am reasonably certain that doing otherwise is broken behaviour WRT the IP protocol.
The are two ways to deal with this:
Make sure that your network interface has an IP address in the target subnet. You can have more than one IP addresses for each network card, so that should not interfere with normal network operations.
Configure or modify you application to use raw sockets, like Wireshark. Keep in mind, however, that this overrides all normal checks and balances and should be avoided, since it can cause behaviour that is almost impossible to diagnose - which is why it is frowned upon by meny network administrators.
Can you you add new routing table entries to Windows machines easily? Windows has to know which interface to use when routing a broadcast packet to the 0.0.0.x network.
The Unix machines I'm familiar with have a routing table that maps network/netmask entries to either gateways or interfaces (if the network is a local network). The local network (192.168.0.0/16 for my home network) gets sent to interface eth0. Everything else 0.0.0.0/0 gets sent to a specific gateway machine 192.168.0.1.
If my machine sent a UDP broadcast message to network 0.0.0.0/24 (in other words, UDP broadcast sent to 0.0.0.255, then my machine would forward the packet to the gateway machine (which it can look up via arp). The switches in the middle wouldn't propagate the packet to other network devices, because the MAC address is set.
If my machine had another routing entry for 0.0.0.0/24 to the local interface, then my machine would send the packet on the wire using an ethernet broadcast group, and the switches would forward the packet to all connections. (Yay! Just like hubs in the 90s! :)
So I figure you need to add a routing entry for 0.0.0.0/24 to your client machines, so that they can properly address the broadcast packet.
I'm looking for some Linux code to find an IP address from an Ethernet address. I suppose I have to do some inverse ARP trickery but I don't find any example...
http://compnetworking.about.com/od/networkprotocolsip/f/convertipmacadd.htm
Try sending an IP broadcast (e.g. ping 192.168.1.255 if your subnet is 192.168.1.0/24) to prime your ARP cache, followed by arp -a to spit it all out.
For computers that you have communicated with, you can look at their arp entry. This is available in text format in /proc/net/arp for example. Finding an IP address for a MAC that you know but haven't communicated with is significantly more difficult. The closest match, protocol-wise, would be RARP but that's hardly ever in use so your are not likely to get a response.
You can always scan your local subnet to make sure you get a full view in your arp table. See for example fping for an efficient way to do this. Note that hosts don't actually need to respond to the pings in question to appear in the ARP table, so this is useful even in the presence of local firewalls etc.
Take a look at Thomas Habet's Arping. I've not tried it, but the basic idea is to send an ICMP Ping network packet to the MAC address in question using a broadcast destination IP address in the IP header. Only the host with the specified MAC address will reply and the reply will (usually) contain its IP address. It won't always work but it might be good enough for you. See the project readme for limitations.