I am now load testing a website through jmeter from my machine. But I want a real world scenario , so can ip aliasing or ip spoofing be used by jmeter which will look like requests are being sent from different ip addresses.?
Yes it can, see property Source IP address::
http://jmeter.apache.org/usermanual/component_reference.html#HTTP_Request
Note that you must use HTTPClient implementations.
For a full tutorial, see :
http://blog.milamberspace.net/index.php/2009/12/03/changer-ladresse-ip-source-dune-requete-http-lors-dun-test-avec-jmeter-549.html
Related
I need to make a request with a spoofed IP address for testing purposes. What's the easiest way to do this?
For my own purposes, changing the HTTP header was enough, via the following:
curl --header "X-Forwarded-For: 1.2.3.4" "http://www.foobar.com"
You can't.
In general, spoofing IP addresses for TCP is remarkably difficult. Unless you have control of a router quite near your target or near the IP you're spoofing, consider it impossible.
The reply packets need a path back to you in order to complete even the three-way handshake. The most reliable way to do this is to have control over a router in the most common pathway between your target and your spoofed IP address: this would let you capture packets between the target and the spoofed address and forward them on to you.
You could also try injecting bogus BGP route advertisements, but doing so would doubtless be noticed and cost you dearly when your peers drop you completely.
Can I make libcurl fake or hide my real IP address?
No. libcurl operates on a higher level. Besides, faking IP address
would imply sending IP packet with a made-up source address, and then
you normally get a problem with receiving the packet sent back as they
would then not be routed to you!
If you use a proxy to access remote sites, the sites will not see your
local IP address but instead the address of the proxy.
Also note that on many networks NATs or other IP-munging techniques
are used that makes you see and use a different IP address locally
than what the remote server will see you coming from.
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.
Am I able to depend on a requestor's IP coming through on all web requests?
I have an asp.net application and I'd like to use the IP to identify unauthenticated visitors. I don't really care if the IP is unique as long as there is something there so that I don't get an empty value.
If not I guess I would have to handle the case where the value is empty.
Or is there a better identifier than IP?
You can get this from Request.ServerVariables["REMOTE_ADDR"].
It doesn't hurt to be defensive. If you're worried about some horrible error condition where this isn't set, check for that case and deal with it accordingly.
There could be many reasons for this value not to be useful. You may only get the address of the last hop, like a load balancer or SSL decoder on the local network. It might be an ISP proxy, or some company NAT firewall.
On that note, some proxies may provide the IP for which they're forwarding traffic in an additional HTTP header, accessible via
Request.ServerVariables["HTTP_X_FORWARDED_FOR"]. You might want to check this first, then fall back to Request.ServerVariables["REMOTE_ADDR"] or Request.UserHostAddress.
It's certainly not a bad idea to log these things for reference/auditing.
I believe that this value is set by your web sever and there is really no way to fake it as your response to there request wouldn't be able to get back to them if they set there IP to something else.
The only thing that you should worry about is proxies. Everyone from a proxy will get the same IP.
You'll always get an IP address, unless your web server is listening on some sort of network that is not an IP network. But the IP address won't necessarily be unique per user.
Well, web request is an http connection, which is a tcp connection and all tcp connections have two endpoints. So, it always exists. But that's about as much as you know about it. It's neither unique nor reliably accurate (with all the proxies and stuff).
Yes, every request must have an IP address, but as stated above, some ISP's use proxies, NAT or gateways which may not give you the individual's computer.
You can easily get this IP (in c#) with:
string IP = Context.Request.ServerVariables["REMOTE_ADDR"].ToString();
or in asp/vbscript with
IP = request.servervariables("REMOTE_ADDR")
IP address is not much use for identifying users. As mentioned already corporate proxies and other private networks can appear as a single IP address.
How are you authenticating users? Typically you would have them log in and then store that state in their session in your app.
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.
I'm working with Microchip's TCP/IP stack and the host name of my device is not being broadcasted, although I can access it using its DHCP assigned IP.
So the question is, what is the protocol that a network device uses to broadcast its host name, so that when I see a list of devices in a network I can identify it by name?
Is it the NetBIOS name service or something else? Thanks in advance.
The most network-agnostic way to specify a hostname for a host on the network is through DNS, which your device itself cannot control, but all is not lost.
In most environments, the DHCP and DNS servers are tied (AD in Windows networks, DNSMasq on linux, etc...) so your best option is to rely on this behaviour. When you request an IP using DHCP, the DHCP protocol allows you to specify the hostname you'd like to use and if the network is set up to allow DNS entries to be created and maintained by the DNS server, the hostname you send during your DHCP request will typically be used.
The DHCP parameter is called 'Hostname'. The Network protocol documentation for this parameter is located in RFC 2132, and explained here.
There is WINS (based on NetBIOS) that supports this functionality.
There is ZeroConf/Bonjour that offer a "service advertisement" protocol but I am guessing that's not what you are after here.
In "normal" IP based networks, name resolution would go through a DNS layer: the DNS servers propagate their databases (if instructed too of course) but there is no concept of "broadcasting" at this layer.
I guess you've solved this by now but I modified the dchp.c file in the Microchip stack and added the following to the options part of _DHCPSend().
// host name
i = strlen(AppConfig.NetBIOSName);
UDPPut(12); //host name code
UDPPut(i); //length
UDPPutString(AppConfig.NetBIOSName);
This worked for me.