Title.
I can think in any sort of DoS or someone spamming messages to increased the billing.
Any idea?
Look into google but I cant find anything.
Yes it is, at least if it includes the keys. Spamming messages to increase the bill would be the least of my worries. Say someone reads all the incoming messages, could be a potential security issue. Or consider someone sending rogue messages, causing all kinds of trouble. Good luck finding out that bug.
Also, exposing any information regarding the azure infrastructure in use to parties not needing to know would be a no-go for me personally.
Related
I have a hapijs application and checking some logs I have found some entries for automated site scanners and hits to entries to /admin.php and similar.
I found this great article How to Block Automated Scanners from Scanning your Site and I thought it was great.
I am looking for guidance on what the best strategy would be to create honey pots for a hapijs / nodejs app to identify suspicious requests, log them, and possibly ban the IPs temporarily.
Do you have any general or specific (to node and hapi) recommendations on how to implement this?
My thoughts include:
Create the honeypot route with a non-obvious name
Add a robots.txt to disallow search engines on that route
Create the content of the route (see the article and discussions for some of the recommendations)
Write to a special log or tag the log entries for easy tracking and later analysis
Possibly create some logic that if traffic from this IP address receives more traffic than certain threshold (5 times of honeypot route access will ban the IP for X hours or permanently)
A few questions I have:
How can you ban an IP address using hapi.js?
Are there any other recommendations to identify automated scanners?
Do you have specific suggestions for implementing a honeypot?
Thanks!
Let me start with saying that this Idea sounds really cool but I'm not if it is much practical.
First the chances of blocking legit bots/users is small but still exisits.
Even if you ignore true mistakes the option for abuse and denial of service is quite big. Once I know your blocking users who enter this route I can try cause legit users touch it (with an iframe / img / redirect) and cause them to be banned from the site.
Than it's effectiveness is small. sure your going to stop all automated bots that scan your sites (I'm sure the first thing they do is check the Disallow info and this is the first thing you do in a pentest). But only unsophisticated attacks are going to be blocked cause anyone actively targeting you will blacklist the endpoint and get a different IP.
So I'm not saying you shouldn't do it but I am saying you should think to see if the pros outwaite the cons here.
How to actually get it done is actually quite simple. And it seem like your looking for a very unique case of rate limiting I wouldn't do it directly in your hapi app since you want the ban to be shared between instances and you probably want them to be persistent across restarts (You can do it from your app but it's too much logic for something that is already solved).
The article you mentioned actually suggests using fail2ban which is a great solution for rate limiting. you'll need to make sure your app logs to afile it can read and write a filter and jail conf specifically for your app but it should work with hapi with no issues.
Specifically for hapi I maintain an npm module for rate limiting called ralphi it has a hapi plugin but unless you need a proper rate limiting (which you should have for logins, sessions and other tokens) fail2ban might be a better option in this case.
In general Honey pots are not hard to implement but as with any secuiry related solution you should consider who is your potential attacker and what are you trying to protect.
Also in general Honey pots are mostly used to notify about an existing breach or an imminent breach. Though they can be used to also trigger a lockdown your main take from them is to get visibility once a breach happend but before the attacker had to much time to abuse the system (You don't want to discover the breach two months later when your site has been defaced and all valuable data was already taken)
A few ideas for honey pots can be -
Have an 'admin' user with relatively average password (random 8 chars) but no privileges at all when this user successfully loges in notify the real admin.
Notice that your not locking the attacker on first attempt to login even if you know he is doing something wrong (he will get a different ip and use another account). But if he actually managed to loggin, maybe there's an error in your login logic ? maybe password reset is broken ? maybe rate limiting isn't working ? So much more info to follow through.
now that you know you have a semi competent attacker maybe try and see what is he trying to do, maybe you'll know who he is or what his end goal is (Highly valuable since he probably going to try again).
Find sensitive places you don't want users to play with and plant some canary tokens in. This can be just a file that sites with all your other uploads on the system, It can be an AWS creds on your dev machine, it can be a link that goes from your admin panel that says "technical documentation" the idea is that regular users should not care or have any access to this files but attackers will find them too tempting to ignore. the moment they touch one you know this area has been compromised and you need to start blocking and investigating
Just remember before implementing any security in try to think who you expect is going to attack you honey pots are probably one of the last security mesaures you should consider and there are a lot more common and basic security issues that need to be addressed first (There are endless amount of lists about node.js security best practices and OWASP Top 10 defacto standard for general web apps security)
If I were to say, upload the sample application written in Python, would Google protect me from malicious bots trying to eat up my resources? DoS attacks?
Exactly how much security can I expect from Google?
background:
I've read this article and it looks like you have the option to manually request certain blocks of IP addresses to be blocked. I am not very knowledgeable when it comes to security, but I would have imagined that Google would automatically blacklist suspicious IPs. But then I realized I really didn't know what kind of protection Google did provide, if any, so I thought it might be best to ask.
They will not protect you. You have to manually block the IP's and even that requires a redeploy of code (there's no UI for it).
I'm speaking about this from the experience of a surprise $1000 / week bill on a normally $5 / day app. I had upped the limit to do a major import of data consuming a ton of resources and then not set it back down again. Big mistake. They did give me system credits for less than a third of it, not sure if that was due to this being the day after the billing change (pre-billing change it wouldn't have cost more than the $5 / day) or if it's general policy after a DoS attack.
Even if you have the bill set to be low, they will just stop serving your resources as soon as your bill is eaten up and no warning email will be sent requiring you to use a third-party monitoring service or watch your site 24/7, making the DoSers job much easier.
Bottom line: tread carefully.
Okay, so we have to store our clients` private medical records online and also the web site will have a lot of requests, so we have to use some scaling solutions.
We can have our own share of a datacenter and run something like Zend Server Cluster Manager on it, but services like Amazon EC2 look a lot easier to manage, and they are incredibly cheaper too. We just don't know if they are secure enough!
Are they?
Any better solutions?
More info: I know that there is a reference server and it's highly secured and without it, even the decrypted data on the cloud server would be useless. It would be a bunch of meaningless numbers that aren't even linked to each other.
Making the question more clear: Are there any secure storage and process service providers that guarantee there won't be leaks from their side?
First off, you should contact AWS and explain what you're trying to build and the kind of data you deal with. As far as I remember, they have regulations in place to accommodate most if not all the privacy concerns.
E.g., in Germany such thing is a called a "Auftragsdatenvereinbarung". I have no idea how this relates and translates to other countries. AWS offers this.
But no matter if you go with AWS or another cloud computing service, the issue stays the same. And therefor, whatever is possible is probably best answered by a lawyer and based on the hopefully well educated (and expensive) recommendation, I'd go cloud shopping, or maybe not. If you're in the EU, there are a ton of regulations especially in regards to medical records -- some countries add more to it.
From what I remember it's basically required to have end to end encryption when you deal with these things.
Last but not least security also depends on the setup and the application, etc..
For complete and full security, I'd recommend a system that is not connected to the Internet. All others can fail.
You should never outsource highly sensitive data. Your company and only your company should have access to it - in both software and hardware terms. Even if your hoster is generally trusted someone there might just steal hardware.
Depending on the size of your company you should have your custom servers - preferable even unaccessible for the technicans in your datacenter (supposing you don't own the datacenter ;).
So the more important the data is, the less foreign people should have access to it in any means. In the best case you can name all people that have access to them in any way.
(Update: This might not apply to anonymous data, but as you're speaking of customers I don't think that applies here?)
(On a third thought: There're are probably laws to take into consideration of how you have to handle that kind of information ;)
Recently Aetna suffered a breach where it lost 65,000 SSNs. They never were able to find an audit trail of what happened which probably hints that the attack leveraged XSS or similar technique.
Are there specific known attacks that the bad guys are repeatedly leveraging for this type of attack?
There are common mistakes that people make and there are common platforms that people use. Each, if left unpatched would allow somebody to break in using a simple script.
But if somebody was going after something specifically, in this case social security numbers, that have high value in organised crime rings, I would have expected somebody to spend a little more time figuring out how the site worked and applying a custom exploit to grab the data.
I don't see why it has to be XSS either. If their systems weren't sending access logs off-server, or even logging every entry point, there are a variety of methods somebody could exploit an exploitable server and clean up afterwards.
It's not at all clear at this point that this was a technical failure, and given the inconclusive forensics it seems much more likely to me that this was a human failure, be it social engineeering, data left on a train seat, or a disgruntled employee.
AFAIK the only way to truly leave zero audit trail is for the auditing to have not been written. Logging HTTP traffic alone will always give you some evidence of an HTTP based attack.
I've seen the results of some automated attacks, and one of the first things they do is disable logging, and delete all logs.
That's why it's common to change logging locations to a non-standard path - it won't do anything against a determined attacker, but it will give you more information in the case of an automated attack.
The lack of an audit trail is not surprising to say the least. Not many companies out there keep meaningful audit trails. Sure, there's often gigabyte and gigabytes of logs, but who goes through all of that? Most IT places would just dump it once it ages enough, so its entirely possible that this breach happened a while ago and they've already dumped the logs since from the article it looks like they did not know about the possible breach until the spam mail started coming in.
I'd suspect poor IT instead of some clever attack that caused the lack of an audit trail.
I'm dealing with a client who is "concerned about security" and they're demanding all files containing ports and IP addresses (config information essentially) must be encrypted.
My view is that IP addresses and ports are essentially public. The file may give away the nature of the server but this sort of "partial secrecy" to me doesn't really add anything to security other than a false sense of security.
Should this sort of information be stored encrypted?
Edit: One small issue is that it's a mobile device so adding encryption is actually a fairly significant overhead as it's a fairly arduous task for the processor and will cause a performance hit.
There is never any harm in keeping as much information private as is possible. The less you give a potential hacker the harder their job will be.
However, the biggest thing to note is as you say, a "false sense of security". As long as the words "noone will hack us they don't know our ip address" are never uttered then that's fine. As soon as you think that this one level of obscurity is enough to keep you safe then you have a problem.
There is no harm in ecrypting the file. If the client is happy then do it. I hope it wont be a much of a problem when it comes to development.
But what I would do is also educate the client that "encrypting the ip" DOES not mean that everythign is safe. You can explain about the restricting access through firewall (if possible) is more secure than encrypting.
More over I don't think this is a common practise to encrypt. So you beter document is properly about how you do it and why you do it ;-) so that future programmers know why it has been done.
My view is that if the customer's asking for it, you may as well do it.
I really don't see a point to it though, as access to configuration files means the system is already heavily compromised.
I think most OS-es have standard support to request all open network connections. (netstat, under Windows XP, Linux.)
So, if the application is actually using the IP addresses to connect with the systems, then encrypting is clearly not enough.
However, if the application can only be started with a password then I could imagine a use for encryption, making it a bit more difficult to see the information when the application is not running.
Well, an IP address could be considered personally identifiable information depending on who you ask. If you client wants it, you might as well do it.
Depending on why you don't want to encrypt it, you might consider obfuscation as another simple alternative. As long as these are sufficiently randomized, I would assume your client should be happy.
Your question is subjective. But yes, you should encrypt your config data, it makes sense.
As for that being confidential, it really depends on why? Your best to do what the Client asks.
I agree with Robin, obscurity is not security, if someone were to find out your IP, which is possible, and they port scan you, it may become apparent what attack vector they can use.
The way I look at it is, an IP address isn't in itself privileged, but it's useful information for an intruder to have. Why make it easy for him to get it? Encrypting the data may simply annoy him and slow him down while he gets that information through other means, but the longer the intrusion takes the more costly it is for him and the greater the risk that he'll be caught and stopped.
Locking my wooden front door won't stop a determined burglar, but it'll slow him down and make him attract the attention of the neighbors if he tries to break in. Compared to the cost of installing the door, that's worth it!
Well with a simple portscan the attacker will have the information anyhow. As some other guys allready wrote it will provide a false sense of security.
The answer is without doubt YES. It's not a real programming answer; this is the opinion of a number of official privacy watchdogs in Europe. IP addresses are considered to be similar enough to physical addresses; they might not 100% reliable identify a single personal but they are still personal data. As such, they come under the relevant legislation (Safe Harbour provisions etc). Your client has every right to take the European market into account, so this request makes perfect sense from a business/legal perspective.
The better question is in fact whether they should ever be stored non-encrypted. If you as a programmer are building a system where you are storing IP addresses from outside your company, you'd better check with the legal dept. which laws would apply to your company.