I'm planning to deploy an internal app that has sensitive data. I suggested that we put it on a machine that isn't exposed to the general internet, just our internal network. The I.T. department rejected this suggestion, saying it's not worth it to set aside a whole machine for one application. (The app has its own domain in case that's relevant, but I was told they can't block requests based on the URL.)
Inside the app I programmed it to only respect requests if they come from an internal I.P. address, otherwise it just shows a page saying "you can't look at this." Our internal addresses all have a distinct pattern, so I'm checking the request I.P. against a regex.
But I'm nervous about this strategy. It feels kind of janky to me. Is this reasonably secure?
IP filtering is better than nothing, but it's got two problems:
IP addresses can be spoofed.
If an internal machine is compromised (that includes a client workstation, e.g. via installation of a Trojan), then the attacker can use that as a jump host or proxy to attack your system.
If this is really sensitive data, it doesn't necessarily need a dedicated machine (though that is best practice), but you should at least authenticate your users somehow, and don't run less sensitive (and more easily attacked) apps on the same machine.
And if it is truly sensitive, get a security professional in to review what you're doing.
edit: incidentally, if you can, ditch the regex and use something like tcpwrappers or the firewalling features within the OS if it has any. Or, if you can have a different IP address for your app, use the firewall to block external access. (And if you have no firewall then you may as well give up and email your data to the attackers :-)
I would rather go with SSL and some certificates, or a simple username / password protection instead of IP filtering.
It depends exactly HOW secure you really need it to be.
I am assuming your server is externally hosted and not connected via a VPN. Therefore, you are checking that the requesting addresses for your HTTPS (you are using HTTPS, aren't you??) site are within your own organisation's networks.
Using a regex to match IP addresses sounds iffy, can't you just use a network/netmask like everyone else?
How secure does it really need to be? IP address spoofing is not easy, spoofed packets cannot be used to establish a HTTPS connection, unless they also manipulate upstream routers to enable the return packets to be redirected to the attacker.
If you need it to be really secure, just get your IT department to install a VPN and route over private IP address space. Set up your IP address restrictions for those private addresses. IP address restrictions where the routing is via a host-based VPN are still secure even if someone compromises an upstream default gateway.
If your application is checking the IP Address, then it is extremely vulnerable. At that point you don't have any protection at the router which is where IP filtering really needs to be. Your application is probably checking HTTP header information for the sending IP address and this is extremely easy to spoof. If you lock the IP address down at the router, that is a different story and will buy you some real security about who can access the site from where.
If are you are doing is accessing the application internally, then SSL won't buy you much unless you are trying to secure the information from parties internal to the organization, or you require client certificates. This is assuming you won't ever access the site from an external connection (VPNs don't count, because you are tunneling into the internal network and are technically part of it at that point). It won't hurt either and isn't that hard to setup, just don't think that it is going to be the solution to all your problems.
IP Whitelisting is, as others have mentioned, vulnerable to IP spoofing and Man-in-the-Middle attacks. On an MITM, consider that some switch or router has been compromised and will see the "replies". It can either monitor or even alter them.
Consider also vulnerabilities with SSL encryption. Depending on the effort, this can be foiled in a MITM as well, as well as the well-known gaffs with the reuse of the primes, etc.
Depending on the sensitivity of your data, I would not settle for SSL, but would go with StrongSWAN or OpenVPN for more security. If handled properly, these will be a lot less vulnerable to a MITM.
Reliance on whitelisting alone (even with SSL) I would consider "low grade", but may be sufficient for your needs. Just be keenly aware of the implications and do not fall into the trap of a "false sense of security".
If it's limited by IP address, then although they can spoof the IP address, they won't be able to get the reply. Of course, if it's exposed to the internet, it can still get hit by attacks other than against the app.
Just because all your internal IPs match a given regex, that doesn't mean that all IPs that match a given regex are internal. So, your regex is a point of possible security failure.
I don't know what technology you used to build your site, but if it's Windows/ASP.net, you can check the permissions of the requesting machine based on its Windows credentials when the request is made.
Like all security, it's useless on it's own. If you do have to put it on a public-facing webserver, use IP whitelisting, with basic username/password auth, with SSL, with a decent monitoring setup, with an up-to-date server application.
That said, what is the point in having the server be publicly accessible, then restrict it to only internal IP addresses? It seems like it's basically reinventing what NAT gives you for free, and with an internal-only server, plus you have to worry about web-server exploits and the likes.
You don't seem to gain anything by having it externally accessible, and there are many benefits to having having it be internal-only..
My first thought on the ressource issue would be to ask if it wouldn't be possible to work some magic with a virtual machine?
Other than that - if the IP addresses you check up against are either IPs you KNOW belongs to computers that are supposed to access the application or in the local IP range, then I cannot see how it could not be secure enough (I am actually using a similiar approach atm on a project, although it is not incredibly important that the site is kept "hidden").
A proper firewall can protect against IP spoofing, and it's not as easy as say spoofing your caller ID, so the argument /not/ to use IP filtering because of the spoofing danger is a bit antiquated. Security is best applied in layers, so you're not relying on only one mechanism. That's why we have WAF systems, username+password, layer 3 firewalls, layer 7 firewalls, encryption, MFA, SIEM and a host of other security measures, each which adds protection (with increasing cost).
If this is a web application you're talking about (which was not clear from your question), the solution is fairly simple without the cost of advanced security systems. Whether using IIS, Apache, etc. you have the ability to restrict connections to your app to a specific target URL as well as source IP address - no changes to your app necessary - on a per-application basis. Preventing IP-based web browsing of your app, coupled with IP source restrictions, should give you significant protection against casual browsing/attacks. If this is not a web app, you'll have to be more specific so people know whether OS-based security (as has been proposed by others) is your only option or not.
Your security is only as strong as your weakest link. In the grand scheme of things, spoofing an IP is child's play. Use SSL and require client certs.
It became useful first to distinguish among different kinds of IP vpn based on the administrative relationships, not the technology, interconnecting the nodes. Once the relationships were defined, different technologies could be used, depending on requirements such as security and quality of service.
Maybe this will help ? I've been looking for the same answer, and found this stackoverflow as well as this idea from Red Hat Linux Ent. I'll try it soon. I hope it helps.
iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -j DROP
Where 0/24 is the LAN range you want to protect. The idea is to block "internet" facing (Forward) devices from being able to spoof the local IP network.
Ref: http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-firewall-ipt-rule.html
Related
So I'm baffled, no dynamic IP is activated on either the router side or my local desktop side. I have to change my IP in Azure almost twice a day. I'm getting scared as it might be a security issue. I tried to write into a chat and it told me that I'm not allowed to use it, because I'm using a proxy, which I don't, not even VPN, so I'm asking you what I should do or if I should be scared?
(scanned the PC and there were no issues)
IPs are not likely to change like that for residential users, you can double check however by logging into your modem and determining the IP of your WAN. This won't reveal the proxied IPs/etc, but what your ISP sent you.
If that's changing then sure, no issues but odd.
Now if that's fixed and it's still changing, you may have a proxy installed and forgot to turn it off.
I'd not worry personally but you could be subject to MITM man in the middle stuff. Best you can do is sort this and if you deem it to be MITM to just change passwords/etc ezpz.
I never use honeypot before. But, I have a task from my lecture, that I should use a honeypot for detecting hackers attacks.
I searched in journals, tutorials and articles. I tried using honeydrive3 and used the honeypot Kippo. When I tried that, and I attack by myself, it works, the detailed of attack is served. But, when I told that to my lecturer, he said it was not what he wanted.
The workflow he want is, we use the honeypot and then we try that to some websites. But, when the attacker scanning or do something to that web IP address, it must deflect to the honeypot, it means that the attacker really attacks the real website.. and I really don't know what to do.
You either misunderstood what the lecturer wanted, or what he wants does not make sense.
You can only analyze traffic sent to your IP (or an IP you control), it is not possible for you to "deflect the traffic" from a generic IP address.
What you did is correct: putting in place the honeypot, and then sending some traffic to it.
The next step would be to expose it to Internet to get malicious traffic (directed to your IP) but you must be very careful as the whole machine is likely going to get successfully attacked. It must not have any connection to your (home|uni|private) network, because (I am being frank reading your question), you stand no chance to secure it for the time being.
I would go for a cloud hosted machine which I would then kill.
so suppose I detect a user's ip using some code to perform restrictions....
is there a way for a user to circumvent this by arbitrarily setting their ip to any ip they want anytime they want (eg. via proxy server or something) hence allowing them to choose a specific ip to be displayed when I detect it
There are several tunneling and proxy-based techniques that will effectively present a different IP address for any HTTP requests than the one belonging to the originating computer. I have mentioned several methods in this answer, as well as here. In many cases it is actually impossible to tell apart a relayed connection from the real thing...
In general you cannot forge the source of a TCP connection on the Internet to be an arbitrary address for a number of reasons, some of which are:
TCP is a stateful protocol and packets go back and forth even in order to establish the connection. Forging an IP source address means that you cannot get any packets back.
Some ISPs will drop packets generated within their own network that do not have a source IP within the proper subnet. This is usually done at the client connection level to protect the ISP network and prevent random packets from leaking client information to the Internet due to simple misconfiguration issues client-side.
ISP filters will also prevent users from just setting an arbitrary IP - if not for any other reason, then just because ISPs sell connections with static IP addresses at significantly higher prices and having users set their own IPs would spoil that. Not to mention the mess that would result if there could be IP conflicts among the clients of an ISP...
So in general you cannot just spoof the source of a TCP connection. You have to use an intermediate computer to relay the connection.
Keep in mind, however, that motivated and experienced attackers may have at their disposal botnets that consist of millions of compromised computers belonging to innocent users. Each and every one of those computers could theoretically be used as a connection relay, thus allowing a potential attacker quite a wide variety of IP addresses to chose from.
The bottom line is that simple IP-based checks and filters cannot in any form ensure the legitimacy of a connection. You should be using additional methods to protect your service:
HTTPS and proper user accounts.
Extensive logging and monitoring of your service.
Intrusion detection systems and automatic attack responders (be careful with those - make sure you don't lock yourself out!).
We cannot really provide a more concrete answer unless you tell us what service you are providing, what restrictions you want to apply and what kind of attacks you are so worried about...
Sort of - as you mentioned, proxies are a risk, however it makes life a wee bit harder for the attacker so it is still worth using IP bans.
Monitor your logs, automate alerts and if attacks come from another IP - ban it too. If you make life hard enough for an attacker they may give up.
I need to put together a small brief about the weaknesses behind limiting content to specific countries based on IP address.
Besides using proxy server located in another country, can you think of another way to circumvent such a system?
Basically, any solution that uses an intermediary is a proxy. Period.
All the "surf anonymously" sites are proxies, even if they use their own software.
You can use SSH and tunneling, but that is, in effect, a proxy as well, just a tunneled one. Same with VPN.
The only thing that doesn't require a proxy is source address spoofing, and that only works with one-way attacks, because no return data will be able to get to you.
Also, consider that Geo-Locating is not 100% accurate. I have IP addresses in Canada that show up as US addresses, and I've had US addresses that show up as Canada. I'm sure this is more common in other parts of the world.
You could buy that software that prevents you from broadcasting your IP address. I'm sure it works, I see it advertised in banner ads all over the place :)
On a more serious note, one way of bypassing this would be by using a caching server (google cache, wayback machine).
I don't think you can. The machine you're talking to has to know where to send it's reply to; that's your IP address. The only way to hide that is to have it reply to someone that's not you who passes it on to you - ie. a proxy.
Tor is a good way of achieving anonymity in general, although it's not appropriate for circumventing the type of system you're talking about.
Since your IP address is in each IP packet that goes over the network, and it is required for you to get the response back, you cannot prevent your real IP address from being detected at the server (other than by putting a proxy in between).
Some links that may be of interest to you:
Conflict between Sweden and Norway about surveillance (Sweden cannot reliably identify Norway IP traffic and exclude it from surveillance)
Herdict.com (which we built, I am happy to report)
It depends on what level of the IP stack you are checking the IP, but on higher levels, you wouldn't need to even have a proxy server to have a different IP address show up. For example, modifying the TCP header would do it if that is what you are checking against.
Here's a link discussing spoofing: http://www.securityfocus.com/infocus/1674
If the service is using a web based Geo IP lookup, then a successful MITM attack could trick the service into thinking that the IP address is valid. Of course this is much more involved, but definitely doable.
Don't forget VPNs (and, admittedly, NAT). I guess that could be classed as a proxy, too. It also requires having access to a suitable machine in another country.
If I just want to know if a domain name is reserved; is it sufficient to use this command and see if any domain name servers turn up, in which case it's reserved?
host -t NS example.com
It's a lot faster than visiting http://www.internic.net/whois.html and typing example.com to get much more detailed results, which I'm not interested in anyway.
Absolutely not.
A past employer registered theirname.biz solely for use on the internal network: it had DNS entries on the inward-facing network DNS server, but nowhere on the internet.
I'm not sure the trick was particularly essential, but "imap.theirname.biz" has the advantage over just "imap" that it's unambiguous if you're connected simultaneously to multiple networks (in the absence of deliberate foul play, of course), so you can just use all their internal DNS resolvers. Also the advantage over "imap.theirname.com" that once you know the convention, it's immediately obvious that it's a private server, and hence the reason you can't connect to it is that you forgot to connect VPN. There may have been other benefits to which I was not privy: I'm a coder, not an IT tech...
Various TLDs have differing requirements for whether name servers are provisioned or not. For example ".de" does require that name servers are up and running and correctly configured before they'll allow the domain registration to proceed.
The technical standards for DNS don't require it though, in fact there's nothing in the core DNS specifications to link together the registration of a name with its subsequent operation in the DNS.
Therefore, using whois is probably the most reliable method, with the caveat that you'll need a whois client that's clever enough to figure out which server to talk to for the domain in question.
That said, checking for the appropriate NS record is a very good shortcut to check that a domain is registered, you just can't use the absence of such a record to prove that it isn't!
NS records are not necessarily required for registered domains. The whois service is your most reliable option.
Note that most Unix systems and Mac OS X have a "whois" command line program that is really quick to use:
whois stackoverflow.com
I don't believe that you have to have a DNS pointing to your domain. Even if you had to have a DNS set up, there is no assurance that the box acting as the DNS server isn't down.