Tag Archives: lua

COPPA Compliance

2018-04-13 Bruce Schneier

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2018/04/coppa_complianc.html

Interesting research: “‘Won’t Somebody Think of the Children?’ Examining COPPA Compliance at Scale“:

Abstract: We present a scalable dynamic analysis framework that allows for the automatic evaluation of the privacy behaviors of Android apps. We use our system to analyze mobile apps’ compliance with the Children’s Online Privacy Protection Act (COPPA), one of the few stringent privacy laws in the U.S. Based on our automated analysis of 5,855 of the most popular free children’s apps, we found that a majority are potentially in violation of COPPA, mainly due to their use of third-party SDKs. While many of these SDKs offer configuration options to respect COPPA by disabling tracking and behavioral advertising, our data suggest that a majority of apps either do not make use of these options or incorrectly propagate them across mediation SDKs. Worse, we observed that 19% of children’s apps collect identifiers or other personally identifiable information (PII) via SDKs whose terms of service outright prohibit their use in child-directed apps. Finally, we show that efforts by Google to limit tracking through the use of a resettable advertising ID have had little success: of the 3,454 apps that share the resettable ID with advertisers, 66% transmit other, non-resettable, persistent identifiers as well, negating any intended privacy-preserving properties of the advertising ID.

Piracy Falls 6%, in Spain, But It’s Still a Multi-Billion Euro Problem

2018-04-09 Andy

Post Syndicated from Andy original https://torrentfreak.com/piracy-falls-6-in-spain-but-its-still-a-multi-billion-euro-problem-180409/

The Coalition of Creators and Content Industries, which represents Spain’s leading entertainment industry companies, is keeping a close eye on the local piracy landscape.

The outfit has just published its latest Piracy Observatory and Digital Content Consumption Habits report, carried out by the independent consultant GFK, and there is good news to report on headline piracy figures.

During 2017, the report estimates that people accessed unlicensed digital content just over four billion times, which equates to almost 21.9 billion euros in lost revenues. While this is a significant number, it’s a decrease of 6% compared to 2016 and an accumulated decrease of 9% compared to 2015, the coalition reports.

Overall, movies are most popular with pirates, with 34% helping themselves to content without paying.

“The volume of films accessed illegally during 2017 was 726 million, with a market value of 5.7 billion euros, compared to 6.9 billion in 2016. 35% of accesses happened while the film was still on screens in cinema theaters, while this percentage was 33% in 2016,” the report notes.

TV shows are in a close second position with 30% of users gobbling up 945 million episodes illegally during 2017. A surprisingly high 24% of users went for eBooks, with music relegated to fourth place with ‘just’ 22%, followed by videogames (11%) and football (10%).

The reasons given by pirates for their habits are both varied and familiar. 51% said that original content is too expensive while 43% said that taking the illegal route “is fast and easy”. Half of the pirates said that simply paying for an internet connection was justification for getting content for free.

A quarter of all pirates believe that they aren’t doing anyone any harm, with the same number saying they get content without paying because there are no consequences for doing so. But it isn’t just pirates themselves in the firing line.

Perhaps unsurprisingly given the current climate, the report heavily criticizes search engines for facilitating access to infringing content.

“With 75%, search engines are the main method of accessing illegal content and Google is used for nine out of ten accesses to pirate content,” the report reads.

“Regarding social networks, Facebook is the most used method of access (83%), followed by Twitter (42%) and Instagram (34%). Therefore it is most valuable that Facebook has reached agreements with different industries to become a legal source and to regulate access to content.”

Once on pirate sites, some consumers reported difficulties in determining whether they’re legal or not. Around 15% said that they had “big difficulties” telling whether a site is authorized with 44% saying they had problems “sometimes”.

That being said, given the amount of advertising on pirate sites, it’s no surprise that most knew a pirate site when they visited one and, according to the report, advertising placement is only on the up.

Just over a quarter of advertising appearing on pirate sites features well-known brands, although this is a reduction from more than 37% in 2016. This needs to be further improved, the coalition says, via collaboration between all parties involved in the industry.

A curious claim from the report is that 81% of pirate site users said they were required to register in order to use a platform. This resulted in “transferring personal data” to pirate site operators who gather it in databases that are used for profitable “e-marketing campaigns”.

“Pirate sites also get much more valuable data than one could imagine which allow them to get important economic benefits, as for example, Internet surfing habits, other websites visited by consumers, preferences, likes, and purchase habits,” the report states.

So what can be done to reduce consumer reliance on pirate sites? The report finds that consumers are largely in line with how the entertainment industries believe piracy should or could be tackled.

“The most efficient measures against piracy would be, according to the internet users’ own view, blocking access to the website offering content (78%) and penalizing internet providers (73%),” the report reads.

“Following these two, the best measure to reduce infringements would be, according to consumers, to promote social awareness campaigns against piracy (61%). This suggests that increased collaboration between the content sector and the ISPs (Internet Service Providers) could count on consumers’ support and positive assessment.”

Finally, consumers in Spain are familiar with the legal options, should they wish to take that route in future. Netflix awareness in the country is at 91%, Spotify at 81%, with Movistar+ and HBO at 80% and 68% respectively.

“This invalidates the reasons given by pirate users who said they did so because of the lack of an accessible legal offer at affordable prices,” the report adds.

However, those who take the plunge into the legal world don’t always kick the pirate habit, with the paper stating that users of pirates sites tend to carry on pirating, although they do pirate less in some sectors, notably music. The study also departs from findings in other regions that pirates can also be avid consumers of legitimate content.

Several reports, from the UK, Sweden, Australia, and even from Hollywood, have clearly indicated that pirates are the entertainment industries’ best customers.

In Spain, however, the situation appears to be much more pessimistic, with only 8% of people who access illegal digital content paying for legal content too. That seems low given that Netflix alone had more than a million Spanish subscribers at the end of 2017 and six million Spanish households currently subscribe to other pay TV services.

The report is available here (Spanish, pdf)

Source: TF, for the latest info on copyright, file-sharing, torrent sites and more. We also have VPN reviews, discounts, offers and coupons.

How to Use Service Control Policies in AWS Organizations

2018-04-02 Frank Phillis

Post Syndicated from Frank Phillis original https://aws.amazon.com/blogs/security/how-to-use-service-control-policies-in-aws-organizations/

With AWS Organizations, you can centrally manage policies across multiple AWS accounts without having to use custom scripts and manual processes. For example, you can apply service control policies (SCPs) across multiple AWS accounts that are members of an organization. SCPs allow you to define which AWS service APIs can and cannot be executed by AWS Identity and Access Management (IAM) entities (such as IAM users and roles) in your organization’s member AWS accounts. SCPs are created and applied from the master account, which is the AWS account that you used when you created your organization.

In a previous post, How to Use Service Control Policies in AWS Organizations to Enforce Healthcare Compliance in Your AWS Account, we reviewed how to create and manage SCPs and Organizational Units (OU) within an organization. In this post, I show how to use SCPs for access control in Organizations, with a specific focus on evaluating SCPs when an IAM entity calls an API in a member AWS account. I first cover some key Organizations concepts, and then I show how an SCP attached to an organization impacts which AWS service APIs are available to member accounts. Finally, I demonstrate these concepts with an example.

Organizational structure in Organizations

OUs give you a way to logically group and structure member AWS accounts in your organization. The screenshot shows the tree view of an example organizational structure in my organization with several OUs. Currently, I have selected OrgUnit01, and this is the current view I see in my main window. You can see here that within the OrgUnit01 OU, I have nested two additional OUs (OrgUnit01ChildA and OrgUnit01ChildB) and an AWS account is also contained within OrgUnit01, named “Developer Sandbox Account”.

The parts of the example organizational structure in the screenshot are:

Tree view — The hierarchy of your organization’s root and any OUs you have created
Tree view toggle — Enable and disable tree view
Organizational Units — Any child OUs of the selected root or OU in tree view
Accounts — Any AWS accounts (members or master) in the current OU

In the next section, I explain why at least one SCP must be attached to your root and OUs and introduce SCP evaluation.

How Service Control Policy evaluation logic works

To allow an AWS service API at the member account level, you must allow the API at every level between the member account and the root of your organization. This means you must attach an SCP at every level between your organization’s root and the member account that allows the given AWS service API (such as ec2:RunInstances). For more information, see About Service Control Policies.

Let’s say you want to allow the ec2:RunInstances API in the Developer Sandbox Account in the example structure in the preceding screenshot. To allow this AWS service API, you must allow the API in at least one SCP attached at each of these levels:

The organization’s root
The OU named OrgUnit01

If you don’t allow the AWS service in an SCP attached at each of these two levels, neither IAM entities nor the root user in the Developer Sandbox Account will be able to call ec2:RunInstances, even if an administrator has given them permission to do so (for IAM entities). In terms of policy evaluation, SCPs follow exactly the same policy evaluation logic as IAM does: by default, all requests are denied, an explicit allow overrides this default, and an explicit deny overrides any explicit allows.

What does this look like in practice? In the next section, I share a practical example to demonstrate how this works in Organizations.

An example structure with nested OUs and SCPs

In the previous section, I introduced design aspects of AWS Organizations that help prevent administrators from breaking structures in their Organizations. But because AWS Organizations is flexible enough to address multiple use cases, administrators can make changes that have unintended consequences, such as breaking organizational structures when moving an AWS account from one OU to another. In this section, I show an example with broken OU and SCP structures and explain how you can fix them.

I’ll take a blacklisting approach. That is, I’ll use the FullAWSAccess SCP, which doesn’t filter out any AWS service APIs. Then, I will filter out specific APIs by blacklisting them in subsequent SCPs attached to OUs at various points in my organization’s structure. For further reading on blacklisting and whitelisting with AWS Organizations, review AWS Organizations Terminology and Concepts.

Let’s say I have developed the OU and SCP structure shown in the diagram below. Before taking a close look at that diagram, I’ll briefly outline the goals I’m trying to achieve. Broadly speaking, there’s a small subset of APIs that I want to filter out using SCPs. This means that IAM entities in some AWS accounts in my organization will not have access to particular AWS service APIs, such as those related to Amazon EC2, while other accounts will not have access to APIs associated with Amazon CloudWatch, Amazon S3, and so on. Apart from these special cases, I do want the accounts in my organization to have access to all other APIs. More specifically, my goals are as follows:

Any AWS accounts in the Root should not have any API filtered out.
Any AWS accounts in OU 001 should have APIs for CloudWatch filtered out, but all other APIs will be accessible.
Any AWS accounts in OU 002 should have APIs for both CloudWatch and EC2 filtered out, but all other APIs will be accessible.
Any AWS accounts in OU 003 should have APIs for S3 filtered out, but all other APIs will be accessible.

To that end, let’s now look at my initial SCP and OU configuration in the image below that shows the example OU and SCP structure. The arrow shows the direction of inheritance: the root and the OUs below it (children) inherit SCPs from the OUs above them (parents). This example structure contains the following SCPs:

FullAWSAccess — Allows all AWS service APIs
Deny_CW — Denies all CloudWatch APIs
Deny_EC2 — Denies all Amazon EC2 APIs
Deny_S3 — Denies all Amazon S3 APIs

Now that I’ve outlined my intent, and shown you the OU / SCP structure that I’ve created to meet that set of goals, you can probably already see that the structure provided in the image above will not work correctly for my stated goals. In fact, AWS accounts in the Root container and OU 001 will have the intended access, as per my goals (1) and (2). I will not, however, meet my goals (3) and (4) with the above structure: entities in member accounts directly under OU 002 cannot perform any actions, even if they’re granted permissions by IAM access policies. This is because the FullAWSAccess SCP isn’t attached directly to this OU (it’s only inherited).

Why is this important? For an AWS service API to be available to IAM entities in a member account, the API must be specified in an SCP attached at every level all the way down the hierarchy to the relevant member account. Similarly, even though OU 003 does have the FullAWSAccess SCP attached directly to it, the fact that it’s not attached to the parent OU (OU 002) means that IAM entities in member accounts under OU 003 also aren’t able to access any service APIs. This doesn’t happen by default—I have deliberately taken this action to organize my structure in this way, to show both the flexibility and the kind of problems you can encounter when working with OUs and SCPs.

So I now need to fix the problems that I’ve inadvertently created. To start with, I’m going to make one change to OU 002 by attaching the FullAWSAccess SCP directly to that OU. After I do that, OU 002 has the attached and inherited policies that are shown in the following image.

With the FullAWSAccess policy attached to OU 002, member accounts in both OU 002 and OU 003 can access the other non-restricted AWS service APIs (keeping in mind that the FullAWSAccess policy was already applied to OU 003).

I have one final issue to address in this example: OU 003 has an SCP attached that blocks access to the Amazon S3 APIs. However, in this OU, the intent is to allow IAM entities in member accounts to access the EC2 APIs. EC2 API access is blocked because in the parent OU (OU 002), an SCP is attached that denies access to that API (the Deny_EC2 SCP), which means that any actions listed in Deny_EC2 have already been filtered out. An explicit deny always trumps an allow, so to meet goal (4) and have an OU in which EC2 APIs are allowed but access to CloudWatch APIs and S3 APIs is filtered out, I will move OU 003 up one level, placing it directly under OU 001. This change gives me a working OU and policy structure, as shown in the following image.

I recommend that at each level of your organization’s hierarchy, you directly apply the relevant SCPs. By doing this, you’re less likely to forget to apply an SCP to a particular OU, which can break your permission structure. By directly applying SCPs, you also make your policy structure easier to read.

If you have a group of accounts in your organization that are for testing purposes, I recommend that you experiment with OUs and SCPs. Applying SCPs to OUs and then moving an AWS account around within that structure can show you how SCPs affect IAM entities. For example, if you have an IAM user with the AdministratorAccess policy attached, you should see how SCPs can filter out certain AWS service APIs from specified member accounts.

Conclusion

I showed you how you can effectively apply SCPs to OUs in your organization and avoid some of the common issues that you might experience. I demonstrated an approach to designing a working organizational structure that I hope will help smooth your deployment of your organization and enables you to better centrally secure and manage your AWS accounts.

If you have comments about this post, submit them in the Comments section below. If you have questions about anything in this post, start a new thread on the Organizations forum.

Facebook and Cambridge Analytica

2018-03-29 Bruce Schneier

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2018/03/facebook_and_ca.html

In the wake of the Cambridge Analytica scandal, news articles and commentators have focused on what Facebook knows about us. A lot, it turns out. It collects data from our posts, our likes, our photos, things we type and delete without posting, and things we do while not on Facebook and even when we’re offline. It buys data about us from others. And it can infer even more: our sexual orientation, political beliefs, relationship status, drug use, and other personality traits — even if we didn’t take the personality test that Cambridge Analytica developed.

But for every article about Facebook’s creepy stalker behavior, thousands of other companies are breathing a collective sigh of relief that it’s Facebook and not them in the spotlight. Because while Facebook is one of the biggest players in this space, there are thousands of other companies that spy on and manipulate us for profit.

Harvard Business School professor Shoshana Zuboff calls it “surveillance capitalism.” And as creepy as Facebook is turning out to be, the entire industry is far creepier. It has existed in secret far too long, and it’s up to lawmakers to force these companies into the public spotlight, where we can all decide if this is how we want society to operate and — if not — what to do about it.

There are 2,500 to 4,000 data brokers in the United States whose business is buying and selling our personal data. Last year, Equifax was in the news when hackers stole personal information on 150 million people, including Social Security numbers, birth dates, addresses, and driver’s license numbers.

You certainly didn’t give it permission to collect any of that information. Equifax is one of those thousands of data brokers, most of them you’ve never heard of, selling your personal information without your knowledge or consent to pretty much anyone who will pay for it.

Surveillance capitalism takes this one step further. Companies like Facebook and Google offer you free services in exchange for your data. Google’s surveillance isn’t in the news, but it’s startlingly intimate. We never lie to our search engines. Our interests and curiosities, hopes and fears, desires and sexual proclivities, are all collected and saved. Add to that the websites we visit that Google tracks through its advertising network, our Gmail accounts, our movements via Google Maps, and what it can collect from our smartphones.

That phone is probably the most intimate surveillance device ever invented. It tracks our location continuously, so it knows where we live, where we work, and where we spend our time. It’s the first and last thing we check in a day, so it knows when we wake up and when we go to sleep. We all have one, so it knows who we sleep with. Uber used just some of that information to detect one-night stands; your smartphone provider and any app you allow to collect location data knows a lot more.

Surveillance capitalism drives much of the internet. It’s behind most of the “free” services, and many of the paid ones as well. Its goal is psychological manipulation, in the form of personalized advertising to persuade you to buy something or do something, like vote for a candidate. And while the individualized profile-driven manipulation exposed by Cambridge Analytica feels abhorrent, it’s really no different from what every company wants in the end. This is why all your personal information is collected, and this is why it is so valuable. Companies that can understand it can use it against you.

None of this is new. The media has been reporting on surveillance capitalism for years. In 2015, I wrote a book about it. Back in 2010, the Wall Street Journal published an award-winning two-year series about how people are tracked both online and offline, titled “What They Know.”

Surveillance capitalism is deeply embedded in our increasingly computerized society, and if the extent of it came to light there would be broad demands for limits and regulation. But because this industry can largely operate in secret, only occasionally exposed after a data breach or investigative report, we remain mostly ignorant of its reach.

This might change soon. In 2016, the European Union passed the comprehensive General Data Protection Regulation, or GDPR. The details of the law are far too complex to explain here, but some of the things it mandates are that personal data of EU citizens can only be collected and saved for “specific, explicit, and legitimate purposes,” and only with explicit consent of the user. Consent can’t be buried in the terms and conditions, nor can it be assumed unless the user opts in. This law will take effect in May, and companies worldwide are bracing for its enforcement.

Because pretty much all surveillance capitalism companies collect data on Europeans, this will expose the industry like nothing else. Here’s just one example. In preparation for this law, PayPal quietly published a list of over 600 companies it might share your personal data with. What will it be like when every company has to publish this sort of information, and explicitly explain how it’s using your personal data? We’re about to find out.

In the wake of this scandal, even Mark Zuckerberg said that his industry probably should be regulated, although he’s certainly not wishing for the sorts of comprehensive regulation the GDPR is bringing to Europe.

He’s right. Surveillance capitalism has operated without constraints for far too long. And advances in both big data analysis and artificial intelligence will make tomorrow’s applications far creepier than today’s. Regulation is the only answer.

The first step to any regulation is transparency. Who has our data? Is it accurate? What are they doing with it? Who are they selling it to? How are they securing it? Can we delete it? I don’t see any hope of Congress passing a GDPR-like data protection law anytime soon, but it’s not too far-fetched to demand laws requiring these companies to be more transparent in what they’re doing.

One of the responses to the Cambridge Analytica scandal is that people are deleting their Facebook accounts. It’s hard to do right, and doesn’t do anything about the data that Facebook collects about people who don’t use Facebook. But it’s a start. The market can put pressure on these companies to reduce their spying on us, but it can only do that if we force the industry out of its secret shadows.

This essay previously appeared on CNN.com.

EDITED TO ADD (4/2): Slashdot thread.

Newly released guide provides Australian public sector the ability to evaluate AWS at PROTECTED level

2018-03-28 Oliver Bell

Post Syndicated from Oliver Bell original https://aws.amazon.com/blogs/security/newly-released-guide-provides-australian-public-sector-the-ability-to-evaluate-aws-at-protected-level/

Australian public sector customers now have a clear roadmap to use our secure services for sensitive workloads at the PROTECTED level. For the first time, we’ve released our Information Security Registered Assessors Program (IRAP) PROTECTED documentation via AWS Artifact. This information provides the ability to plan, architect, and self-assess systems built in AWS under the Digital Transformation Agency’s Secure Cloud Guidelines.

In short, this documentation gives public sector customers everything needed to evaluate AWS at the PROTECTED level. And we’re making this resource available to download on-demand through AWS Artifact. When you download the guide, you’ll find a mapping of how AWS meets each requirement to securely and compliantly process PROTECTED data.

With the AWS IRAP PROTECTED documentation, the process of adopting our secure services has never been easier. The information enables individual agencies to complete their own assessments and adopt AWS, but we also continue to work with the Australian Signals Directorate to include our services at the PROTECTED level on the Certified Cloud Services List.

Meanwhile, we’re also excited to announce that there are now 46 services in scope, which mean more options to build secure and innovative solutions, while also saving money and gaining the productivity of the cloud.

If you have questions about this announcement or would like to inquire about how to use AWS for your regulated workloads, contact your account team.

All AWS Services GDPR ready

2018-03-26 Chad Woolf

Post Syndicated from Chad Woolf original https://aws.amazon.com/blogs/security/all-aws-services-gdpr-ready/

Today, I’m very pleased to announce that AWS services comply with the General Data Protection Regulation (GDPR). This means that, in addition to benefiting from all of the measures that AWS already takes to maintain services security, customers can deploy AWS services as a key part of their GDPR compliance plans.

This announcement confirms we have completed the entirety of our GDPR service readiness audit, validating that all generally available services and features adhere to the high privacy bar and data protection standards required of data processors by the GDPR. We completed this work two months ahead of the May 25, 2018 enforcement deadline in order to give customers and APN partners an environment in which they can confidently build their own GDPR-compliant products, services, and solutions.

AWS’s GDPR service readiness is only part of the story; we are continuing to work alongside our customers and the AWS Partner Network (APN) to help on their journey toward GDPR compliance. Along with this announcement, I’d like to highlight the following examples of ways AWS can help you accelerate your own GDPR compliance efforts.

Security of Personal Data
During our GDPR service readiness audit, our security and compliance experts confirmed that AWS has in place effective technical and organizational measures for data processors to secure personal data in accordance with the GDPR. Security remains our highest priority, and we continue to innovate and invest in a high bar for security and compliance across all global operations. Our industry-leading functionality provides the foundation for our long list of internationally-recognized certifications and accreditations, demonstrating compliance with rigorous international standards, such as ISO 27001 for technical measures, ISO 27017 for cloud security, ISO 27018 for cloud privacy, SOC 1, SOC 2 and SOC 3, PCI DSS Level 1, and EU-specific certifications such as BSI’s Common Cloud Computing Controls Catalogue (C5). AWS continues to pursue the certifications that assist our customers.

Compliance-enabling Services
Many requirements under the GDPR focus on ensuring effective control and protection of personal data. AWS services give you the capability to implement your own security measures in the ways you need in order to enable your compliance with the GDPR, including specific measures such as:

Encryption of personal data
Ability to ensure the ongoing confidentiality, integrity, availability, and resilience of processing systems and services
Ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident
Processes for regularly testing, assessing, and evaluating the effectiveness of technical and organizational measures for ensuring the security of processing

This is an advanced set of security and compliance services that are designed specifically to handle the requirements of the GDPR. There are numerous AWS services that have particular significance for customers focusing on GDPR compliance, including:

Amazon GuardDuty – a security service featuring intelligent threat detection and continuous monitoring
Amazon Macie – a machine learning tool to assist discovery and securing of personal data stored in Amazon S3
Amazon Inspector – an automated security assessment service to help keep applications in conformity with best security practices
AWS Config Rules – a monitoring service that dynamically checks cloud resources for compliance with security rules

Additionally, we have published a whitepaper, “Navigating GDPR Compliance on AWS,” dedicated to this topic. This paper details how to tie GDPR concepts to specific AWS services, including those relating to monitoring, data access, and key management. Furthermore, our GDPR Center will give you access to the up-to-date resources you need to tackle requirements that directly support your GDPR efforts.

Compliant DPA
We offer a GDPR-compliant Data Processing Addendum (DPA), enabling you to comply with GDPR contractual obligations.

Conformity with a Code of Conduct
GDPR introduces adherence to a “code of conduct” as a mechanism for demonstrating sufficient guarantees of requirements that the GDPR places on data processors. In this context, we previously announced compliance with the CISPE Code of Conduct. The CISPE Code of Conduct provides customers with additional assurances regarding their ability to fully control their data in a safe, secure, and compliant environment when they use services from providers like AWS. More detail about the CISPE Code of Conduct can be found at: https://aws.amazon.com/compliance/cispe/

Training and Summits
We can provide you with training on navigating GDPR compliance using AWS services via our Professional Services team. This team has a GDPR workshop offering, which is a two-day facilitated session customized to your specific needs and challenges. We are also providing GDPR presentations during our AWS Summits in European countries, as well as San Francisco and Tokyo.

Additional Resources
Finally, we have teams of compliance, data protection, and security experts, as well as the APN, helping customers across Europe prepare for running regulated workloads in the cloud as the GDPR becomes enforceable. For additional information on this, please contact your AWS Account Manager.

As we move towards May 25 and beyond, we’ll be posting a series of blogs to dive deeper into GDPR-related concepts along with how AWS can help. Please visit our GDPR Center for more information. We’re excited about being your partner in fully addressing this important regulation.

-Chad Woolf

Vice President, AWS Security Assurance

Interested in additional AWS Security news? Follow the AWS Security Blog on Twitter.

Adding Backdoors at the Chip Level

2018-03-26 Bruce Schneier

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2018/03/adding_backdoor.html

Interesting research into undetectably adding backdoors into computer chips during manufacture: “Stealthy dopant-level hardware Trojans: extended version,” also available here:

Abstract: In recent years, hardware Trojans have drawn the attention of governments and industry as well as the scientific community. One of the main concerns is that integrated circuits, e.g., for military or critical-infrastructure applications, could be maliciously manipulated during the manufacturing process, which often takes place abroad. However, since there have been no reported hardware Trojans in practice yet, little is known about how such a Trojan would look like and how difficult it would be in practice to implement one. In this paper we propose an extremely stealthy approach for implementing hardware Trojans below the gate level, and we evaluate their impact on the security of the target device. Instead of adding additional circuitry to the target design, we insert our hardware Trojans by changing the dopant polarity of existing transistors. Since the modified circuit appears legitimate on all wiring layers (including all metal and polysilicon), our family of Trojans is resistant to most detection techniques, including fine-grain optical inspection and checking against “golden chips”. We demonstrate the effectiveness of our approach by inserting Trojans into two designs — a digital post-processing derived from Intel’s cryptographically secure RNG design used in the Ivy Bridge processors and a side-channel resistant SBox implementation — and by exploring their detectability and their effects on security.

The moral is that this kind of technique is very difficult to detect.

Repeat Infringer Policy Doesn’t Have to Be Spelled Out, Appeals Court Rules

2018-03-24 Ernesto

Post Syndicated from Ernesto original https://torrentfreak.com/repeat-infringer-policy-doesnt-have-to-be-spelled-out-appeals-court-rules-180324/

The “repeat infringer” issue is a hot topic in US Courts, leading to much uncertainty among various Internet services.

Under the DMCA, companies are required to implement a reasonable policy to deal with frequent offenders.

