Just to explain my setup: I have a few websites hosted on a shared server (Lunarpages) and I use Google Apps (with modified MX records in Lunarpages) so the Google Apps emails work.
Now, I've noticed occationally that a mail script on one of my sites gets triggered without any content, though it includes IP information that the form collects. I looked up a couple of those IP address with AbuseIPDB, and they are known hacking IPs. So I want a good way to block all access to my server from known bad IPs.
I see in Cpanel in Lunarpages an option to turn on CloudFlare for security, and looking into them a little, it does appear that they block bad IPs. But I'm a little concerned about whether that would risk messing up how my site works or email works or how my analytics and email forms collect IP address information or if there would be anything different from me besides just turning it on and that the bad IPs would be blocked. I'm not looking to get myself in to a lot of troubleshooting.
Is CloudFlare a good solution, or are there other good alternatives?
Regarding the AbuseIPDB, they look like they have an API that I might be able to set up to block IPs, but if I understand right, I would have to modify all my sites and that still wouldn't block direct access to a lot of files. Unless I'm mistaken.
You can use ipset to block a list of IP addresses and you can set up ipset list of IP addresses from some spam DB.
Related
I develop and manage a small promotional/marketing website on Wordpress for a startup SaaS product. We're using Cloudflare for DNS and whatnot. Apparently the WAF has been turned on which uses a proxy and changes the user's IP address. i'm trying to use IP address to filter "internal" traffic for Google Analytics and the only way this works is with the WAF turned off. If not using the WAF is going to cause any sort of significant risk for my website, then obviously I'll need another way to do my analytics thing. Reading about what all it provides on their website doesn't make it all that clear to me how important it is for a website like this. If anyone who "gets it" had some insight to share, I'd be most appreciative. thx!
You should definitely use the WAF - it will protect your website from many malicious bots and attacks.
Wordpress sites are particularly juicy targets for attackers, for a number of reasons:
The security of a default Wordpress installation is not great.
Every Wordpress site shares common default features, such as the location of the admin login page, the admin username, and other exploitative resources.
Wordpress is extremely popular, and currently used by an estimated third of all websites on the internet.
Wordpress is used by many, many small businesses and hobbyists who do not how to secure their site properly.
Ergo, attackers can very easily scour the web for Wordpress websites that are easily hackable. Other nefarious activities are commonly carried out with ease on most Wordpress sites, such as comment spam or Denial of Service attacks.
What protection does the WAF offer?
Cloudflare and most other high quality WAFs can be configured to protect your site by automatically performing actions like:
Blocking known bad IP addresses.
Blocking bad bots which are automatically making requests to your site.
Limiting high numbers of requests from one source in a short amount of time (usually a sign of a DoS attack or scraping).
Blocking requests from particular countries or locations.
There is no reason why you wouldn't want to enable this protection if you have it available to you, and Cloudflare is the industry leader in this area.
Additionally, I would recommend you research how to better secure your Wordpress site in ways other than just the WAF - e.g. The Ultimate WordPress Security Guide
How to solve the IP address issue
Cloudflare is not changing the user's (the client) IP address, but rather acting as a proxy. As you have noticed, the IP address you're seeing is not the client's own, but one of Cloudflare's. This is crucial to how Cloudflare works to protect your site, but this is a common issue when using any kind of proxy.
To get the correct IP address when using a proxy, you need to check the X-FORWARDED-FOR header. You might see this as a string of comma-separated IP addresses, depending on how many proxies the user has gone through before reaching the site. The first one in the list is the original client IP.
e.g. Here 203.0.113.1 is the client's original IP address:
X-Forwarded-For: 203.0.113.1,198.51.100.101,198.51.100.102
Documentation: How does Cloudflare handle HTTP Request headers?
Anyway, it's good to use a function which can comprehensively check headers and give you the best match for the original client IP, regardless of whether the user is behind a proxy or not, so that you can guarantee it always works.
Here's a very popular StackOverflow question about this:
What is the most accurate way to retrieve a user's correct IP address in PHP?
My college has different proxies for accessing Internet like 192.168.0.2/3/4 and also a specific port number.What is the advantage of using this ? I also would like to know what exactly happens there.I also heard that my institution has different ISP connections shared over the same network. What is the role of proxy there?
It will be very easy to know if you understand what proxies do and why they are used generally. Which could be found on a magical website called www.google.com. By using a proxy, you get more control over the network because all request go through there.Your school may want to do stuffs like traffic shaping, content filtering etc. Using the proxy server will make sure all request to the internet are routed there first.
Proxies are good for a few things:
Filtering. By using a proxy, your college can filter out viruses, porn, Facebook or torrent downloads.
Logging. By requiring a username and password, the college can track what you do with your internet time, and can tell you off if you go somewhere you shouldn't or help you be allowing them to do traffic shaping, or other network maintenance.
Line Bonding. For example, if you have two ADSL lines of 5Mb, you can bond those to get a 10Mb line (normally this is done at the gateway stage, and not the proxy, but it is possible to do it at this stage of the network)
Failover. Again, this would normally be done at the gateway/router stage. This detects which lines are active and routes your traffic to those lines.
Network Connectivity. If your college is in-turn part of a bigger academic network, this could allow crossing those network boundaries to get internet access.
Although those are valid possibilities, it's probably just for Filtering...
In the wider internet, proxies are in use for allowing access to blocked content - like giving China access to Google...
I am currently building an web app which also utilizes websockets. (Rails for webserver and Nodejs for socket.io)
I have structured my application to use subdomains to separate between connection to the Nodejs server and the Rails webserver. I have "socket.mysite.com" redirected to the Node server and everything else to the webserver.
I am able to test this functionality on localhost. I simply modified my /etc/hosts to include the following:
127.0.0.1 socket.mysite.com
127.0.0.1 mysite.com
I know that on production I simply have to generate a CNAME record for socket.mysite.com and this will also work on my users' computers.
However, I am accustomed to testing my application by passing an IP address around. My team typically set up the server on our own machines and do development. When we want to test our individual servers, we just pass around an IP like "http://123.45.123.45".
With the new subdomain hack, this is no longer possible without modifying each of my tester's /etc/hosts. I honestly don't expect my testers to modify their /etc/hosts on the spot. What I can do is have each member of my team have their own domain and create the appropriate CNAME records for each individual team member.
Is there an easier way to allow me to run my app on an IP and just pass that IP around?
It sounds like your needs have scaled beyond the days of just simply editing a host file. While you could continue to have everyone on your team continue to edit host files, there are two main risks that I see here:
For your idea to just use IP Addresses, you risk missing something in testing that you wouldn't see unless you were on production, as the issue may be dependent on something in the domain configuration.
For using host entries, you introduce a lot of complexity and unnecessary changes to each developer and tester's configuration, which of course leaves the door open for mistakes, and it also takes time that will add-up over the long term.
Setting up a DNS server may be helpful in your case. You could map a set of domains for each developer that match a certain pattern so that your application will still run correctly. This would allow you to share the URLS without having to constantly reconfigure each person's computer. Additionally, marketing and sales stakeholders can easily view product demos as well, without needing to learn what the elusive host file is for.
If you have an IT department, they can help you setup the DNS. However, if you are a small team without a real IT department, some users have found success using DNS systems designed for home or small office networks.
Basically I want to display a hosts external public facing IP address regardless of whether or not it is part of a natted lan. What I'm doing now is just connecting to myipaddress.com and retrieving it from there. I just don't know if I trust that site as a stable source. Is there some authority that facilitates this?
Every web server on the public internet automatically sees your external IP address. There is just no standardized way to "talk it back" as far as I know (e.g. through a header or something).
If you want to do this manually, just use one of the numerous "what's my IP?" services around like www.infobyip.com/detectmyip.php
If you want to do it in an automated fashion, the most stable way would be to set up a script on a remote server, and have that output the requester's IP. In PHP, in most cases, it would look like so:
<? echo $_SERVER["REMOTE_ADDR"]; ?>
(Here is a detailed discussion on how to retrieve the IP in various ways, but if the above worked for you once, it is likely to work forever.)
STUN RFC 3489will do it, though you need access to an open STUN server. There are other sites (like myipaddress.com) that will report your apparent address back to you, but there is no "standard" service for this.
I have a web application that should behave differently for internal users than external ones. The web application is available over the Internet, and therefore obviously to the internal users as well.
All the users are anonymous, not authenticated, but the page should render differently for internal users than external. What I'm doing in my code is use Request.UserHostName and then Dns.GetHostEntry. The result is then compared to a setting in my web.config (that holds something like *.mydomain.local) . If the comparison gives a positive result then I render the HTML that the internal user should see otherwise I render the HTML the external user should see.
However, my problem is that I don't always get the expected value from Request.UserHostName. on the development site I get the IP-number (?) of the machine running the browser but on the customer site I don't get the IP-number of the user machine, I get some other IP-number. The browsers don't have any proxies set or anything like that.
Should I be using something else than Request.UserHostName?
I recommend using IP addresses as well. I'm dealing with this exact same situation setting up an authentication system right now as well and the conditions described by Epso and Robin M are exactly what is happening. External users coming to the site give me their actual IP address while all internal users provide the IP of the gateway machine(router) on to the private subnet the webservers sit on.
To deal with it I just check for that one IP. If I get the IP of the gateway, I provide the internal access. If I get anything else they get the external one which requires additional authentication in my case. In yours, it would just mean a different interface.
Try Request.UserHostAddress, which returns the client's IP address. Assuming your internal network uses IP addresses reserved for LANs, it should be relatively simple to check if an IP is internal or external.
There might be a firewall that is doing some sort of NAT, to enable inside clients to use the external dns-name to reach the server.
Is the IP-number you get on customer site the same at the external customer-server ip? In that case you can hard code for that one IP-address. All internal computers behind that firewall will appear to have to same ip-address and you can classify them as "internal".
It looks like you're being returned a public facing IP Address. Get the user to go to http://www.myipaddress.com . If this is the same as the IP Address returned to your software, then this is definitely the case.
The only solution I can see to get around this is to either get them to connect to the machine holding the asp.net application via a VPN, or to use some other kind of authentication. The latter is probably the best option.
It does sound like there is a proxy between users and the server on the customer site (it doesn't need to be configured in the browser). It may be an internal or external proxy depending on your network configuration.
I would avoid using the UserHostName for what is effectively authentication as it is presented by the browser duing the request and would be easy to spoof. IP address would be much more effective as it's difficult to spoof an IP address in a TCP/IP connection (and maintain a connection). It's still weak authentication but may be sufficient in this scenario.
Even if you are using IP address, if there's a NAT proxy between client and server, you may have to accept that anything coming through that proxy is trusted (I'm assuming that external/untrusted clients don't come through that proxy).
If that isn't acceptable, you're back to other methods of authentication. Rather than requiring a logon or VPN connection, you might consider a permanent cookie or client certificates and only give those to internal clients but you would need some way of delivering those to the client. You could certainly deliver a permanent cookie based on a one-time logon. Cookies can be spoofed in a similar way in that the UserHostName can be however you've got a better opportunity to create a cookie value that is less guessable than a domain name.