In similar questions, the question that has been answered is:
why do we need both MAC and IP addresses on the internet? They are
both addresses. Why can't one just be used to describe a device?
The answer is along the lines of:
The two protocols are not universal, not all devices use it. IP
provides a logical address and allows routing, MAC doesn't support routing, and more.
My new question is:
That's a nice answer as to why the internet as a whole needs both types of addresses, but why do we need Local IP addresses?
Locally, on the same network, no routing is involved, I'm simply sending to the computer next to me. Why can't I just send directly to his MAC address? And the router that connects our local network to the internet - why can't he just store a table of MAC addresses to keep track of what from the outside world goes where in the "local world"?
The existence of Local IP seems unnecessary.
So lets forget for a second that all modern OS's are primarily based on IP/IPv6 and your suggestion would completely break everything. Imagine this analogy:
An IP address is like a fully qualified postal address:
I. M. Ray
1024 Megabit Dr
Somecity, State 10101
Your MAC address is your physical house. The blue one 4 house from the corner, with the big oak tree.
When someone is sending you a letter conventionally, the mail is routed to your local post office based on the full address. We will compare this with routing of IP over the internet. The post office the mail was sent from could care less about your oak tree.
In the conventional method, the post man would organize his deliveries by street, and go house to house delivering the mail. This is similar to ARP table, we have organized the houses into an easy to find and navigate index.
In your proposed method, as soon as the mail arrives at the post office, they replace the envelope with your full address to one with a description of your house on it. It is now the post mans job to remember where the Blue house with the oak tree is.
So, while your thoughts are on the right track, they are just not practical. Once you are on the same layer 2 domain (local), then you don't necessarily need routing and could in theory use just physical addresses.
I am sorry if this is a pretty far out answer. I've been reading your other questions on the topic, and it seems as though you are trying to wrap your head around this subject, and this was my best attempt at breaking it down logically. The whole idea is pretty tricky to understand at first (we've all been there), but once you figure out the parts and the role they play in the grand scheme, the more it starts to make sense.
Please feel free to ask if you have any questions, as my primary intention of posting this is to actually help you out.
Related
Is it possible for someone to track a dynamic IP address, if so what would it take and how would it manifest?
Would the person doing so be able to log every change in your ip range and eventually end up with the whole set of ip's you are able to have?
Is it possible to make my dynamic ip change in a different pattern, say in a more extreme way, making it harder for someone to trace it as described above? Is it possible to encrypt it somehow, and also all other information such as hardware MAC's / Inet MAC etc. everything.
The answer is yes and no.
In most cases only your service provider (and law enforcement) will have a log of all IPs you had and start/end times of each lease. You basically can't do anything to prevent this because they need to be able to identify you as their customer with a valid contract. This is usually done via MAC address of CPE equipment you get from service provider or by some login credentials (for PPPoE for example). There is no such thing as encrypting the IP and changing your MAC address would not prevent service provider from identifying you. For someone else there is no reliable way to track you. The closest thing they can find is the scope (or scopes) from which dynamic IP addresses are issued.
At the other hand, when you mix the technology and psychology, every one of us leaves the unique fingerprint when browsing the web. If you examine the combination of software someone uses, their traffic patterns (amount of traffic, sites they visit, activity during the day), their behavior and style of writing, etc, you can not just link them to some IP address but make a distinction between different users behind the same IP address. Anyway collecting this data is really hard which makes it improbable, especially if we are talking about ordinary internet users.
(please redirect my question to relevant stack site, if I am in wrong place, however here I feel guaranteed to get help)
When playing with traceroute command I want to be sure I am not connecting to virtual host that may be dynamically mapped to a number of geographically dispersed servers(since it does not make much sense to track packets jumping from continents).
So more precisely with concrete example: how to prove with help of nslookup -querytype=NS google.com that google may redirect me to different servers across the world. I tried IPconfig locator for all values returned by nslookup, it always returns same location: California Mountain View.
It seems I don't understand something really important in here. Thanks.
update: tried nslook up from australian server, all the ip adresses still point to same location..
You cannot prove the location of any host. At the very best you can make an educated guess.
Geolocation databases are a big list of IP addresses and where the machines hosting those addresses are believed to be located. But they are just a guess and even the best of them are only 90% accurate to the state/regional level, meaning 10% of the addresses are someplace completely different. I use MaxMind because they have a fairly accurate free version and their commercial versions are not too expensive. They also have a free web-form where you can do 25 lookups per day.
You can use tools like traceroute to see some of the machines between you and your destination. Sometimes they have geographic locations in their DNS names. Sometimes their IP addresses will be listed in Geolocation databases. However, not all routers respond, many segments are virtualized and so their hops/routers are invisible, and firewalls may block the trace before it completes.
DNS databases list the address of the organization who owns an address or domain. DNS names themselves can be anything anyone wants, so even they contain geolocation information, there is no reason to believe it is true. In particular, a router might have a DNS name indicating the destination its connecting to, or even the administrative office responsible for it, and not the physical location of the device itself.
The IP address you are talking to can forward anything it wants to anywhere else it wants and there's absolutely no way you can detect that. So you can only follow the trail up to a point.
To make a good guess for the location of a host, look-up its IP address in a geolocation database, then run a traceroute and look-up the IP address of the last router before the destination. That will get you as close as you can.
First-timer on Stack Overflow here. I'm surprised nobody seems to have asked this question, and I hope this is the right place to ask this. I'm trying to determine if I should expect regular network switches (just simple switches, not routers) to have the capability to isolate local network traffic (i.e. targeted traffic that is directed to another local port in the ame switch) within the switch?
For example, if I have 2 machines connected to ports on the same switch (say, ports 2 and 3) and conversing using a directed, non-broadcast protocol (e.g. TCP), I wanted to make sure the traffic between these 2 machines are not forwarded the the rest of the network outside of the switched subnet.
I'm building a home network and I wanted to build private network "subnets" or "zones" using switches where local subnet traffic does not get forwarded to the "backbone" or the rest of the network. Note that I am NOT trying to block any inbound or outbound traffic to/from/between these "zones", but I just wanted to implement a "need to know" basis for these zones to limit network-wide exposure for localized traffic destined within the same switch. Specifically, I wanted the backbone to have as little unnecessary traffic as possible.
So back to the original question: is it fair to expect any network switch out there to be smart enough not to forward local traffic to the rest of the network? I would expect this to be the case, but I wanted to make sure.
PS: You can assume I have a DHCP/WINS server somewhere on the network that will be assigning IP addresses and the such.
I hope the question makes sense, and any help will be appreciated!
- K.
Short answer: yes, the switch is smart enough (otherwise it would be a hub).
And if you need fancy stuff you might have a look a VLANs.
And I believe this question belongs to serverfault or maybe superuser. That's probably why nobody asked it here :)
Here is my situation. I am part of a project creating a P2P charity website, where users connect and can give money to one another. Because of the nature of the site, we know scammers are going to be rampant. We have several preventative measure ideas, and one idea that came up was tying an IP address to the user's account. The reason for this would be to be able to detect when someone from the same IP address creates several accounts.
Would this be reliable? Why, or why not? I have been googling and found many conflicting ideas on the subject. Thanks for any help you can give.
No, it is not reliable. Because:
Residential customers who aren't specifically paying for a static IP address will often see their addresses change frequently. I'm on AT&T DSL and I see my IP address change roughly twice per month on average
People legitimately sharing an internet connection, whether they're using different workstations in the same office with a T1 line, or they're all connected to the same Wi-fi hotspot at Starbucks, will all have the same IP address.
Related to the above, people who are mobile, such as people who use laptops to connect to Wi-fi at coffee shops, airports, hotels, etc, will have a different IP address for each location they visit.
Even people who stay in one place with a static IP address can spoof your system by using a proxy server or a proxy tool like Tor. This makes IP restrictions trivial to bypass.
No.
Many connections are behind NAT (One public gateway IP address for many people), or use DHCP (frequently changed IP addresses).
An IP address is one of the worst ways of identifying a user.
There is a dicussion board I am part of that bans sock puppets ( that is, multiple accounts by the same user ). They have no means of automatically detecting them, becasue there is no means of definitively identifying them. IP addresses are captured, because they can be used to help identify sock puppets, but I know that the process of identifying these is laborious, manual, and error-prone.
This is only undertaken when there is suspicion that someone is using sock puppets for malicious or disruptive purposes. In your case, there is no real answer other than careful and manual monitoring of usage habits, using the information that you gather about users to attempt to identify suspicious habits. But you also have to accept that 80% of sock puppets will go undetected, and do what you can to warn other users of the possibility.
Your bigger issue, incidentally, may be Munchausen by Internet which we were also caught by.
No, not least because:
IP Addresses can change over time, thanks to DHCP leases expiring.
People access websites from many different locations including home, work, coffee shops, etc.
When behind a NAT firewall or a proxy server, many people can share the same IP address.
Will you have many people registering who are entitled to receive money? I'd suggest a manual verification process using real people if at all possible. If nothing else, you can claim to be exercising due diligence if there's a human involved.
No: for example, any company proxy will only have one external IP address, so everyone registering from within the network will appear to have the same IP address.
Recent legal case perhaps worth reading up on : http://yro.slashdot.org/story/11/05/03/2020205/An-IP-Address-Does-Not-Point-To-a-Person-Judge-Rules
Totally unreliable...
Somebody on dial-up will have a different IP address every time they "dial-up".
DSL users will have a different IP address every time they reset or reconnect their account unless they pay for a static IP.
Many users on a particular LAN will be sharing one public IP address.
A particular user can login from home, work, public hotspot and have a different IP from each location.
I do development for an ASP service, and we have recently went through a required 3rd party security audit to obtain status allowing us to host data for a certain government agency. So if I may share some of the information I gleaned turning the trainings, perhaps it would help.
First, IP addresses can be used to assist in what you are trying to accomplish, but they are definately not good by themselves. An example would be the wireless at McDonalds. Everyone at McDonalds is connected to the same wireless and are using the same public IP address through a NAT, which translates from a local address (i.e. 192.168.0.xxx) to a public address for all computers located behind it. The NAT keeps entries so it knows what traffic is allowed to come back into the network, and which computer it is going to.
We found that a good security measure is to use an encrypted session key that is included with all GET/POST submits. That session key contains a GUID which is a lookup to the current session. So even if someone breaks your session encryption, they still need to guess at a GUID in order to find a valid session. On top of that, by tracking IP addresses, if it changes suddenly, we can immediately invalidate the session (we also have whitelisting in case someone is load balancing multiple internet lines, which can cause the IP to change frequently). A cookie can also be used in place of the IP address tracking, as two people behind the same NAT can potentially hijack each other if they can find a way to steal the other person's session key.
Encrypted cookies are also a good way to enforce security. But make sure you are using a framework that is tried and tested, as they have already closed the known vulnerabilities for you. Believe it or not, our security company told us that .NET has emerged as one of the top secure frameworks that they know of. I almost fell out of my chair when I heard that.
Personally I don't think it'll be reliable.
The main reason will be for those using a shared IP. That includes most users connecting from inside a business and home users connecting through the same WIFI hub.
It's more than likely for multiple users to be coming to your site with the same IP address.
Adding to that the fact that IP addresses change over time and you're already losing track of your users.
It's also worth remembering that oftentimes multiple users will be using the same physical computer. Are you wanting to have only one member of a household able to signup etc?
It could be somewhat useful as part of a defense-in-depth approach, but I wouldn't call it "reliable".
If you want to identify users, you can use a cookie. One solution uses a combination of cookies, local storage, flash, and other state information that can be stored in a browser: http://samy.pl/evercookie/
Nothing is 100% reliable. These cookies can be erased by a determined user, or in some browsers with one click. Ultimately, in many countries outside of the USA, a user has the right not to be tracked.
As an alternative for the future: New Intel® Business Processors Deliver Leading Security, Manageability and Performance
As long as the connection between the browser and the CPU isn't interviened which I believe there is more risk of with a browser than a desktop application.
How can I detect if another host is using the same MAC address as the current host, e.g. because the other host is spoofing?
I'm working in an embedded environment, so looking for answers on a protocol level, rather than “use such and such a tool”.
Edit: RARP does not solve this problem. For RARP to get any reply at all, there has to be at least one host on the segment which supports RARP. Since RARP is obsolete, modern operating systems don't support it. Furthermore, all RARP can do is tell you your own IP address - the response won't be any different if there’s another host on the segment with the same MAC, unless that host has itself used a different IP address.
This question is too interesting to put down! After several false starts I started thinking about the essential components of the problem and scoured the RFCs for advice. I haven't found a definitive answer, but here's my thought process, in the hope that it helps:
The original question asks how to detect another device with your MAC address. Assuming you're on an IP network, what's required to accomplish this?
The passive method would be simply to listen to traffic and look for any packets that you didn't transmit but have your MAC address. This may or may not occur, so although it can tell you definitively if a duplicate exists, it cannot tell you definitively that it doesn't.
Any active method requires you to transmit a packet that forces an impostor to respond. This immediately eliminates any methods that depend on optional protocols.
If another device is spoofing you, it must (by definition) respond to packets with your MAC address as the destination. Otherwise it's snooping but not spoofing.
The solution should be independent of IP address and involve only the MAC address.
So the answer, it seems, would be to transmit either a broadcast (ethernet) packet or a packet with your MAC address as its destination, that requires a response. The monkeywrench is that an IP address is usually involved, and you don't know it.
What sort of protocol fits this description?
Easy Answer:
If your network supports BOOTP or DHCP, you're done, because this authoritatively binds a MAC address to an IP address. Send a BOOTP request, get an IP address, and try to talk to it. You may need to be creative to force the packet onto the wire and prevent yourself from responding (I'm thinking judicious use of iptables and NAT).
Not-so-easy Answers:
A protocol that's independent of IP: either one that doesn't use the IP layer, or one that allows broadcasts. None comes to mind.
Send any packet that would normally generate a response from you, prevent yourself from responding, and look for a response from another device. It would seem sensible to use your IP address as the destination, but I'm not convinced of that. Unfortunately, the details (and, therefore the answer) are left as an exercise for the OP ... but I hope the discussion was helpful.
I suspect the final solution will involve a combination of techniques, as no single approach seems to guarantee a dependable determination.
Some information is available at http://en.wikipedia.org/wiki/ARP_spoofing#Defenses
If all else fails, you may enjoy this: http://www.rfc-editor.org/rfc/rfc2321.txt
Please post a follow-up with your solution, as I'm sure it will be helpful to others. Good luck!
You could send an ARP request for each possible ip in the subnet.
Of course the source address of the ARP request must be ff:ff:ff:ff:ff:ff, otherwise you might not see the response.
I forged a packet like this with bittwiste and replayed it with PReplay and all the hosts on the network got the response. (I don't know if these forged ARP packets are legal or not... some OSes might ignore them)
Here is what the forged package looked like:
Here is what the reply looked like:
If you watch the responses and see your MAC address in one of the packets (in the red rectangle) , than someone has the same MAC address as you do...
Unfortuantely I couldn't test the theory fully because none of my (Windows) machines care about me trying to set the nic's MAC address...
Two hosts using same MAC address on a single network segment would probably make switches go nuts and you could probably detect it by having an extremely unreliable network connection (as the switches would send some portion of packets that belong to your host to the second one, depending on which one of you sent the last packet in their direction).
This is very late, and a non-answer, but I wanted to follow up with exactly what I did in case anyone else is interested.
I was working with some very weird embedded hardware that doesn’t have a MAC address assigned at manufacture. That means we needed to assign one in software.
The obvious solution is to have the user pick a MAC address that they know is available on their network, preferably from the locally-administered range, and that’s what I did. However, I wanted to pick a reasonably safe default, and also attempt to warn the user if a conflict occurred.
In the end I resorted to picking a random-ish default in the locally-administered range, chosen by making some hardware readings that have moderate entropy. I deliberately excluded the beginning and end of the range on the assumption that those are moderately more likely to be chosen manually. The chances are that there will only be one of these devices on any given network, and certainly less than 20, so the chances of a conflict are very low, albeit not as low as they could be due to the somewhat predictable random numbers.
Given the low chances of there being a problem, and despite the excellent answers above, I decided to dispense with the conflict detection and make do with a warning to the user to look out for MAC conflict problems.
If I did decide to implement conflict detection, then given that I control the whole network stack, I would probably look out for excessive unknown or missing packets, and then trigger a change of MAC address or warn the user when that happens.
Hopefully that will help someone else somewhere – but probably not!