This not only applies to commercial Internet providers, as Cox found out the hard way, but also to websites that host user-uploaded content, such as video and image hosting services.

Last week the United States Court of Appeals for the Ninth Circuit issued an order that provides some further clarification on how a repeat infringer policy should be documented.

The case in question was filed by adult content producer Ventura Content, which accused the adult-themed site Motherless of copyright infringement. While Motherless relies on user-uploaded content, the adult producer argued that it is liable for pirated content on its site.

In a majority ruling, the Court found that Motherless did not know about the alleged infringements before the lawsuit was filed and removed them within a day of being properly alerted.

This means that the site is entitled to safe harbor protection if it implemented a reasonable repeat infringer policy, which brings us to the crux of the case.

The operator of the site, Joshua Lange, is the sole employee who single-handedly deals with all takedown requests. The site also has a page informing users that there is a repeat infringer policy, without providing specific details.

The adult content producer argued that the site had failed to reasonably implement such a policy, but the Court disagreed, noting that the DMCA doesn’t prescribe a written policy.

“The details of the termination policy are not written down. However, the statute does not say that the policy details must be written, just that the site must inform subscribers of ‘a policy’ of terminating repeat infringers in appropriate circumstances,” the Court states.

In this case, the details of the policy were in the mind of the operator, who made his decisions based on a case-by-case evaluation.

“Lange uses his judgment, not a mechanical test, to terminate infringers based on the volume, history, severity, and intentions behind a user’s infringing content uploads.”

The fact that the details of the policy were not spelled out doesn’t mean that Motherless has no safe harbor protection, although this may be different for large companies.

“A company might need a written policy to tell its employees or independent contractors what to do if there were a significant number of them, but Motherless is not such a firm.

“So the lack of a detailed written policy is not by itself fatal to safe harbor eligibility. Neither is the fact that Motherless did not publicize its internal criteria,” the Court adds.

Surprisingly, the site’s operator didn’t keep any written logs of repeat infringers either. He simply kept track of them in his head and terminated more than a thousand accounts this way. This didn’t work flawlessly, as a few repeat infringers slipped through, but the Court believes it was good enough.

“It is tempting, perhaps, to say that a policy is not ‘reasonably’ implemented if it does not include both a database of users whose uploads have generated DMCA notices and some automated means of catching them if they do it again. But the statute does not require that,” the order reads.

Overall, the Court sides with Motherless and its operator and affirmed the summary judgment in its favor.

This case is unique in many ways. Among other things, it shows that written details or logs are not always required for a “reasonable” repeat infringer policy. While this could be different for large companies, it is likely to be referenced frequently in related cases.

This week, hosting provider Steadfast was quick to use the ruling to argue that it sufficiently adopted and informed users of its repeat infringer policy.

—-

A copy of the Ninth Circuit Court of Appeals ruling is available here (pdf).

Source: TF, for the latest info on copyright, file-sharing, torrent sites and more. We also have VPN reviews, discounts, offers and coupons.

Israeli Security Attacks AMD by Publishing Zero-Day Exploits

2018-03-19 Bruce Schneier

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2018/03/israeli_securit.html

Last week, the Israeli security company CTS Labs published a series of exploits against AMD chips. The publication came with the flashy website, detailed whitepaper, cool vulnerability names — RYZENFALL, MASTERKEY, FALLOUT, and CHIMERA — and logos we’ve come to expect from these sorts of things. What’s new is that the company only gave AMD a day’s notice, which breaks with every norm about responsible disclosure. CTS Labs didn’t release details of the exploits, only high-level descriptions of the vulnerabilities, but it is probably still enough for others to reproduce their results. This is incredibly irresponsible of the company.

Moreover, the vulnerabilities are kind of meh. Nicholas Weaver explains:

In order to use any of the four vulnerabilities, an attacker must already have almost complete control over the machine. For most purposes, if the attacker already has this access, we would generally say they’ve already won. But these days, modern computers at least attempt to protect against a rogue operating system by having separate secure subprocessors. CTS Labs discovered the vulnerabilities when they looked at AMD’s implementation of the secure subprocessor to see if an attacker, having already taken control of the host operating system, could bypass these last lines of defense.

In a “Clarification,” CTS Labs kind of agrees:

The vulnerabilities described in amdflaws.com could give an attacker that has already gained initial foothold into one or more computers in the enterprise a significant advantage against IT and security teams.

The only thing the attacker would need after the initial local compromise is local admin privileges and an affected machine. To clarify misunderstandings — there is no need for physical access, no digital signatures, no additional vulnerability to reflash an unsigned BIOS. Buy a computer from the store, run the exploits as admin — and they will work (on the affected models as described on the site).

The weirdest thing about this story is that CTS Labs describes one of the vulnerabilities, Chimera, as a backdoor. Although it doesn’t t come out and say that this was deliberately planted by someone, it does make the point that the chips were designed in Taiwan. This is an incredible accusation, and honestly needs more evidence before we can evaluate it.

The upshot of all of this is that CTS Labs played this for maximum publicity: over-hyping its results and minimizing AMD’s ability to respond. And it may have an ulterior motive:

But CTS’s website touting AMD’s flaws also contained a disclaimer that threw some shadows on the company’s motives: “Although we have a good faith belief in our analysis and believe it to be objective and unbiased, you are advised that we may have, either directly or indirectly, an economic interest in the performance of the securities of the companies whose products are the subject of our reports,” reads one line. WIRED asked in a follow-up email to CTS whether the company holds any financial positions designed to profit from the release of its AMD research specifically. CTS didn’t respond.

We all need to demand better behavior from security researchers. I know that any publicity is good publicity, but I am pleased to see the stories critical of CTS Labs outnumbering the stories praising it.

EDITED TO ADD (3/21): AMD responds:

AMD’s response today agrees that all four bug families are real and are found in the various components identified by CTS. The company says that it is developing firmware updates for the three PSP flaws. These fixes, to be made available in “coming weeks,” will be installed through system firmware updates. The firmware updates will also mitigate, in some unspecified way, the Chimera issue, with AMD saying that it’s working with ASMedia, the third-party hardware company that developed Promontory for AMD, to develop suitable protections. In its report, CTS wrote that, while one CTS attack vector was a firmware bug (and hence in principle correctable), the other was a hardware flaw. If true, there may be no effective way of solving it.

Response here.

How we reduce complexity and rapidly iterate on Amazon GuardDuty: twelve new detections added

2018-03-14 Michael Fuller

Post Syndicated from Michael Fuller original https://aws.amazon.com/blogs/security/why-we-reduce-complexity-and-rapidly-iterate-on-amazon-guardduty-twelve-new-detections-added/

We’re relentlessly innovating on your behalf at AWS, especially when it comes to security. Last November, we launched Amazon GuardDuty, a continuous security monitoring and threat detection service that incorporates threat intelligence, anomaly detection, and machine learning to help protect your AWS resources, including your AWS accounts. Many large customers, including General Electric, Autodesk, and MapBox, discovered these benefits and have quickly adopted the service for its ease of use and improved threat detection. In this post, I want to show you how easy it is for everyone to get started—large and small—and discuss our rapid iteration on the service.

After more than seven years at AWS, I still find myself staying up at night obsessing about unnecessary complexity. Sounds fun, right? Well, I don’t have to tell you that there’s a lot of unnecessary complexity and undifferentiated heavy lifting in security. Most security tooling requires significant care and feeding by humans. It’s often difficult to configure and manage, it’s hard to know if it’s working properly, and it’s costly to procure and run. As a result, it’s not accessible to all customers, and for those that do get their hands on it, they spend a lot of highly-skilled resources trying to keep it operating at its potential.

Even for the most skilled security teams, it can be a struggle to ensure that all resources are covered, especially in the age of virtualization, where new accounts, new resources, and new users can come and go across your organization at a rapid pace. Furthermore, attackers have come up with ingenious ways of giving you the impression your security solution is working when, in fact, it has been completely disabled.

I’ve spent a lot of time obsessing about these problems. How can we use the Cloud to not just innovate in security, but also make it easier, more affordable, and more accessible to all? Our ultimate goal is to help you better protect your AWS resources, while also freeing you up to focus on the next big project.

With GuardDuty, we really turned the screws on unnecessary complexity, distilling continuous security monitoring and threat detection down to a binary decision—it’s either on or off. That’s it. There’s no software, virtual appliances, or agents to deploy, no data sources to enable, and no complex permissions to create. You don’t have to write custom rules or become an expert at machine learning. All we ask of you is to simply turn the service on with a single-click or API call.

GuardDuty operates completely on our infrastructure, so there’s no risk of disrupting your workloads. By providing a hard hypervisor boundary between the code running in your AWS accounts and the code running in GuardDuty, we can help ensure full coverage while making it harder for a misconfiguration or an ingenious attacker to change that. When we detect something interesting, we generate a security finding and deliver it to you through the GuardDuty console and AWS CloudWatch Events. This makes it possible to simply view findings in GuardDuty or push them to an existing SIEM or workflow system. We’ve already seen customers take it a step further using AWS Lambda to automate actions such as changing security groups, isolating instances, or rotating credentials.

Now… are you ready to get started? It’s this simple:

So, you’ve got it enabled, now what can GuardDuty detect?

As soon as you enable the service, it immediately starts consuming multiple metadata streams at scale, including AWS CloudTrail, VPC Flow Logs, and DNS logs. It compares what it finds to fully managed threat intelligence feeds containing the latest malicious IPs and domains. In parallel, GuardDuty profiles all activity in your account, which allows it to learn the behavior of your resources so it can identify highly suspicious activity that suggests a threat.

The threat-intelligence-based detections can identify activity such as an EC2 instance being probed or brute-forced by an attacker. If an instance is compromised, it can detect attempts at lateral movement, communication with a known malware or command-and-control server, crypto-currency mining, or an attempt to exfiltrate data through DNS.

Where it gets more interesting is the ability to detect AWS account-focused threats. For example, if an attacker gets a hold of your AWS account credentials—say, one of your developers exposes credentials on GitHub—GuardDuty will identify unusual account behavior. For example, an unusual instance type being deployed in a region that has never been used, suspicious attempts to inventory your resources by calling unusual patterns of list APIs or describe APIs, or an effort to obscure user activity by disabling CloudTrail logging.

Our obsession with removing complexity meant making these detections fully-managed. We take on all the heavy lifting of building, maintaining, measuring, and improving the detections so that you can focus on what to do when an event does occur.

What’s new?

When we launched at the end of November, we had thirty-four distinct detections in GuardDuty, but we weren’t stopping there. Many of these detections are already on their second or third continuous improvement iteration. In less than three months, we’ve also added twelve more, including nine CloudTrail-based anomaly detections that identify highly suspicious activity in your accounts. These new detections intelligently catch changes to, or reconnaissance of, network, resource, user permissions, and anomalous activity in EC2, CloudTrail, and AWS console log-ins. These are detections we’ve built based on what we’ve learned from observed attack patterns across the scale of AWS.

The intelligence in these detections is built around the identification of highly sensitive AWS API calls that are invoked under one or more highly suspicious circumstances. The combination of “highly sensitive” and “highly suspicious” is important. Highly sensitive APIs are those that either change the security posture of an account by adding or elevating users, user policies, roles, or account-key IDs (AKIDs). Highly suspicious circumstances are determined from underlying models profiled at the API level by GuardDuty. The result is the ability to catch real threats, while decreasing false positives, limiting false negatives, and reducing alert-noise.

It’s still day one

As we like to say in Amazon, it’s still day one. I’m excited about what we’ve built with GuardDuty, but we’re not going to stop improving, even if you’re already happy with what we’ve built. Check out the list of new detections below and all of the GuardDuty detections in our online documentation. Keep the feedback coming as it’s what powers us at AWS.

Now, I have to stop writing because my wife tells me I have some unnecessary complexity to remove from our closet.

New GuardDuty CloudTrail-based anomaly detections

Recon:IAMUser/NetworkPermissions
Situation: An IAM user invoked an API commonly used to discover the network access permissions of existing security groups, ACLs, and routes in your AWS account.
Description: This finding is triggered when network configuration settings in your AWS environment are probed under suspicious circumstances. For example, if an IAM user in your AWS environment invoked the DescribeSecurityGroups API with no prior history of doing so. An attacker might use stolen credentials to perform this reconnaissance of network configuration settings before executing the next stage of their attack, which might include changing network permissions or making use of existing openings in the network configuration.
Recon:IAMUser/ResourcePermissions
Situation: An IAM user invoked an API commonly used to discover the permissions associated with various resources in your AWS account.
Description: This finding is triggered when resource access permissions in your AWS account are probed under suspicious circumstances. For example, if an IAM user with no prior history of doing so, invoked the DescribeInstances API. An attacker might use stolen credentials to perform this reconnaissance of your AWS resources in order to find valuable information or determine the capabilities of the credentials they already have.
Recon:IAMUser/UserPermissions
Situation: An IAM user invoked an API commonly used to discover the users, groups, policies, and permissions in your AWS account.
Description: This finding is triggered when user permissions in your AWS environment are probed under suspicious circumstances. For example, if an IAM user invoked the ListInstanceProfilesForRole API with no prior history of doing so. An attacker might use stolen credentials to perform this reconnaissance of your IAM users and roles to determine the capabilities of the credentials they already have or to find more permissive credentials that are vulnerable to lateral movement.
Persistence:IAMUser/NetworkPermissions
Situation: An IAM user invoked an API commonly used to change the network access permissions for security groups, routes, and ACLs in your AWS account.
Description: This finding is triggered when network configuration settings are changed under suspicious circumstances. For example, if an IAM user in your AWS environment invoked the CreateSecurityGroup API with no prior history of doing so. Attackers often attempt to change security groups, allowing certain inbound traffic on various ports to improve their ability to access the bot they might have planted on your EC2 instance.
Persistence:IAMUser/ResourcePermissions
Situation: An IAM user invoked an API commonly used to change the security access policies of various resources in your AWS account.
Description: This finding is triggered when a change is detected to policies or permissions attached to AWS resources. For example, if an IAM user in your AWS environment invoked the PutBucketPolicy API with no prior history of doing so. Some services, such as Amazon S3, support resource-attached permissions that grant one or more IAM principals access to the resource. With stolen credentials, attackers can change the policies attached to a resource, granting themselves future access to that resource.
Persistence:IAMUser/UserPermissions
Situation: An IAM user invoked an API commonly used to add, modify, or delete IAM users, groups, or policies in your AWS account.
Description: This finding is triggered by suspicious changes to the user-related permissions in your AWS environment. For example, if an IAM user in your AWS environment invoked the AttachUserPolicy API with no prior history of doing so. In an effort to maximize their ability to access the account even after they’ve been discovered, attackers can use stolen credentials to create new users, add access policies to existing users, create access keys, and so on. The owner of the account might notice that a particular IAM user or password was stolen and delete it from the account, but might not delete other users that were created by the fraudulently created admin IAM user, leaving their AWS account still accessible to the attacker.
ResourceConsumption:IAMUser/ComputeResources
Situation: An IAM user invoked an API commonly used to launch compute resources like EC2 Instances.
Description: This finding is triggered when EC2 instances in your AWS environment are launched under suspicious circumstances. For example, if an IAM user invoked the RunInstances API with no prior history of doing so. This might be an indication of an attacker using stolen credentials to access compute time (possibly for cryptocurrency mining or password cracking). It can also be an indication of an attacker using an EC2 instance in your AWS environment and its credentials to maintain access to your account.
Stealth:IAMUser/LoggingConfigurationModified
Situation: An IAM user invoked an API commonly used to stop CloudTrail logging, delete existing logs, and otherwise eliminate traces of activity in your AWS account.
Description: This finding is triggered when the logging configuration in your AWS account is modified under suspicious circumstances. For example, if an IAM user invoked the StopLogging API with no prior history of doing so. This can be an indication of an attacker trying to cover their tracks by eliminating any trace of their activity.
UnauthorizedAccess:IAMUser/ConsoleLogin
Situation: An unusual console login by an IAM user in your AWS account was observed.
Description: This finding is triggered when a console login is detected under suspicious circumstances. For example, if an IAM user invoked the ConsoleLogin API from a never-before- used client or an unusual location. This could be an indication of stolen credentials being used to gain access to your AWS account, or a valid user accessing the account in an invalid or less secure manner (for example, not over an approved VPN).

New GuardDuty threat intelligence based detections

Trojan:EC2/PhishingDomainRequest!DNS
This detection occurs when an EC2 instance queries domains involved in phishing attacks.
Trojan:EC2/BlackholeTraffic!DNS
This detection occurs when an EC2 instance connects to a black hole domain. Black holes refer to places in the network where incoming or outgoing traffic is silently discarded without informing the source that the data didn’t reach its intended recipient.
Trojan:EC2/DGADomainRequest.C!DNS
This detection occurs when an EC2 instance queries algorithmically generated domains. Such domains are commonly used by malware and could be an indication of a compromised EC2 instance.

If you have feedback about this blog post, submit comments in the “Comments” section below. If you have questions about this blog post, start a new thread on the Amazon GuardDuty forum or contact AWS Support.

Join the AWS Quest – Help me to Rebuild Ozz!

2018-03-09 Jeff Barr

Post Syndicated from Jeff Barr original https://aws.amazon.com/blogs/aws/join-the-aws-quest-help-me-to-rebuild-ozz/

If you have been watching my weekly videos, you may have noticed an orange robot in the background from time to time. That’s Ozz, my robot friend and helper. Built from the ground up in my home laboratory, Ozz is an invaluable part of the AWS blogging process!

Sadly, when we announced we are adding the AWS Podcast to the blog, Ozz literally went to pieces and all I have left is a large pile of bricks and some great memories of our time together. From what I can tell, Ozz went haywire over this new development due to excessive enthusiasm!

Ozz, perhaps anticipating that this could happen at some point, buried a set of clues (each pointing to carefully protected plans) in this blog, in the AWS Podcast, and in other parts of the AWS site. If we can find and decode these plans, we can rebuild Ozz, better, stronger, and faster. Unfortunately, due to concerns about the ultra-competitive robot friend market, Ozz concealed each of the plans inside a set of devious, brain-twisting puzzles. You are going to need to look high, low, inside, outside, around, and through the clues in order to figure this one out. You may even need to phone a friend or two.

Your mission, should you choose to accept it, is to find these clues, decode the plans, and help me to rebuild Ozz. The information that I have is a bit fuzzy, but I think there are 20 or so puzzles, each one describing one part of Ozz. If we can solve them all, we’ll get together on Twitch later this month and put Ozz back together.

Are you with me on this? Let’s do it!

— Jeff;

How to Use Bucket Policies and Apply Defense-in-Depth to Help Secure Your Amazon S3 Data

2018-03-07 Rajat Ravinder Varuni

Post Syndicated from Rajat Ravinder Varuni original https://aws.amazon.com/blogs/security/how-to-use-bucket-policies-and-apply-defense-in-depth-to-help-secure-your-amazon-s3-data/

Amazon S3 provides comprehensive security and compliance capabilities that meet even the most stringent regulatory requirements. It gives you flexibility in the way you manage data for cost optimization, access control, and compliance. However, because the service is flexible, a user could accidentally configure buckets in a manner that is not secure. For example, let’s say you uploaded files to an Amazon S3 bucket with public read permissions, even though you intended only to share this file with a colleague or a partner. Although this might have accomplished your task to share the file internally, the file is now available to anyone on the internet, even without authentication.

In this blog post, we show you how to prevent your Amazon S3 buckets and objects from allowing public access. We discuss how to secure data in Amazon S3 with a defense-in-depth approach, where multiple security controls are put in place to help prevent data leakage. This approach helps prevent you from allowing public access to confidential information, such as personally identifiable information (PII) or protected health information (PHI).

Preventing your Amazon S3 buckets and objects from allowing public access

Every call to an Amazon S3 service becomes a REST API request. When your request is transformed via a REST call, the permissions are converted into parameters included in the HTTP header or as URL parameters. The Amazon S3 bucket policy allows or denies access to the Amazon S3 bucket or Amazon S3 objects based on policy statements, and then evaluates conditions based on those parameters. To learn more, see Using Bucket Policies and User Policies.

With this in mind, let’s say multiple AWS Identity and Access Management (IAM) users at Example Corp. have access to an Amazon S3 bucket and the objects in the bucket. Example Corp. wants to share the objects among its IAM users, while at the same time preventing the objects from being made available publicly.

To demonstrate how to do this, we start by creating an Amazon S3 bucket named examplebucket. After creating this bucket, we must apply the following bucket policy. This policy denies any uploaded object (PutObject) with the attribute x-amz-acl having the values public-read, public-read-write, or authenticated-read. This means authenticated users cannot upload objects to the bucket if the objects have public permissions.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyPublicReadACL",
            "Effect": "Deny",
            "Principal": {
                "AWS": "*"
            },
            "Action": [
                "s3:PutObject",
                "s3:PutObjectAcl"
            ],
            "Resource": "arn:aws:s3:::examplebucket/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": [
                        "public-read",
                        "public-read-write",
                        "authenticated-read"
                    ]
                }
            }
        },
        {
            "Sid": "DenyPublicReadGrant",
            "Effect": "Deny",
            "Principal": {
                "AWS": "*"
            },
            "Action": [
                "s3:PutObject",
                "s3:PutObjectAcl"
            ],
            "Resource": "arn:aws:s3:::examplebucket/*",
            "Condition": {
                "StringLike": {
                    "s3:x-amz-grant-read": [
                        "*http://acs.amazonaws.com/groups/global/AllUsers*",
                        "*http://acs.amazonaws.com/groups/global/AuthenticatedUsers*"
                    ]
                }
            }
        },
        {
            "Sid": "DenyPublicListACL",
            "Effect": "Deny",
            "Principal": {
                "AWS": "*"
            },
            "Action": "s3:PutBucketAcl",
            "Resource": "arn:aws:s3:::examplebucket",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": [
                        "public-read",
                        "public-read-write",
                        "authenticated-read"
                    ]
                }
            }
        },
        {
            "Sid": "DenyPublicListGrant",
            "Effect": "Deny",
            "Principal": {
                "AWS": "*"
            },
            "Action": "s3:PutBucketAcl",
            "Resource": "arn:aws:s3:::examplebucket",
            "Condition": {
                "StringLike": {
                    "s3:x-amz-grant-read": [
                        "*http://acs.amazonaws.com/groups/global/AllUsers*",
                        "*http://acs.amazonaws.com/groups/global/AuthenticatedUsers*"
                    ]
                }
            }
        }
    ]
}

To better understand what is happening in this bucket policy, we’ll explain each statement. Let’s start with the first statement.


{
    "Sid": "DenyPublicReadACL",
    "Effect": "Deny",
    "Principal": {
        "AWS": "*"
    },
    "Action": [
        "s3:PutObject",
        "s3:PutObjectAcl"
    ],
    "Resource": "arn:aws:s3:::examplebucket/*",
    "Condition": {
        "StringEquals": {
            "s3:x-amz-acl": [
                "public-read",
                "public-read-write",
                "authenticated-read"
            ]
        }
    }
}

This statement accomplishes the following:

“Deny any Amazon S3 request to PutObject or PutObjectAcl in the bucket examplebucket when the request includes one of the following access control lists (ACLs): public-read, public-read-write, or authenticated-read.”

Remember that IAM policies are evaluated not in a first-match-and-exit model. Instead, IAM evaluates first if there is an explicit Deny. If there is not, IAM continues to evaluate if you have an explicit Allow and then you have an implicit Deny.

The above policy creates an explicit Deny. Even when any authenticated user tries to upload (PutObject) an object with public read or write permissions, such as public-read or public-read-write or authenticated-read, the action will be denied. To understand how S3 Access Permissions work, you must understand what Access Control Lists (ACL) and Grants are. You can find the documentation here.

Now let’s continue our bucket policy explanation by examining the next statement.

{
    "Sid": "DenyPublicReadGrant",
    "Effect": "Deny",
    "Principal": {
        "AWS": "*"
    },
    "Action": [
        "s3:PutObject",
        "s3:PutObjectAcl"
    ],
    "Resource": "arn:aws:s3:::examplebucket/*",
    "Condition": {
        "StringLike": {
            "s3:x-amz-grant-read": [
                "*http://acs.amazonaws.com/groups/global/AllUsers*",
                "*http://acs.amazonaws.com/groups/global/AuthenticatedUsers*"
            ]
        }
    }
}

This statement is very similar to the first statement, except that instead of checking the ACLs, we are checking specific user groups’ grants that represent the following groups:

AuthenticatedUsers group. Represented by http://acs.amazonaws.com/groups/global/AuthenticatedUsers, this group represents all AWS accounts. Access permissions to this group allow any AWS account to access the resource. However, all requests must be signed (authenticated).
AllUsers group. Represented by http://acs.amazonaws.com/groups/global/AllUsers, access permissions to this group allow anyone on the internet access to the resource. The requests can be signed (authenticated) or unsigned (anonymous). Unsigned requests omit the Authentication header in the request.

For more information about which parameters you can use to create bucket policies, see Using Bucket Policies and User Policies.

Now that you know how to deny object uploads with permissions that would make the object public, you just have two statement policies that prevent users from changing the bucket permissions (Denying s3:PutBucketACL from ACL and Denying s3:PutBucketACL from Grants).

Below is how we’re preventing users from changing the bucket permisssions.

{
  "Sid": "DenyPublicListACL",
  "Effect": "Deny",
  "Principal": {
    "AWS": "*"
  },
  "Action": "s3:PutBucketAcl",
  "Resource": "arn:aws:s3:::examplebucket",
  "Condition": {
    "StringEquals": {
      "s3:x-amz-acl": [
        "public-read",
        "public-read-write",
        "authenticated-read"
      ]
    }
  }
},
{
  "Sid": "DenyPublicListGrant",
  "Effect": "Deny",
  "Principal": {
    "AWS": "*"
  },
  "Action": "s3:PutBucketAcl",
  "Resource": "arn:aws:s3:::examplebucket",
  "Condition": {
    "StringLike": {
      "s3:x-amz-grant-read": [
        "*http://acs.amazonaws.com/groups/global/AllUsers*",
        "*http://acs.amazonaws.com/groups/global/AuthenticatedUsers*"
      ]
    }
  }
}

