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)
I was at a meeting recently for our startup. For half an hour, I was listening to one of the key people on the team talk about timelines, the market, confidentiality, being there first and so on. But I couldn't help ask myself the question: all that talk about confidentiality is nice, but there isn't much talk about physical security. This thing we're working on is web-hosted. What if after uploading it to the webhost, someone walks into the server room (don't even know where that is) and grabs a copy of the code and the database. The database is encrypted, but with access to the machine, you'd have the key.
What do the big boys do to guard the code from being stolen off? Is it common for startups to host it themselves in some private data center or what? Does anyone have facts about what known startups have done, like digg, etc.? Anyone has firsthand experience on this issue?
Very few people are interested in seeing your source code. The sysadmins working at your host are most likely in this group. It's probably not the case that they can copy your code, paste it on another host and be up and running, stealing your customers in 42 minutes.
People might be interested in seeing the contents of your DB if you're storing things like user contact information (or even more extreme, financial information). How do you protect against this? Do the easy, host independent things (like storing passwords as hashes, offloading financial data to financial service providers, HTTPS/SSL, etc.) and make sure you use a host with a good reputation. Places like Amazon (with AWS) and RackSpace would fail quickly if it got out that they regularly let employees walk off with customer (your) data.
How do the big boys do it? They have their own infrastructure (places like Google, Yahoo, etc.) or they use one of the major players (Amazon AWS, Rackspace, etc.).
How do other startups do it? I remember hearing that Stack Overflow hosts their own infrastructure (details, anyone?). This old piece on Digg indicates that they run themselves too. These two instances do not mean that all (or even most) startups have an internal infrastructure.
Most big players in the hosting biz have a solid security policy on their servers. Some very advanced technology goes into securing most high end data centers.
Check out the security at the host that I use
http://www.liquidweb.com/datacenter/
What if after uploading it to the webhost, someone walks into the server room (don't even know where that is) and grabs a copy of the code and the database. The database is encrypted, but with access to the machine, you'd have the key.
Then you're screwed :-) Even colo or rented servers should be under an authorized-access only policy, that is physically enforced at the site. Of course that doesn't prevent anyone from obtaining the "super secret" code otherwise. For that, hire expensive lawyers and get insurance.
By sharing user accounts on the same system you have more to worry about. It can be done without ever having a problem, but you are less secure than if you controlled the entire system.
Make sure you code is chmod 500, or even chmod 700, as long as the last 2 are zeros then your better off. If you do a chmod 777, then everyone on the system will be able to access your files.
However there are still problems. A vulnerability in the Linux kernel would give the attacker access to all accounts. A vulnerability in MySQL would give the attacker access to all databases. By having your own system, then you don't have to worry about these attacks.
I'm thinking of using Google Docs as a content management system, and to integrate it with my java/j2ee web application.
I only need to upload, view, search meta-data, and organize docs.
Would anybody have a reason to believe I should not try this?
One good reason not to do that is that then you have no control over your system's uptime. Google does occasionally have outages, which would take your system down as well.
In addition, by storing them on Google's servers, you are giving up any control over privacy. There is nothing you can do to ensure Google's security of both their live systems and their backup systems will never be broken, and if they get broken in to, your documents' privacy is lost. In addition, you'll need to keep an eye on Google's terms of use. They may very well update it to read "We reserve the right to sell your documents to whomever we please." which may include your competitors.
That being said, if downtime won't break you, and privacy isn't a huge concern, it doesn't sound like a bad idea. Just make sure they're not the ONLY place you're storing your documents.
We've currently got four web servers in a farm generating IIS web logs about 100Mb per day. These can be compressed pretty effieciently down to somewhere around 5% of their size.
We are planning to use waRmZip to move them off the servers and onto a SAN. After a week or so we can be confident we don't have any technical issues to investigate so the only other thing would be using them for trend analysis as a compliment to Google Analytics.
What retention periods do people recommend? Are there any legal requirements to keep this data?
Legal requirements will depend on your country, how much you're logging, and quite possibly the nature of your business. Talk to your company's lawyers - legal advice on SO is likely to be worth what you pay for it.
If you're only storing 5MB per day, you should be able to store them for basically as long as you want without worrying on the technical front.
Please consider the sensitivity of your web log data as well. I have no idea whether access to your web apps would be considered sensitive if made public, but you need to realize that your web logs contain the necessary information to potentially identify individuals (esp. in conjunction with other information available elsewhere). Your privacy policies should reflect how long you retain these logs and what purposes to which they will be put. Google, I think, recently decided to anonymize their logs after 9 months to help protect user privacy. Granted, their situation is a little different since they collect so much information, but you need to consider your customer's needs as well as your own when determining how long and in what form to keep your logs.
I tend to keep mine forever. That's mainly for trend analysis because Google misses some visitors (non-JavaScript ones).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
This question talks about different payment processors and what they cost, but I'm looking for the answer to what do I need to do if I want to accept credit card payments?
Assume I need to store credit card numbers for customers, so that the obvious solution of relying on the credit card processor to do the heavy lifting is not available.
PCI Data Security, which is apparently the standard for storing credit card info, has a bunch of general requirements, but how does one implement them?
And what about the vendors, like Visa, who have their own best practices?
Do I need to have keyfob access to the machine? What about physically protecting it from hackers in the building? Or even what if someone got their hands on the backup files with the sql server data files on it?
What about backups? Are there other physical copies of that data around?
Tip: If you get a merchant account, you should negotiate that they charge you "interchange-plus" instead of tiered pricing. With tiered pricing, they will charge you different rates based on what type of Visa/MC is used -- ie. they charge you more for cards with big rewards attached to them. Interchange plus billing means you only pay the processor what Visa/MC charges them, plus a flat fee. (Amex and Discover charge their own rates directly to merchants, so this doesn't apply to those cards. You'll find Amex rates to be in the 3% range and Discover could be as low as 1%. Visa/MC is in the 2% range). This service is supposed to do the negotiation for you (I haven't used it, this is not an ad, and I'm not affiliated with the website, but this service is greatly needed.)
This blog post gives a complete rundown of handling credit cards (specifically for the UK).
Perhaps I phrased the question wrong, but I'm looking for tips like these:
Use SecurID or eToken to add an additional password layer to the physical box.
Make sure the box is in a room with a physical lock or keycode combination.
I went through this process not to long ago with a company I worked for and I plan on going through it again soon with my own business. If you have some network technical knowledge, it really isn't that bad. Otherwise you will be better off using Paypal or another type of service.
The process starts by getting a merchant account setup and tied to your bank account. You may want to check with your bank, because a lot of major banks provide merchant services. You may be able to get deals, because you are already a customer of theirs, but if not, then you can shop around. If you plan on accepting Discover or American Express, those will be separate, because they provide the merchant services for their cards, no getting around this. There are other special cases also. This is an application process, be prepared.
Next you will want to purchase an SSL certificate that you can use for securing your communications for when the credit card info is transmitted over public networks. There are plenty of vendors, but my rule of thumb is to pick one that is a brand name in a way. The better they are known, the better your customer has probably heard of them.
Next you will want to find a payment gateway to use with your site. Although this can be optional depending on how big you are, but majority of the time it won't be. You will need one. The payment gateway vendors provide a way to talk to the Internet Gateway API that you will communicate with. Most vendors provide HTTP or TCP/IP communication with their API. They will process the credit card information on your behalf. Two vendors are Authorize.Net and PayFlow Pro. The link I provide below has some more information on other vendors.
Now what? For starters there are guidelines on what your application has to adhere to for transmitting the transactions. During the process of getting everything setup, someone will look at your site or application and make sure you are adhering to the guidelines, like using SSL and that you have terms of use and policy documentation on what the information the user is giving you is used for. Don't steal this from another site. Come up with your own, hire a lawyer if you need to. Most of these things fall under the PCI Data Security link Michael provided in his question.
If you plan on storing the credit card numbers, then you better be prepared to put some security measures in place internally to protect the info. Make sure the server the information is stored on is only accessible to members who need to have access. Like any good security, you do things in layers. The more layers you put in place the better. If you want you can use key fob type security, like SecureID or eToken to protect the room the server is in. If you can't afford the key fob route, then use the two key method. Allow a person who has access to the room to sign out a key, which goes along with a key they already carry. They will need both keys to access the room. Next you protect the communication to the server with policies. My policy is that the only thing communicating to it over the network is the application and that information is encrypted. The server should not be accessible in any other form. For backups, I use truecrypt to encrypt the volumes the backups will be saved to. Anytime the data is removed or stored somewhere else, then again you use truecrypt to encrypt the volume the data is on. Basically where ever the data is, it needs to be encrypted. Make sure all processes for getting at the data carries auditing trails. use logs for access to the server room, use cameras if you can, etc... Another measure is to encrypt the credit card information in the database. This makes sure that the data can only be viewed in your application where you can enforce who sees the information.
I use pfsense for my firewall. I run it off a compact flash card and have two servers setup. One is for fail over for redundancy.
I found this blog post by Rick Strahl which helped tremendously to understand doing e-commerce and what it takes to accept credit cards through a web application.
Well, this turned out to be a long answer. I hope these tips help.
Ask yourself the following question: why do you want to store credit card numbers in the first place? Chances are that you don't. In fact, if you do store them and manage to have one stolen, you could be looking at some serious liability.
I've written an app that does store credit card numbers (since the transactions were processed offline). Here's a good way to do it:
Get an SSL certificate!
Create a form to get CC# from the user.
Encrypt part (not all!) of the CC# and store it in your database. (I'd suggest the middle 8 digits.) Use a strong encryption method and a secret key.
Mail the remainder of the CC# to whoever processes your transactions (probably yourself) with the ID of the person to process.
When you log in later, you will type in the ID and the mailed-out portion of the CC#. Your system can decrypt the other portion and recombine to get the full number so you can process the transaction.
Finally, delete the online record. My paranoid solution was to overwrite the record with random data before deletion, to remove the possibility of an undelete.
This sounds like a lot of work, but by never recording a complete CC# anywhere, you make it extremely hard for a hacker to find anything of value on your webserver. Trust me, it's worth the peace of mind.
The PCI 1.2 document just came out. It gives a process for how to implement PCI compliance along with the requirements. You can find the full doc here:
https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
Long story short, create a separate network segment for whichever servers will be dedicated to storing CC info (usually DB server(s)). Isolate the data as much as possible, and ensure only the minimum access necessary to access the data is present. Encrypt it when you store it. Never store PAN's. Purge old data and rotate your encryption keys.
Example Don'ts :
Don't let the same account that can lookup general info in the database look up CC info.
Don't keep your CC database on the same physical server as your web server.
Don't allow external (Internet) traffic into your CC database network segment.
Example Dos:
Use a separate Database account to query CC info.
Disallow all but required traffic to CC database server via firewall/access-lists
Restrict access to CC server to a limited set of authorized users.
I'd like to add a non-technical comment that you may wish to think about
Several of my clients run e-commerce sites, including a couple who have moderately large stores. Both of those, whilst they certainly could implement a payment gateway choose not too, they take the cc number, store it temporarily encrypted online and process it manually.
They do this because of the high incidence of fraud and manual processing allows them to take additional checks before filling an order. I'm told that they reject a little over 20% of all their transactions - processing manually certainly takes extra time and in one case they have an employee who does nothing but process transactions, but the cost of paying his salary is apparently less than their exposure if they just passed cc numbers though an online gateway.
Both of these clients are delivering physical goods with resale value, so are particularly exposed and for items like software where a fraudulent sale wouldn't result in any actual loss your mileage would vary, but it's worth considering above the technical aspects of an online gateway if implementing such is really what you want.
EDIT: And since creating this answer I'd like to add a cautionary tale and say that the time is past when this was a good idea.
Why? Because I know of another contact who was taking a similar approach. The card details were stored encrypted, the website was accessed by SSL, and the numbers were deleted immediately after processing. Secure you think?
No - one machine on their network got infected by a key logging Trojan. As a result they were identified as being the source for several score credit card forgeries - and were consequently hit by a large fine.
As a result of this I now never advise anyone to handle credit cards themselves. Payment gateways have since become much more competitive and cost effective, and fraud measures have improved. The risk is now no longer worth it.
I could delete this answer, but I think best to leave up edited as a cautionary tale.
Keep in mind that using SSL to send a card number from a browser to a server is like covering your credit card number with your thumb when you hand your card to a cashier in a restaurant: your thumb (SSL) prevents other customers in the restaurant (the Net) from seeing the card, but once the card is in the hands of the cashier (a web server) the card is no longer protected by the SSL exchange, and the cashier could be doing anything with that card. Access to a saved card number can only be stopped by the security on the web server. Ie, most card thefts on the net aren't done during transmission, they're done by breaking through poor server security and stealing databases.
Why bother with PCI compliance?? At best you'll shave a fraction of a percent off your processing fees. This is one of those cases where you gotta be sure this is what you want to be doing with your time both upfront in development and over time in keeping up with the latest requirements.
In our case, it made the most sense to use a subscription-savy gateway and pair that with a merchant account. The subscription-savy gateway allows you to skip all the PCI compliance and do nothing more than process the transaction proper.
We use TrustCommerce as our gateway and are happy with their service/pricing. They have code for a bunch of languages that makes integration pretty easy.
Be sure to get a handle on the extra work and budget required for PCI. PCI may require huge external audit fees and internal effort/support. Also be aware of the fines/penalties that can be unilaterally levied on you, often hugely disproportionate to the scale of the 'ofense'.
There's a lot to the whole process. The single easiest way to do it is to use services similar to paypal, so that you never actually handle any credit card data. Apart from that, there's a quite a bit of stuff to go through to get approved to offer credit card services on your website. You should probably talk with your bank, and the people who issue your merchant ID to help you in setting up the process.
As others have mentioned the easiest way into this area is with the use of Paypal, Google checkout or Nochex. However if you intend to to a significant amount of business you may wish to look up "upgrading" to higher level site integrations services such as WorldPay, NetBanx (UK) or Neteller (US). All of these services are reasonably easy to set up. And I know that Netbanx offers convenient integration into some of the off the shelf shopping cart solutions such as Intershop (because I wrote some of them). Beyond that you are looking at direct integration with the banking systems (and their APAX systems) but thats hard and at that point you also need to prove to the Credit card companies that you are handling the credit card numbers securely (probably not worth considering if you are not taking $100k's worth per month).
Working from 1st to last the cost/benefits are that the early options are much easier (quicker/cheaper) to set up put you pay quite high handling charges for each transaction. the later ones are much more costly to set up but you pay less in the long run.
The other advantage of the most of the non dedicated solutions is that you don't need to keep encrypted credit card numbers secure. Thats someone else's problem :-)