In an ASP.NET (C#) WebApp, I can get the IP of the visitors' PC easily, But How to get the MAC address of the visitors' PC in an ASP.NET webApp?
And this ASP.NET app is runing on the inner intranet of our company, and the visitors are also in the same inner intranet of our company.
The MAC address is not part of the IP header (or any other protocols above that), and thus not available if all you see is the HTTP traffic.
EDIT (after OP's update): Since clients and servers are on the same internal network, wouldn't it be better to get a host name from the IP address instead of the MAC address? You can easily look up the host name based on the IP address.
The answer that immediately comes to mind, is that this is only possible if you write an ActiveX control that runs in the client browser to obtain this information on your behalf. On the other hand it might be possible with JavaScript on the client if the javascript can instantiate a COM object that will get the information. The only other way I can think of is have a windows service that does an ARP request once the IP has been captured.
You can't easily do this. There are protocols such as ARP which allow translation between MAC and IP addresses, but this traffic is typically behind a firewall and so not available to you on a public website.
On an intranet, you might be able to do something, but not via ASP.NET. You would need to use other mechanisms to capture this information - but those kinds of tools (e.g. packet sniffers) are generally not available to developers and may contravene corporate IS policies.
Since you're on the same subnet, you can P/Invoke GetIpNetTable to get the webserver's ARP table. If you do this real-time, no additional work would be necessary - since you're having a conversation with the client, you'll have the ARP info. Otherwise, you'd need to construct an ARP request or some IP traffic (say, a ping) to get it in the cache - and note that due to DHCP and other network vagaries (like a machine being turned off), it is possible that converting IP to MAC later will yield a different answer.
Note also that any external clients (ie., ones across a router) just won't show up in the table - so be prepared to deal with that as well. If you need a MAC for them for some reason, it's technically your router's MAC.
Related
According to Obtain client MAC address in ASP.NET Application, it is not possible. I am not entirely convinced because whenever I connect to Tim Hortons WiFi, my MAC address is known.
Occasionally, the network is slow and I see this URL like this before being redirected to the Connect page:
http://timhortonswifi.com/cp/tdl3/index.asp
?cmd=login
&switchip=172.30.129.73
&mac=60:6c:66:17:1a:83
&ip=10.40.66.229
&essid=Tim%20Hortons%20WiFi
&apname=TDL-ON-NEP-02177-WAP1
&apgroup=02177
&url=http%3A%2F%2Fweather%2Egc%2Eca%2Fcity%2Fpages%2Fon-72_metric_e%2Ehtml
So according to this URL, the site knows the IP address of the router, my MAC address, the IP address assigned to my device by the router, the network SSID, some other pieces of information, and the URL I was trying to access prior to connecting.
There's two options: Tim Hortons WiFi Basic and Tim Hortons WiFi Plus, where the "Plus" option allows me to connect to any Tim Hortons WiFi access point in Canada automatically with this device. Registration requires an email address, so I'm assuming this is possible by checking the MAC address and storing it in a database that routers ping upon connection. More info here.
According to the extension of this page, I can safely assume it is ASP. How are they obtaining this information?
When your client traffic reaches the first router, that router will route the traffic to the adecuated port, changing the response MAC address with its own MAC address so the answer will be routed to it. And this will happen for each of the routers the packets travel by. So, at the end, the web server will only see the MAC address of the last router where the answer will be sent to be routed back to the previous roter, and this process repeated until the answer reaches the client.
No, there is not way to obtain the MAC address of client from server side.
But, what you are seeing is a client sending its information to a server. So, the answer can be converted into "how can i obtain my local mac address and send it to the server?".
Browsers do not allow to read this information. Some properly signed/configured ActiveX or Java applets can do it, but they can be blocked, or you can have some device that will not execute java nor activex, so it is not a reliable way of doing it.
In the case in your post, the easiest way of doing it is configuring the wifi access point dhcp or dns server to serve a proxy configuration file that will allow to configure a redirection to the desired web server, redirection that has been created inside the access point, which have all the shown information in your post.
i am using windows server 2003 and 2008
i am about to install a web application on a server that is connected to other computers using simple wired network i.e. no active directory, no domain controller etc..
my question is:
is there a way to prevent mac addresses outside my specified list from accessing my application ? should it be through IIS or Web.config or should i put certain code in the page load events.
another concern: if i use an SSL to secure my application, is it enough along with a reputable anti virus to prevent a virus to access my server through any network computer using my web application
I don't think this is possible.
If you visualise the route from the client to your server; along this route there are 'hops', i.e., routers and switches which route the client's request down one of multiple paths.
At each hop a different MAC address is inserted into the packet - this is the MAC address of the next hop on the route.
So although the IP address always stays the same throughout the entire route (hence you can use the server variables or such like to determine the client's IP address) the MAC that you receive at the server after the final hop is actually the MAC address of the last networking device that the request was directed through.
The only way you'd be able to accurately use this MAC address for some sort of access control is if you had no routing or switching hardware between you and all the clients.
What if routing is involved - the MAC address you'd like to exclude is on another network? In that case you'll never see the MAC address. Using IIS you CAN filter specific IP addresses.
the simplest way to secure a network (also minimum requirement, else considered non-secure network)
1-get CISCO switches and router or (multilayer switch)
2-change native VLAN then create and configure VLANs for example 10, 20, 30 and put ranges of IP for each VLAN
3-enable port security: set max number of mac addresses and enable MAC address "sticky"
4-configure routing protocol to allow switches to "talk" to each other
good luck
The project I am working on is a client/server architecture. In a LAN environment, I want the client's to be able to automatically determine the server's address. I want to avoid having to manually configure each client with the ip address of the server. What is the best way to do this? Some alternatives I have thought about doing are:
The server could listen for
broadcast packets from the clients.
The message from the client would be
a request for the IP address of the
server. The server would respond with its address.
The machine running my project's server could also have a
bind server running. The LAN's router could
be configured to use it as one of its
DNS servers.
I think I saw that
there is a bind library. Does that
mean I can build the bind service
into my server so that bind doesn't
have to be installed on the server?
Any other ideas? What have you done in the past? What are the pros/cons of these approaches and others that might be suggested?
Thanks for your help!
I like number one, that seems shortest and simplest to me. Might get tricky if the "LAN" actually involves switches that you can't broadcast through. Multicasting should help, then.
You can also use DNS, as in Zeroconf. See Bonjour for information about an implementation.
You can use WCF 4.0's new Discovery feature. Two things are possible:
The server can announce to the network that he has gone up or down, and clients can connect to it or look elsewhere, respectively.
The client broadcast an inquiry for a service and all matching services on the network will reply. The client can then pick the service he wishes to use.
You can use either or both, and it's all handled by WCF, so there's little work to actually use it. You can even set up WCF proxies if you have a restrictive network topology (such as NAT or other routing issues). The proxies can cross/convert protocols and even have custom load-balancing or other routing logic.
http://msdn.microsoft.com/en-us/library/dd456782.aspx
We meet a testing scenario which needs to tamper with source IP address of a Http request to simulate clients coming from different countries. Do you know any tool help on this?
Last but not least, our web site is built with ASP.NET.
Thanks.
In a test environment it usually isn't difficult. First read this SO question about virtual network interfaces.
If the server and client are on the same machine, all you have to do is figure out how to get your client software to bind to your virtual interface.
wget for instance has the --bind-address option to specify which local address to bind to. Web browsers are a bit more difficult to do this with; you may need to just run it in a VM.
If your server and client are on the same LAN, you just need to configure your router with some static routes to your client machine. In this case you probably don't need a virtual network interface, just set a static IP for your client machine; as long as the gateway is set up correctly it should be able to send packets to the server, and as long as the route is set up correctly the replies should find their way back to the client.
If the client and server are separated by an internet, it's rather more difficult. One option is to set up a network tunnel endpoint on the server and tunnel it to the client machine, which "knows" that it has the virtual network interface.
As noted in answers to the ServerFault question "Are IP addresses trivial to forge", you cannot easily forge source addresses in a protocol that required two way communication (e.g. TCP). Note that this "two way communication" is required at the packet level. You cannot just say "no problem, I want to send requests and ignore HTTP responses." To establish a TCP session, you need to receive data. Your best bet is to use a proxy server.
I am unsure if the IP standard allows for this, but if you are working in a Lab environment, where you don't need internet connectivity during the test, I can see it working under following circumstances:
Basically, I would set the server's network interface to use netmask 0.0.0.0 and flush the rest of the routing table.
Then you could configure a client machine to take on any IP address as long as you use netmask 0.0.0.0. And two-way communication should be possible.
Server[1.2.3.4/0] <---> Client[x.x.x.x/0]
But please bear with me. I haven't tested this, so I could be wrong :-)
If you have access to your infrastructure, you can add an interface off the router and then place a static route on the router to that network.
Server-----Router----Internet
/
Test_PC----/
Alternatively you can look into PBR (Policy Based Routing) and on the routers you can flag source packets and change the source on the fly, so your server will think they are coming from where you'd like them to come from.
Server-------------Router_with_PBR-------------Internet----- PC
SCR:4.2.2.2 Change SCR:6.6.6.6 to 4.2.2.2 6.6.6.6
But you have to ask yourself why do you want to see when packets come from different countries. Some countries have massive proxy servers that filter access ( "Great Firewall of China"), so the above tests will not prove much.
Your best bet then is using proxy servers or if your looking for a long term solution then setup a server (virtual is great for this) and use RDP for testing. I'm sure you can rent a virtual server somewhere for a month or two.
That's not possible. Because when you forge the ip address, the response is never going to come back, which is required for http.
The best way is to use proxies. See also this question on serverfault.
If you change your source IP address, that means no traffic from your web server will be able to reach back to the client.
You might be able to use some kind of proxy and/or address translation filter to do the remapping while still allowing two-way communication.
In short: How to reliably discover a server running somewhere on a (presumably multi-segmented) local area network with zero client configuration
My client application has to locate the server application without knowing the server IP address. It has to work on a local LAN that may be split into segments with hubs or other switching devices.
I already have a working solution, but it is a bit cumbersome to get it working on multi-segment networks. It works as follows:
When the client starts up, it sends UDP broadcasts on its own network segment. If the server is running on the same segment, it works without any issues - the server responds with the appropriate messages.
If the server and client are running on networks separated by a hub / switch that won't forward UDP (the most likely case), then I have a server instance running on each segment, and they forward client requests to each other via TCP - but I need to configure this for the server instances (simple, but still a pain for tech support.) This is the main problem that I need to address. There are sites where we have hundreds of clients running on 5 or 6 separate segments.
The problems I'm facing:
1. Although my application installer enables the appropriate ports on the firewall, sometimes I come across situations where this doesn't seem to happen correctly.
2. Having to run multiple server instances (and therefore configure and maintain them) on hub/switched networks that won't forward UDP
Finally I need a solution that will work without maintenance on a minimal Windows network (XP / 2000 / Vista) that probably doesn't have Active Directory or other lookup services configured.
I don't want to tag on any runtime stuff for this - should be able to do it with plain VC++ or Delphi.
What approaches do commercial apps usually take? I know that SQL Server uses a combination of broadcast and NetBEUI calls (I may be wrong about this).
Thanks in advance.
You have a few terminology issues:
Where you say "network segment" you appear to mean "IP subnet". Devices on the same network segment can see the same IP broadcasts.
Where you say "hub/switch" you appear mean "IP router".
Where you say "won't forward UDP", the problem is actually "won't forward IP broadcasts".
Once we get past that, you have a few options:
Your servers could register themselves under a well-known name in DNS, if you have a DNS server that allows dynamic DNS updates. You should probably use a SRV record as specified in RFC2782. The clients then do a DNS lookup to find the server(s).
You could statically assign your server(s) well-known names in the organisation's DNS, perhaps with a SRV record as with the previous option.
Your servers could join an IP multicast group, if your routers support IP multicast. The clients then send their initial discovery request as a UDP packet to the (pre-ordained) multicast address.
If you have domain server, I would go with small service on it. You can connect with other services to it and use it as distribution point.
Why domain server? It is relatively easy to find it's name (DsGetDcName).
Other choices would include DHCP server, DNS server or something of that kind that needs to be filled by maintenance staff anyhow.