In particular I'm looking for an IP address that I can put in my hosts file that will black-hole a given DNS name. Right now I'm using 127.0.0.1 but that would start acting odd if I installed any services.
How can I prevent a 3rd party program from contacting a given server?
RFC-3330 seems to be the goldmine
The best option seems to be:
192.0.2.0/24 - This block is assigned as "TEST-NET" for use in
documentation and example code. It is often used in conjunction with
domain names example.com or example.net in vendor and protocol
documentation. Addresses within this block should not appear on the
public Internet.
Actually the loopback IP 127.0.0.1 is ideal for ad blocking. If you run Apache anyway, you setup a virtual server that returns 404 for requests on 127.0.0.1. That way your browser is not constantly waiting for the connect to an unknown host to timeout. All those ad requests return instantly, freeing up resources in your browser to get the actual page content.
I've used 0.0.0.0 in my hosts file to block ad web sites. Not sure if there are any side affects?!?!
I see that you've correctly found that 192.0.2.0/24 is reserved for testing, and won't appear on the Internet.
However if your local area network relies on a default route to get to the rest of the Internet then you'll still be sending this traffic out of your network towards your ISP.
Best case is that your ISP will send back ICMP_NET_UNREACHABLE errors and your applications will notice those and act accordingly. Worst case is that the traffic is completely blackholed, at which point your applications will sit around until the connections timeout.
The correct strategy for avoiding this depends on your OS and local network configuration. On a Linux system I'd just add a route for that /24 with "reject" as a target.
Addresses 127.0.0.0 to 127.255.255.255 can be used for loopback connections.
So have your httpd listening on 127.0.0.1 and use any of the others for the blacklist.
If you use any of the private IP address ranges (10.whatever, 192.168.whatever) that you aren't connected to that should work.
One advantage of using 127.0.0.1 is that an attempt to contact the server will return immediately with failure (as long as you're not running a local server, of course). If you use any other address that does not refer to a specific machine, such as 192.0.2.x, then attempts to connect to a server at that address will take some time to time out (at least a minute or more).
I use denyhosts for ssh. http://denyhosts.sourceforge.net/ It attempts to block known malicious sources. Is this what you're talking about?
0.0.0.0 ( as another poster put ) shouldn't be used - it has a distinct meaning that isn't "nothing" and it isn't reserved for what in most cases is a dead-end. As for BCS's comment to dulaneyb about DCHP and private ranges - a private range is a private range. If you're kicking to your private range, then you're routing to an empty slot. If you're kicking to one of the other private ranges, then an upstream device should drop it.
Related
We are attempting to use a Cisco ASA as a VPN as well as forward traffic to two servers.
Our ISP has given us a range of IP addresses that are sequential.
154.223.252.146-149
default GW of 154.223.252.145, we're using netmask 255.255.255.240
We have the first of these, 154.223.252.146, assigned to the external interface on our ASA and it’s successfully hosting our VPN service. It works great.
The next and final goal is to have 154.223.252.147 forward https traffic to 10.1.90.40 and 154.223.252.148 forward https traffic to 10.1.94.40.
Our current blocker is our inability to get the outside interface of the asa to respond to these ip addresses.
We’ve been able to use 154.223.252.146 to forward https traffic correctly. So we know that works.
I’ve plugged my laptop into the switch from our ISP and have successfully manually assigned 154.223.252.147 and 154.223.252.148 with the default gw of 154.223.252.145 and was happily connected. So we know the IP’s are there and available, we just need to convince the ASA to respond to them and use them to forward https.
We’ve tried plugging cables from the switch into other interfaces on the firewall. This failed because the netmask overlaps with our first outside interface 154.223.252.146 255.255.255.240, Cisco hates this and doesn’t allow it.
We’ve read documentation and have heard that it’s possible to assign a range of IPs to the ouside interface by defining a vlan. We do not know how to successfully make this work and out attempts have failed.
What's the best way to accomplish this configuration with a Cisco ASA?
You don't need to assign multiple IPs from the same range to more than one interface. That doesn't work with Cisco. Instead try a static one to one NAT for your Web server and terminate your VPN traffic on the IP address assigned to the interface.
Watch this video for one to one NAT:
https://www.youtube.com/watch?v=cNaEsZSsxcg
Cisco has an active scanning technology that was enabled on this ASA. We were able to diagnose it by intermittent bad behavior. After troubleshooting long enough we realized that some of the behavior couldn't be consistent with the changes we were making. So we started looking for things that the firewall would be trying to do by itself. That ended up helping us narrow it down. Disabling active scanning allowed our external vlan configurations to work. Now moving on to tightening up the configs.
I have two applications (diy container type) which have to be connected via TCP. Let's take as example application clusternode1 and clusternode2.
Each one has TCP listener set up for $OPENSHIFT_DIY_IP:$OPENSHIFT_DIY_PORT.
For some reason clusternode1 fails to connect to any of the following options for clusternode2:
$OPENSHIFT_DIY_IP:$OPENSHIFT_DIY_PORT
$OPENSHIFT_APP_DNS
Can you please help in understanding what should be url for external TCP connection?
You might check the logs to see if the OPENSHIFT_DIY_IP for both apps are within the same subnet. If one, say, is...
1.2.3.4
...and the other is...
1.5.6.7
...for example, then you might not expect Amazon's firewalls to just arbitrarily allow TCP traffic from one subnet to another. If this were allowed by default then one person's app might try to hack another's.
I know that when you're dealing directly with Amazon AWS and you spin up multiple virtual servers you have to create virtual zones to allow traffic between them. This might be something that's necessary.
Proxy Ports I don't know if this is useful but it's possible that a private IP address is being bound to your application(s) and then a NAT server is translating that into a public IP address.
I have a website that I'm running locally at localhost:8000. I'd like to access my site from other devices on my network. I've tried to visit the site via my computer's internal IP address via: 127.0.0.1:8000but this doesn't work. Is this possible?
Three most probable things:
Check if there is a network route between the client and the server machine (commands like PING and TRACERT will help);
Check if the server machine has a firewall. If it does, there must be a rule allowing (opening) connections through that port (8000) in TCP;
Most likely, the problem is one of the two above. If not, there's one last thing:
Make sure the web server (the one that serves localhost:8000) is bound to listen to all IP addresses (not only 127.0.0.1).
To know that, search for servername bind all ip addresses on google. E.g., for apache HTTPD, it'd be apache bind all ip addresses.
here is what I do in similar cases:
search rejetto hfs on google, it is single executable less than 1Mb size and download it into your server machine.
after starting it, follow menu->IP addresses. these are all your possible addresess on the server side.
these are your IP addresses to enter, and your port is 8000 as you mentioned.
most possible IP addresses you will find are in the format of following:
192.168.?.?
10.0.0.?
169.254.?.?
besided you will probably need to add a firewall rule for your server app.
I have an application that relies on IP addresses for communication (Domain names simply does not work. :(... )
Its function is to connect to its peer on the other machine and send data over after establishing trust. During the "trust establishing" phase they both exchange their IPs for future communication. They both are behind the two different firewalls and are NATted. One is in our NATted office network and other is in the cloud NATted behind their firewall. The applications knows their respective private IPs and exchange that (the 10.x.xxx.xxx range), when they try to connect back to each other (using the private IPs with range 10.x.xxx.xxx) for transferring data they fail. The connection is TCP and the port range is pretty varied.
I am curious if there is anyway I can hard code (for this one time) a rule (at may be firewall level or some place outside my application) that says if there is a connection being initiated for IP address 10.x.xxx.xxx then redirect it to 205.x.xxx.xxx?
Private IP address ranges like 10.x.y.z are, by their very nature, private.
You can't do any meaningful resolution unless each node in between the endpoints has rules in place to translate these.
Translation is tricky, all the main tools you would use cater for static translation (port forwarding, e.g. where a particular port is forwarded to a particular IP). This is one avenue, but it is a hacky one (it requires you to open lots of ports, procedurally update your router and probably have some sort of broker server to maintain mappings).
Alternatively, you could run the isolated networks over a VPN, which would give your endpoints mutual private IPs which you can use to connect to eachother. It would simply be a case of binding to this new address and communicating across the VPN. This would also potentially encrypt your communication over the internet.
Other possibilities are to use NAT/TCP punchthrough techniques which can allow traversal, but these are really a patch to a broken network topology (Read up on IPv6 to see how this can be alleviated).
Alternatively, you could route all the connections over a proxy, but this will complicate matters compared to a VPN.
To answer the question about hardcoding a rule, port forwarding is the solution here. It will obviously depend on your router configuration for the peer accepting the connection, but this client should have the port target port forwarded to the machine. This will obviously not scale very well and is really shifting to a server/client architecture for one connection!
Depending on your hardware, you may be able to forward a range of ports (if a single port cannot be established) and limit the port forwarding to certain incoming connections (the external IPs).
Information on port forwarding can be found at http://portforward.com/
This sounds a lot like what you'd want out of a VPN. Is there anyway that you could set one up? Basically the Site-To-Site VPN between you and the cloud would say 'oh hey, here is an ip located on the remote network, go ahead and connect through the link'. Would this kind of solution work in your case?
Something along these lines: http://i.msdn.microsoft.com/dynimg/IC589512.jpg
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.