As you can see above, the statement is very similar to the Object statements, except that now we use s3:PutBucketAcl instead of s3:PutObjectAcl, the Resource is just the bucket ARN, and the objects have the “/*” in the end of the ARN.

In this section, we showed how to prevent IAM users from accidently uploading Amazon S3 objects with public permissions to buckets. In the next section, we show you how to enforce multiple layers of security controls, such as encryption of data at rest and in transit while serving traffic from Amazon S3.

Securing data on Amazon S3 with defense-in-depth

Let’s say that Example Corp. wants to serve files securely from Amazon S3 to its users with the following requirements:

The data must be encrypted at rest and during transit.
The data must be accessible only by a limited set of public IP addresses.
All requests for data should be handled only by Amazon CloudFront (which is a content delivery network) instead of being directly available from an Amazon S3 URL. If you’re using an Amazon S3 bucket as the origin for a CloudFront distribution, you can grant public permission to read the objects in your bucket. This allows anyone to access your objects either through CloudFront or the Amazon S3 URL. CloudFront doesn’t expose Amazon S3 URLs, but your users still might have access to those URLs if your application serves any objects directly from Amazon S3, or if anyone gives out direct links to specific objects in Amazon S3.
A domain name is required to consume the content. Custom SSL certificate support lets you deliver content over HTTPS by using your own domain name and your own SSL certificate. This gives visitors to your website the security benefits of CloudFront over an SSL connection that uses your own domain name, in addition to lower latency and higher reliability.

To represent defense-in-depth visually, the following diagram contains several Amazon S3 objects (A) in a single Amazon S3 bucket (B). You can encrypt these objects on the server side or the client side. You also can configure the bucket policy such that objects are accessible only through CloudFront, which you can accomplish through an origin access identity (C). You then can configure CloudFront to deliver content only over HTTPS in addition to using your own domain name (D).

Defense-in-depth requirement 1: Data must be encrypted at rest and during transit

Let’s start with the objects themselves. Amazon S3 objects—files in this case—can range from zero bytes to multiple terabytes in size (see service limits for the latest information). Each Amazon S3 bucket includes a collection of objects, and the objects can be uploaded via the Amazon S3 console, AWS CLI, or AWS API.

You can encrypt Amazon S3 objects at rest and during transit. At rest, objects in a bucket are encrypted with server-side encryption by using Amazon S3 managed keys or AWS Key Management Service (AWS KMS) managed keys or customer-provided keys through AWS KMS. You also can encrypt objects on the client side by using AWS KMS managed keys or a customer-supplied client-side master key.

If you choose to use server-side encryption, Amazon S3 encrypts your objects before saving them on disks in AWS data centers. To encrypt an object at the time of upload, you need to add the x-amz-server-side-encryption header to the request to tell Amazon S3 to encrypt the object using Amazon S3 managed keys (SSE-S3), AWS KMS managed keys (SSE-KMS), or customer-provided keys (SSE-C). There are two possible values for the x-amz-server-side-encryption header: AES256, which tells Amazon S3 to use Amazon S3 managed keys, and aws:kms, which tells Amazon S3 to use AWS KMS managed keys.

The following code example shows a Put request using SSE-S3.

PUT /example-object HTTP/1.1
Host: myBucket.s3.amazonaws.com
Date: Wed, 8 Jun 2016 17:50:00 GMT
Authorization: authorization string
Content-Type: text/plain
Content-Length: 11434
x-amz-meta-author: Janet
Expect: 100-continue
x-amz-server-side-encryption: AES256
[11434 bytes of object data]

If you choose to use client-side encryption, you can encrypt data on the client side and upload the encrypted data to Amazon S3. In this case, you manage the encryption process, the encryption keys, and related tools. You encrypt data on the client side by using AWS KMS managed keys or a customer-supplied, client-side master key.

Defense-in-depth requirement 2: Data must be accessible only by a limited set of public IP addresses

At the Amazon S3 bucket level, you can configure permissions through a bucket policy. For example, you can limit access to the objects in a bucket by IP address range or specific IP addresses. Alternatively, you can make the objects accessible only through HTTPS.

The following bucket policy allows access to Amazon S3 objects only through HTTPS (the policy was generated with the AWS Policy Generator). Here the bucket policy explicitly denies ("Effect": "Deny") all read access ("Action": "s3:GetObject") from anybody who browses ("Principal": "*") to Amazon S3 objects within an Amazon S3 bucket if they are not accessed through HTTPS ("aws:SecureTransport": "false").

{
    "Version": "2012-10-17",
    "Id": "Policy1504640911349",
    "Statement": [
        {
            "Sid": "Stmt1504640908907",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::/*",
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": "false"
                }
            }
        }
    ]
}

Defense-in-depth requirement 3: Data must not be publicly accessible directly from an Amazon S3 URL

Next, configure Amazon CloudFront to serve traffic from within the bucket. The use of CloudFront serves several purposes:

CloudFront is a content delivery network that acts as a cache to serve static files quickly to clients.
Depending on the number of requests, the cost of delivery is less than if objects were served directly via Amazon S3.
Objects served through CloudFront can be limited to specific countries.

Access to these Amazon S3 objects is available only through CloudFront. We do this by creating an origin access identity (OAI) for CloudFront and granting access to objects in the respective Amazon S3 bucket only to that OAI. As a result, access to Amazon S3 objects from the internet is possible only through CloudFront; all other means of accessing the objects—such as through an Amazon S3 URL—are denied. CloudFront acts not only as a content distribution network, but also as a host that denies access based on geographic restrictions. You apply these restrictions by updating your CloudFront web distribution and adding a whitelist that contains only a specific country’s name (let’s say Liechtenstein). Alternatively, you could add a blacklist that contains every country except that country. Learn more about how to use CloudFront geographic restriction to whitelist or blacklist a country to restrict or allow users in specific locations from accessing web content in the AWS Support Knowledge Center.

Defense-in-depth requirement 4: A domain name is required to consume the content

To serve content from CloudFront, you must use a domain name in the URLs for objects on your webpages or in your web application. The domain name can be either of the following:

The domain name that CloudFront automatically assigns when you create a distribution, such as d111111abcdef8.cloudfront.net
Your own domain name, such as example.com

For example, you might use one of the following URLs to return the file image.jpg:

http://d111111abcdef8.cloudfront.net/images/image.jpg
http://example.com/images/image.jpg

You use the same URL format whether you store the content in Amazon S3 buckets or at a custom origin, like one of your own web servers.

Instead of using the default domain name that CloudFront assigns for you when you create a distribution, you can add an alternate domain name that’s easier to work with, like example.com. By setting up your own domain name with CloudFront, you can use a URL like this for objects in your distribution: http://example.com/images/image.jpg.

Let’s say that you already have a domain name hosted on Amazon Route 53. You would like to serve traffic from the domain name, request an SSL certificate, and add this to your CloudFront web distribution. The SSL offloading occurs in CloudFront by serving traffic securely from each CloudFront location. You also can configure CloudFront to deliver your content over HTTPS by using your custom domain name and your own SSL certificate. Serving web content through CloudFront reduces response from the origin as requests are redirected to the nearest edge location. This results in faster download times than if the visitor had requested the content from a data center that is located farther away.

Summary

In this post, we demonstrated how you can apply policies to Amazon S3 buckets so that only users with appropriate permissions are allowed to access the buckets. Anonymous users (with public-read/public-read-write permissions) and authenticated users without the appropriate permissions are prevented from accessing the buckets.

We also examined how to secure access to objects in Amazon S3 buckets. The objects in Amazon S3 buckets can be encrypted at rest and during transit. Doing so helps provide end-to-end security from the source (in this case, Amazon S3) to your users.

If you have feedback about this blog post, submit comments in the “Comments” section below. If you have questions about this blog post, start a new thread on the Amazon S3 forum or contact AWS Support.

Improve the Operational Efficiency of Amazon Elasticsearch Service Domains with Automated Alarms Using Amazon CloudWatch

2018-03-06 Veronika Megler

Post Syndicated from Veronika Megler original https://aws.amazon.com/blogs/big-data/improve-the-operational-efficiency-of-amazon-elasticsearch-service-domains-with-automated-alarms-using-amazon-cloudwatch/

A customer has been successfully creating and running multiple Amazon Elasticsearch Service (Amazon ES) domains to support their business users’ search needs across products, orders, support documentation, and a growing suite of similar needs. The service has become heavily used across the organization. This led to some domains running at 100% capacity during peak times, while others began to run low on storage space. Because of this increased usage, the technical teams were in danger of missing their service level agreements. They contacted me for help.

This post shows how you can set up automated alarms to warn when domains need attention.

Solution overview

Amazon ES is a fully managed service that delivers Elasticsearch’s easy-to-use APIs and real-time analytics capabilities along with the availability, scalability, and security that production workloads require. The service offers built-in integrations with a number of other components and AWS services, enabling customers to go from raw data to actionable insights quickly and securely.

One of these other integrated services is Amazon CloudWatch. CloudWatch is a monitoring service for AWS Cloud resources and the applications that you run on AWS. You can use CloudWatch to collect and track metrics, collect and monitor log files, set alarms, and automatically react to changes in your AWS resources.

CloudWatch collects metrics for Amazon ES. You can use these metrics to monitor the state of your Amazon ES domains, and set alarms to notify you about high utilization of system resources. For more information, see Amazon Elasticsearch Service Metrics and Dimensions.

While the metrics are automatically collected, the missing piece is how to set alarms on these metrics at appropriate levels for each of your domains. This post includes sample Python code to evaluate the current state of your Amazon ES environment, and to set up alarms according to AWS recommendations and best practices.

There are two components to the sample solution:

es-check-cwalarms.py: This Python script checks the CloudWatch alarms that have been set, for all Amazon ES domains in a given account and region.
es-create-cwalarms.py: This Python script sets up a set of CloudWatch alarms for a single given domain.

The sample code can also be found in the amazon-es-check-cw-alarms GitHub repo. The scripts are easy to extend or combine, as described in the section “Extensions and Adaptations”.

Assessing the current state

The first script, es-check-cwalarms.py, is used to give an overview of the configurations and alarm settings for all the Amazon ES domains in the given region. The script takes the following parameters:

python es-checkcwalarms.py -h
usage: es-checkcwalarms.py [-h] [-e ESPREFIX] [-n NOTIFY] [-f FREE][-p PROFILE] [-r REGION]
Checks a set of recommended CloudWatch alarms for Amazon Elasticsearch Service domains (optionally, those beginning with a given prefix).
optional arguments:
  -h, --help   		show this help message and exit
  -e ESPREFIX, --esprefix ESPREFIX	Only check Amazon Elasticsearch Service domains that begin with this prefix.
  -n NOTIFY, --notify NOTIFY    List of CloudWatch alarm actions; e.g. ['arn:aws:sns:xxxx']
  -f FREE, --free FREE  Minimum free storage (MB) on which to alarm
  -p PROFILE, --profile PROFILE     IAM profile name to use
  -r REGION, --region REGION       AWS region for the domain. Default: us-east-1

The script first identifies all the domains in the given region (or, optionally, limits them to the subset that begins with a given prefix). It then starts running a set of checks against each one.

The script can be run from the command line or set up as a scheduled Lambda function. For example, for one customer, it was deemed appropriate to regularly run the script to check that alarms were correctly set for all domains. In addition, because configuration changes—cluster size increases to accommodate larger workloads being a common change—might require updates to alarms, this approach allowed the automatic identification of alarms no longer appropriately set as the domain configurations changed.

The output shown below is the output for one domain in my account.

Starting checks for Elasticsearch domain iotfleet , version is 53
Iotfleet Automated snapshot hour (UTC): 0
Iotfleet Instance configuration: 1 instances; type:m3.medium.elasticsearch
Iotfleet Instance storage definition is: 4 GB; free storage calced to: 819.2 MB
iotfleet Desired free storage set to (in MB): 819.2
iotfleet WARNING: Not using VPC Endpoint
iotfleet WARNING: Does not have Zone Awareness enabled
iotfleet WARNING: Instance count is ODD. Best practice is for an even number of data nodes and zone awareness.
iotfleet WARNING: Does not have Dedicated Masters.
iotfleet WARNING: Neither index nor search slow logs are enabled.
iotfleet WARNING: EBS not in use. Using instance storage only.
iotfleet Alarm ok; definition matches. Test-Elasticsearch-iotfleet-ClusterStatus.yellow-Alarm ClusterStatus.yellow
iotfleet Alarm ok; definition matches. Test-Elasticsearch-iotfleet-ClusterStatus.red-Alarm ClusterStatus.red
iotfleet Alarm ok; definition matches. Test-Elasticsearch-iotfleet-CPUUtilization-Alarm CPUUtilization
iotfleet Alarm ok; definition matches. Test-Elasticsearch-iotfleet-JVMMemoryPressure-Alarm JVMMemoryPressure
iotfleet WARNING: Missing alarm!! ('ClusterIndexWritesBlocked', 'Maximum', 60, 5, 'GreaterThanOrEqualToThreshold', 1.0)
iotfleet Alarm ok; definition matches. Test-Elasticsearch-iotfleet-AutomatedSnapshotFailure-Alarm AutomatedSnapshotFailure
iotfleet Alarm: Threshold does not match: Test-Elasticsearch-iotfleet-FreeStorageSpace-Alarm Should be:  819.2 ; is 3000.0

The output messages fall into the following categories:

System overview, Informational: The Amazon ES version and configuration, including instance type and number, storage, automated snapshot hour, etc.
Free storage: A calculation for the appropriate amount of free storage, based on the recommended 20% of total storage.
Warnings: best practices that are not being followed for this domain. (For more about this, read on.)
Alarms: An assessment of the CloudWatch alarms currently set for this domain, against a recommended set.

The script contains an array of recommended CloudWatch alarms, based on best practices for these metrics and statistics. Using the array allows alarm parameters (such as free space) to be updated within the code based on current domain statistics and configurations.

For a given domain, the script checks if each alarm has been set. If the alarm is set, it checks whether the values match those in the array esAlarms. In the output above, you can see three different situations being reported:

Alarm ok; definition matches. The alarm set for the domain matches the settings in the array.
Alarm: Threshold does not match. An alarm exists, but the threshold value at which the alarm is triggered does not match.
WARNING: Missing alarm!! The recommended alarm is missing.

All in all, the list above shows that this domain does not have a configuration that adheres to best practices, nor does it have all the recommended alarms.

Setting up alarms

Now that you know that the domains in their current state are missing critical alarms, you can correct the situation.

To demonstrate the script, set up a new domain named “ver”, in us-west-2. Specify 1 node, and a 10-GB EBS disk. Also, create an SNS topic in us-west-2 with a name of “sendnotification”, which sends you an email.

Run the second script, es-create-cwalarms.py, from the command line. This script creates (or updates) the desired CloudWatch alarms for the specified Amazon ES domain, “ver”.

python es-create-cwalarms.py -r us-west-2 -e test -c ver -n "['arn:aws:sns:us-west-2:xxxxxxxxxx:sendnotification']"
EBS enabled: True type: gp2 size (GB): 10 No Iops 10240  total storage (MB)
Desired free storage set to (in MB): 2048.0
Creating  Test-Elasticsearch-ver-ClusterStatus.yellow-Alarm
Creating  Test-Elasticsearch-ver-ClusterStatus.red-Alarm
Creating  Test-Elasticsearch-ver-CPUUtilization-Alarm
Creating  Test-Elasticsearch-ver-JVMMemoryPressure-Alarm
Creating  Test-Elasticsearch-ver-FreeStorageSpace-Alarm
Creating  Test-Elasticsearch-ver-ClusterIndexWritesBlocked-Alarm
Creating  Test-Elasticsearch-ver-AutomatedSnapshotFailure-Alarm
Successfully finished creating alarms!

As with the first script, this script contains an array of recommended CloudWatch alarms, based on best practices for these metrics and statistics. This approach allows you to add or modify alarms based on your use case (more on that below).

After running the script, navigate to Alarms on the CloudWatch console. You can see the set of alarms set up on your domain.

Because the “ver” domain has only a single node, cluster status is yellow, and that alarm is in an “ALARM” state. It’s already sent a notification that the alarm has been triggered.

What to do when an alarm triggers

After alarms are set up, you need to identify the correct action to take for each alarm, which depends on the alarm triggered. For ideas, guidance, and additional pointers to supporting documentation, see Get Started with Amazon Elasticsearch Service: Set CloudWatch Alarms on Key Metrics. For information about common errors and recovery actions to take, see Handling AWS Service Errors.

In most cases, the alarm triggers due to an increased workload. The likely action is to reconfigure the system to handle the increased workload, rather than reducing the incoming workload. Reconfiguring any backend store—a category of systems that includes Elasticsearch—is best performed when the system is quiescent or lightly loaded. Reconfigurations such as setting zone awareness or modifying the disk type cause Amazon ES to enter a “processing” state, potentially disrupting client access.

Other changes, such as increasing the number of data nodes, may cause Elasticsearch to begin moving shards, potentially impacting search performance on these shards while this is happening. These actions should be considered in the context of your production usage. For the same reason I also do not recommend running a script that resets all domains to match best practices.

Avoid the need to reconfigure during heavy workload by setting alarms at a level that allows a considered approach to making the needed changes. For example, if you identify that each weekly peak is increasing, you can reconfigure during a weekly quiet period.

While Elasticsearch can be reconfigured without being quiesced, it is not a best practice to automatically scale it up and down based on usage patterns. Unlike some other AWS services, I recommend against setting a CloudWatch action that automatically reconfigures the system when alarms are triggered.

There are other situations where the planned reconfiguration approach may not work, such as low or zero free disk space causing the domain to reject writes. If the business is dependent on the domain continuing to accept incoming writes and deleting data is not an option, the team may choose to reconfigure immediately.

Extensions and adaptations

You may wish to modify the best practices encoded in the scripts for your own environment or workloads. It’s always better to avoid situations where alerts are generated but routinely ignored. All alerts should trigger a review and one or more actions, either immediately or at a planned date. The following is a list of common situations where you may wish to set different alarms for different domains:

Dev/test vs. production
You may have a different set of configuration rules and alarms for your dev environment configurations than for test. For example, you may require zone awareness and dedicated masters for your production environment, but not for your development domains. Or, you may not have any alarms set in dev. For test environments that mirror your potential peak load, test to ensure that the alarms are appropriately triggered.
Differing workloads or SLAs for different domains
You may have one domain with a requirement for superfast search performance, and another domain with a heavy ingest load that tolerates slower search response. Your reaction to slow response for these two workloads is likely to be different, so perhaps the thresholds for these two domains should be set at a different level. In this case, you might add a “max CPU utilization” alarm at 100% for 1 minute for the fast search domain, while the other domain only triggers an alarm when the average has been higher than 60% for 5 minutes. You might also add a “free space” rule with a higher threshold to reflect the need for more space for the heavy ingest load if there is danger that it could fill the available disk quickly.
“Normal” alarms versus “emergency” alarms
If, for example, free disk space drops to 25% of total capacity, an alarm is triggered that indicates action should be taken as soon as possible, such as cleaning up old indexes or reconfiguring at the next quiet period for this domain. However, if free space drops below a critical level (20% free space), action must be taken immediately in order to prevent Amazon ES from setting the domain to read-only. Similarly, if the “ClusterIndexWritesBlocked” alarm triggers, the domain has already stopped accepting writes, so immediate action is needed. In this case, you may wish to set “laddered” alarms, where one threshold causes an alarm to be triggered to review the current workload for a planned reconfiguration, but a different threshold raises a “DefCon 3” alarm that immediate action is required.

The sample scripts provided here are a starting point, intended for you to adapt to your own environment and needs.

Running the scripts one time can identify how far your current state is from your desired state, and create an initial set of alarms. Regularly re-running these scripts can capture changes in your environment over time and adjusting your alarms for changes in your environment and configurations. One customer has set them up to run nightly, and to automatically create and update alarms to match their preferred settings.

Removing unwanted alarms

Each CloudWatch alarm costs approximately $0.10 per month. You can remove unwanted alarms in the CloudWatch console, under Alarms. If you set up a “ver” domain above, remember to remove it to avoid continuing charges.

Conclusion

Setting CloudWatch alarms appropriately for your Amazon ES domains can help you avoid suboptimal performance and allow you to respond to workload growth or configuration issues well before they become urgent. This post gives you a starting point for doing so. The additional sleep you’ll get knowing you don’t need to be concerned about Elasticsearch domain performance will allow you to focus on building creative solutions for your business and solving problems for your customers.

Enjoy!

Additional Reading

If you found this post useful, be sure to check out Analyzing Amazon Elasticsearch Service Slow Logs Using Amazon CloudWatch Logs Streaming and Kibana and Get Started with Amazon Elasticsearch Service: How Many Shards Do I Need?

About the Author

Dr. Veronika Megler is a senior consultant at Amazon Web Services. She works with our customers to implement innovative big data, AI and ML projects, helping them accelerate their time-to-value when using AWS.

HDD vs SSD: What Does the Future for Storage Hold?

2018-03-06 Roderick Bauer

Post Syndicated from Roderick Bauer original https://www.backblaze.com/blog/ssd-vs-hdd-future-of-storage/

This is part one of a series. Use the Join button above to receive notification of future posts on this and other topics.

Customers frequently ask us whether and when we plan to move our cloud backup and data storage to SSDs (Solid-State Drives). That’s not a surprising question considering the many advantages SSDs have over magnetic platter type drives, also known as HDDs (Hard-Disk Drives).

We’re a large user of HDDs in our data centers (currently 100,000 hard drives holding over 500 petabytes of data). We want to provide the best performance, reliability, and economy for our cloud backup and cloud storage services, so we continually evaluate which drives to use for operations and in our data centers. While we use SSDs for some applications, which we’ll describe below, there are reasons why HDDs will continue to be the primary drives of choice for us and other cloud providers for the foreseeable future.

HDDs vs SSDs

HDD vs SSD

The laptop computer I am writing this on has a single 512GB SSD, which has become a common feature in higher end laptops. The SSD’s advantages for a laptop are easy to understand: they are smaller than an HDD, faster, quieter, last longer, and are not susceptible to vibration and magnetic fields. They also have much lower latency and access times.

Today’s typical online price for a 2.5” 512GB SSD is $140 to $170. The typical online price for a 3.5” 512 GB HDD is $44 to $65. That’s a pretty significant difference in price, but since the SSD helps make the laptop lighter, enables it to be more resistant to the inevitable shocks and jolts it will experience in daily use, and adds of benefits of faster booting, faster waking from sleep, and faster launching of applications and handling of big files, the extra cost for the SSD in this case is worth it.

Some of these SSD advantages, chiefly speed, also will apply to a desktop computer, so desktops are increasingly outfitted with SSDs, particularly to hold the operating system, applications, and data that is accessed frequently. Replacing a boot drive with an SSD has become a popular upgrade option to breathe new life into a computer, especially one that seems to take forever to boot or is used for notoriously slow-loading applications such as Photoshop.

We covered upgrading your computer with an SSD in our blog post SSD 101: How to Upgrade Your Computer With An SSD.

Data centers are an entirely different kettle of fish. The primary concerns for data center storage are reliability, storage density, and cost. While SSDs are strong in the first two areas, it’s the third where they are not yet competitive. At Backblaze we adopt higher density HDDs as they become available — we’re currently using both 10TB and 12TB drives (among other capacities) in our data centers. Higher density drives provide greater storage density per Storage Pod and Vault and reduce our overhead cost through less required maintenance and lower total power requirements. Comparable SSDs in those sizes would cost roughly $1,000 per terabyte, considerably higher than the corresponding HDD. Simply put, SSDs are not yet in the price range to make their use economical for the benefits they provide, which is the reason why we expect to be using HDDs as our primary storage media for the foreseeable future.

What Are HDDs?

HDDs have been around over 60 years since IBM introduced them in 1956. The first disk drive was the size of a car, stored a mere 3.75 megabytes, and cost $300,000 in today’s dollars.

IBM 350 Disk Storage System — 3.75MB in 1956

The 350 Disk Storage System was a major component of the IBM 305 RAMAC (Random Access Method of Accounting and Control) system, which was introduced in September 1956. It consisted of 40 platters and a dual read/write head on a single arm that moved up and down the stack of magnetic disk platters.

The basic mechanism of an HDD remains unchanged since then, though it has undergone continual refinement. An HDD uses magnetism to store data on a rotating platter. A read/write head is affixed to an arm that floats above the spinning platter reading and writing data. The faster the platter spins, the faster an HDD can perform. Typical laptop drives today spin at either 5400 RPM (revolutions per minute) or 7200 RPM, though some server-based platters spin at even higher speeds.

Exploded drawing of a hard drive

The platters inside the drives are coated with a magnetically sensitive film consisting of tiny magnetic grains. Data is recorded when a magnetic write-head flies just above the spinning disk; the write head rapidly flips the magnetization of one magnetic region of grains so that its magnetic pole points up or down, to encode a 1 or a 0 in binary code. If all this sounds like an HDD is vulnerable to shocks and vibration, you’d be right. They also are vulnerable to magnets, which is one way to destroy the data on an HDD if you’re getting rid of it.

The major advantage of an HDD is that it can store lots of data cheaply. One and two terabyte (1,024 and 2,048 gigabytes) hard drives are not unusual for a laptop these days, and 10TB and 12TB drives are now available for desktops and servers. Densities and rotation speeds continue to grow. However, if you compare the cost of common HDDs vs SSDs for sale online, the SSDs are roughly 3-5x the cost per gigabyte. So if you want cheap storage and lots of it, using a standard hard drive is definitely the more economical way to go.

What are the best uses for HDDs?

Disk arrays (NAS, RAID, etc.) where high capacity is needed
Desktops when low cost is priority
Media storage (photos, videos, audio not currently being worked on)
Drives with extreme number of reads and writes

What Are SSDs?

SSDs go back almost as far as HDDs, with the first semiconductor storage device compatible with a hard drive interface introduced in 1978, the StorageTek 4305.

Storage Technology 4305 SSD

The StorageTek was an SSD aimed at the IBM mainframe compatible market. The STC 4305 was seven times faster than IBM’s popular 2305 HDD system (and also about half the price). It consisted of a cabinet full of charge-coupled devices and cost $400,000 for 45MB capacity with throughput speeds up to 1.5 MB/sec.

SSDs are based on a type of non-volatile memory called NAND (named for the Boolean operator “NOT AND,” and one of two main types of flash memory). Flash memory stores data in individual memory cells, which are made of floating-gate transistors. Though they are semiconductor-based memory, they retain their information when no power is applied to them — a feature that’s obviously a necessity for permanent data storage.

Samsung SSD 850 Pro

Compared to an HDD, SSDs have higher data-transfer rates, higher areal storage density, better reliability, and much lower latency and access times. For most users, it’s the speed of an SSD that primarily attracts them. When discussing the speed of drives, what we are referring to is the speed at which they can read and write data.

For HDDs, the speed at which the platters spin strongly determines the read/write times. When data on an HDD is accessed, the read/write head must physically move to the location where the data was encoded on a magnetic section on the platter. If the file being read was written sequentially to the disk, it will be read quickly. As more data is written to the disk, however, it’s likely that the file will be written across multiple sections, resulting in fragmentation of the data. Fragmented data takes longer to read with an HDD as the read head has to move to different areas of the platter(s) to completely read all the data requested.

Because SSDs have no moving parts, they can operate at speeds far above those of a typical HDD. Fragmentation is not an issue for SSDs. Files can be written anywhere with little impact on read/write times, resulting in read times far faster than any HDD, regardless of fragmentation.

Samsung SSD 850 Pro (back)

Due to the way data is written and read to the drive, however, SSD cells can wear out over time. SSD cells push electrons through a gate to set its state. This process wears on the cell and over time reduces its performance until the SSD wears out. This effect takes a long time and SSDs have mechanisms to minimize this effect, such as the TRIM command. Flash memory writes an entire block of storage no matter how few pages within the block are updated. This requires reading and caching the existing data, erasing the block and rewriting the block. If an empty block is available, a write operation is much faster. The TRIM command, which must be supported in both the OS and the SSD, enables the OS to inform the drive which blocks are no longer needed. It allows the drive to erase the blocks ahead of time in order to make empty blocks available for subsequent writes.

The effect of repeated reading and erasing on an SSD is cumulative and an SSD can slow down and even display errors with age. It’s more likely, however, that the system using the SSD will be discarded for obsolescence before the SSD begins to display read/write errors. Hard drives eventually wear out from constant use as well, since they use physical recording methods, so most users won’t base their selection of an HDD or SSD drive based on expected longevity.

SSD circuit board

Overall, SSDs are considered far more durable than HDDs due to a lack of mechanical parts. The moving mechanisms within an HDD are susceptible to not only wear and tear over time, but to damage due to movement or forceful contact. If one were to drop a laptop with an HDD, there is a high likelihood that all those moving parts will collide, resulting in potential data loss and even destructive physical damage that could kill the HDD outright. SSDs have no moving parts so, while they hold the risk of a potentially shorter life span due to high use, they can survive the rigors we impose upon our portable devices and laptops.

What are the best uses for SSDs?

Notebooks, laptops, where performance, lightweight, areal storage density, resistance to shock and general ruggedness are desirable
Boot drives holding operating system and applications, which will speed up booting and application launching
Working files (media that is being edited: photos, video, audio, etc.)
Swap drives where SSD will speed up disk paging
Cache drives
Database servers
Revitalizing an older computer. If you’ve got a computer that seems slow to start up and slow to load applications and files, updating the boot drive with an SSD could make it seem, if not new, at least as if it just came back refreshed from spending some time on the beach.

Stay Tuned for Part 2 of HDD vs SSD

That’s it for part 1. In our second part we’ll take a deeper look at the differences between HDDs and SSDs, how both HDD and SSD technologies are evolving, and how Backblaze takes advantage of SSDs in our operations and data centers.

Here’s a tip on finding all the posts tagged with SSD on our blog. Just follow https://www.backblaze.com/blog/tag/ssd/.

Don’t miss future posts on HDDs, SSDs, and other topics, including hard drive stats, cloud storage, and tips and tricks for backing up to the cloud. Use the Join button above to receive notification of future posts on our blog.

The post HDD vs SSD: What Does the Future for Storage Hold? appeared first on Backblaze Blog | Cloud Storage & Cloud Backup.

Spotify Emails Warning to ‘Pirates’ Using Hacked Apps

2018-03-05 Andy

Post Syndicated from Andy original https://torrentfreak.com/spotify-emails-warning-to-pirates-using-hacked-apps-180305/

Spotify is a fantastic music streaming service used by more than 159 million users around the world. Around 71m of those are premium subscibers according to figures released by the company last December.

Given the above, 88 million Spotify members are using the free tier, meaning that they’re subjected to advertising and other limitations such as shuffle-only play and track skip restrictions.

The idea is that the free user gets a decent level of service but is held back just enough with small irritations to make the jump to a premium subscription a logical step at some point.

What millions of free users don’t know, however, is that there are modified Spotify apps out there that can remove many of these restrictions. All the user has to do is sign up to free Spotify account, download one of the many ‘hacked’ Spotify installation files out there, put in their username and password, and enjoy.

How many people use these hacked versions of Spotify isn’t clear and up to now, it’s been somewhat of a mystery as to why Spotify itself hasn’t done something about them. During the past few days, however, there have been signs that a crackdown could be on the way.

In an email sent to an unknown but significant number of people, Spotify informs users of modified apps that they’re on the company’s radar and there could be consequences for trying to subvert the system.

“We detected abnormal activity on the app you are using so we have disabled it. Don’t worry – your Spotify account is safe,” the email from Spotify reads.

“To access your Spotify account, simply uninstall any unauthorized or modified version of Spotify and download and install the Spotify app from the official Google Play Store. If you need more help, please see our support article on Reinstalling Spotify.”

Users have been popping up on Spotify’s forums asking why they’ve received this email. Some seem to think they’ve done nothing wrong but most signs point to people using modified software.

The warning email from Spotify

While the email signs off with a note thanking the recipient for being a Spotify user, there is also a warning.

“If we detect repeated use of unauthorized apps in violation of our terms, we reserve all rights, including suspending or terminating your account,” Spotify writes.

For people who used their real accounts along with modified apps this could be a problem but many people using hacked versions go in prepared with a secondary or temporary email address and false details.

Quite how far Spotify will go to rid its service of this kind of a user remains unknown but at least for now, the actual effects of this early crackdown seemed mixed.

TorrentFreak has spoken with users who have modified versions and have received the email, yet their installation still works just fine. Others report that they can no longer log in with their modified version.

What is clear, however, is that Spotify has both modified apps and their creators on its radar. On March 1, 2018 the company wrote to Github demanding that a popular Spotify mod known as ‘Dogfood’ be taken down from the repository.

Dogfood is done on Github

The full takedown notice can be found here. It lists Dogfood itself plus a whole bunch of ‘forks’ which have also been taken down by Github.

There were signs in January that the developer of Dogfood might have been under pressure to limit the effectiveness of his app. On January 18 he announced on XDA that some functionality would be removed moving forward.

“In order to comply with XDA’s Rules and CoC, Spotify Dogfood has taken a new direction, and now offers *exclusively* Ad-free music playback,” he wrote.

“Any other features won’t be included anymore in this mod. But, that doesn’t mean anything if you’re a true, a core user of this app, because there will still be regular updates to it, as there has been up until now.”

Where that development will take place now isn’t clear but it clearly won’t be on Github. Indeed, even XDA has been targeted by Spotify, with the site receiving a DMCA notice from the company which required the removal of links and an apparent closure of the whole discussion.

XDA DMCA takedown

For now it seems that Spotify is playing nice, at least with users of modified apps. Whether it will continue with the same relaxed attitude is unclear but it’s hard not to connect the move with its intention to go public and its $23bn valuation.

Still, the company should be more in tune with pirates than most given its history, so may yet have a decent plan up its sleeve.

Source: TF, for the latest info on copyright, file-sharing, torrent sites and more. We also have VPN discounts, offers and coupons

Which VPN Services Keep You Anonymous in 2018?

2018-03-04 Ernesto

Post Syndicated from Ernesto original https://torrentfreak.com/vpn-services-keep-anonymous-2018/

Using a VPN service is a great way to protect your privacy online.

However, not all VPN services are as private as you might think. In fact, some are known to keep extensive logs that can easily identify specific users on their network.

This is the main reason why we publish a yearly VPN review, asking providers about their respective logging policies as well as other security and privacy aspects.

It’s worth keeping in mind though that not all VPN protocols and encryption algorithms are equally secure. PPTP is known to be vulnerable for example, and pre-shared keys are also a risk. We ask all VPN providers what their best recommendation is, but we encourage readers to fully research all options.

This year’s questions are as follows:

1. Do you keep ANY logs which would allow you to match an IP-address and a time stamp to a user of your service? If so, exactly what information do you hold and for how long?

2. What is the name under which your company is incorporated, and under which jurisdiction does your company operate?

3. What tools are used to monitor and mitigate abuse of your service, including limits of concurrent connections if these are enforced?

4. Do you use any external email providers (e.g. Google Apps), analytics, or support tools ( e.g Live support, Zendesk) that hold information provided by users?

5. In the event you receive a DMCA takedown notice or a non-US equivalent, how are these handled?

6. What steps are taken when a court orders your company to identify an active or past user of your service? How would your company respond to a court order that requires you to log activity going forward? Has any of this ever happened?

7. Is BitTorrent and other file-sharing traffic allowed on all servers? If not, why?

8. Which payment systems/providers do you use? Do you take any measures to ensure that payment details can’t be linked to account usage or IP-assignments?

9. What is the most secure VPN connection and encryption algorithm you would recommend to your users?

10. Do you provide tools such as “kill switches” if a connection drops and DNS leak protection?

11. Do you have physical control over your VPN servers and network or are they outsourced and hosted by a third party (if so, which ones)? Do you use your own DNS servers? (if not, which servers do you use?)

12. What countries are your servers physically located? Do you offer virtual locations?

—-

Below is the list of responses from the VPN services in their own words. These are not endorsements and trust is crucial. Providers which didn’t answer our questions directly, blocked certain traffic, or are logging extensively were excluded. We specifically chose to leave room for detailed answers where needed. The order of the list holds no value.

—

Private Internet Access

1. We do not store any logs relating to traffic, session, DNS or metadata. We do not keep any logs for any person or entity to match an IP address and a timestamp to a user of our service. In other words, we do not log, period. Privacy is our policy.

2. Private Internet Access is operated by London Trust Media, Inc., with branches in the US and Iceland, which are a few of the countries that still respect privacy and do not have a mandatory data retention policy.

3. We have an active, proprietary system in place to help mitigate abuse.

4. At the moment we are using Google Apps Suite and Zendesk. However, we are in the process of migrating our support to Deskpro, an in-house self-hosted solution.

5. We do not monitor our users, and we keep no logs, period. That said, we do have an active, proprietary system in place to help mitigate abuse.

6. Every court order is scrutinized to the highest extent for compliance with both the “spirit” and “letter of the law.” We do periodically receive subpoenas from law enforcement agencies that we scrutinize for compliance and respond accordingly. This is all driven based upon our commitment to privacy. All this being said, we do not log and do not have any data on our customers other than their signup e-mail and account username.

7. Yes, BitTorrent and file-sharing traffic are allowed and treated equally to all other traffic (although it’s routed through a second VPN in some cases). We do not censor our traffic because we believe in an open internet, period.

8. We utilize a variety of payment systems, including, but not limited to: PayPal, Credit Card (with Stripe), Amazon, Google, Bitcoin, Bitcoin Cash, Zcash, CashU, PaymentWall, and any major store-bought gift card and OKPay. Payment data is not linked nor linkable to user activity do to our no logs policy.

9. At the moment, the most secure and practical VPN connection and encryption algorithm that we recommend to our users would be our cipher suite of AES-256 + RSA4096 + SHA256.

10. Yes, our users gain access to a plethora of additional tools, including but not limited to:

(a) Kill Switch: Ensures that traffic is routed through the VPN such that if the VPN connection is unexpectedly terminated, the traffic will not route.
(b) IPv6 Leak Protection: Protects clients from websites which may include IPv6 embeds, which could lead to IPv6 IP information coming out.
(c) DNS Leak Protection: This is built-in and ensures that DNS requests are made through the VPN on a safe, private, no-log DNS daemon.
(d) Shared IP System: We mix clients’ traffic with many other clients’ traffic through the use of an anonymous shared-IP system ensuring that our users blend in with the crowd.
(e) MACE™: Protects users from malware, trackers, and ads.

11. We utilize our own bare metal servers in third-party data centers that are operated by trusted friends and, now, business partners whom we have met and on which we have completed serious due diligence. Our servers are located in facilities including 100TB, Choopa, Leaseweb, among others.

We also operate our own DNS servers on our high throughput network. These servers are private and do not log.

12. As of the beginning of 2018, we operate 3172 servers across 43 locations in 28 countries. For more information on what countries are available, please visit our network information page. All of our locations are physical and not virtualized.

Private Internet Access website

NordVPN

1. We do not keep any logs nor timestamps that could allow our customers to be identified.

2. The registered company name is Tefincom co S.A., and it operates under the jurisdiction of Panama.

3.We have developed and implemented an automated tool that limits the maximum number of connections to six devices. We do not use any other tools.

4. We use Google Analytics and third-party ticket/live chat tools (Zendesk/Zopim). Google Analytics is used to improve our website and provide our users with the most relevant information. The ticket/live chat tool is used to provide the best support in the industry (available 24/7), but not tracking our users by any means.

5. We operate under Panama’s jurisdiction, where DMCA and similar orders have no legal bearing. Therefore, they do not apply to us.

6. If the order or subpoena is issued by a Panamanian court, we would have to provide the information if we had any. However, our zero-log policy means that we don’t have any information about our users’ online activity. So far, we haven’t had any such cases.

7. Yes, we allow P2P traffic. We have optimized a number of our servers specifically for file-sharing; this way, we ensure that other servers, which are meant for streaming and other purposes, have uninterrupted speeds.

8. Our customers are able to pay via credit card, PayPal and Bitcoin. Our payment processing partners collect basic billing information for payment processing and refund requests, but it cannot be related to any Internet activity of a particular customer. Bitcoin is the most anonymous option, as it does not link the payment details with the user identity or other personal information.

9. The ciphers we use along with the OpenVPN and IKEv2/IPSec protocols have never been cracked. Therefore, both of these protocols are highly secure. For OpenVPN connection, we use the AES 256 CBC algorithm. IKEv2/IPSec ciphers used to generate Phase1 keys are AES-256-GCM for encryption, coupled with SHA2-384 to ensure integrity, combined with PFS (Perfect Forward Secrecy) using 3072-bit Diffie Hellmann keys.

10. Yes, we do provide both an automatic kill switch and a feature for DNS leak protection.

11. We use a hybrid model, whereby we control some of our servers but also partner with premium data centers with strong security practices. Due to our special server configuration, no one is able to collect or retain any data, ensuring compliance with our no-logs policy. We also have specific requirements for network providers to ensure highest service quality for our customers. We do have our own DNS servers, and all DNS requests go through those.

12. All of our servers are dedicated and located in the same countries we state they are – we do not offer virtual locations. At the moment, NordVPN provides more than 3000 servers in 59 countries. Full location list can be found at nordvpn.com/servers.

NordVPN website

ExpressVPN

1. No, ExpressVPN doesn’t keep any connection or activity logs, including never logging browsing history, data contents, DNS requests, timestamps, source IPs, outgoing IPs, or destination IPs. This ensures that we cannot ascertain whether a given user was connected to the VPN at a certain time, assumed a particular outgoing IP address, or generated any specific network activity. It is not possible to match a user to data points that we never possess.

2. Express VPN International Ltd. is a BVI (British Virgin Islands) company. Being under BVI jurisdiction helps to protect user privacy, as the BVI has no data retention laws, is not party to any 14 Eyes intelligence sharing agreements, and has a dual criminality provision that safeguards against legal overreach.

3. To protect our customers’ privacy, we do not monitor or log any user activity on our network. We do however reserve the right to block specific abusive traffic to protect the server network and other ExpressVPN customers. With regards to limits on the number of devices simultaneously connected, no timestamps or IP addresses are ever logged; our systems are merely able to identify how many active sessions a given license has at a given moment in time and use that counter to decide whether a license is allowed to create one additional session. This counter is temporary and is not tracked over time.

4. We use Zendesk for support tickets and SnapEngage for live chat support; we have assessed the security profiles of both and consider them to be secure platforms. We use Google Analytics and cookies to collect marketing metrics for our website and several externals tools for collecting crash reports (a setting that can be switched off in any of our apps). ExpressVPN is committed to protecting the privacy of our users, and our practices are discussed in detail in our comprehensive Privacy Policy.

5. As we do not keep any data or logs that could link specific activity to a given user, ExpressVPN does not identify or report users as a result of DMCA notices. User privacy and anonymity are always preserved.

6. Legally our company is only bound to respect subpoenas and court orders when they originate from the British Virgin Islands government or in conjunction with BVI authorities via a mutual legal assistance treaty. As a general rule, we reply to law enforcement inquiries by informing the investigator that we do not possess any data that could link activity or IP addresses to a specific user. Regarding a demand that we log activity going forward: Were BVI law enforcement ever to make such a request, we would refuse to re-engineer our systems in a way that infringes on the privacy protections that our customers trust us to uphold.

7. We do not believe in restricting or censoring any type of traffic. ExpressVPN allows all traffic, including BitTorrent and other file-sharing traffic (without re-routing), from all of our VPN servers.

8. ExpressVPN accepts all major credit cards, PayPal, and a large number of local payment options. We also accept Bitcoin, which we recommend for those who seek maximum privacy with relation to their form of payment. As we do not log user activity, IP addresses, or timestamps, there is no way for ExpressVPN or any external party to link payment details entered on our website with any VPN activities.

9. ExpressVPN apps generally default to our recommended protocol for security and performance: OpenVPN UDP. Our apps use a 4096-bit CA, AES-256-CBC encryption, TLSv1.2, and SHA512 signatures to authenticate our servers.

10. Yes, ExpressVPN protects users from privacy and security leaks in a number of ways (for more info about leak protection, see our Privacy Research Lab). Our “Network Lock” feature, which is turned on by default, prevents all types of traffic including IPv4, IPv6, and DNS from leaking outside of the VPN, such as when your internet connection drops or in various additional scenarios where other VPNs might leak.

11. Our VPN servers are hosted in trusted data centers with strong security practices. The data center employees do not have server credentials, and the server disks are fully encrypted to mitigate risks from physical seizure. Our policy of not collecting activity or connection logs also means that servers do not contain any data that could map users to specific activity.

We run our own logless DNS on every server, meaning no personally identifiable data is ever stored. We do not use third-party DNS.

12. ExpressVPN has over 2,000 servers covering 94 countries. For more than 97% of these servers, the physical server and the associated IP addresses are located in the same country — a physical footprint covering every continent save Antarctica, ensuring there are server locations near all users.

For countries where it is difficult to find servers that meet ExpressVPN’s rigorous standards for server security, reliability, and speed, we use virtual locations to still make it possible for users to assume IP addresses from those countries. These locations represent less than 3% of ExpressVPN’s server count, and the specific countries are published on our website here.

ExpressVPN website

Ipredator

1. No logs are retained that would allow the correlation of the user’s IP address to a VPN address. The session database does not include the origin IP address of the user. Once a connection has been terminated the session information is deleted from the session database.

2. The name of the company is PrivActually Ltd which operates out of Cyprus.

3. Real abuse is mitigated by meatware [humans]. User traffic is not monitored or inspected in any way. TCP/IP sessions are not limited individually, but by server, to 10 million established connections. Packet floods are dealt with by using adaptive packet rate limiters at the switch port level and kick in at 90k pps. The number of concurrent connections is limited by the VPN backend software.

4. There is no visitor tracking mechanism, not even passive ones analyzing the web server logs. IPredator runs its own mail infrastructure and does not use third party products like GMail. Neither do we use data hogs like a ticket system to manage support requests. IPredator sticks to a simple mail system and deletes old data after three months from the mailboxes.

5. Requests are evaluated according to the legal frameworks set forth in the jurisdictions the service operates in and we react accordingly. After receiving a request its validity is verified. DMCA takedown abuse using fake credentials seems to be all the rage these days.

6. A canary is maintained to indicate the current legal state of affairs. In case of a court order that forces us to enable log activity we would rather shut down the service than comply.

7. BitTorrent and other file-sharing traffic is allowed.

8. PayPal, Bitcoins, Payza, and Payson are fully integrated. Other payment methods are available on request. An internal transaction ID is used to link payments to the payment processor. We do not store any other data about payments associated with the user’s account. The systems dealing with payments have no connection to the part of the infrastructure that handles VPN connections. Frontend proxies are used to make sure user IP addresses do not show up in any of the backend systems.

9. IPredator provides config files for various platforms and clients that enforce TLS1.2 on supported systems. Ideally, the client negotiates ECDHE-RSA-AES256-GCM as a suite for the control and AES256 for the data channel. For further protection, detailed setup instructions and howtos are provided to our users.

10. Netsplice, IPredator’s cross-platform VPN client, has native support for various types of kill switches. You can kill a program, just put it to sleep, shutdown your machine or wipe your hard disk … it is up to you. Users can use this page to check for a number of leaks, not just DNS leaks.

11. We own every server, switch, and cable we use to provide the VPN service up to our uplink network. The machines are located in Sweden due to the laws that allow us to run our service in a privacy-protecting manner. If the situation should change we are able to move operations to a different country. The core for any privacy service is trust in the integrity of the underlying infrastructure. Everything else has to build upon that, which includes the DNS servers.

12. Sweden.

Ipredator website

TorGuard

1. No logs or timestamps are kept whatsoever. TorGuard does not store any traffic logs or user session data on our network. In addition to a strict no logging policy we run a default shared IP configuration across all servers. Because there are no logs kept and multiple users sharing a single IP address, it is not possible to match any user with an IP and time stamp.

2. TorGuard is owned and operated by VPNetworks LLC under US jurisdiction, with our parent company VPNetworks LTD, LLC based in Nevis.

3. We utilize a number of highly customized scripts to monitor network performance and limit simultaneous connections through a radius-based authentication server.

4. We use anonymized Google Analytics data to optimize our website and Sendgrid for transactional email. TorGuard’s 24/7 live chat services are provided through Livechatinc’s platform. Customer support desk requests are maintained by TorGuard’s own private ticketing system.

5. In the event a valid DMCA notice is received it is immediately processed by our abuse team. Due to our no log and no time stamp policy and shared IP network – we are unable to forward any requests to a single user.

6. If a court order is received, it is first handled by our legal team and examined for validity in our jurisdiction. Should it be deemed valid, our legal representation would be forced to further explain the nature of our shared IP network configuration and the fact that we do not hold any identifying logs or time stamps. TorGuard’s network was designed to operate with minimum server resources and is not physically capable of retaining such logs. There is no on/off switch to log activity so it would be impossible to comply with such a request. No, this has never happened.

7. Yes, BitTorrent and all P2P traffic is allowed. By default we do not block, re-route, or limit any types of traffic across our network.

8. We currently offer over 200 different payment options. This includes all forms of credit card, PayPal, Bitcoin, cryptocurrency (e.g. Litecoin, Ethereum, Monero + many more), Alipay, WeChat Pay, UnionPay, 100+ Gift Card brands, and many other worldwide local payment options. No user can be linked back to account usage or IP assignments because we maintain zero logs across our network.

9. For best security, we advise clients to use OpenVPN and select the cipher option AES-256-GCM, with 4096bit RSA and SHA512 HMAC. We use TLS 1.2 on all servers with perfect forward secrecy enabled. For faster speeds and “obfuscated” Stealth VPN access, we suggest using OpenConnect SSL VPN with cipher option AES-256-GCM. TorGuard offers a wide range of VPN protocols, including OpenVPN, iKEV2, IPsec, SSTP, OpenConnect/AnyConnect, Stunnel, and Shadowsocks.

10. TorGuard’s VPN software provides strict security features by automatically disabling IPv6 and blocking any potential DNS or WebRTC leaks. We offer a full connection kill-switch that safeguards your VPN traffic against accidental disconnects and can hard kill your interfaces if needed, and an application kill-switch that can terminate specific apps if the VPN connection is interrupted for additional safety.

11. We retain full physical control over all hardware and only seek partnerships with data centers who can meet our strict security criteria. All servers are deployed and managed exclusively by TorGuard staff. By default, the TorGuard VPN app uses private no log DNS on each VPN endpoint. The TG also app allows clients to modify their VPN session with a custom DNS entry of their choosing.

12. TorGuard currently maintains thousands of servers in over 55 countries around the world, and we continue to expand the network each month. All servers are physically located in the stated country of origin and we do not use any virtual locations.

TorGuard website

AzireVPN

1. No, we do not record or store any logs related to our services. No traffic, user activity, timestamps, IP addresses, number of active and total sessions, DNS requests, or any other kind of logs are stored. System logs are disabled. Anonymity of our users is very important to us as described in our Terms of Service.

2. The registered company name is Netbouncer AB and we operate under Swedish jurisdiction where there are no data retention laws that apply to VPN providers.

3. Our servers are running using Blind Operator mode which means we took extra security steps to ensure that we cannot monitor any traffic at all. Abuses like incoming DDoS attacks are usually mitigated with UDP filtering on the source port used by an attacker.

4. No, we do not rely on and refuse to use external third-party systems. We run our own email infrastructure and encourage people to use PGP encryption. Ticketing support system, website analytics (Piwik, with anonymization settings) and other tools are hosted in-house on open-source software. We have plans to replace some of these tools by solutions developed by ourselves.

5. We politely inform the sender party that we do not keep any logs and are unable to identify a user.

6. In the case that a valid court order is issued, we will inform the other party that we are unable to identify an active user or past user of our service while running as a Blind Operator, which is preventing live analysis of traffic. In that case, they would probably force us to handover physical access to the server, which is fine since they would have to reboot to gain any kind of access, and since we are running diskless in RAM – all data will be lost. So far, we have never received any court order and no personal information has ever been given away.

7. Yes, BitTorrent, peer-to-peer and file-sharing traffic is allowed and treated equally to any other traffic on all of our locations. We strongly believe in net neutrality.

8. As of now, we propose a variety of payments options including anonymous methods such as Bitcoin, Bitcoin Cash, Litecoin, Monero, Ethereum and some other cryptocurrencies (through CoinPayments) and cash money via postal mail. We also offer PayPal, credit cards (VISA, MasterCard and American Express through Paymentwall) and Swish. We do not store sensitive payment information on our servers, we only retain an internal reference code for order confirmation.

9. We recommend our users to use our new WireGuard servers available on Linux, some routers (LEDE/OpenWRT), and soon on Android.
– Data channel cipher: CHACHA20 with POLY1305 for authentication and data integrity
– Authenticated key exchange: Noise Protocol Framework’s Noise_IKpsk2, using Curve25519, Blake2s, and CHACHA20-POLY1305, a formally verified
construction.

Otherwise, we recommend OpenVPN with default configuration available in UDP and TCP modes. These settings offer the highest grade of security achieved through OpenVPN on all of our servers:
– Data channel cipher: AES-256-GCM (OpenVPN 2.4) or AES-256-CBC with HMAC-512 for authentication and data integrity (OpenVPN 2.3)
– Control channel cipher: TLS v1.2 using TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 (AEAD)
– Authenticated key exchange: Diffie-Hellman method and Perfect Forward Secrecy (DHE) using a RSA key with a 4096 bit key size, re-keying every 120 minutes (can be lowered)
– Additional auth key: RSA with a 2048 bit key size
– Additional crypt key: RSA with a 2048 bit key size

10. We offer a new custom open-source VPN application called azclient, for all desktop platforms (Windows, macOS and Linux), with source code released on Github under the GPLv2 license, currently supporting OpenVPN. Our client is developed by a security expert and designed with ease of installation and use in mind, allowing users to connect to the VPN servers with only a few clicks. We plan to add a kill switch and DNS leak protection features to the client in the future.

11. We physically own all of our hardware, in all of our locations, including bare metal dedicated servers and switches, co-located in closed racks on different data centers around the world meeting our strict security criteria, using network dedicated links and carefully chosen providers for maximum network quality and throughput. We host our own non-logging DNS servers in different locations and provide DNSCrypt support for DNS requests encryption.

12. As of now, we operate across five locations including Canada, Spain, Sweden, United Kingdom and the United States. Moldova is planned later this
year, as indicated on our roadmap. There are no virtual locations.

AzireVPN website

HideIPVPN

1. Currently, we store no logs related to any IP address. There is no way for any third-party to match a user IP to any specific activity on the internet.

2. Registered name of the company is Server Management LLC and we operate under US jurisdiction.

3. A single subscription can be used simultaneously for three connections. Abuses of service usually means using non-P2P servers for torrents or DMCA notices. Also, our no-log policy makes it impossible to track who downloaded/uploaded any data from the internet using our VPN. We use iptables plugin to block P2P traffic on servers where P2P is not explicitly allowed. We block outgoing mail on port 25 to prevent spamming activity.

4. We use live chat provided by tawk.to and Google Apps for incoming email. For outgoing email we use our own SMTP server.

5. Since no information is stored on any of our servers there is nothing that we can take down. We reply to the datacenter or copyright holder that we do not log our users’ traffic and we use shared IP-addresses, which makes it impossible to track who downloaded any data from the internet using our VPN.

6. HideIPVPN may disclose information, including but not limited to, information concerning a client, in order to comply with a court order, subpoena, summons, discovery request, warrant, statute, regulation, or governmental request. But due to the fact that we have a no-logs policy and we use Shared IPs, there won’t be anything to disclose excepting billing details. This has never happened before.

7. This type of traffic is welcomed on our German (DE VPN), Dutch (NL VPN), Luxembourg (LU VPN) and Lithuanian (LT VPN) servers. It is not allowed on US, UK, Canada, Poland, Singapore and French servers as stated in our TOS – the reason for this is our agreements with data centers. We also have specific VPN plan for torrents.

8. Currently, HideIPVPN accepts following methods: PayPal, Bitcoin, Credit & Debit cards, JCB, American Express, Diners Club International, Discover. All our clients billing details are stored in WHMCS billing system.

9. SoftEther VPN protocol looks very promising and secure. Users can currently use our VPN applications on Windows and OSX systems.

10. Yes, our free VPN apps have both features built in.

11. We don’t have physical control on our VPN servers. Servers are outsourced in premium data-center with high-quality tier1 networks.

12. At the moment we have VPN servers located in 10 countries – US, UK, Netherlands, Germany, Luxembourg, Lithuania, Canada, Poland, France and Singapore. As you can see number of available locations is steadily growing.

HideIPVPN website

Hide.me

1. No, we don’t keep any logs. We have developed our system with an eye on our customers’ privacy, so we created a distributed VPN cluster with independent public nodes that do not store any customer data or logs at all.

2. Hide.me VPN is operated by eVenture Limited and based in Malaysia with no legal obligation to store any user logs at all.

3. We do not limit or monitor individual connections. To mitigate abuse we deploy general firewall rules on some servers that apply to specific IP ranges. By design, one username can only establish one simultaneous connection.

4. Our landing pages, which are solely used for advertising purposes, include a limited amount of third-party tracking scripts, namely Google Analytics. However, no personal information that could be linked with the VPN usage is shared with these providers. We do not send information that could compromise someone’s security over email.

5. Since we don’t store any logs and/or host copyright infringing material on our services, we’ll reply to these notices accordingly.

6. Although it has never happened, in such a scenario, we won’t be able to entertain the court orders because our infrastructure is built in a way that it does not store any logs and there is no way we could link any particular cyber activity to any particular user. In case we are forced to store user logs, we would prefer to close down rather than putting our users at stake who have put their trust in us.

7. There is no effective way of blocking file-sharing traffic without monitoring our customers which is against our principles and would be even illegal. Usually, we only recommend our customers to avoid the US & UK locations for file-sharing but it is on a self-regulatory basis since these countries have strong anti-copyright laws in place.

8. We support a wide range of popular payment methods, including all major cryptocurrencies like Bitcoin, Litecoin, Ethereum, Dash, Monero, PayPal, Credit Cards and Bank transfer. All payments are handled by external payment providers and are linked to a temporary payment ID. This temporary payment ID can’t be connected to the user’s VPN account/activity. After the payment is completed, the temporary payment ID will be permanently removed from the database.

9. After all, modern VPN protocols that we all support – like IKEv2, OpenVPN and SSTP – are considered secure even after the NSA leaks. We follow cryptographic standards and configured our VPN servers accordingly in order to support a secure key exchange with 8192-bit key size and a strong symmetric encryption (AES-256) for the data transfer.

10. Our users’ privacy is of utmost concern to us. Our Windows client has the features such as Kill Switch, Auto Connect, Auto Reconnect etc which makes sure that the user is always encrypted and anonymous.

11. We operate our own non-logging DNS-servers to protect our customers from DNS hijacking and similar attacks. We operate 30+ server locations in 27 different countries. However we do not own physical hardware. There is intrusion detection and other various security measures in place to ensure the integrity and security of all our single servers. Furthermore, we choose all third-party hosting providers very carefully, so we can assure that there are certain security standards in place (ISO 27001) and no unauthorized person can access our servers. Among our reputable partners are Leaseweb, NFOrce, Equinix and Softlayer.

12. Our servers are located in countries all over the world, among the most popular ones are Canada, Netherlands, Singapore, Germany, Brazil, Mexico and Australia. Below is the complete list of countries, alternatively you can view all available locations here.

Hide.me website

IVPN

1. No, not doing so is fundamental to any privacy service regardless of the security or policies implemented to protect the log data. In addition, it is not within our interest to do so as it would increase our liability and is not required by the laws of any jurisdiction that IVPN operates in.

2. Privatus Limited, Gibraltar.

3. We use a few custom scripts (based on PSAD) to proactively detect and alert malicious activity. From a management perspective, we monitor our network using Zabbix. In the almost 10 years we’ve been operating its safe to say we’ve seen almost everything.

4. No. We made a strategic decision from day one that no company or customer data would ever be stored on 3rd party systems. All our internal services run on our own dedicated servers that we setup, configure and manage. No 3rd parties have access to our servers or data.

5. Our legal department sends a reply stating that we do not store content on our servers and that our VPN servers act only as a conduit for data. In addition, we inform them that we never store the IP addresses of customers connected to our network nor are we legally required to do so.

6. Firstly, this has never happened. However, if asked to identify a customer based on a timestamp and/or IP address then we would reply factually that we do not store this information. If legally compelled to log activity going forward we would do everything in our power to alert the relevant customers directly (or indirectly through our warrant canary).

7. Yes, all file-sharing traffic is permitted and treated equally on all servers. We do encourage customers to use non-USA based exit servers for P2P as any company receiving a large number of DMCA notices is exposing themselves to legal action and our upstream providers have threatened to disconnect our servers in the past.

8. We accept Bitcoin, Cash, PayPal and credit cards. When using cash there is no link to a user account within our system. When using Bitcoin, we store the Bitcoin transaction ID in our system. If you wish to remain anonymous to IVPN you should take the necessary precautions when purchasing Bitcoin. When paying with PayPal or a credit card a token is stored that is used to process recurring payments but this is not linked in anyway to account usage or IP-assignments.

9. We provide RSA-4096 / AES-256-GCM with OpenVPN, which we believe is more than secure enough for our customers’ needs.

10. Yes, the IVPN client offers an advanced VPN firewall that blocks every type of IP leak possible including IPv6, DNS, network failures, WebRTC STUN etc.

11. We use bare metal dedicated servers leased from 3rd party data centers in each country where we have a presence. We install each server using our own custom images and employ full disk encryption to ensure that if a server is ever seized the data is worthless. We also operate an exclusive multi-hop network allowing customers to choose an entry and exit server in different jurisdictions which would make the task of legally gaining access to servers at the same time significantly more difficult. We operate our own network of log free DNS servers that are only accessible to our customers.

12. Please see https://www.ivpn.net/server-locations. We do not offer virtual locations.

IVPN website

Windscribe

1. We don’t keep any logs that can match a user to an IP and timestamp.

2. Windscribe Limited, Ontario (Canada) Corporation.

3. We store the total amount of bytes transferred in a 30 day period. This counter gets reset monthly and there is no historical usage. We block SMTP port 25 to prevent email spamming.

4. Everything is self-hosted including but not limited to email, support desk, and live chat.

5. We notify the sender that the IP address is a VPN node and is shared by hundreds of people at any given moment, so there is no way to trace the activity to any single user.

6. We received multiple subpoenas and court orders requesting subscriber information. Our response was identical to what we send in case of a DMCA related request in every case. We were never ordered to log users (although there were requests), but since we’re in Canada which has no mandatory data retention directives that apply to VPNs, we wouldn’t need to comply.

7. BitTorrent is allowed in all locations as we don’t interfere with the traffic. We request that users don’t do it in Japan and India due to more stringent providers in those regions, but it’s more of a guideline than a rule.

8. Credit cards (Stripe), PayPal, all major cryptocurrencies and various gift cards. As we store no logs of this type, there is nothing to link the payments to.

9. We support OpenVPN and IKEv2. Both are equally secure as we use the strongest encryption possible (GCM-AES-256) with both. We recommend trying IKEv2 first, as it’s faster almost in all cases. If it’s blocked on your network, then you can use OpenVPN which operates on common ports and is a lot harder to block, especially when using Stealth (Stunnel) mode. Our application tries all the protocols automatically and uses the best one for your specific network.

10. Windscribe Firewall is built into our Windows and Mac applications. It blocks all connectivity outside of the tunnel to ensure there is zero chance of any kind of leak, including but not limited to DNS leaks, IPv6 leaks, WebRTC leaks, etc.

A firewall blocks ALL connectivity outside of the tunnel. If the VPN connection drops, there is nothing that needs to be done, and not a single packet can leave the machine, since the firewall will not allow it. In geek terms, it fails closed.

11. All our servers are bare metal machines which are leased from various reputable hosting providers worldwide. As we have servers in over 100 different data-centers, listing them here would create a fairly lengthy list.

Each VPN node we operate has a recursive DNS server running on it, which is only accessible over the tunnel as it listens exclusively on a LAN IP address.

12. We have servers in 50 countries and over 100 cities. The full list is shown here. All our servers are physically where they are claimed to be, as we don’t have any fake/virtual locations.

Windscribe website

VPNBaron

1. We do not keep traffic logs that match an IP address with a user. We do monitor the number of active connections for the user in order to prevent unlimited connections from one subscription.

2. Our registered legal name is Hexville SRL. We’re under Romanian jurisdiction, inside of the European Union.

3. Our tools are developed in-house. To limit the concurrent connections we keep track of the active connections of users. Every user has a limited number of concurrent connections, depending on his subscription. When he connects, we subtract one. When he disconnects, we add one back. Reach zero and the service will not allow the user to connect until he disconnects one of his active instances.

To limit the brute force types of abuses, we monitor the health of the servers and limit the network priority of the obvious DDOS that might be masked through our service. SMTP abuses will also result in temporary port blocking for that service.

4. Emails and the support platform are hosted in-house. For our sales site analytics, we rely on Google Analytics. Live support is hosted by tawk.to which has a great privacy policy.

5. We designed our system in such a way that DMCA notices cannot be forwarded to our users. A diverse approach is needed to deal with this particular industry issue: from explaining that we don’t host any content to replacing IPs and servers that received multiple strikes.

6. No subpoena has been received by our company. If that happens, we’ll be sure to assist as much as we’re legally obliged. Keep in mind that we don’t have much information to provide.

7. Net neutrality is king. We allow any kind of traffic. P2P included.

8. We use Bitcoins (and many other kinds of virtual currencies: ETH, XRP, DGB, LTC ), PayPal, PerfectMoney and Credit Cards. The sales & billing platform is stored separately of the actual VPN system.

9. We use only OpenVPN protocol, one of the most secure and hard to crack protocols, with AES-256-CBC cipher, TLSv1/SSLv3 DHE-RSA-AES512-SHA, 2048 bit RSA.

On top of the OpenVPN, you can also choose one of the two anti DPI (Deep Package Inspection) protocols: “TOR’s OBFSPROXY Scamblesuit” and “SSL” that mask your VPN connection from your ISP. These protocols come handy in places that actively block VPN connections, like China, Egypt or university campuses.

10. Yes, we have an incorporated kill switch in our client and DNS leak protection.

11. We do use our own DNS and Google DNS for some servers.

Because of the nature of the industry, we consider that replacing servers and blacklisted IPs as fast as possible, having the ability to migrate from one ISP to another, and not existing in a constant physical location is a great plus. That’s why decided to rent the VPN servers.

12. At the time of writing this, we do not offer virtual locations. We offer more than 30 servers in 18 countries and we’re expanding fast. You can find the full list here.

VPNBaron website

SecureVPN.to

1. We don’t log any individually identifying information. The privacy of our customers is our top priority.

2. Our service is operated by a group of autonomous privacy activists outside of “Fourteen Eyes” or “Enemy of the Internet” countries. Each server is handled within the jurisdiction of the server’s location.

3. There are no tools which monitor our customers but we use techniques which don’t require any logging to prevent the abuse of our service.

4. Our website has been entirely developed by ourselves and thus we don’t rely on external service providers.

5. We reply to takedown notices but can’t be forced to hand out information because of our non-logging policy.

6. This hasn’t happened yet, but if we were forced to identify any of our customers at a specific server location, we would immediately terminate this location. We are not going to log, monitor or share any information about our customers under any circumstances.

7. BitTorrent and other file-sharing traffic is allowed and treated equally to other traffic on all servers.

8. We offer a wide range of anonymous payment methods like Bitcoin, Dash, Ethereum, Paysafecard and Perfect Money. No external payment processor receives any information because all payments are processed by our own payment interface.

9. We would recommend OpenVPN, available in UDP and TCP mode. We are using AES-256-GCM/CBC for traffic encryption, 4096 bit RSA keys for the key exchange and SHA-512 as HMAC. These settings offer you the highest grade of security available.

10. Our VPN Client provides advanced security features like a Kill Switch, DNS Leak Protection, IPv4/IPv6 Leak Protection, WebRTC Leak Protection and many more.

11. We rent 27 servers in 20 countries and are continuously expanding our server park. During the last year we focused on replacing our 100 Mbit/s servers with high-end dedicated gigabit servers and thus the number of servers slightly decreased. It is impossible to have physical control over all widespread servers but we took security measures to prevent unintended server access. At the moment we are using the nameservers of Quad9 which offer good privacy.

12. Every server is physically located in its specified country and thus we don’t offer virtual locations. You can find our server list at the following link.

SecureVPN.to website

VPNArea

1. We do not keep or record any logs. We are therefore not able to match an IP-address and a time stamp to a user of our service.

2. The registered name of our company is “Offshore Security EOOD” (spelled “ОФШОР СЕКЮРИТИ ЕООД” in Bulgarian). We’re a VAT registered business. We operate under the jurisdiction of Bulgaria.

3. To prevent mail spam abuse we block mail ports used for such activity, but we preemptively whitelist known and legit email servers so that genuine mail users can still receive and send their emails.

To limit concurrent connections to 6, we use our in-house developed system that adds and subtracts +1 or -1 towards the user’s “global-live-connections-count” in a database of ours which the authentication API corresponds with anonymously each time the user disconnects or connects to a server. The process does not record any data about which servers the subtracting/detracting is coming from or any other data at any time, logging is completely disabled at the API.

4. We host our own email servers in Switzerland. We host our own Ticket Support system on our servers in Switzerland. The only external tools we use are Google Analytics for our website and Zopim Live Chat.

5. DMCA notices are not forwarded to our members as we’re unable to identify a responsible user due to not having any logs or data that can help us associate an individual with an account. We would reply to the DMCA notices explaining that we do not host or hold any copyrighted content ourselves and we’re not able to identify or penalize a user of our service.

6. This has not happened yet. Should it happen our attorney will examine the validity of the court order in accordance with our jurisdiction, we will then delegate our no logs policy to the appropriate party pointing out that we’re not able to match a user to an IP or timestamp due to not keeping or recording any logs. In our six year history we’ve upheld our reputation and we believe one of the reasons such court orders don’t reach us is our clearly stated no-logs policy.

7. BitTorrent/P2P is allowed on most of our servers but not all of them. Why not? Some servers that we use are not tolerant to DMCA notices, but some of our members utilize them for other activities not related to torrenting. That is why we keep them in our network despite the inability to use P2P/torrents on them. Most of our VPN servers and locations do allow torrents and P2P. We even allow torrenting on server locations that most VPN providers don’t, such as USA and Canada.

8. We accept PayPal, Credit/Debit cards and Webmoney via third party payment processor, plus Bitcoin and Payza. We do not require personal details to register an account with us. In the case of PayPal/Payza/card payments we link usernames to their transactions so we can process a refund. We do take active steps to make sure payment details can’t be linked to account usage or IP assignments. We do not use a recurring payments system.

9. We use AES-256-CBC + SHA256 cipher and RSA4096 keys on all our VPN servers with without exception. We also have Double VPN servers, where for example the traffic goes through Russia and Israel before reaching the final destination.

10. Yes, we provide both KillSwitch and DNS Leak protection for our Windows and Mac apps. Our new Android app already has DNS Leak protection and AdBlocking and within a couple of days will also have KillSwitch in the upcoming new version.

11. We work with reliable and established data centers. Nobody but us has virtual access to our servers. The entire logs directories are wiped out and disabled, rendering possible physical brute force access to the servers useless in terms of identifying users.

12. All our servers are physically located in the stated countries. A list of our servers in 70 countries can be found here.

VPNArea website

AirVPN

1. No, we don’t.

2. The name of the company is Air and it is located in Italy.

3. We do not use any monitoring or traffic inspection tools. We do associate a connections counter for each account to enforce the limit of five simultaneous connections per account. We also promptly investigate any service (website etc.) running behind our service to prevent phishing and other scams (malware spreading, bot controllers, etc) if we receive a complaint about them. However, checking those services after a complaint or a warning from a third-party does not require any traffic monitoring.

4. Absolutely not.

5. They are ignored.

6. The matter is handled by our law firm which explains to the competent authorities how our system works and why it is not possible to track a user “ex-post” when such identification requires access to traffic logs, which simply do not exist. We have so far not received any order trying to force us to “log activity going forward” and we would not be able to comply for strictly technical reasons.

7. Yes, BitTorrent (just like any other protocol) is allowed on all servers without any re-routing.

8. Nowadays we use Coinpayments, BitPay, PayPal and Avangate. We accept a wide variety of cryptocurrencies and several credit cards. We also planned to accept payments in Bitcoin (and some other cryptocurrency) directly in late 2018, with no need for any third party payment processor, which anyway does not require any personal data to complete a transaction.

We do not keep any information about account usage and/or IP address assignments, so there can’t be any correlation with any payment. As usual a customer needs to consider that any payment via a credit card or PayPal will be recorded for an indefinite amount of time by the respective financial companies. We also accept cryptocurrencies inherently designed to provide a strong layer of anonymity.

9. We recommend only and exclusively OpenVPN. A proper configuration must include TLS mode, Perfect Forward Secrecy, 4096 bit Diffie-Hellmnn keys, and at least 2048 bit (preferably 4096 bit) RSA keys. About the channels ciphers, AES-256 both on the Control Channel and the Data Channel is an excellent choice, while digests like HMAC SHA (when you don’t use an AED cipher such as AES-GCM) for authentication of packets are essential to guarantee integrity (preventing for example injection of forged packets in the stream), both on the Control and the Data channels.

Our service provides all of the above. About Elliptic Curve Cryptography, since it is finally of public domain that at least one random number generator (Dual_EC_DRBG) had a backdoor, and that an NSA program did exist with the aim to implement backdoors in some curves and then have exactly those curves recommended by NIST, momentarily we would suggest to drop ECC completely, just to stay on the safe side and according to Bruce Schneier’s considerations.

10. Yes, of course. They are integrated in our free and open source software “Eddie” released under GPLv3. Anyway, usage of our software is not mandatory to access our service, so we also provide guides to prevent any kind of traffic leaks outside the VPN “tunnel” on a variety of systems.

11. The VPN server management is never outsourced. Even the IPMI, which has proven to be the source of extremely dangerous vulnerabilities, is patched and access-restricted by the AirVPN core management persons only. The Air company does not own datacenters. Owning a datacenter would put Air in a vulnerable position in the scenario described in your question number 6 (second part: court order to start logging traffic).

12. We do not offer “virtual” locations. No IP address geo-location trick, hidden re-routing or any other trick is ever performed. We do not use Virtual Servers at all. Currently, we have physical (bare metal) servers really located in the following countries: Austria, Belgium, Bulgaria, Canada, Czech Republic, Germany, Hong Kong, Japan, Latvia, Lithuania, Netherlands, Norway, Romania, Singapore, Spain, Sweden, Switzerland, Ukraine, United Kingdom, United States.

AirVPN website

Trust.Zone

1. Trust.Zone doesn’t store any logs. All we need from users is just an email to sign up. No first name, no last name, no personal info, no tracking, no logs.

2. Trust.Zone is under Seychelles jurisdiction and we operate according to the law in Seychelles. There is no mandatory data retention law in Seychelles. In our jurisdiction, a foreign court order would not be enforceable and since we don’t store any logs, there is nothing to be taken from our servers. The company is operated by Extra Solutions Ltd.

3. We have no usage restriction on our service. As we don’t have any logs, we can’t track any user online activity. Trust.Zone doesn’t use any third party tools on the website. The single restriction we have is three simultaneous connections per user.

4. Trust.Zone does not use any third-party support tools, tracking systems like Google Analytics or live chats. If a user loads our website in a browser, all information like Javascript, HTML and CSS belongs to trust.zone domain only.

5. If we receive any type of DMCA requests or Copyright Infringement Notices – we ignore them. Why? Trust.Zone is under Seychelles offshore jurisdiction. There is no mandatory data retention law in Seychelles. Since we don’t store any logs, there is nothing to be had from our servers.

6. A court order would not be enforceable because we do not log information and therefore there is nothing to be had from our servers. Trust.Zone is a VPN provider with a Warrant Canary. Trust.Zone has not received or has been subject to any searches, seizures of data or requirements to log any actions of our customers.

7. We don’t restrict any kind of traffic. Trust.Zone does not throttle or block any protocols, IP addresses, servers or any type of traffic whatsoever.

8. All major credit cards are accepted. Besides, Bitcoin, PayPal, Webmoney, Alipay, wire transfer and many other types of payments are available. To stay completely anonymous, we highly recommend using anonymous payments via Bitcoin.

9. Trust.Zone uses the highest level of data encryption. We use a protocol which is faster than OpenVPN and also includes Perfect Forward Secrecy (PFS). The unique feature of Trust.Zone VPN is that you can forward your VPN traffic via ports – 21(FTP) 22 ( SCP, SFTP ), 80 (HTTP), 443 (HTTPS) or 1194 (OpenVPN), most of which can’t be blocked by your ISP. Trust.Zone uses AES-256 Encryption by default. We also offer L2TP over IPsec which also uses 256bit AES Encryption.

10. Trust.Zone supports a kill-switch function. We also own our DNS servers and provide users with using our DNS to avoid any DNS leaks. Trust.Zone has no support for IPv6 connections to avoid any leaks. We also provide users with additional recommendations to be sure that there are no any DNS leaks or IP leaks.

11. We have a mixed infrastructure. Trust.Zone owns some physical servers and we have access to them physically. In locations with lower utilization, we normally host with third parties. But the most important point is that we use dedicated servers in this case only, with full control by our network administrators. DNS queries go through our own DNS servers.

12. We are operating with 150+ servers in 30+ countries and still growing. The most popular Trust.Zone locations are France, Australia, US, Canada and UK. The full map of the server locations is available here.

Trust.Zone website

CactusVPN

1. We don’t keep any logs.

2. CactusVPN Inc., Canada

3. We restrict our services with up to five devices per package for VPN connection and to unlimited devices for SmartDNS service as long as all of them have the same IP address. Abuse of services is regulated by our Linux firewall and most of the datacenters we hire servers from provide additional security measures for servers attacks.

4. No.

5. We did not receive any official notices yet. We will only respond to a local court order.

6. If we have a valid order from Canadian authorities we have to help them identify the user. Bus as we do not keep any logs we just can’t do that. We did not receive any orders yet.

7. BitTorrent and other file-sharing traffic is allowed on Netherlands, Germany, Switzerland and Romanian servers.

8. PayPal, Visa, MasterCard, Discover, American Express, Bitcoin & Altcoins, Alipay, Qiwi, Webmoney, Boleto Bancario, Yandex Money and other not so popular payment options.

9. We recommend users to use SoftEther with ECDHE-RSA-AES128-GCM-SHA256 cipher suite.

10. Yes, our apps include Kill Switch and Apps. Killer options in case a VPN connection is dropped. Also they include DNS Leak protection.

11. We use servers from various data centers.

12. USA, UK, France, Germany, Canada, Netherlands, South Korea, Australia, Poland, Japan, Switzerland, Singapore, Romania.

CactusVPN website

ShadeYou VPN

1. ShadeYou VPN does not keep any logs. To use our service only a username and e-mail are required. No personal or real data is required.

2. We are incorporated as DATA ACCENTS LP and operate under the United Kingdom jurisdiction.

3. Limits of concurrent connections are regulated in real time on the server side by our own developed tools without any logs kept.

4. We are using Google Analytics as a tool which allows us to improve our website and bring our users better experience. Also, we are using SiteHeart online support. But none of these tools track / hold personal information.

5. The abuse team of ShadeYou VPN answers as follows: A) We do not store any illegal content on our servers. B) Every user agrees with our privacy policy while registering, so we warned that illegal actions are prohibited and at this time we are not responsible. C) We have no any personal data of our users or any logs of their activities that can be shared with third-parties because we simply do not store it.

6. There are no any special steps since we have no logs to share and analyze. It means we can’t help with identifying the active or past user of our service. Logging activity is not acceptable for our service. We had different cases but we can guarantee that none of our users were compromised.

7. BitTorrent and any other file-sharing traffic is allowed mostly on all our servers. There are only a few exceptions (such as when traffic is limited on the servers).

8. ShadeYou VPN uses payment systems including PayPal, Perfect Money, Webmoney, Qiwi, Yandex Money, Easy Pay, Ligpay, UnionPay, AliPay, MINT, CashU, Ukash also accept payments via Visa, Master Card, Maestro and Discover. Of course, Bitcoin is available. Important note: we do not store billing information which is required to improve users safety.

9. We strongly recommend using OpenVPN since it is the safest and uses the strongest encryption (TLS Protocol with 4096-bit key length and AES-256-CBC crypto-algorithm).

10. We support “Kill switches” and DNS leak protection using our desktop client.

11. All our servers are collocated around the world in data centers of different leading hosting companies. Yes, we are using our own DNS servers.

12. Here is an overview and all servers are physically located.

ShadeYou VPN website

PrivateVPN

1. We don’t retain or log any identifiers namely IP addresses, timestamps of any sort of connections on our VPN or authentication servers, data used, the speed of connection at all. Period.

2. PrivateVPN is run by a Swedish company viz. ‘Privat Kommunikation Sverige AB’ under Swedish jurisdiction.

3. Owing to our above-mentioned privacy promise, active monitoring of our service is out of the question.

4. We use a service known as LiveAgent to provide email or ticket and live chat support. They do not hold any information about chat sessions. Chat conversation transcripts are not stored on chat servers. They remain on the chat server for the duration of the chat session, then optionally sent by email to a user, and then destroyed.

5. DMCA is not applicable to our service as it is not a codified law or act under Swedish jurisdiction. So, it is none of our business. A Swedish equivalent isn’t in the scene as of now in our jurisdiction at all.

6. As already mentioned above, we don’t retain or log any identifiers at all. So, basically even when ordered to actively investigate a user we are limited to the number of active logins which is just a numerical value. That being said, we have not received a court order to date.

7. Of course, we are not in the business of restricting and throttling things. The whole point of a user connecting to our VPN servers is to get uncensored and unrestricted Internet.

8. We support PayPal, Stripe, and Bitcoin. Alipay as a payment method is en route. We offer a 30-day money-back guarantee and in order to enforce it, we keep a track of payments linked to a user account. There is no way to link an IP address assigned from us to a user account as we do not log such data.

9. No single VPN protocol works for everyone. We support multiple VPN protocols viz. PPTP,L2TP,IPsec,IKEv2,OpenVPN,Shadowsocks(beta) and soon SSH(in labs). Our default VPN protocol on all the platforms other than iOS is OpenVPN over UDP with 256-bit AEAD ciphers when you use our VPN application.

We recommend a user with an ideal ISP to use OpenVPN over UDP/1194. In case your ISP happens to throttle default OpenVPN port 1194, you can use OpenVPN over TCP/443, which is deployed with the latest –tls-crypt that OpenVPN offers for additional privacy and very basic obfuscation of the protocol itself.

For users who love built-in VPN clients for an OS, like Windows, Mac, Blackberry, iOS etc, we recommend IKEv2. For users from UAE, Egypt, some parts of China etc, we are working on secure Shadowsocks over TCP/80 with AEAD cipher and/or SSH-based solutions to tunnel their OpenVPN traffic. Shadowsocks is already being tested and working with many happy users new and old users from Egypt & UAE. For Tor lovers, we offer a guide, help, instructions on how to connect to our OpenVPN servers over Tor for additional security and privacy.

10. Our Windows VPN App offers robust Kill switch and DNS leak protection. DNS leaks on any major platform are owing to broken installations which are fixed as soon we see a report or any issues. IPv6 leak protection is available on every platform and multiple VPN protocols. We offer guides and instructions to set up a kill switch on macOS, GNU/Linux, BSD etc and are rapidly working with our developers to add these features in our easy to use and install VPN applications.

11. We have physical control over our servers and network in Sweden. We’re only using trusted data centers with strong security. Our providers have no access to PrivateVPN’s servers and most importantly, there is no customer data/activities stored on the VPN servers or on any other system we have.

We have deployed our own multiple DNS nameservers which work from within tunnel and are automatically pushed to VPN clients upon successful connection. You are at liberty to use whatever DNS nameservers you like though. For example, if you or someone you trust hosts a server with additional security features like DNSCRYPT and DNSSEC, it is fair if you wish to use it.

12. We use a mix of physical and virtual servers depending on the demand and needs of a given location.

PrivateVPN website

OctaneVPN

1. No.

2. Octane Networks, LLC. US registered company.

3. We block port 25 outbound to reduce the possibility of spam. Our auth system limits concurrent connections via our custom backend.

4. We use Google Analytics for general website trends. We use Hotjar occasionally for A/B and user experience testing. Support is internal.

5. If the customer session is still connected to our service we take action. Repeat infringers must be disabled since we are a US based company and must comply with DMCA.

6. This has not happened. We would take every action we legally could to maintain the privacy of our customers. Since logs are not used, there is little information we could provide if ordered to do so by a court of competent jurisdiction.

7. Yes. We operate with net neutrality with the exception of restricting outgoing SMTP to prevent spammers from abusing the service.

8. Bitcoin, Credit/Debit Card and PayPal. IP addresses are not linked to payment details.

9. OpenVPN
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
cipher AES-256-CBC
auth SHA512

10. Our client disables IPv6 completely as part of our DNS and IP leak protection in our Windows and Mac OS X OctaneVPN clients. Our OpenVPN based client’s IP leak protection works by removing all routes except the VPN route from the device when the client has an active VPN connection.

This a better option than a ‘kill switch’ because our client ensures the VPN is active before it allows any data to leave the device, whereas a ‘kill switch’ typically monitors the connection periodically, and, if it detects a drop in the VPN connection, reacts. With a ‘kill switch’, data sent during the time between checks is potentially vulnerable to a dropped connection. Our system is proactive vs a reactive kill switch.

Customers should vigilant as other software such as JavaScript, Flash, Java and WebRTC can leak IP independently of their VPN connection. Customers might want to consider creating a profile in their web browser specifically tailored toward web browsing privacy by disabling 3rd party plugins/extensions.

11. In our more active gateway locations, we colocate. In locations with lower utilization, we normally host. We do not do the virtual location BS you hear about sometimes. Each of our gateways acts as a DNS server for the end-user.

12. We have gateways in 45 countries and 92 cities.

OctaneVPN website

SlickVPN

1. SlickVPN doesn’t log traffic or session data of any kind. We don’t store connection time stamps, used bandwidth, traffic logs, or IP addresses.

2. Slick Networks, Inc. is our recognized corporate name. We operate a complex business structure with multiple layers of offshore holding companies, subsidiary holding companies, and finally some operating companies to help protect our interests. The main marketing entity for our business is based in the United States of America but the top level of our operating entity is based out of Nevis.

3. We block port 25 to reduce the likelihood of spam originating from our systems. The SlickVPN authentication backend is completely custom and limits concurrent connections.

4. We utilize third party email systems to contact clients who opt in for our newsletters and Google Analytics for basic website traffic monitoring and troubleshooting. We believe these platforms to be secure. Because we do not log your traffic/browsing data, no information about how users may or may not use the SlickVPN service is ever visible to these platforms.

5. If a valid DMCA complaint is received while the offending connection is still active, we stop the session and notify the active user of that session. Otherwise, we are unable to act on any complaint as we have no way of tracking down the user. It is important to note that we rarely receive a valid DMCA complaint while a user is still in an active session.

6. This has never happened in the history of our company. Our customer’s privacy is of topmost importance to us. We are required to comply with all valid court orders. We would proceed with the court order with complete transparency, but we have no data to provide any court in any jurisdiction. SlickVPN uses a warrant canary to inform users if we have received any such requests from a government agency. Users can monitor our warrant canary here: SlickVPN Warrant Canary

7. Yes. All traffic is allowed. SlickVPN does not impose restrictions based on the type of traffic our users send.

8. We accept PayPal, Credit Cards, Bitcoin, Cash, and Money Orders. We keep user authentication and billing information on independent platforms. One platform is operated out of the United States of America (Marketing) and the other platform is operated out of Nevis (Operations).

Payment details are held by our marketing company which has no access to the Operations data. We offer the ability for the customer to permanently delete their payment information from our servers at any point and all customer data is automatically removed from our records shortly after the customer ceases being a paying member.

9. We recommend using OpenVPN if at all possible (available for Windows, Apple, Linux, iOS, Android) and we use the AES-256-CBC algorithm for encryption.

10. Our leak protection (commonly called a ‘kill-switch’) keeps your IPv4 and IPv6 traffic from leaking to any other network and protects against DNS leaks. Your network will be disabled if you lose the connection to our servers and the only way to restore the network is manual intervention by the user.

11. We physically control some of our server locations where we have a heavier load. Other locations are hosted with third parties unless there is enough demand in that location to justify racking our own server setup. To ensure redundancy, we host with multiple providers in each location. We have server locations in over forty countries. We’re currently in the process of deploying 10Gb connected nodes that are physically controlled by our company.

In all cases, our network nodes load over our encrypted network stack and run from ramdisk. Anyone taking control of the server would have no usable data on the disk. We periodically remount our ramdisks to remove any lingering data. Each of our access servers acts as the DNS server for customers connected to that node.

12. At SlickVPN we actually go through the expense of putting a physical server in each country that we list. SlickVPN offers VPN service in 40 countries around the world. We do not do offer virtual locations.

SlickVPN reviews

CryptoStorm

1. No. The only logs on our servers are security related, such as: [[email protected] ~]# tail -n1 /var/log/messages Feb 21 17:27:51 wilno kernel: grsec: exec of /usr/bin/tail (tail -n1 /var/log/messages ) by /usr/bin/tail[bash:14447] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:12336] uid/euid:0/0 gid/egid:0/0

This is so we can monitor for unauthorized commands in the unlikely event that a server is compromised by some 0day exploit. Strict privilege separation and access control is done to minimize the access any potential attackers would get if any of our services were vulnerable to a 0day exploit. None of those logs contain any customer-related data.

2. Cryptostorm consists of several different entities that are in different regions. This is so if any adversary were to put legal pressure on one of those entities, we can simply drop and replace it, along with any resources that might be under it. The names and locations of these entities are not publicly disclosed, simply to make it more difficult for any potential adversaries.

3. Abuse is mitigated by using snort’s NFQ DAQ as an Intrusion Prevention System. This allows us to block the most basic or automated attacks/scans that would violate the Terms of Service at most data centers. It also allows us to prevent basic attacks without requiring us to keep any data that could be used to identify a customer. No customer IPs ever show up in those snort alerts.

4. No.

5. Most of the data centers we’ve chosen aren’t legally required to do anything about DMCA or similar complaints. The few that are legally required to do something, are only required to forward the complaint to us. Currently, the only exception is one of our Netherlands data centers, who requires a response from us. For them, we use a template very similar to this.

If an ISP, data center, or anyone else were to request customer information related to a DMCA complaint, we wouldn’t be able to provide anything since we don’t have anything. If a data center threatens to suspend our server if we don’t comply, we simply stop doing business with that data center.

6. The locations of the entities that make up Cryptostorm were specifically chosen for their strong privacy and business laws. We wouldn’t be able to comply with any court order requesting customer information since we don’t have any information to give. If a court successfully ordered one of our entities to start collecting customer information, we would absolve any entities in that court’s region.

In the highly unlikely event that international courts coordinating together were successful in ordering all of our entities to comply, we would shut down Cryptostorm, Lavabit style. As of February 2018, we have never received any such court orders. If we were to receive any “gag orders”, our warrant canary would inform customers of its existence.

7. Yes.

8. Credit/debit card payments are accepted via PayPal and Stripe. Bitcoin is accepted through BitPay. Bitcoin, Bitcoin Cash, BlackCoin, Dash, DigiByte, Dogecoin, Ether Classic, Ether, GameCredits, Litecoin, PotCoin, Vertcoin, Monero, and Zcash are accepted through CoinPayments.net. Our anonymous token authentication system plus our no-logging policy prevents us from knowing which customers are connected to which server, or what traffic they’re generating on that server.

9. Our most secure OpenVPN instances use: SHA512 for authentication; AES-256-GCM to encrypt the data channel; TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 for the control channel, forced to TLS v1.2 to prevent downgrade attacks; Unique 4096-bit DH parameters for perfect forward secrecy; prime256v1 ECC server/CA certificates, signed with ecdsa-with-SHA512; 2048-bit static key for additional encrypting/authenticating of control channel packets.

For backwards compatibility on older devices that might not support OpenVPN 2.4.x, we also provide instances using: SHA512 for auth, AES-256-CBC for the data channel, TLS-DHE-RSA-WITH-AES-256-CBC-SHA for the control channel, and unique 2048-bit DH parameters for perfect forward secrecy.

10. We do provide firewall rule sets for IPtables, ufw, pf, etc. For Windows users, our open-source VPN client includes a kill switch.

11. We rent/lease servers at various data centers throughout the world. To account for the possibility of physical compromise (i.e., a confiscated server), each server is designed to be as disposable as possible. We don’t keep any data on the servers that can be used to identify a customer, and the data cannot be used to gain access to any other server. We do use our own DNS servers, and we also provide more secure alternatives to DNS such as DNSCrypt and DNSChain.

12. Currently, we have servers in Germany, Netherlands, Lithuania, Finland, Poland, Moldova, Spain, Latvia, Canada, England, Italy, France, Switzerland, Portugal, and eight US servers. We do not use VPS/VMs for our VPN servers. Only bare metal dedicated servers.

CryptoStorm website

WhatTheServer

1. Our OpenVPN servers are configured with “verb 0” so that they keep no logs at all.

2. What The * Services, LLC is incorporated in the USA. We have VPN servers in the USA, Germany, and the Netherlands.

3. We use a custom session management system which operates completely on real-time data and keeps no logs. The session management infrastructure (and all VPN servers) is built on top of OpenBSD and uses the services built into OpenBSD to enforce user management.

4. We run all of our own communications infrastructure. However, we do use Google Analytics on the WhatTheServer.me website.

5. We have never received a DMCA take-down notice or a non-US equivalent regarding our VPN service. However, we did receive a DMCA take-down notice regarding a website one of our customers was running on our Virtual Private Servers.

We responded by replying to the requester letting them know we were looking into it, and we notified the customer via his email on file. Then we contacted the EFF and they put us in touch with a lawyer who helped us get the case dropped, because we did not have the information requested. The customer’s identity was never revealed to the people making the DMCA take-down request, because the bill was paid in Bitcoin & a throwaway email account was used.

6. We have not yet received such a court order or subpoena for user information. However, if we do we will take several steps. First, we would consult with our lawyers to confirm the validity of the order/subpoena, and respond accordingly if it is NOT a valid order/subpoena. Then we would alert our user of the event if we are legally able to.

If the order/subpoena is valid, we would see if we have the ability to provide the information requested, and respond that we do NOT have the information requested. If we DO have the information requested, we would immediately reconfigure our systems to stop keeping that information. Then we would consult with our lawyer to determine if there is any way we can fight the order/subpoena and/or what is the minimum level of compliance we must meet, as well as, notify the user of the event if we are legally able to do so.

If we were forced to start keeping logs on our users, we would go out of business and start a new company in a different jurisdiction.

7. BitTorrent and other file-sharing traffic is allowed on all VPN/Proxy servers which are NOT located in the USA.

8. We accept PayPal, as well as Monero, Bitcoin and over 140 CryptoCurrencies and AltCoins via CoinPayments.net We encourage our users to pay with anonymous payment methods and supply false contact information. We also use a completely different authentication infrastructure and random usernames for the VPN accounts.

9. All of our OpenVPN and SOCKS Proxy servers are running OpenBSD and are using LibreSSL instead of OpenSSL. This protects our servers from a wide range of attacks on the encryption. Our OpenVPN Servers use AES-256-CBC & SHA512 HMAC for the Data Channel, and DHE-RSA-AES256-GCM-SHA384 on the Control Channel. Our OpenVPN Servers are also configured with 4096bit RSA keys and a custom 4096bit Diffie-Hellman parameters. Our SOCKS Proxy is based on OpenSSH, so they support any ciphers the client wants to use. With the OpenSSH protocol, the Client decides what cipher to use instead of the Server.

10. We push Google DNS 8.8.8.8 and 8.8.4.4 to clients. We also have ‘push “block-outside-dns”’ in our OpenVPN server config files which will prevent the client from leaking DNS requests. Additionally, we include “resolve-retry infinite” and “persist-tun” in the OpenVPN client config files which will prevent the client from sending data in the clear if the VPN connection goes down.

11. All of our infrastructure is hosted in third party colocations. However, we use full-disk-encryption on all of our servers. We use Google DNS at this time but we are currently testing alternatives.

12. We offer VPN server locations in the USA, Germany, and Netherlands.

WhatTheServer website

ibVPN

1. We do not keep any log that can identify a user of our service with an IP address and/or a timestamp. We are getting ready to be GDPR compliant and (in our opinion) keeping this kind of logs is not respecting the Privacy by Design guidelines.

2. Company’s registered name is Amplusnet SRL. We are a Romanian company, which means we are under EU jurisdiction.

3. We limit the number of concurrent connections and we are using Radius for this purpose.

4. The back end of the website is a dedicated WHMCS for billing and support tickets. We do not use external e-mail providers (we host our own mail server). Our users can contact us via live chat (Zopim). The chat activity logs are deleted on a daily basis. There is no way to associate any information provided via live chat with the users’ account.

5. So far we did not receive any DMCA notice for any P2P server from our server list. That is normal considering that the servers are located in DMCA free zones. For the rest of the servers, p2p and file sharing activities are not allowed/supported.

6. So far, we have not received any court order. We do not support criminal activities, and in case of a valid court order, we must follow the EU laws under which we operate.

7. We have dedicated P2P servers that allows BitTorrent and other file-sharing applications. The servers are located in Netherlands, Luxembourg, Canada, Sweden, Russia, Hong Kong and Lithuania. We do not reroute P2P connections.

8. Payments are performed exclusively by third party processors, thus no credit card info, PayPal ids or other identifying info are stored in our database. For those who would like to keep a low profile, we accept BitCoin, LiteCoin, Ethereum, WebMoney, Perfect Money etc.

9. We support SSTP and SoftEther on most of the servers. We also offer double VPN and TOR over VPN.

10. Yes, Kill Switch and DNS leak protections are implemented in our VPN Clients. Kill Switch is one of the most used features. Our users can decide to block all the traffic when the VPN connection drops or to kill a list of applications. We allow customers to disable IPv6 Traffic and to make sure that only our DNS servers are used while connected to the VPN.

11. We do not have physical control over our VPN servers. We have full remote control to all servers. Admin access to servers is not provided for any third party.

12. The full list of server locations is available here.

ibVPN website

OVPN

1. Our entire infrastructure and VPN service is built to ensure that no logs can be stored – anywhere. Our servers are locked in cabinets and operate without any hard drives. We use a tailored version ofAlpine, which doesn’t support SATA controllers, USB ports etc. To further increase security, we use TRESOR and grsecurity to be resistant to cold boot attacks.

2. OVPN Integritet AB (Org no. 556999-4469). We operate under Swedish jurisdiction.

3. None.

4. For website insights, we use Piwik, an Open Source solution that we host ourselves. The last two bytes of visitors’ IP addresses are anonymized; hence no individual users can be identified. For support, we use an internally built system.

The mail server is hosted by Glesys, a trusted provider in Sweden. Automatic emails from the website are sent using Mailgun, but we never send any sensitive information via email. Zendesk chat is used for live chat, which we will eventually migrate from when we’ve built a satisfactory in-house solution.

5. Since we don’t store any information, such requests aren’t applicable to us.

6. We can’t provide any information to the court. A court wouldn’t be able to do that [require logging] in our jurisdiction – but in case it did happen we would move the company abroad.

7. Yes.

8. We offer PayPal, credit cards (via Braintree), Bitcoin (via Bitpay), cash in envelopes as well as a Swedish payment system called Swish. We never log IP addresses of users, so we can’t correlate an IP address to a payment.

9. We offer AES-256-GCM. In terms of connection, we recommend using our Multihop add-on.

10. Yes.

11. Yes. We own all the servers and routers, and they’re co-located in various data centers in locked cabinets.

12. USA, Germany, Sweden, United Kingdom, the Netherlands, Canada and Norway. No virtual locations are offered.

OVPN website

Mullvad

1. No, all details are explained in our no-logging data policy.

2. Amagicom AB, Sweden.

3. We limit the number of simultaneous connections to five per account. This is monitored in real time by our VPN servers which report this information to our central service. When a customer connects to one of our servers, the server asks the central service if the account has reached its connection limit. As we do not save this information, we cannot, for example, tell you how many connections your account had five minutes ago.

4. We have no external elements at all on our website. We do use an external email provider; for those who want to email us, we encourage them to use PGP encryption which is the only effective way to keep email somewhat private. The decrypted content is only available to us.

5. There is no such Swedish law that is applicable to us.

6. From time to time, we are contacted by governments asking us to divulge information about our customers. Given that we don’t store activity logs of any kind, we have no information to give out. So far this has never happened.

In addition, we do not believe that it’s possible for Swedish law to order us to actually give out information about our users. Not that we would anyway. We started Mullvad for political reasons and would rather discontinue the service than have it work against its purpose.

7. All traffic is treated equally, therefore we do not block or throttle BitTorrent or other file-sharing protocols.

8. We accept cash, Bitcoin, Bitcoin Cash, bank wire, credit card, PayPal, and Swish. We encourage anonymous payments via cash or one of the cryptocurrencies. We run our own full node in each of the blockchains and do not use third parties for any step in the payment process, from the generation of QR codes to adding time to accounts. Our website explains how we handle payment information.

9. On Windows, macOS, and mobile, we offer OpenVPN with RSA-4096 and AES-256-GCM. On Linux, we also offer WireGuard which uses Curve25519 and ChaCha20-Poly1305. We also offer an experimental post-quantum secure VPN tunnel using WireGuard and NewHope.

10. We offer a kill switch and DNS leak protection, both of which are supported in IPv6 as IPv4. While the kill switch is only available via our client/app, we also provide a SOCKS5 proxy that works as a kill switch and is only accessible through our VPN.

11. Yes, we use our own DNS servers.

12. Our website has an up-to-date server list.

Mullvad website

AceVPN

1. We do not log period. No meta-data logging, no traffic logging, no bandwidth usage tracking. We do not have any hidden fair usage policy. We respect our users’ privacy. We do not store any personal or billing information on VPN servers. IP’s are shared amongst users and our configuration makes it extremely difficult to single out any user.

2. We are registered in USA and operate as AceVPN.com

3. We have developed tools to mitigate abuse.

4. We use Google Analytics on www.acevpn.com (marketing site). We do not track proxied pages. We use G Suite for email. Emails are deleted regularly.

5. If we receive DMCA takedown, we block the port mentioned in the complaint. IPs are shared by other users and our configuration makes it extremely difficult to single out any user. We do not share any information with third parties.

6. To date, we have not received a court order. We only store billing information which the payment processor or bank or credit card issuer has.

7. We have special servers for P2P and are in datacenters that allow such traffic. These servers also have additional security to protect privacy when p2p programs are running. We do not reroute traffic as this require inspecting and analyzing traffic which contradicts with our no logs policy.

8. We accept Paypal, Bitcons and Credit cards for payments. We store billing information on a secure server separate from VPN servers and do not track usage nor IP assignments.

9. Both our IKEv2 and OpenVPN supports Elliptic curve cryptography (ECC) which we recommend for secure connectivity. To give an idea, 384 bits ECDSA is equivalent to RSA 7680 bits. Higher the bits, more secure it gets.

10. Yes, we do provide kill switches if a connection drops. Our servers are tested for DNS leak.

11. We have full control over our servers. Servers are housed in reputed datacenters. Many of them are ISO certified and are designed to the highest specifications for performance, reliability and security. We operate our own DNS servers (Smart DNS) for streaming videos. For VPN, we use Google, OpenDNS and Level3 DNS.

12. We have servers in 26+ countries and over 50+ locations /datacenters. USA, Brazil, Canada, Mexico, Denmark, Egypt, France, Germany, Ireland, Italy, Japan, Latvia, Luxembourg, Netherlands, Norway, Romania, Russia, Spain, Sweden, Switzerland, Turkey, UK, Hong Kong, Singapore, Australia, and South Africa.

AceVPN website

BlackVPN

1. No. We purge all this information when the user disconnects from the VPN.

2. The name of the company is BLACKVPN LIMITED and is registered in Hong Kong and operates under the jurisdiction of Hong Kong.

3. Most of the time we use iptables to manually monitor and mitigate abuse, but in some special and complicated cases we have used fwsnort and psad to detect hacking and spamming from our platform. Limiting concurrent sessions is done through built in functionality in FreeRadius.

4. We run our own email server plus support and live chat systems using open source tools. We use StreamSend for sending generic welcome and renewal reminder emails, as well as for the occasional news updates. We have Twitter widgets on our frontpage that may track visitors. We use our own website analytics (Piwik) where we only save anonymous IP data.

5. We block the port in the firewall on the server listed in the notice.

6. If we received a valid court order from a Hong Kong court, then we would be legally obliged to obey it. So far this has never happened.

7. Bittorrent traffic is not restricted in our Privacy VPN locations, but due to stricter enforcement of DMA notices in the USA and UK we restrict most BitTorrent traffic and only whitelist torrents of known open source software.

8. PayPal and PaymentWall for Credit Cards, Bank Transfers and Prepaid cards. Coingate for all kind of Cryptocurrencies. The transaction details (ID, time, amount, etc) are linked to each user account.

9. We recommend to use IKEv2 or OpenVPN for the most secure VPN connection. We support the very secure GCM cipher mode (AES-256-GCM) together with 4096 bit RSA and Diffie Hellman keys. We also enforce DHE/ECDHE enabled cipher suites and key exchange is done with Diffie-Hellman, providing forward secrecy.

10. For OpenVPN, we stop IPv6 and DNS leaks with the OpenVPN config, and we also disable and blackhole all IPv6 traffic server side. Our custom VPN app provides 100% IPV6 and DNS leak protection client side and we are working on adding a 100% working kill switch there soon.

11. We use dedicated servers which are hosted in 3rd party data centers, but they do not have access to login or manage the server. We run our own DNS servers which do not save any logs. Among others we use Steadfast, i3D, Zenex5ive, Worldstream, Evoluso, Estnoc,Amanah, Voxility, Rackend, CherryServers.

12. We do not now offer virtual locations. Our servers are in USA, UK, Australia, Brazil, Canada, Czech Republic, Estonia, France, Germany, Japan, Lithuania, Luxembourg, Netherlands, Norway, Romania, Spain, Switzerland and Ukraine.

BlackVPN website

Perfect Privacy

1. We do not log or store any traffic, IP addresses or any other kind of data that would allow identification of our users or their activities. The anonymity and privacy of our users is our highest priority and the Perfect Privacy infrastructure was built with this in mind.

2. Perfect Privacy is operated by Vectura Datamanagement, registered in Zug, Switzerland.

3. The primary method to mitigate abuse is reacting to email tickets. In case of malicious activity towards specific targets, we block IP addresses or ranges so they are not accessible from our VPN servers. Additionally, we have limits on new outgoing connections for protocols like SSH, IMAP, and SMTP to prevent automated spam and brute force attacks. We do not limit or keep track of the number of connections per user.

4. All email and support tools are developed and hosted in-house under our control. We use Google Analytics for website optimization and better market reach, but with the anonymizeIp parameter set. However, Perfect Privacy users are exempted from any tracking by Google Analytics and are also able to use our TrackStop filter which will block any tracking (as well as ads and known malware domains) directly on our servers.

5. Because we do not host any data, DMCA notices do not directly affect us. However, we do receive copyright violation notices for file-sharing in which case we truthfully reply that we have no data that would allow us to identify the responsible party.

6. The only step on our side is to inform the contacting party that we do not have any data that would allow the identification of a user. There had been incidents in the past where Perfect Privacy servers have been seized but never was any user information compromised that way. Since no logs are stored in the first place and additionally all our services are running within ramdisks, a server seizure will never compromise our customers. In August 2016 Dutch Authorities seized two of our servers in Rotterdam and no user data was compromised.

7. Yes, BitTorrent and other file sharing is generally allowed and treated equally to other traffic. However, at certain locations that are known to treat copyright violations rather harshly (very quick termination of servers) we block the most popular torrent trackers to reduce the impact of this problem. Currently, this is the case for servers located in the United States and France.

8. We offer a variety of payment options ranging from anonymous methods such as sending cash, or Bitcoin. However, we also offer payment with PayPal and credit cards for users who prefer these options. Because we do not monitor or log IP assignments or account usage, there is no link to the payments.

9. While we offer a range of connection possibilities we would recommend using OpenVPN with 256 bit AES encryption. Additional security can be established by using a cascaded connection over up to four hops and by activating NeuroRouting for optimized routing to keep all traffic in the encrypted VPN network as long as possible.

10. Our VPN client versions for Windows and MacOS both have “kill-switch” functionality (firewall protection against IP and DNS leaks) integrated.

11. All our VPN servers are dedicated servers that run in various data centers around the world. While we have no physical access to the servers, they all are running within RAM disks only and are fully encrypted. We operate our own DNS servers.

12. Currently, we offer servers in 23 countries. All servers are located in the city displayed in the host name – there are no “virtual locations”. For full details about all servers locations please check our server status site as we are constantly adding new servers.

Perfect Privacy website

VPN.ht

1. We keep 0 logs about usage or to match IP-Timestamp to a user.

2. VPN.ht Limited, a Hong Kong Company

3. We allow five concurrent connections with the same UserID.

4. Google Analytics.

5. We do not handle DMCA notices, our data center partners do, and in all cases we do not keep logs so we cannot identify the customer.

6. We will stop updating our Warrant Canary. It has never happened before.

7. Allowed on all our servers.

8. We accept various payment methods: Credit card / PayPal / Cryptocurrency / Other national payments. All are linked by an email.

9. For general use 128bit AES, but we do offer 256bit AES as maximum encryption level.

10. On the next application update.

11. We don’t, but we do have a strong relationship with our partners who operate data centers.

12. We have 127 servers in around 33 countries and we try our best to expand to locations most requested by our customers.

VPN.ht website

VPN Land

1. We store only payment IP addresses for the reasons of fraud prevention, applies to Credit Card and PayPal payments. We don’t record or store information about what our clients do online and it is practically impossible to reverse track an external IP with a timestamp back to a real user.

2. VPNLand Inc., Canada

3. We use custom modified Radius databases to limit concurrent connections. We have AVs installed on all servers, and obvious known attacks are blocked at the firewall level.

4. We use ZenDesk (former Zopim online chat) online chat. Email and support databases are all in-house.

5. Ignored

6. We haven’t received any court order, thankfully. If there is a court order it will be evaluated first and then any action will be taken.

7. P2P is OK on all our VPN servers, except the US ones

8. We use Stripe, PayPal, PaymentWall, BitPay. As said above – IP addresses are logged only for fraud prevention purposes. Payment details are not linked to account usage

9. OpenVPN with AES-256-CBC key, SHA512 Hash Auth, and additional 2048 bit “tls-crypt” key

10. At this moment no, but the work is in progress and with our updated iOS, Android, Windows and Mac apps a “kill-switch” feature will be offered

11. We own half of our infrastructure in Canada, UK and Netherlands. In other countries we rent dedicated servers from hosting companies.

12. USA, Canada, UK, Netherlands, Germany, France, Sweden, Italy, Belgium, Luxembourg, Russian Federation, Singapore, Korea and Japan. VPN Land has no “virtual locations.”

VPN Land website

Hidester

1. We do not log any information that can link a VPN IP-address and timestamp to a specific user. We do not collect connecting IP addresses from our members when they are using Hidester VPN Service.

2. Our company is incorporated under the name of Hidester Limited. We are incorporated in Hong-Kong, as this country does not have any data retention laws or regulations.

3. As explained above, we do measure total traffic volume (incoming and outgoing) by our members on a daily basis, to avoid excessive consumption of bandwidth by abusive users that would significantly reduce quality of service for other members. So far, we do not have had any problem with any our members.

4. Our website analytics tool is Piwik and is self-hosted on our server. This tool records information about hidester.com website visitors, and is not linking in anyway website visitors with our Subscribed Members.

5. Our P2P-enabled servers are opened in countries known by us to not process DMCA or local equivalent. So we in case we receive such enquiry, we simply apologize that we CANNOT provide further information regarding our Member as we do not record the data needed to link traffic sources and destinations.

6. We will reply to such a court order that we do not know which users are using our servers and that we are not legally obliged to do so. This has not happened so far.

7. All P2P-enabled servers are identified in the server list window of Hidester VPN application by a small double arrow icon on the right side of the server name in the list. Some servers are not P2P-enabled for legal reasons (hosting countries could force us to shut them down in case of court summon).

8. We are using Paymentwall, PayPal, and CoinPayments as our payment providers. Paymentwall and PayPal collect payers IPs and we cannot guaranty full anonymity for our Members using Paymentwall (Credit Card) or PayPal. For full anonymity even at account creation level, we recommend our Members to use CoinPayments with many cryptocurrencies of their choice to ensure full anonymity.

But once again, our NO LOG on traffic data does not allow us to link data traffic sources and destinations, which was the cornerstone of our VPN software development on all computer applications (Mac / Windows / Linux).

9. Our most secure VPN protocol is OpenVPN, running with an AES-256-CBC TLS 2048 bits Encryption. We recommend using this one for torrenting, except for Members located in censored countries, where CamoVPN might provide a more stable connection.

10. We provide a kill switch function, as well as a DNS leak protection when using CamoVPN and OpenVPN protocols.

11. We use third-party hosting providers VPS servers. We mostly use well-recommended hosting providers which exist for a long time on the market. We use OpenDNS and Google DNS servers for our services.

12. We have servers located in over 33 countries, the full list is available here. We do not offer virtual locations.

Hidester website

BolehVPN

1. We do not keep any logs on our VPN servers that would allow us to do this.

2. BV Internet Services Limited, in the Seychelles.

3. Generally, we just look at network graphs and number of connections and see if there is any abnormal activity. We also block certain sensitive ports that are often used for hacking/spamming.

4. We use Zendesk to deal with support queries and do track referrals from affiliates. We also provide the option to send us PGP encrypted messages via e-mail and also Zendesk. We do not use Cloudflare.

5. We generally find providers that are friendly towards such DMCA notices or where it cannot be avoided, we just keep them as surfing/streaming servers with P2P disabled. These servers are more for geo-location or general purpose surfing rather than P2P. We at no times give out customer information to handle this.

6. We maintain a warrant canary which we do update once a month or when there is a request for information (even if we have not complied with it).

7. We marked a few servers as surfing-streaming, as they are on providers with strict DMCA requirements. All other servers support P2P and are not treated differently from any other traffic.

8. PayPal, Paymentwall, Coinpayments, Paydollar, MolPay, Z-Coin/Z-Cash, direct bank-in and we also accept direct Bitcoin/Dash payments.

9. We recommend OpenVPN, with our Cloak servers running AES-256 bit encryption as well as an XOR patch that obfuscates your traffic. This obfuscation prevents it from being recognized as VPN traffic.

10. Yes we do. Our leak prevention also includes IPv6.

11. They are bare metal boxes hosted in various providers. We use our own DNS servers.

12. Canada, France, Germany, Italy, Japan, Luxembourg, Malaysia, Netherlands, Singapore, Sweden, Switzerland, United Kingdom and USA.

BolehVPN website

SaferVPN

1. No logs, timestamps or IP addresses are kept whatsoever. At SaferVPN, we guarantee that we will never log your browsing activity, data, or IP addresses. This includes any websites you visited, any data you may have downloaded, shared or viewed, and any of your IP address or DNS queries.

In respecting everyone’s right to privacy, we also encrypt all of your data traffic, never share or sell any of your traffic details, never read your traffic, and never identify which traffic is yours.

2. SaferVPN operates under our Safer Social Limited company, under Israeli jurisdiction. Israel has strict privacy regulations which do not include a mandatory data retention policy and only apply specifically within the state.

3. Firstly, we do not monitor our users, and we keep no logs, period. That said, we have an active, proprietary system in place to help mitigate abuse. In addition, we also limit our simultaneous connections to five devices per user.

4. We use standard business tools including Google Analytics to improve our website and provide users with the most relevant information. We also use Zendesk as a secure third-party support platform and SendGrid for transactional emails. Our users’ information is never stored within these apps, rather in a separate proprietary database used solely for support and billing requirements.

Any information about how our customers use the VPN itself (such as browsing history, traffic data or DNS queries) is never revealed to third parties and is never logged or stored by SaferVPN.

5. We have not received any court orders as of yet, but in the case that we would be served with one, we would not be able to offer any information at all. We do not log IP addresses nor browsing activity, and we cannot match any activity to real IP addresses, even if we were asked by the court. We simply don’t have that data.

6. See above.

7. BitTorrent and other file-sharing traffic is welcome on our Dutch (NL) VPN servers without any throttling. It isn’t allowed on our other servers as stated in our Terms of Service, due to our agreements with data centers.

8. Our customers can pay via credit card, PayPal and Bitcoin. Payments are performed exclusively by third-party processors — BlueSnap for credit cards, PayPal for PayPal and CoinBase for Bitcoin — who only get the necessary data to verify the payment. As we don’t monitor account usage, payment details cannot be linked to any IP assignments.

9. In most cases we recommend (and default to) OpenVPN UDP and our cipher suite of AES-256 + RSA4096 + SHA256. Our apps use a 4096-bit CA, AES-256-CBC encryption, TLSv1.2, and SHA512 signatures to authenticate our servers. We use TLS 1.2 on all servers with enabled Perfect Forward Secrecy keys. At the same time, we also offer a wide range of VPN protocols, including OpenVPN, L2TP, IPsec, OpenConnect/AnyConnect (SSL VPN), and iKEV2 – we still offer PPTP for those of you who need it, but we don’t recommend it.

10. SaferVPN provides both an automatic app-level kill switch and a feature for DNS leak protection across all mobile and desktop platforms. We also ensure that our users enjoy Automatic Wi-Fi Security that activates immediate VPN protection across public Wi-Fi hotspots.

11. We use dedicated servers at premium data centers with strong security practices. Due to our special server configuration, no one can access, retain or collect any data. All servers have been set up with a zero logs policy, ensuring that no customer data nor activity is stored on any VPN server.

12. Our servers are physically located in over 34 countries, and across every continent except Antarctica (we’re working on that!).

SaferVPN website

HeadVPN

1. We DO NOT keep any logs. We do not store logs relating to traffic, session, DNS or metadata.

2. We’re registered in the United Kingdom under the name “HEADVPN LTD”

3. We use a pre-configured firewall which is configured by our own technology.

4. Google is the one mail external based system we use. We make standard use of Google Apps and Google Analytics. Of course, we provide 24/7 Live Chat support (powered by Tawk). All other support tools are kept internal for our users and visitors.

5. Since we don’t keep any information on any of our servers there is nothing that we can take down. If we receive a valid DMCA notice we can only take action if the connection is still active (we notify the user and stop the session).

6. We haven’t received any court orders. If that happens, the agency will be informed that no user information is available as we DO NOT keep log. In our practice this was not the case.

7. Yes, we allow P2P/BitTorrent downloading. For P2P/Bittorent traffic we have special VPN servers (which are located in a data center that allows such traffic). On other VPN servers, P2P/Bittorent traffic is blocked.

8. We accept all forms of Credit/Debit cards payments through the Stripe payment gateway, Bitcoins, QIWI, Yandex.Money, WebMoney, AliPay, CashU, iDeal, PaySafecard, and PayPal payment method. We do not store any billing information such as credit cards or addresses.

9. We provide all kinds of encryption methods, including PPTP, L2TP/IPsec, SSTP, OpenVPN and SoftEther protocols. We recommend using OpenVPN protocol as it’s the most secure and using RSA 4096 bit and AES 256 bit encryption keys.

10. We do not offer DNS leak protection via kill switches. DNS leak protection is best handled by using OpenVPN protocol (AES-256-CBC algorithm for encryption).

11. All our VPN servers are hosted in 3rd party data centers with the highest specifications for performance, reliability and security. We have direct access to each server and they all are running within RAM disks (which are fully encrypted).

12. Our VPN servers are located in the United Kingdom, United States, Germany and Netherlands. We do not offer virtual locations.

HeadVPN website

Zenmate

1. No, we do not keep any such logs. We do not monitor the bandwidth usage, nor the websites that users visit.

2. ZenMate is incorporated under the legal entity “ZenGuard GmbH”, registered and operating under German jurisdiction. Germany is known for its strict internet privacy and security laws, we are therefore bound to Germany’s data privacy rules. The latter are reflected in the company’s strict privacy policies, which are followed rigorously.

3. All of our VPN systems and tools that are used to prevent abuse are proprietary and maintained in-house.

4. For user support we use ZenDesk that holds the email address the user provided us and a name if the user added that to the support ticket. For our website we do use Google Analytics, but with the “anonymize_IP” setting enabled.

5. We answer that due to the absence of any user-related data in regards to the usage with ZenMate we cannot give any support to these authorities, as this kind of data is not logged.

6. Due to the absence of any log data we cannot give any historical data to these authorities. As of now, no judge was ever willing to sign a court order to make us start logging (in general, without a specific suspicion) in the future, as this would result in a breach of several other German/European laws. We therefore have been successfully defending our users’ rights for now more than five years, without having to fear any change anytime soon.

7. Yes, we allow all traffic on all servers – as we do not have any control over the user’s traffic at all.

8. We offer a variety of payment methods depending on the country you are located in. Among others, we support payments via VISA, MasterCard, American Express, PayPal, Sofort Banking. We do not process payments on our own. We contracted with Adyen B.V. as our payment provider for the processing of payments – who is fully PCI DSS and PCI SAQ compliant.

We do not have a linked connection between payment details (which is on Adyen’s side) and account usage (which we do not log) or IP assignment (which happens completely automatically), as these are completely different systems at two different companies.

9. We use the latest TLS 1.2 (RFC 5246) protocol and support different cipher suites with PFS (Default for Chrome is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) and up to TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. No known attack currently target these cyphers. AES 128 is preferred to AES 256. There have been discussions on whether AES 256 extra security was worth the cost, and the result is far from obvious. At the moment, AES 128 is preferred, since it provides bulletproof security, it is really fast and seems to be more resistant to timing attacks.

10. Yes, we provide kill switches in the browser extensions, Windows and Android.

11. We work with a small number of trusted partners that operate premium data centers with strong security practices. Nevertheless, due to the high encryption and the zero-logging policy even at an unauthorized access, the attacker could not get any information about the activity of a specific user, as there is none on our VPN servers.

12. With ZenMate you can relocate your IP address to hide your real location and circumvent network restrictions to unblock geo-restricted sites.

We are currently offering over 30 different country locations to choose from, for example: Germany, Romania, Hong Kong, United States, Austria, Australia, Belgium, Bulgaria, Canada, Czech Republic, Finland, France, Israel, Italy, Japan, Latvia, Luxembourg, Moldova, Netherlands, Norway, Poland, Russia, Singapore, South Africa, Spain, Sweden, Switzerland, Ukraine, United Kingdom, United States.

Zenmate website

Buffered

1. We do not keep any logs that can link a user to a certain IP address. We keep anonymized logs of some usage so that we can improve the service. No single user can ever be identified.

2. We are incorporated in Gibraltar as Buffered Ltd. All card payments are taken via this entity. We take payments on PayPal via our Hungarian subsidiary, which is fully owned by the Gibraltar company.

3. Our own internal tools monitor how many devices a user has connected.

4. We do not use any external email providers, we only use internal traffic analytics (no Google Analytics or any other tracking). We use Livechat.com for live support.

5. We are not a content provider, but a network/transit service, therefore DMCA requests are not applicable to us. If we do receive one we do not attempt to identify the user (since we cannot anyway).

6. This has not happened.

7. Yes, we do not interfere with traffic in this way.

8. We use Checkout.com and PayPal, and Bitpay for bitcoin payments. Since we do not store usage logs of users this cannot be linked to payment providers, however, users should be aware that paying for a VPN with anything other than bitcoin will make it easy to identify that you have at least paid for that particular VPN.

9. Even though blowfish is sufficiently secure, now with hardware-accelerated AES, this is faster than blowfish. Consequently, we are rolling this out everywhere as it greatly improves battery consumption and security, especially in resource-constrained environments like routers and mobiles.

10. Yes we do, we recently released a firewall based killswitch. It blocks all traffic in case of the VPN connection dropping.

11. We use our own DNS servers. We rent servers across the world from providers like Leaseweb and 100TB.

12. We offer connections in 45 countries, and there are no virtual locations.

Buffered website

VPN providers With Some Logs

Seed4.me

1. We do not analyze or DPI traffic. We also do not keep logs on VPN nodes. General connection logs are stored on a secure server for seven days to solve network issues if there are any (for example if VPN IP is blocked in China and needs replacement). These logs are deleted after seven days if there are no network problems.

2. Taiwan. Seed4.Me Inc. We are not aware of any legislation requiring to share client information and we are not aware of any precedents in Taiwan, where client information was disclosed. We do not hold much information anyway. On the other hand, we do not welcome illegal activities which potentially harm other people.

3. We use simple firewall rules to avoid some abuses in advance. Regarding concurrent connections: we do not have any limits when Client uses our Windows, MAC, iOS or Android app. When Customer sets up L2TP/PPTP VPN manually he has one simultaneous connections by default, this number can be increased and it’s totally free. We use our own solution to manage abusive accounts and limit concurrent L2TP/PPTP connections.

4. Currently, we utilize Google Analytics and G Suite (ex. Google Apps). Regarding G Suite, we do not store any sensitive information there, only support issues.

5. In case of abuse we null route the IP to keep ourselves in compliance with the DMCA. Currently, we use simple firewall rules to block torrents in countries where the DMCA applies.

6. We will act in accordance with the laws of the jurisdiction, only if court order comes from a jurisdiction where the affected server is located. Fortunately, as I said before, we do not keep any logs on VPN nodes, on the other hand – we do not encourage illegal activity. This never happened.

7. Torrents are allowed on our VPN servers in Switzerland, Sweden, and Latvia. This is torrent-friendly countries with high-quality data centers and networks.

8. We accept Bitcoin, PayPal, Visa, MasterCard, Webmoney, QIWI, Yandex.Money, Bank transfer and In-App purchases in our mobile apps. We do not store sensitive payment information on our servers, in most cases payment system simply sends us a notification about successful payment with the amount of payment. We validate this data and grant access to VPN. BTW, we do not require name of the cardholder when he pays for the VPN in our desktop app.

9. Obfuscated OpenVPN with 2048-bit key will be a good choice, it’s available in our Desktop and Android apps. Also our iOS App has Automatic protection option that guarantees for example that all outgoing connections on open Wi-Fi will be encrypted and passed through secure VPN channel.

10. Yes, we have a kill switch in our Desktop VPN app. Yes, we provide DNS leak protection in our Desktop VPN app.

11. All servers are remotely administered by our team only, no outsourcing. No data is stored on VPN nodes (if the node is confiscated, there will not be any data). We prefer to deal with trustworthy Tier-3 (PCI-DSS) data centers and providers to ensure reliable service with high security. As for DNS, we use Google, users can override these settings with their own.

12. Currently we offer VPN nodes in 21 location: USA, UK, Canada, France, Russia, Switzerland (torrent-friendly), Sweden (torrent-friendly), Belgium, Ukraine, Latvia (torrent-friendly), Bulgaria, Netherlands, Spain, Germany, Italy, India, Hong Kong, Singapore, Israel, Taiwan and South Korea.

We offer one virtual location. Currently, we try not to fake IP locations and provide real IPs directly from the country where the VPN server is physically located.

Seed4.me website

VPN.ac

1. We keep connection logs for one day to help us in troubleshooting customers’ connection problems but also to identify attacks (e.g. bruteforce, account theft). This information contains IP address, connection start and end time, protocol used (including port) and amount of data transferred.

2. Netsec Interactive Solutions SRL, registered in Romania.

3. There are automated firewall rules that can kick-in in the event of some specific abusive activities, manual intervention can be done when absolutely necessary in order to maintain the infrastructure stable and reliable for everyone. Concurrent connections are limited by the authentication back-ends.

4. No.

5. We are handling DMCA complaints internally without involving the users (i.e. we are not forwarding anything). We use shared IP addresses so it’s not possible to identify the users.

6. It never happened. In such event, we would rely on legal advice.

7. It is allowed.

8. All major cryptocurrencies, PayPal, credit cards, Perfect Money, several country-specific payment methods, gift cards. Payment with cryptocurrencies can be anonymous.

9. OpenVPN using Elliptic Curve Cryptography for Key Exchange (ECDHE, curve secp256k1) is used by default in most cases. We also support RSA-4096, SHA256 and SHA512 for digest/HMAC. For data encryption we use AES-256-GCM and AES-128-GCM.

10. Yes, such features are embedded in our client software.

11. We have physical control of our servers in Romania. In other countries, we rent or collocate our hardware. We use our own DNS resolvers and all DNS traffic between VPN gateways and DNS resolvers is encrypted.

12. We don’t use “virtual locations”. All servers are physically located in several countries (and growing), such as: Australia, Canada, Switzerland, Germany, Spain, Finland, France, Hong Kong, Italy, Japan, South Korea, Lithuania, Luxembourg, Mexico, Netherlands, Norway, Poland, Portugal, Romania, Sweden, Singapore, Taiwan, UK, USA.

VPN.ac website

IronSocket

1. We keep limited session logs for all of our services. These logs record the duration of a connection, the IP address used for the connection and the number of bytes transferred.

These logs are typically kept for 72 hours, usually less, after which they are purged. We log this data for fraud and abuse detection/prevention. Since we use shared IPs on our servers, and do not log activity, it is difficult to associate specific activity with individual users.

2. IronSocket is owned and operated by Pusa and Daga Hong Kong Limited in the jurisdiction of the Hong Kong Special Administrative Region.

3. We do not use any third-party email providers or support tools. We use Google Analytics and HasOffers which have minimal visitor tracking information used for website usage reporting and management of our affiliate program, respectively.

4. IronSocket is not subject to the DMCA or any international equivalent. We do NOT host any user-uploaded content on any of our servers. While IronSocket is not subject to DMCA, some of our hosting and data center partners reside in locations that are. If they escalate a DMCA notice to us, we reply to the provider that we are a service provider like them, and that we do not log our user’s activity.

5. This has not happened. It is our policy to cooperate with legal orders that are valid under Hong Kong SAR law. The process to address such request is: (A) Verify the order is legal and valid. (B) Consult with legal counsel to determine what we are required to provide. (C) Determine if we have the data being requested.

Because of our privacy policy, terms of service, shared IP usage, and anonymous payment methods, it would be difficult to impossible to associate a specific activity with an individual user.

6. P2P traffic is allowed on servers in countries where such traffic is not restricted. We do not allow P2P on all servers due to the legal pressure on the data centers in certain regions of the world. All traffic is treated equally on our network.

7. We accept credit / debit card payments via SafeCharge and PayPal. Bitcoin transactions are processed by BitPay and major US brand gift cards are handled by PayGarden. We do not collect sensitive payment information. Any sensitive payment information is maintained by each respective payment processor and is linked by a unique transaction number.

8. OpenVPN with strong encryption: AES 256-bit encryption with SHA256 message authentication, using a 4096-bit key for secure authentication.

9. We are currently beta testing a new client for Microsoft Windows systems that offers DNS leak protection and VPN drop protection. VPN drop protection has the option of killing specific applications or the system’s network connection.

10. We are currently beta testing a new client for Microsoft Windows systems that offers support for the OpenVPN, L2TP, and PPTP VPN protocols.

11. We host and maintain our own DNS servers. We manage all our VPN servers but they are hosted and maintained by third-party data centers. We vet all providers prior to engaging their services and we continuously evaluate the quality of service and responsiveness to our requirements and requests.

12. We have hundreds of servers in 38 different countries and are always adding more. The most up-to-date list can be found here.

IronSocket website

—–

Note: several of the providers listed in this article are TorrentFreak sponsors. We reserve the first three spots for our sponsors, as a courtesy.

VPN providers who want to be in future question rounds are free to get in touch.

Source: TF, for the latest info on copyright, file-sharing, torrent sites and more. We also have VPN discounts, offers and coupons

The Challenges of Opening a Data Center — Part 2

2018-03-02 Roderick Bauer

Post Syndicated from Roderick Bauer original https://www.backblaze.com/blog/factors-for-choosing-data-center/

This is part two of a series on the factors that an organization needs to consider when opening a data center and the challenges that must be met in the process.

In Part 1 of this series, we looked at the different types of data centers, the importance of location in planning a data center, data center certification, and the single most expensive factor in running a data center, power.

In Part 2, we continue to look at factors that need to considered both by those interested in a dedicated data center and those seeking to colocate in an existing center.

Power (continued from Part 1)

In part 1, we began our discussion of the power requirements of data centers.

As we discussed, redundancy and failover is a chief requirement for data center power. A redundantly designed power supply system is also a necessity for maintenance, as it enables repairs to be performed on one network, for example, without having to turn off servers, databases, or electrical equipment.

Power Path

The common critical components of a data center’s power flow are:

Utility Supply
Generators
Transfer Switches
Distribution Panels
Uninterruptible Power Supplies (UPS)
PDUs

Utility Supply is the power that comes from one or more utility grids. While most of us consider the grid to be our primary power supply (hats off to those of you who manage to live off the grid), politics, economics, and distribution make utility supply power susceptible to outages, which is why data centers must have autonomous power available to maintain availability.

Generators are used to supply power when the utility supply is unavailable. They convert mechanical energy, usually from motors, to electrical energy.

Transfer Switches are used to transfer electric load from one source or electrical device to another, such as from one utility line to another, from a generator to a utility, or between generators. The transfer could be manually activated or automatic to ensure continuous electrical power.

Distribution Panels get the power where it needs to go, taking a power feed and dividing it into separate circuits to supply multiple loads.

A UPS, as we touched on earlier, ensures that continuous power is available even when the main power source isn’t. It often consists of batteries that can come online almost instantaneously when the current power ceases. The power from a UPS does not have to last a long time as it is considered an emergency measure until the main power source can be restored. Another function of the UPS is to filter and stabilize the power from the main power supply.

Data center UPSs

PDU stands for the Power Distribution Unit and is the device that distributes power to the individual pieces of equipment.

Network

After power, the networking connections to the data center are of prime importance. Can the data center obtain and maintain high-speed networking connections to the building? With networking, as with all aspects of a data center, availability is a primary consideration. Data center designers think of all possible ways service can be interrupted or lost, even briefly. Details such as the vulnerabilities in the route the network connections make from the core network (the backhaul) to the center, and where network connections enter and exit a building, must be taken into consideration in network and data center design.

Routers and switches are used to transport traffic between the servers in the data center and the core network. Just as with power, network redundancy is a prime factor in maintaining availability of data center services. Two or more upstream service providers are required to ensure that availability.

How fast a customer can transfer data to a data center is affected by: 1) the speed of the connections the data center has with the outside world, 2) the quality of the connections between the customer and the data center, and 3) the distance of the route from customer to the data center. The longer the length of the route and the greater the number of packets that must be transferred, the more significant a factor will be played by latency in the data transfer. Latency is the delay before a transfer of data begins following an instruction for its transfer. Generally latency, not speed, will be the most significant factor in transferring data to and from a data center. Packets transferred using the TCP/IP protocol suite, which is the conceptual model and set of communications protocols used on the internet and similar computer networks, must be acknowledged when received (ACK’d) and requires a communications roundtrip for each packet. If the data is in larger packets, the number of ACKs required is reduced, so latency will be a smaller factor in the overall network communications speed.

Latency generally will be less significant for data storage transfers than for cloud computing. Optimizations such as multi-threading, which is used in Backblaze’s Cloud Backup service, will generally improve overall transfer throughput if sufficient bandwidth is available.

Those interested in testing the overall speed and latency of their connection to Backblaze’s data centers can use the Check Your Bandwidth tool on our website.

Data center telecommunications equipment

Data center under floor cable runs

Cooling

Computer, networking, and power generation equipment generates heat, and there are a number of solutions employed to rid a data center of that heat. The location and climate of the data center is of great importance to the data center designer because the climatic conditions dictate to a large degree what cooling technologies should be deployed that in turn affect the power used and the cost of using that power. The power required and cost needed to manage a data center in a warm, humid climate will vary greatly from managing one in a cool, dry climate. Innovation is strong in this area and many new approaches to efficient and cost-effective cooling are used in the latest data centers.

Switch’s uninterruptible, multi-system, HVAC Data Center Cooling Units

There are three primary ways data center cooling can be achieved:

Room Cooling cools the entire operating area of the data center. This method can be suitable for small data centers, but becomes more difficult and inefficient as IT equipment density and center size increase.

Row Cooling concentrates on cooling a data center on a row by row basis. In its simplest form, hot aisle/cold aisle data center design involves lining up server racks in alternating rows with cold air intakes facing one way and hot air exhausts facing the other. The rows composed of rack fronts are called cold aisles. Typically, cold aisles face air conditioner output ducts. The rows the heated exhausts pour into are called hot aisles. Typically, hot aisles face air conditioner return ducts.

Rack Cooling tackles cooling on a rack by rack basis. Air-conditioning units are dedicated to specific racks. This approach allows for maximum densities to be deployed per rack. This works best in data centers with fully loaded racks, otherwise there would be too much cooling capacity, and the air-conditioning losses alone could exceed the total IT load.

Security

Data Centers are high-security facilities as they house business, government, and other data that contains personal, financial, and other secure information about businesses and individuals.

This list contains the physical-security considerations when opening or co-locating in a data center:

Layered Security Zones. Systems and processes are deployed to allow only authorized personnel in certain areas of the data center. Examples include keycard access, alarm systems, mantraps, secure doors, and staffed checkpoints.

Physical Barriers. Physical barriers, fencing and reinforced walls are used to protect facilities. In a colocation facility, one customers’ racks and servers are often inaccessible to other customers colocating in the same data center.

Backblaze racks secured in the data center

Monitoring Systems. Advanced surveillance technology monitors and records activity on approaching driveways, building entrances, exits, loading areas, and equipment areas. These systems also can be used to monitor and detect fire and water emergencies, providing early detection and notification before significant damage results.

Top-tier providers evaluate their data center security and facilities on an ongoing basis. Technology becomes outdated quickly, so providers must stay-on-top of new approaches and technologies in order to protect valuable IT assets.

To pass into high security areas of a data center requires passing through a security checkpoint where credentials are verified.

The gauntlet of cameras and steel bars one must pass before entering this data center

Facilities and Services

Data center colocation providers often differentiate themselves by offering value-added services. In addition to the required space, power, cooling, connectivity and security capabilities, the best solutions provide several on-site amenities. These accommodations include offices and workstations, conference rooms, and access to phones, copy machines, and office equipment.

Additional features may consist of kitchen facilities, break rooms and relaxation lounges, storage facilities for client equipment, and secure loading docks and freight elevators.

Moving into A Data Center

Moving into a data center is a major job for any organization. We wrote a post last year, Desert To Data in 7 Days — Our New Phoenix Data Center, about what it was like to move into our new data center in Phoenix, Arizona.

Desert To Data in 7 Days — Our New Phoenix Data Center

Visiting a Data Center

Our Director of Product Marketing Andy Klein wrote a popular post last year on what it’s like to visit a data center called A Day in the Life of a Data Center.

A Day in the Life of a Data Center

Would you Like to Know More about The Challenges of Opening and Running a Data Center?

That’s it for part 2 of this series. If readers are interested, we could write a post about some of the new technologies and trends affecting data center design and use. Please let us know in the comments.

Here’s a tip on finding all the posts tagged with data center on our blog. Just follow https://www.backblaze.com/blog/tag/data-center/.

Don’t miss future posts on data centers and other topics, including hard drive stats, cloud storage, and tips and tricks for backing up to the cloud. Use the Join button above to receive notification of future posts on our blog.

The post The Challenges of Opening a Data Center — Part 2 appeared first on Backblaze Blog | Cloud Storage & Cloud Backup.

BMG Wants Appeals Court to Rehear Cox Piracy Liability Case

2018-02-26 Ernesto

Post Syndicated from Ernesto original https://torrentfreak.com/bmg-wants-appeals-court-to-rehear-cox-piracy-liability-case-180226/

Earlier this month, the Court of Appeals for the Fourth Circuit overturned the $25 million piracy liability verdict against Internet provider Cox.

The panel of three judges concluded that the district court made an error in its jury instruction and ordered a new trial.

The erroneous instruction said that the ISP could be found liable for contributory infringement if it “knew or should have known of such infringing activity.” The Court of Appeals agrees that based on the law, the “should have known” standard is too low.

As a result of the ruling, music publisher BMG Rights Management and Cox would have to go head to head again in a new trial. However, according to BMG, the Court of Appeals itself made a mistake.

A few days ago the copyright holder petitioned the court for a rehearing en banc, asking for a do-over before all the judges of a court.

The music publisher argues that the appeals court judges mistakenly reached their decision based on a legal principle that applies to “inducement” of liability, while BMG was pursuing a claim of “material contribution.”

“The panel’s unprecedented application of a heightened knowledge standard creates a conflict with decisions and pattern jury instructions from other circuits as well as with the common-law rules underlying contributory infringement.

“All of those recognize that BMG’s material-contribution theory requires only constructive knowledge,” BMG’s brief adds.

Even if the appeals court persists with its assertion that the liability standard is “willful blindness” rather than “should have known,” a new trial would not be warranted, according to the music publisher.

They point out that plenty of evidence was presented which proved that Cox was wilfully blind to the copyright infringements and describe the erroneous instruction as a “harmless error of the most benign kind.”

The music publisher’s request for a rehearing is supported by the RIAA, which filed an amicus curiae brief together with the National Music Publishers Association.

Both music industry groups back BMG’s arguments and ask the appeals court to consider a rehearing, stating that it would be in the best interests of artists, songwriters, and other rightsholders.

“The level of copyright infringement that takes place over the Internet is ‘staggering,’ and it is vital that copyright owners have effective mechanisms to address it. It is also critical that copyright owners can adequately address infringement that occurs in other contexts.

“If the panel’s decision is not corrected, it would threaten the very incentives of artists, songwriters, and others to create valuable works and distribute them to the public,” the RIAA and NMPA add.

For the RIAA the case is particularly important since it filed a similar lawsuit against Internet provider Grande Communications last year.

Given what’s at stake, we can assume that Cox will protest the request for a rehearing. And it wouldn’t be a big surprise if other telecommunications companies take the same position.

—

BMG’s petition is available here (pdf) and a copy of the RIAA/NMPA motion can be found here (pdf).

Source: TF, for the latest info on copyright, file-sharing, torrent sites and more. We also have VPN discounts, offers and coupons

Getting product security engineering right

2018-02-25 Michal Zalewski

Post Syndicated from Michal Zalewski original http://lcamtuf.blogspot.com/2018/02/getting-product-security-engineering.html

Product security is an interesting animal: it is a uniquely cross-disciplinary endeavor that spans policy, consulting,
process automation, in-depth software engineering, and cutting-edge vulnerability research. And in contrast to many
other specializations in our field of expertise – say, incident response or network security – we have virtually no
time-tested and coherent frameworks for setting it up within a company of any size.

In my previous post, I shared some thoughts
on nurturing technical organizations and cultivating the right kind of leadership within. Today, I figured it would
be fitting to follow up with several notes on what I learned about structuring product security work – and about actually
making the effort count.

The “comfort zone” trap

For security engineers, knowing your limits is a sought-after quality: there is nothing more dangerous than a security
expert who goes off script and starts dispensing authoritatively-sounding but bogus advice on a topic they know very
little about. But that same quality can be destructive when it prevents us from growing beyond our most familiar role: that of
a critic who pokes holes in other people’s designs.

The role of a resident security critic lends itself all too easily to a sense of supremacy: the mistaken
belief that our cognitive skills exceed the capabilities of the engineers and product managers who come to us for help
– and that the cool bugs we file are the ultimate proof of our special gift. We start taking pride in the mere act
of breaking somebody else’s software – and then write scathing but ineffectual critiques addressed to executives,
demanding that they either put a stop to a project or sign off on a risk. And hey, in the latter case, they better
brace for our triumphant “I told you so” at some later date.

Of course, escalations of this type have their place, but they need to be a very rare sight; when practiced routinely, they are a telltale
sign of a dysfunctional team. We might be failing to think up viable alternatives that are in tune with business or engineering needs; we might
be very unpersuasive, failing to communicate with other rational people in a language they understand; or it might be that our tolerance for risk
is badly out of whack with the rest of the company. Whatever the cause, I’ve seen high-level escalations where the security team
spoke of valiant efforts to resist inexplicably awful design decisions or data sharing setups; and where product leads in turn talked about
pressing business needs randomly blocked by obstinate security folks. Sometimes, simply having them compare their notes would be enough to arrive
at a technical solution – such as sharing a less sensitive subset of the data at hand.

To be effective, any product security program must be rooted in a partnership with the rest of the company, focused on helping them get stuff done
while eliminating or reducing security risks. To combat the toxic us-versus-them mentality, I found it helpful to have some team members with
software engineering backgrounds, even if it’s the ownership of a small open-source project or so. This can broaden our horizons, helping us see
that we all make the same mistakes – and that not every solution that sounds good on paper is usable once we code it up.

Getting off the treadmill

All security programs involve a good chunk of operational work. For product security, this can be a combination of product launch reviews, design consulting requests, incoming bug reports, or compliance-driven assessments of some sort. And curiously, such reactive work also has the property of gradually expanding to consume all the available resources on a team: next year is bound to bring even more review requests, even more regulatory hurdles, and even more incoming bugs to triage and fix.

Being more tractable, such routine tasks are also more readily enshrined in SDLs, SLAs, and all kinds of other official documents that are often mistaken for a mission statement that justifies the existence of our teams. Soon, instead of explaining to a developer why they should fix a particular problem right away, we end up pointing them to page 17 in our severity classification guideline, which defines that “severity 2” vulnerabilities need to be resolved within a month. Meanwhile, another policy may be telling them that they need to run a fuzzer or a web application scanner for a particular number of CPU-hours – no matter whether it makes sense or whether the job is set up right.

To run a product security program that scales sublinearly, stays abreast of future threats, and doesn’t erect bureaucratic speed bumps just for the sake of it, we need to recognize this inherent tendency for operational work to take over – and we need to reign it in. No matter what the last year’s policy says, we usually don’t need to be doing security reviews with a particular cadence or to a particular depth; if we need to scale them back 10% to staff a two-quarter project that fixes an important API and squashes an entire class of bugs, it’s a short-term risk we should feel empowered to take.

As noted in my earlier post, I find contingency planning to be a valuable tool in this regard: why not ask ourselves how the team would cope if the workload went up another 30%, but bad financial results precluded any team growth? It’s actually fun to think about such hypotheticals ahead of the time – and hey, if the ideas sound good, why not try them out today?

Living for a cause

It can be difficult to understand if our security efforts are structured and prioritized right; when faced with such uncertainty, it is natural to stick to the safe fundamentals – investing most of our resources into the very same things that everybody else in our industry appears to be focusing on today.

I think it’s important to combat this mindset – and if so, we might as well tackle it head on. Rather than focusing on tactical objectives and policy documents, try to write down a concise mission statement explaining why you are a team in the first place, what specific business outcomes you are aiming for, how do you prioritize it, and how you want it all to change in a year or two. It should be a fluid narrative that reads right and that everybody on your team can take pride in; my favorite way of starting the conversation is telling folks that we could always have a new VP tomorrow – and that the VP’s first order of business could be asking, “why do you have so many people here and how do I know they are doing the right thing?”. It’s a playful but realistic framing device that motivates people to get it done.

In general, a comprehensive product security program should probably start with the assumption that no matter how many resources we have at our disposal, we will never be able to stay in the loop on everything that’s happening across the company – and even if we did, we’re not going to be able to catch every single bug. It follows that one of our top priorities for the team should be making sure that bugs don’t happen very often; a scalable way of getting there is equipping engineers with intuitive and usable tools that make it easy to perform common tasks without having to worry about security at all. Examples include standardized, managed containers for production jobs; safe-by-default APIs, such as strict contextual autoescaping for XSS or type safety for SQL; security-conscious style guidelines; or plug-and-play libraries that take care of common crypto or ACL enforcement tasks.

Of course, not all problems can be addressed on framework level, and not every engineer will always reach for the right tools. Because of this, the next principle that I found to be worth focusing on is containment and mitigation: making sure that bugs are difficult to exploit when they happen, or that the damage is kept in check. The solutions in this space can range from low-level enhancements (say, hardened allocators or seccomp-bpf sandboxes) to client-facing features such as browser origin isolation or Content Security Policy.

The usual consulting, review, and outreach tasks are an important facet of a product security program, but probably shouldn’t be the sole focus of your team. It’s also best to avoid undue emphasis on vulnerability showmanship: while valuable in some contexts, it creates a hypercompetitive environment that may be hostile to less experienced team members – not to mention, squashing individual bugs offers very limited value if the same issue is likely to be reintroduced into the codebase the next day. I like to think of security reviews as a teaching opportunity instead: it’s a way to raise awareness, form partnerships with engineers, and help them develop lasting habits that reduce the incidence of bugs. Metrics to understand the impact of your work are important, too; if your engagements are seen mostly as a yet another layer of red tape, product teams will stop reaching out to you for advice.

The other tenet of a healthy product security effort requires us to recognize at a scale and given enough time, every defense mechanism is bound to fail – and so, we need ways to prevent bugs from turning into incidents. The efforts in this space may range from developing product-specific signals for the incident response and monitoring teams; to offering meaningful vulnerability reward programs and nourishing a healthy and respectful relationship with the research community; to organizing regular offensive exercises in hopes of spotting bugs before anybody else does.

Oh, one final note: an important feature of a healthy security program is the existence of multiple feedback loops that help you spot problems without the need to micromanage the organization and without being deathly afraid of taking chances. For example, the data coming from bug bounty programs, if analyzed correctly, offers a wonderful way to alert you to systemic problems in your codebase – and later on, to measure the impact of any remediation and hardening work.

Amazon Redshift – 2017 Recap

2018-02-23 Larry Heathcote

Post Syndicated from Larry Heathcote original https://aws.amazon.com/blogs/big-data/amazon-redshift-2017-recap/

We have been busy adding new features and capabilities to Amazon Redshift, and we wanted to give you a glimpse of what we’ve been doing over the past year. In this article, we recap a few of our enhancements and provide a set of resources that you can use to learn more and get the most out of your Amazon Redshift implementation.

In 2017, we made more than 30 announcements about Amazon Redshift. We listened to you, our customers, and delivered Redshift Spectrum, a feature of Amazon Redshift, that gives you the ability to extend analytics to your data lake—without moving data. We launched new DC2 nodes, doubling performance at the same price. We also announced many new features that provide greater scalability, better performance, more automation, and easier ways to manage your analytics workloads.

To see a full list of our launches, visit our what’s new page—and be sure to subscribe to our RSS feed.

Major launches in 2017

Amazon Redshift Spectrum—extend analytics to your data lake, without moving data

We launched Amazon Redshift Spectrum to give you the freedom to store data in Amazon S3, in open file formats, and have it available for analytics without the need to load it into your Amazon Redshift cluster. It enables you to easily join datasets across Redshift clusters and S3 to provide unique insights that you would not be able to obtain by querying independent data silos.

With Redshift Spectrum, you can run SQL queries against data in an Amazon S3 data lake as easily as you analyze data stored in Amazon Redshift. And you can do it without loading data or resizing the Amazon Redshift cluster based on growing data volumes. Redshift Spectrum separates compute and storage to meet workload demands for data size, concurrency, and performance. Redshift Spectrum scales processing across thousands of nodes, so results are fast, even with massive datasets and complex queries. You can query open file formats that you already use—such as Apache Avro, CSV, Grok, ORC, Apache Parquet, RCFile, RegexSerDe, SequenceFile, TextFile, and TSV—directly in Amazon S3, without any data movement.

“For complex queries, Redshift Spectrum provided a 67 percent performance gain,” said Rafi Ton, CEO, NUVIAD. “Using the Parquet data format, Redshift Spectrum delivered an 80 percent performance improvement. For us, this was substantial.”

To learn more about Redshift Spectrum, watch our AWS Summit session Intro to Amazon Redshift Spectrum: Now Query Exabytes of Data in S3, and read our announcement blog post Amazon Redshift Spectrum – Exabyte-Scale In-Place Queries of S3 Data.

DC2 nodes—twice the performance of DC1 at the same price

We launched second-generation Dense Compute (DC2) nodes to provide low latency and high throughput for demanding data warehousing workloads. DC2 nodes feature powerful Intel E5-2686 v4 (Broadwell) CPUs, fast DDR4 memory, and NVMe-based solid state disks (SSDs). We’ve tuned Amazon Redshift to take advantage of the better CPU, network, and disk on DC2 nodes, providing up to twice the performance of DC1 at the same price. Our DC2.8xlarge instances now provide twice the memory per slice of data and an optimized storage layout with 30 percent better storage utilization.

“Redshift allows us to quickly spin up clusters and provide our data scientists with a fast and easy method to access data and generate insights,” said Bradley Todd, technology architect at Liberty Mutual. “We saw a 9x reduction in month-end reporting time with Redshift DC2 nodes as compared to DC1.”

Read our customer testimonials to see the performance gains our customers are experiencing with DC2 nodes. To learn more, read our blog post Amazon Redshift Dense Compute (DC2) Nodes Deliver Twice the Performance as DC1 at the Same Price.

Performance enhancements— 3x-5x faster queries

On average, our customers are seeing 3x to 5x performance gains for most of their critical workloads.

We introduced short query acceleration to speed up execution of queries such as reports, dashboards, and interactive analysis. Short query acceleration uses machine learning to predict the execution time of a query, and to move short running queries to an express short query queue for faster processing.

We launched results caching to deliver sub-second response times for queries that are repeated, such as dashboards, visualizations, and those from BI tools. Results caching has an added benefit of freeing up resources to improve the performance of all other queries.

We also introduced late materialization to reduce the amount of data scanned for queries with predicate filters by batching and factoring in the filtering of predicates before fetching data blocks in the next column. For example, if only 10 percent of the table rows satisfy the predicate filters, Amazon Redshift can potentially save 90 percent of the I/O for the remaining columns to improve query performance.

We launched query monitoring rules and pre-defined rule templates. These features make it easier for you to set metrics-based performance boundaries for workload management (WLM) queries, and specify what action to take when a query goes beyond those boundaries. For example, for a queue that’s dedicated to short-running queries, you might create a rule that aborts queries that run for more than 60 seconds. To track poorly designed queries, you might have another rule that logs queries that contain nested loops.

Customer insights

Amazon Redshift and Redshift Spectrum serve customers across a variety of industries and sizes, from startups to large enterprises. Visit our customer page to see the success that customers are having with our recent enhancements. Learn how companies like Liberty Mutual Insurance saw a 9x reduction in month-end reporting time using DC2 nodes. On this page, you can find case studies, videos, and other content that show how our customers are using Amazon Redshift to drive innovation and business results.

In addition, check out these resources to learn about the success our customers are having building out a data warehouse and data lake integration solution with Amazon Redshift:

Sysco: Developing an Insights Platform – Sysco’s Journey from Disparate Systems to a Data Lake and Beyond (re:Invent session recording)
21^st Century Fox: Migrating Your Traditional Data Warehouse to a Modern Data Lake (re:Invent session recording)
Cerberus Technologies: How I built a data warehouse using Amazon Redshift and AWS services in record time (blog post)
NUVIAD: Using Amazon Redshift Spectrum, Amazon Athena, and AWS Glue with Node.js in Production (blog post)
Periscope Data: Making Every Redshift Query Valuable with Periscope Data (This is My Architecture episode)
Lyft Case Study
Boingo Wireless Case Study

Partner solutions

You can enhance your Amazon Redshift data warehouse by working with industry-leading experts. Our AWS Partner Network (APN) Partners have certified their solutions to work with Amazon Redshift. They offer software, tools, integration, and consulting services to help you at every step. Visit our Amazon Redshift Partner page and choose an APN Partner. Or, use AWS Marketplace to find and immediately start using third-party software.

To see what our Partners are saying about Amazon Redshift Spectrum and our DC2 nodes mentioned earlier, read these blog posts:

Looker: Using Amazon Redshift’s new Spectrum Feature
Matillion: Accessing your Data Lake Assets from Amazon Redshift Spectrum
Periscope Data: Amazon Redshift’s Hardware Upgrade Improves Query Speed by up to 5x
Reflect: The Implications of Redshift Spectrum
SnapLogic: Integrate through the big data insights gap
Tableau: Tableau 10.4 Supports Amazon Redshift Spectrum with External Amazon S3 Tables

Resources

Blog posts

Visit the AWS Big Data Blog for a list of all Amazon Redshift articles.

YouTube videos

re:Invent session recording: Best Practices for Data Warehousing with Amazon Redshift
AWS Online Tech Talk: Analyze your Data Lake, Fast @ Any Scale
AWS Online Tech Talk: Amazon Redshift Spectrum: Quickly Query Exabytes of Data in S3

GitHub

Our community of experts contribute on GitHub to provide tips and hints that can help you get the most out of your deployment. Visit GitHub frequently to get the latest technical guidance, code samples, administrative task automation utilities, the analyze & vacuum schema utility, and more.

Customer support

If you are evaluating or considering a proof of concept with Amazon Redshift, or you need assistance migrating your on-premises or other cloud-based data warehouse to Amazon Redshift, our team of product experts and solutions architects can help you with architecting, sizing, and optimizing your data warehouse. Contact us using this support request form, and let us know how we can assist you.

If you are an Amazon Redshift customer, we offer a no-cost health check program. Our team of database engineers and solutions architects give you recommendations for optimizing Amazon Redshift and Amazon Redshift Spectrum for your specific workloads. To learn more, email us at [email protected].

If you have any questions, email us at [email protected].

Additional Reading

If you found this post useful, be sure to check out Amazon Redshift Spectrum – Exabyte-Scale In-Place Queries of S3 Data, Using Amazon Redshift for Fast Analytical Reports and How to Migrate Your Oracle Data Warehouse to Amazon Redshift Using AWS SCT and AWS DMS.

About the Author

Larry Heathcote is a Principle Product Marketing Manager at Amazon Web Services for data warehousing and analytics. Larry is passionate about seeing the results of data-driven insights on business outcomes. He enjoys family time, home projects, grilling out and the taste of classic barbeque.

Organizational structure in Organizations

How Service Control Policy evaluation logic works

An example structure with nested OUs and SCPs

Conclusion

So, you’ve got it enabled, now what can GuardDuty detect?

What’s new?

It’s still day one

New GuardDuty CloudTrail-based anomaly detections

New GuardDuty threat intelligence based detections

Preventing your Amazon S3 buckets and objects from allowing public access

Securing data on Amazon S3 with defense-in-depth

Defense-in-depth requirement 1: Data must be encrypted at rest and during transit

Defense-in-depth requirement 2: Data must be accessible only by a limited set of public IP addresses

Defense-in-depth requirement 3: Data must not be publicly accessible directly from an Amazon S3 URL

Defense-in-depth requirement 4: A domain name is required to consume the content

Summary

Solution overview

Assessing the current state

Setting up alarms

What to do when an alarm triggers

Extensions and adaptations

Removing unwanted alarms

Conclusion

Additional Reading

About the Author

HDDs vs SSDs

What Are HDDs?

What Are SSDs?

Stay Tuned for Part 2 of HDD vs SSD

VPN providers With Some Logs

Power (continued from Part 1)

Power Path

Network

Cooling

Security

Facilities and Services

Moving into A Data Center

Visiting a Data Center

Would you Like to Know More about The Challenges of Opening and Running a Data Center?

The “comfort zone” trap

Getting off the treadmill

Living for a cause

Major launches in 2017

Customer insights

Partner solutions

Resources

Customer support

Additional Reading

About the Author

The collective thoughts of the interwebz