Tag Archives: domain

Tamilrockers Arrests: Police Parade Alleged Movie Pirates on TV

Post Syndicated from Andy original https://torrentfreak.com/tamilrockers-arrests-police-parade-alleged-movie-pirates-on-tv-180315/

Just two years ago around 277 million people used the Internet in India. Today there are estimates as high as 355 million and with a population of more than 1.3 billion, India has plenty of growth yet to come.

Also evident is that in addition to a thirst for hard work, many Internet-enabled Indians have developed a taste for Internet piracy. While the US and Europe were the most likely bases for pirate site operators between 2000 and 2015, India now appears in a growing number of cases, from torrent and streaming platforms to movie release groups.

One site that is clearly Indian-focused is the ever-popular Tamilrockers. The movie has laughed in the face of the authorities for a number of years, skipping from domain to domain as efforts to block the site descend into a chaotic game of whack-a-mole. Like The Pirate Bay, Tamilrockers has burned through plenty of domains including tamilrockers.in, tamilrockers.ac, tamilrockers.me, tamilrockers.co, tamilrockers.is, tamilrockers.us and tamilrockers.ro.

Now, however, the authorities are claiming a significant victory against the so-far elusive operators of the site. The anti-piracy cell of the Kerala police announced last evening that they’ve arrested five men said to be behind both Tamilrockers and alleged sister site, DVDRockers.

They’re named as alleged Tamilrockers owner ‘Prabhu’, plus ‘Karthi’ and ‘Suresh’ (all aged 24), plus alleged DVD Rockers owner ‘Johnson’ and ‘Jagan’ (elsewhere reported as ‘Maria John’). The men were said to be generating between US$1,500 and US$3,000 each per month. The average salary in India is around $600 per annum.

While details of how the suspects were caught tend to come later in US and European cases, the Indian authorities are more forthright. According to Anti-Piracy Cell Superintendent B.K. Prasanthan, who headed the team that apprehended the men, it was a trail of advertising revenue crumbs that led them to the suspects.

Prasanthan revealed that it was an email, sent by a Haryana-based ad company to an individual who was arrested in 2016 in a similar case, that helped in tracking the members of Tamilrockers.

“This ad company had sent a mail to [the individual], offering to publish ads on the website he was running. In that email, the company happened to mention that they have ties with Tamilrockers. We got the information about Tamilrockers through this ad company,” Prasanthan said.

That information included the bank account details of the suspects.

Given the technical nature of the sites, it’s perhaps no surprise that the suspects are qualified in the IT field. Prasanthan revealed that all had done well.

“All the gang members were technically qualified. It even included MSc and BSc holders in computer science. They used to record movies in pieces from various parts of the world and join [them together]. We are trying to trace more members of the gang including Karthi’s brothers,” Prasanathan said.

All five men were remanded in custody but not before they were paraded in front of the media, footage which later appeared on TV.

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

Microsoft: Poisoned Torrent Client Triggered Coin Miner Outbreak

Post Syndicated from Ernesto original https://torrentfreak.com/microsoft-poisoned-torrent-client-triggered-coin-miner-outbreak-180315/

First released in 2010, MediaGet has been around for a while. Initially, the torrent client was available in Russian only, but the team later expanded its reach across the world.

While it’s a relatively small player, it has been installed on millions of computers in recent years. It still has a significant reach, which is what Microsoft also found out recently.

This week the Windows Defender Research team reported that a poisoned version of the BitTorrent client was used to start the Dofoil campaign, which attempted to offload hundreds of thousands of malicious cryptocurrency miners.

Although Windows Defender caught and blocked the culprit within milliseconds, the team further researched the issue to find out how this could have happened.

It turns out that the update process for the application was poisoned. This then enabled a signed version of MediaGet to drop off a compromised version, as can be seen in the diagram below.

“A signed mediaget.exe downloads an update.exe program and runs it on the machine to install a new mediaget.exe. The new mediaget.exe program has the same functionality as the original but with additional backdoor capability,” Microsoft’s team explains.

The update poisoning

The malicious MediaGet version eventually triggered the mass coin miner outbreak. Windows Defender Research stresses that the poisoned version was signed by a third-party software company, not MediaGet itself.

Once the malware was launched the client built a list of command-and-control servers, using embedded NameCoin DNS servers and domains with the non-ICANN-sanctioned .bit TLD, making it harder to shut down.

More detailed information on the attack and how Dofoil was used to infect computers can be found in Microsoft’s full analysis.

MediaGet informs TorrentFreak that hackers compromised the update server to carry out their attack.

“Hackers got access to our update server, using an exploit in the Zabbix service and deeply integrated into our update mechanics. They modified the original version of Mediaget to add their functionality,” MediaGet reveals.

The company says that roughly five percent of all users were affected by the compromised update servers. All affected users were alerted and urged to update their software.

The issue is believed to be fully resolved at MediaGet’s end and they’re working with Microsoft to take care of any copies that may still be floating around in the wild.

“We patched everything and improved our verification system. To all the poisoned users we sent the message about an urgent update. Also, we are in contact with Microsoft, they will clean up all the poisoned versions,” MediaGet concludes.

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

ACME v2 and Wildcard Certificate Support is Live

Post Syndicated from ris original https://lwn.net/Articles/749291/rss

Let’s Encrypt has announced
that ACMEv2 (Automated Certificate Management Environment) and wildcard
certificate support is live. ACMEv2 is an updated
version of the ACME protocol that has gone through the IETF standards
process. Wildcard
allow you to secure all subdomains of a domain with a
single certificate. (Thanks to Alphonse Ogulla)

How to Delegate Administration of Your AWS Managed Microsoft AD Directory to Your On-Premises Active Directory Users

Post Syndicated from Vijay Sharma original https://aws.amazon.com/blogs/security/how-to-delegate-administration-of-your-aws-managed-microsoft-ad-directory-to-your-on-premises-active-directory-users/

You can now enable your on-premises users administer your AWS Directory Service for Microsoft Active Directory, also known as AWS Managed Microsoft AD. Using an Active Directory (AD) trust and the new AWS delegated AD security groups, you can grant administrative permissions to your on-premises users by managing group membership in your on-premises AD directory. This simplifies how you manage who can perform administration. It also makes it easier for your administrators because they can sign in to their existing workstation with their on-premises AD credential to administer your AWS Managed Microsoft AD.

AWS created new domain local AD security groups (AWS delegated groups) in your AWS Managed Microsoft AD directory. Each AWS delegated group has unique AD administrative permissions. Users that are members in the new AWS delegated groups get permissions to perform administrative tasks, such as add users, configure fine-grained password policies and enable Microsoft enterprise Certificate Authority. Because the AWS delegated groups are domain local in scope, you can use them through an AD Trust to your on-premises AD. This eliminates the requirement to create and use separate identities to administer your AWS Managed Microsoft AD. Instead, by adding selected on-premises users to desired AWS delegated groups, you can grant your administrators some or all of the permissions. You can simplify this even further by adding on-premises AD security groups to the AWS delegated groups. This enables you to add and remove users from your on-premises AD security group so that they can manage administrative permissions in your AWS Managed Microsoft AD.

In this blog post, I will show you how to delegate permissions to your on-premises users to perform an administrative task–configuring fine-grained password policies–in your AWS Managed Microsoft AD directory. You can follow the steps in this post to delegate other administrative permissions, such as configuring group Managed Service Accounts and Kerberos constrained delegation, to your on-premises users.


Until now, AWS Managed Microsoft AD delegated administrative permissions for your directory by creating AD security groups in your Organization Unit (OU) and authorizing these AWS delegated groups for common administrative activities. The admin user in your directory created user accounts within your OU, and granted these users permissions to administer your directory by adding them to one or more of these AWS delegated groups.

However, if you used your AWS Managed Microsoft AD with a trust to an on-premises AD forest, you couldn’t add users from your on-premises directory to these AWS delegated groups. This is because AWS created the AWS delegated groups with global scope, which restricts adding users from another forest. This necessitated that you create different user accounts in AWS Managed Microsoft AD for the purpose of administration. As a result, AD administrators typically had to remember additional credentials for AWS Managed Microsoft AD.

To address this, AWS created new AWS delegated groups with domain local scope in a separate OU called AWS Delegated Groups. These new AWS delegated groups with domain local scope are more flexible and permit adding users and groups from other domains and forests. This allows your admin user to delegate your on-premises users and groups administrative permissions to your AWS Managed Microsoft AD directory.

Note: If you already have an existing AWS Managed Microsoft AD directory containing the original AWS delegated groups with global scope, AWS preserved the original AWS delegated groups in the event you are currently using them with identities in AWS Managed Microsoft AD. AWS recommends that you transition to use the new AWS delegated groups with domain local scope. All newly created AWS Managed Microsoft AD directories have the new AWS delegated groups with domain local scope only.

Now, I will show you the steps to delegate administrative permissions to your on-premises users and groups to configure fine-grained password policies in your AWS Managed Microsoft AD directory.


For this post, I assume you are familiar with AD security groups and how security group scope rules work. I also assume you are familiar with AD trusts.

The instructions in this blog post require you to have the following components running:

Solution overview

I will now show you how to manage which on-premises users have delegated permissions to administer your directory by efficiently using on-premises AD security groups to manage these permissions. I will do this by:

  1. Adding on-premises groups to an AWS delegated group. In this step, you sign in to management instance connected to AWS Managed Microsoft AD directory as admin user and add on-premises groups to AWS delegated groups.
  2. Administer your AWS Managed Microsoft AD directory as on-premises user. In this step, you sign in to a workstation connected to your on-premises AD using your on-premises credentials and administer your AWS Managed Microsoft AD directory.

For the purpose of this blog, I already have an on-premises AD directory (in this case, on-premises.com). I also created an AWS Managed Microsoft AD directory (in this case, corp.example.com) that I use with Amazon RDS for SQL Server. To enable Integrated Windows Authentication to my on-premises.com domain, I established a one-way outgoing trust from my AWS Managed Microsoft AD directory to my on-premises AD directory. To administer my AWS Managed Microsoft AD, I created an Amazon EC2 for Windows Server instance (in this case, Cloud Management). I also have an on-premises workstation (in this case, On-premises Management), that is connected to my on-premises AD directory.

The following diagram represents the relationships between the on-premises AD and the AWS Managed Microsoft AD directory.

The left side represents the AWS Cloud containing AWS Managed Microsoft AD directory. I connected the directory to the on-premises AD directory via a 1-way forest trust relationship. When AWS created my AWS Managed Microsoft AD directory, AWS created a group called AWS Delegated Fine Grained Password Policy Administrators that has permissions to configure fine-grained password policies in AWS Managed Microsoft AD.

The right side of the diagram represents the on-premises AD directory. I created a global AD security group called On-premises fine grained password policy admins and I configured it so all members can manage fine grained password policies in my on-premises AD. I have two administrators in my company, John and Richard, who I added as members of On-premises fine grained password policy admins. I want to enable John and Richard to also manage fine grained password policies in my AWS Managed Microsoft AD.

While I could add John and Richard to the AWS Delegated Fine Grained Password Policy Administrators individually, I want a more efficient way to delegate and remove permissions for on-premises users to manage fine grained password policies in my AWS Managed Microsoft AD. In fact, I want to assign permissions to the same people that manage password policies in my on-premises directory.

Diagram showing delegation of administrative permissions to on-premises users

To do this, I will:

  1. As admin user, add the On-premises fine grained password policy admins as member of the AWS Delegated Fine Grained Password Policy Administrators security group from my Cloud Management machine.
  2. Manage who can administer password policies in my AWS Managed Microsoft AD directory by adding and removing users as members of the On-premises fine grained password policy admins. Doing so enables me to perform all my delegation work in my on-premises directory without the need to use a remote desktop protocol (RDP) session to my Cloud Management instance. In this case, Richard, who is a member of On-premises fine grained password policy admins group can now administer AWS Managed Microsoft AD directory from On-premises Management workstation.

Although I’m showing a specific case using fine grained password policy delegation, you can do this with any of the new AWS delegated groups and your on-premises groups and users.

Let’s get started.

Step 1 – Add on-premises groups to AWS delegated groups

In this step, open an RDP session to the Cloud Management instance and sign in as the admin user in your AWS Managed Microsoft AD directory. Then, add your users and groups from your on-premises AD to AWS delegated groups in AWS Managed Microsoft AD directory. In this example, I do the following:

  1. Sign in to the Cloud Management instance with the user name admin and the password that you set for the admin user when you created your directory.
  2. Open the Microsoft Windows Server Manager and navigate to Tools > Active Directory Users and Computers.
  3. Switch to the tree view and navigate to corp.example.com > AWS Delegated Groups. Right-click AWS Delegated Fine Grained Password Policy Administrators and select Properties.
  4. In the AWS Delegated Fine Grained Password Policy window, switch to Members tab and choose Add.
  5. In the Select Users, Contacts, Computers, Service Accounts, or Groups window, choose Locations.
  6. In the Locations window, select on-premises.com domain and choose OK.
  7. In the Enter the object names to select box, enter on-premises fine grained password policy admins and choose Check Names.
  8. Because I have a 1-way trust from AWS Managed Microsoft AD to my on-premises AD, Windows prompts me to enter credentials for an on-premises user account that has permissions to complete the search. If I had a 2-way trust and the admin account in my AWS Managed Microsoft AD has permissions to read my on-premises directory, Windows will not prompt me.In the Windows Security window, enter the credentials for an account with permissions for on-premises.com and choose OK.
  9. Click OK to add On-premises fine grained password policy admins group as a member of the AWS Delegated Fine Grained Password Policy Administrators group in your AWS Managed Microsoft AD directory.

At this point, any user that is a member of On-premises fine grained password policy admins group has permissions to manage password policies in your AWS Managed Microsoft AD directory.

Step 2 – Administer your AWS Managed Microsoft AD as on-premises user

Any member of the on-premises group(s) that you added to an AWS delegated group inherited the permissions of the AWS delegated group.

In this example, Richard signs in to the On-premises Management instance. Because Richard inherited permissions from Delegated Fine Grained Password Policy Administrators, he can now administer fine grained password policies in the AWS Managed Microsoft AD directory using on-premises credentials.

  1. Sign in to the On-premises Management instance as Richard.
  2. Open the Microsoft Windows Server Manager and navigate to Tools > Active Directory Users and Computers.
  3. Switch to the tree view, right-click Active Directory Users and Computers, and then select Change Domain.
  4. In the Change Domain window, enter corp.example.com, and then choose OK.
  5. You’ll be connected to your AWS Managed Microsoft AD domain:

Richard can now administer the password policies. Because John is also a member of the AWS delegated group, John can also perform password policy administration the same way.

In future, if Richard moves to another division within the company and you hire Judy as a replacement for Richard, you can simply remove Richard from On-premises fine grained password policy admins group and add Judy to this group. Richard will no longer have administrative permissions, while Judy can now administer password policies for your AWS Managed Microsoft AD directory.


We’ve tried to make it easier for you to administer your AWS Managed Microsoft AD directory by creating AWS delegated groups with domain local scope. You can add your on-premises AD groups to the AWS delegated groups. You can then control who can administer your directory by managing group membership in your on-premises AD directory. Your administrators can sign in to their existing on-premises workstations using their on-premises credentials and administer your AWS Managed Microsoft AD directory. I encourage you to explore the new AWS delegated security groups by using Active Directory Users and Computers from the management instance for your AWS Managed Microsoft AD. To learn more about AWS Directory Service, see the AWS Directory Service home page. If you have questions, please post them on the Directory Service forum. If you have comments about this post, submit them in the “Comments” section below.


New DDoS Reflection-Attack Variant

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

This is worrisome:

DDoS vandals have long intensified their attacks by sending a small number of specially designed data packets to publicly available services. The services then unwittingly respond by sending a much larger number of unwanted packets to a target. The best known vectors for these DDoS amplification attacks are poorly secured domain name system resolution servers, which magnify volumes by as much as 50 fold, and network time protocol, which increases volumes by about 58 times.

On Tuesday, researchers reported attackers are abusing a previously obscure method that delivers attacks 51,000 times their original size, making it by far the biggest amplification method ever used in the wild. The vector this time is memcached, a database caching system for speeding up websites and networks. Over the past week, attackers have started abusing it to deliver DDoSes with volumes of 500 gigabits per second and bigger, DDoS mitigation service Arbor Networks reported in a blog post.

Cloudflare blog post. BoingBoing post.

EDITED TO ADD (3/9): Brian Krebs covered this.

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

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.


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.


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.




Rightsholders & Belgian ISPs Cooperate to Block 450 ‘Pirate’ Domains

Post Syndicated from Andy original https://torrentfreak.com/rightsholders-belgian-isps-cooperate-to-block-450-pirate-domains-180303/

While site-blocking on copyright infringement grounds is now widespread, in most countries it requires intervention from the courts.

The process nearly always involves rightsholders grouping together with claims that customers of ISPs are infringing their rights by using ‘pirate’ sites to obtain movies, TV shows and music. As such, it isn’t pirate sites that are targeted by rightsholder legal action, but the ISPs themselves.

Of course, none of the ISPs targeted are breaking the law by providing access to the sites. However, the demands for a blocking injunction frame the ISPs as the wrong-doers, even if there is an underlying understanding that the pirate sites themselves are the issue. For this reason, ISPs around the world have regularly found themselves in an adversarial process.

In the Netherlands, for example, ISPs took their fight to the highest court in Europe to avoid blocking but will almost certainly fail after spending large sums of money. In others, such as the UK where the blocking process has matured, ISPs rarely object to anything, smoothing the process for both them and the rightsholders.

With the knowledge that site-blocking injunctions are likely to be granted by national courts in Europe, rightsholders and ISPs in Belgium now appear to be taking a collaborative approach. Sites have been blocked in the country before but future blocking efforts will be much easier to implement if a case before the Commercial Court of Brussels runs to plan.

It involves the Belgian Entertainment Association (BEA) on one side and ISPs Proximus, Telenet and VOO on the other. Rather than squabbling over the details, it appears that the parties will jointly present a list of 33 websites and 450 domain names to a judge, alongside claims that they facilitate the illegal downloading of copyrighted material.

According to a report from L’Echo (paywall), the companies hope to avoid complex and costly legal proceedings by working together and accepting the inevitability of a blocking injunction.

The case has been running for a year already but during a hearing before the Commercial Court of Brussels this week, Benoît Michaux, lawyer for the Belgian Entertainment Association, explained the new approach.

“The European legislator has put in place a mechanism that allows a national judge to request injunctions to order the providers to block access to the websites in question”, Michaux said.

After being presented to the Court, the list of sites and domains will be assessed to determine whether they’re acting illegally. Michaux said that the parties have settled on a common approach and have been able to identify “reasonable measures” that can be ordered by the Court that are consistent with case law of the European Court of Justice.

“This joint request is a little unusual, things are changing, there is a certain maturation of minds, we realize, from all sides, that we must tackle the problem of piracy by blocking measures. There is a common vision on what to do and how to handle piracy,” he said.

While the ISPs are clearly on a path of cooperation, L’Echo reports that concerns over possible breaches of the E-Commerce Directive mean that the ISPs don’t want to take action against the sites themselves without being ordered to do so by the Court.

“The responsible actors want to demonstrate that it is possible to stop piracy through procedural law,” says Benoît Van Asbroeck, lawyer for Proximus and Telenet.

The Court is expected to hand down its judgment within a month. Given the cooperation on all sides, it’s likely to be in favor of mass site-blocking.

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

The Pirate Bay’s Domain Suffers “40% Traffic Drop” After Dutch Blocking

Post Syndicated from Andy original https://torrentfreak.com/the-pirate-bays-domain-suffers-40-traffic-drop-after-dutch-blocking-180302/

Over the past several years, Dutch anti-piracy outfit BREIN has been engaged in continuous legal action against local ISPs Ziggo and XS4All. BREIN felt they should block The Pirate Bay to reduce copyright infringement but the ISPs felt blocking was disproportionate.

The case went all the way to the Supreme Court and then to the EU Court of Justice for clarification. Last June, the ECJ ruled that as a platform effectively communicating copyright works to the public, The Pirate Bay can indeed be blocked by ISPs.

The case will go back to the Supreme Court which is likely to give permanent blocking the go ahead. However, BREIN wanted a blocking decision more quickly and got one last September when The Hague Court of Appeal told Ziggo and XS4All to block The Pirate Bay pending a Supreme Court decision.

With The Pirate Bay blocked by the ISPs from September last year, BREIN has been monitoring the effect of the blockade on traffic to the site. In a statement, the anti-piracy outfit suggests that blocking is doing its job.

“Monitoring by ComScore shows that the number of unique visitors to thepiratebay.org from the Netherlands has dropped by more than 40% between September 2017 and December 2017 after internet providers Ziggo and XS4ALL were ordered by the court to demand access to the site on the basis of BREIN’s claim,” BREIN writes.

Ziggo is the largest cable operator in the Netherlands and XS4All one of the longest standing, so it comes as no surprise to learn that traffic to The Pirate Bay’s main domain has been hit. However, since the site can be accessed in numerous different indirect ways, including via proxies, mirrors and VPNs, to name a few, does BREIN’s claim that “blocking works” still hold water?

According to BREIN director Tim Kuik, yes it does.

“We also are blocking many proxies and mirrors. There is a whole list of them which also changes. New ones are added and others may be deleted,” Kuik informs TF.

“The monitoring compares like with like and shows a trend that correlates with other sources. I think this trend holds true for all blocked sites.”

So, to be clear, the 40% does not represent a drop in Dutch traffic to The Pirate Bay’s site and/or content overall, it only represents traffic which goes directly to the specific thepiratebay.org domain. Anyone circumventing the blockade isn’t counted.

Of course, that’s not to say that the overall traffic numbers from the Netherlands aren’t down as well, but there are no public figures to prove that one way or another. The precise impact of proxies and mirrors is also unclear but Kuik thinks that the blockades themselves send a message.

“Bypassing a blockade requires users to take action to illegally download and it is now clear that they are committing a criminal offense and most people do not want that,” he says.

VPNs are undoubtedly an effective unblocking solution for some but Kuik doesn’t believe they represent a big threat, currently at least.

“We think VPN use is not common under the average user, that is more something for the hardcore and not all of those will use it for access to illegal sources,” he informs TF.

While BREIN is fairly relaxed about VPNs for now, the group suggests it could take action if they begin to pose a risk to the site-blocking regime they’ve fought so hard for.

“If it becomes problematic, blocking could in principle also be demanded from VPN services,” Kuik warns.

Given the 40% figure and the caveats above, it is likely that the direct traffic figure to The Pirate Bay’s domain will fall again in the months to come. Mid-January a Dutch court ruled that local Internet providers KPN, Tele2, T-Mobile, Zeelandnet and CAIW must follow Ziggo and XS4All by also blocking The Pirate Bay.

There’s no doubt that blocking has at least some effect on direct traffic to pirate sites and it’s clear that entertainment industry groups feel it’s essential as part of a bigger anti-piracy toolkit.

Thus far, however, pirates have proven to be extremely resilient so the Netherlands will probably need further action against a much broader range of sites if blocking is to have any meaningful effect.

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

Hollywood Commissioned Tough Jail Sentences for Online Piracy, ISP Says

Post Syndicated from Andy original https://torrentfreak.com/hollywood-commissioned-tough-jail-sentences-for-online-piracy-isp-says-180227/

According to local prosecutors who have handled many copyright infringement cases over the past decade, Sweden is nowhere near tough enough on those who commit online infringement.

With this in mind, the government sought advice on how such crimes should be punished, not only more severely, but also in proportion to the damages alleged to have been caused by defendants’ activities.

The corresponding report was returned to Minister for Justice Heléne Fritzon earlier this month by Council of Justice member Dag Mattsson. The paper proposed a new tier of offenses that should receive special punishment when there are convictions for large-scale copyright infringement and “serious” trademark infringement.

Partitioning the offenses into two broad categories, the report envisions those found guilty of copyright infringement or trademark infringement “of a normal grade” may be sentenced to fines or imprisonment up to a maximum of two years. For those at the other end of the scale, engaged in “cases of gross crimes”, the penalty sought is a minimum of six months in prison and not more than six years.

The proposals have been criticized by those who feel that copyright infringement shouldn’t be put on a par with more serious and even potentially violent crimes. On the other hand, tools to deter larger instances of infringement have been welcomed by entertainment industry groups, who have long sought more robust sentencing options in order to protect their interests.

In the middle, however, are Internet service providers such as Bahnhof, who are often dragged into the online piracy debate due to the allegedly infringing actions of some of their customers. In a statement on the new proposals, the company is clear on why Sweden is preparing to take such a tough stance against infringement.

“It’s not a daring guess that media companies are asking for Sweden to tighten the penalty for illegal file sharing and streaming,” says Bahnhof lawyer Wilhelm Dahlborn.

“It would have been better if the need for legislative change had taken place at EU level and co-ordinated with other similar intellectual property legislation.”

Bahnhof chief Jon Karlung, who is never afraid to speak his mind on such matters, goes a step further. He believes the initiative amounts to a gift to the United States.

“It’s nothing but a commission from the American film industry,” Karlung says.

“I do not mind them going for their goals in court and trying to protect their interests, but it does not mean that the state, the police, and ultimately taxpayers should put mass resources on it.”

Bahnhof notes that the proposals for the toughest extended jail sentences aren’t directly aimed at petty file-sharers. However, the introduction of a new offense of “gross crime” means that the limitation period shifts from the current five years to ten.

It also means that due to the expansion of prison terms beyond two years, secret monitoring of communications (known as HÖK) could come into play.

“If the police have access to HÖK, it can be used to get information about which individuals are file sharing,” warns Bahnhof lawyer Wilhelm Dahlborn.

“One can also imagine a scenario where media companies increasingly report crime as gross in order to get the police to do the investigative work they have previously done. Harder punishments to tackle file-sharing also appear very old-fashioned and equally ineffective.”

As noted in our earlier report, the new proposals also include measures that would enable the state to confiscate all kinds of property, both physical items and more intangible assets such as domain names. Bahnhof also takes issue with this, noting that domains are not the problem here.

“In our opinion, it is not the domain name which is the problem, it is the content of the website that the domain name points to,” the company says.

“Moreover, confiscation of a domain name may conflict with constitutional rules on freedom of expression in a way that is very unfortunate. The issues of freedom of expression and why copyright infringement is to be treated differently haven’t been addressed much in the investigation.”

Under the new proposals, damage to rightsholders and monetary gain by the defendant would also be taken into account when assessing whether a crime is “gross” or not. This raises questions as to what extent someone could be held liable for piracy when a rightsholder maintains damage was caused yet no profit was generated.

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

Preparing for AWS Certificate Manager (ACM) Support of Certificate Transparency

Post Syndicated from Jonathan Kozolchyk original https://aws.amazon.com/blogs/security/how-to-get-ready-for-certificate-transparency/


Starting April 30, 2018, Google Chrome will require all publicly trusted certificates to be logged in at least two Certificate Transparency logs. This means that any certificate issued that is not logged will result in an error message in Google Chrome. Beginning April 24, 2018, Amazon will log all new and renewed certificates in at least two public logs unless you disable Certificate Transparency logging.

Without Certificate Transparency, it can be difficult for a domain owner to know if an unexpected certificate was issued for their domain. Under the current system, no record is kept of certificates being issued, and domain owners do not have a reliable way to identify rogue certificates.

To address this situation, Certificate Transparency creates a cryptographically secure log of each certificate issued. Domain owners can search the log to identify unexpected certificates, whether issued by mistake or malice. Domain owners can also identify Certificate Authorities (CAs) that are improperly issuing certificates. In this blog post, I explain more about Certificate Transparency and tell you how to prepare for it.

How does Certificate Transparency work?

When a CA issues a publicly trusted certificate, the CA must submit the certificate to one or more Certificate Transparency log servers. The Certificate Transparency log server responds with a signed certificate timestamp (SCT) that confirms the log server will add the certificate to the list of known certificates. The SCT is then embedded in the certificate and delivered automatically to a browser. The SCT is like a receipt that proves the certificate was published into the Certificate Transparency log. Starting April 30, Google Chrome will require an SCT as proof that the certificate was published to a Certificate Transparency log in order to trust the certificate without displaying an error message.

What is Amazon doing to support Certificate Transparency?

Certificate Transparency is a good practice. It enables AWS customers to be more confident that an unauthorized certificate hasn’t been issued by a CA. Beginning on April 24, 2018, Amazon will log all new and renewed certificates in at least two Certificate Transparency logs unless you disable Certificate Transparency logging.

We recognize that there can be times when our customers do not want to log certificates. For example, if you are building a website for an unreleased product and have registered the subdomain, newproduct.example.com, requesting a logged certificate for your domain will make it publicly known that the new product is coming. Certificate Transparency logging also can expose server hostnames that you want to keep private. Hostnames such as payments.example.com can reveal the purpose of a server and provide attackers with information about your private network. These logs do not contain the private key for your certificate. For these reasons, you will be able to disable Certificate Transparency logging on a per-certificate basis using the ACM APIs or with the AWS CLI, starting on March 27, 2018. Doing so will lead to errors in Google Chrome, which may be preferable to exposing the information. We will share instructions on the AWS Security Blog about how to disable Certificate Transparency logging as we get closer to March 27, 2018.


Beginning April 24, 2018, ACM will begin logging all new and renewed certificates by default. If you don’t want a certificate to be logged, you’ll be able to opt out using the AWS API or CLI. However, for Google Chrome to trust the certificate, all issued or imported certificates must have the SCT information embedded in them by April 30, 2018.

If you have comments about this blog post, submit them in the “Comments” section below. If you have questions, start a new thread in the ACM forum.

– Jonathan

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

Pirate Site Operators’ Jail Sentences Overturned By Court of Appeal

Post Syndicated from Andy original https://torrentfreak.com/pirate-site-operators-jail-sentences-overturned-by-court-of-appeal-180226/

With The Pirate Bay proving to be somewhat of an elusive and irritating target, in 2014 police took on a site capturing an increasing portion of the Swedish pirate market.

Unlike The Pirate Bay which uses torrents, Dreamfilm was a portal for streaming content and it quickly grew alongside the now-defunct Swefilmer to dominate the local illicit in-browser viewing sector. But after impressive growth, things came to a sudden halt.

In January 2015, Dreamfilm announced that the site would be shut down after one of its administrators was detained by the authorities and interrogated. A month later, several more Sweden-based sites went down including the country’s second largest torrent site Tankefetast, torrent site PirateHub, and streaming portal Tankefetast Play (TFPlay).

Anti-piracy group Rights Alliance described the four-site networks as one of “Europe’s leading players for illegal file sharing and streaming.”

Image published by Dreamfilm after the raiddreamfilm

After admitting they’d been involved in the sites but insisting they’d committed no crimes, last year four men aged between 21 and 31-years-old appeared in court charged with copyright infringement. It didn’t go well.

The Linköping District Court found them guilty and decided they should all go to prison, with the then 23-year-old founder receiving the harshest sentence of 10 months, a member of the Pirate Party who reportedly handled advertising receiving 8 months, and two others getting six months each. On top, they were ordered to pay damages of SEK 1,000,000 ($122,330) to film industry plaintiffs.

Like many similar cases in Sweden, the case went to appeal and late last week the court handed down its decision which amends the earlier decision in several ways.

Firstly, the Hovrätten (Court of Appeals) agreed that with the District Court’s ruling that the defendants had used dreamfilm.se, tfplay.org, tankafetast.com and piratehub.net as platforms to deliver movies stored on Russian servers to the public.

One defendant owned the domains, another worked as a site supervisor, while the other pair worked as a programmer and in server acquisition, the Court said.

Dagens Juridik reports that the defendants argued that the websites were not a prerequisite for people to access the films, and therefore they had not been made available to a new market.

However, the Court of Appeal agreed with the District Court’s assessment that the links meant that the movies had been made available to a “new audience”, which under EU law means that a copyright infringement had been committed. As far as the samples presented in the case would allow, the men were found to have committed between 45 and 118 breaches of copyright law.

The Court also found that the website operation had a clear financial motive, delivering movies to the public for free while earning money from advertising.

While agreeing with the District Court on most points, the Court of Appeals decided to boost the damages award from SEK 1,000,000 ($122,330) to SEK 4,250,000 ($519,902). However, there was much better news in respect of the prison sentences.

Taking into consideration the young age of the men (who before this case had no criminal records) and the unlikely event that they would offend again, the Court decided that none would have to go to prison as previously determined.

Instead, all of the men were handed conditional sentences with two ordered to pay daily fines, which are penalties based on the offender’s daily personal income.

Last week it was reported that Sweden is preparing to take a tougher line with large-scale online copyright infringers. Proposals currently with the government foresee a new crime of “gross infringement” under both copyright and trademark law, which could lead to sentences of up to six years in prison.

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

Copyright Holders Call Out Costa Rica Over ThePirateBay.cr

Post Syndicated from Ernesto original https://torrentfreak.com/copyright-holders-call-out-costa-rica-over-thepiratebay-cr-180224/

The International Intellectual Property Alliance (IIPA) has submitted its latest submission for the U.S. Government’s 2018 Special 301 Review, pinpointing countries it believes should better protect the interests of the copyright industry.

The IIPA, which includes a wide range of copyright groups including the MPAA, RIAA, BSA, and ESA, has listed its complaints against a whole host of countries.

Canada is prominently discussed, of course, as are Argentina, China, India, Mexico, Switzerland and many others. The allegations are broad, ranging from border protection problems to pirate site hosting and everything in between.

What caught our eye, however, was a mention of ThePirateBay.cr. This domain name which, unlike the name suggests, sports a KickassTorrents logo, uses the Costa Rican Top Level Domain .cr.

While it’s a relatively small player in the torrent site ecosystem, it appears to be of great concern in diplomatic circles.


Previously, the U.S. Embassy in Costa Rica threatened to have the country’s domain registry shut down unless it suspended ThePirateBay.cr. This hasn’t happened, yet, but it was a clear signal.

In the IIPA’s recent submission to the USTR, the domain is also brought into play. The copyright holders argue that Costa Rica is not living up to its obligations under the CAFTA-DR trade agreement.

“One of the key DR-CAFTA obligations that has not been implemented is introducing clear rules on copyright, liability, as well as providing meaningful legal incentives for inter-industry cooperation to deal with online infringements,” the IIPA writes.

“Instead, Costa Rica’s law offers largely unconditional liability exceptions to Internet Service Providers (ISPs) and others, even allowing identified infringing activity to remain on their systems for as long as 45 days.”

Next, it puts a spotlight on the local domain registry, which it described as a safe haven for sites including ThePirateBay.cr.

“There are still many instances where the Costa Rican Top Level Domain (ccTLD) registry has provided a safe haven to notorious online enterprises dedicated to copyright infringement,” IIPA writes.

“For example, thepiratebay.cr domain is still online despite actions against it from ICANN and the U.S. Embassy in Costa Rica. Costa Rica’s failure to deal effectively with its obligations regarding online infringement, more than six years after these came into force under DR-CAFTA, is a serious concern.”

The latter is worth highlighting. It claims that ICANN, the main oversight body for the Internet’s global domain name system, also “took action” against the notorious domain name.

While it is true that ICANN was made aware of the tense situation between the US Embassy and the Costa Rican domain registry through a letter, we were not aware of any action it took.

Interestingly, ICANN itself also appears to be unaware of this, when we asked the organization whether it took any action in response to the domain or letter.

“The Governmental Advisory Committee and ICANN Org took note of the letter but did not provide a response as it was not warranted. While the letter was addressed to the GAC Chair, it did not contain any specific question or request for action,” an ICANN spokesperson responded.

Whether ICANN got involved or not is irrelevant in the larger scheme though. The IIPA wants the US Government to use ThePirateBay.cr domain to spur Costa Rica into action. After all, no country would like a local domain registry to serve a Pirate Bay proxy.

Meanwhile, the official Pirate Bay domain remains operational from ThePirateBay.org, which happens to be using the US-based PIR registry. But let’s not bring that up…

IIPA’s full submission is available here (pdf).

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

Russia VPN Blocking Law Failing? No Provider Told To Block Any Site

Post Syndicated from Andy original https://torrentfreak.com/russia-vpn-blocking-law-failing-no-provider-told-to-block-any-site-180224/

Continuing Russia’s continued pressure on the restriction of banned websites for copyright infringement and other offenses, President Vladimir Putin signed a brand new bill into law July 2017.

The legislation aimed to prevent citizens from circumventing ISP blockades with the use of services such as VPNs, proxies, Tor, and other anonymizing services. The theory was that if VPNs were found to be facilitating access to banned sites, they too would find themselves on Russia’s national Internet blacklist.

The list is maintained by local telecoms watchdog Rozcomnadzor and currently contains many tens of thousands of restricted domains. In respect of VPNs, the Federal Security Service (FSB) and the Ministry of Internal Affairs is tasked with monitoring ‘unblocking’ offenses, which they are then expected to refer to the telecoms watchdog for action.

The legislation caused significant uproar both locally and overseas and was widely predicted to signal a whole new level of censorship in Russia. However, things haven’t played out that way since, far from it. Since being introduced November 1, 2017, not a single VPN has been cautioned over its activities, much less advised to block or cease and desist.

The revelation comes via Russian news outlet RBC, which received an official confirmation from Rozcomnadzor itself that no VPN or anonymization service had been asked to take action to prevent access to blocked sites. Given the attention to detail when passing the law, the reasons seem extraordinary.

While Rozcomnadzor is empowered to put VPN providers on the blacklist, it must first be instructed to do so by the FSB, after that organization has carried out an investigation. Once the FSB gives the go-ahead, Rozcomnadzor can then order the provider to connect itself to the federal state information system, known locally as FGIS.

FGIS is the system that contains the details of nationally blocked sites and if a VPN provider does not interface with it within 30 days of being ordered to do so, it too will be added to the blocklist by Rozcomnadzor. Trouble is, Rozcomnadzor hasn’t received any requests to contact VPNs from higher up the chain, so they can’t do anything.

“As of today, there have been no requests from the members of the RDD [operational and investigative activities] and state security regarding anonymizers and VPN services,” a Roskomnadzor spokesperson said.

However, the problems don’t end there. RBC quotes Karen Ghazaryan, an analyst at the Russian Electronic Communications Association (RAEC), who says that even if it had received instructions, Rozcomnadzor wouldn’t be able to block the VPN services in question for both technical and legal reasons.

“Roskomnadzor does not have leverage over most VPN services, and they can not block them for failing to comply with the law, because Roskomnadzor does not have ready technical solutions for this, and the law does not yet have relevant by-laws,” the expert said.

“Copying the Chinese model of fighting VPNs in Russia will not be possible because of its high cost and the radically different topology of the Russian segment of the Internet,” Ghazaryan adds.

This apparent inability to act is surprising, not least since millions of Russian Internet users are now using VPNs, anonymizers, and similar services on a regular basis. Ghazaryan puts the figure as high as 25% of all Russian Internet users.

However, there is also a third element to Russia’s VPN dilemma – how to differentiate between VPNs used by the public and those used in a commercial environment. China is trying to solve this problem by forcing VPN providers to register and align themselves with the state. Russia hasn’t tried that, yet.

“The [blocking] law says that it does not apply to corporate VPN networks, but there is no way to distinguish them from services used for personal needs,” concludes Sarkis Darbinian from the anti-censorship project, Roskomvoboda.

This week, Russia’s Ministry of Culture unveiled yet more new proposals for dealing with copyright infringement via a bill that would allow websites to be blocked without a court order. It’s envisioned that if pirate material is found on a site and its operator either fails to respond to a complaint or leaves the content online for more than 24 hours, ISPs will be told to block the entire site.

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

Spanish Authorities Launch New Campaign to Block Pirate Websites

Post Syndicated from Andy original https://torrentfreak.com/spanish-authorities-launch-new-campaign-to-block-pirate-websites-180223/

Following complaints from Disney, 20th Century Fox, Paramount, Sony, Universal and Warner, a court in Spain recently ordered local ISPs to block HDFull.tv and Repelis.tv, a pair of popular pirate sites.

Citing changes in local law which helped facilitate the action, the MPA welcomed the blockades as necessary to prevent further damage to the creative industries. Now, just a week later, it seems that Spain really has the bit between its teeth.

An announcement from the Guardia Civil (Civil Guard), the oldest law enforcement agency in the country, reveals that almost two dozen websites have just been blocked for infringing intellectual property rights.

“The Civil Guard, within the framework of the ‘Operation CASCADA’, has initiated a campaign to block websites that allow people to download content protected by copyright and disseminate them through links in P2P networks, that is, networks of computers that work without fixed servers,” the Civil Guard said in a statement.

“In this first phase, a total of 23 web domains have been blocked from which direct download links of all kinds of protected audiovisual material such as movies, series, music and video games were accessed, many of them of recent creation and without being released yet in our country.

“High-quality versions of films available on the cinema billboards of our country were offered, although they had not yet been sold in physical or digital format and dubbed with audio in several languages.”

A full list of websites and domains hasn’t yet been provided by the authorities but familiar names including divxtotal.com and gamestorrents.com are confirmed to be included in the first wave.

The Civil Guard, which is organized as a military force under the authority of the Ministry of the Interior and Ministry of Defense, said that the administrators of the sites operate their platforms from abroad, generating advertising revenue from Spanish visitors who are said to make up 80% of the sites’ traffic.

In common with similar sites, the authorities accuse their owners of taking evasive action to avoid being shut down, including hiding the true location of their servers while moving them from country to country and masking domain registration data.

“Cases have been detected in which previously judicially blocked domains were reactivated in a matter of hours, with practically identical domain names or even changing only the extension thereof. In this way, and even if several successive blocks were made, they were able to ‘resurrect’ the web pages again in a very short space of time,” the Civil Guard reports.

“For all these reasons, components of the Department of Telematic Crimes of the Central Operative Unit of the Civil Guard, responsible for the investigation, were forced to implement a series of measures tending to cause a total blockade of them that would be effective and definitive, being currently inaccessible web pages or lacking download links.”

According to the authorities, the sites are now being continuously monitored, with replacement domains being blocked in less than three hours. That doesn’t appear to have been the case yesterday, however.

It’s claimed that the blocked sites were created by “a person of Spanish origin” who subsequently sold them to a company in Argentina. On Thursday, Argentina-based site Dixv.com.ar fired back against the blockade with a new site called Yadivx.com, which is reportedly serving all of the former’s content to users in Spain.

The sites’ owners continue to administer the rogue sites from Argentina, Spanish authorities believe. Only time will tell who will emerge victorious but at least for now, the sites are remaining defiant.

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

TVAddons Suffers Big Setback as Court Completely Overturns Earlier Ruling

Post Syndicated from Andy original https://torrentfreak.com/tvaddons-suffers-big-setback-as-court-completely-overturns-earlier-ruling-180221/

On June 2, 2017 a group of Canadian telecoms giants including Bell Canada, Bell ExpressVu, Bell Media, Videotron, Groupe TVA, Rogers Communications and Rogers Media, filed a complaint in Federal Court against Montreal resident, Adam Lackman.

Better known as the man behind Kodi addon repository TVAddons, Lackman was painted as a serial infringer in the complaint. The telecoms companies said that, without gaining permission from rightsholders, Lackman communicated copyrighted TV shows including Game of Thrones, Prison Break, The Big Bang Theory, America’s Got Talent, Keeping Up With The Kardashians and dozens more, by developing, hosting, distributing and promoting infringing Kodi add-ons.

To limit the harm allegedly caused by TVAddons, the complaint demanded interim, interlocutory, and permanent injunctions restraining Lackman from developing, promoting or distributing any of the allegedly infringing add-ons or software. On top, the plaintiffs requested punitive and exemplary damages, plus costs.

On June 9, 2017 the Federal Court handed down a time-limited interim injunction against Lackman ex parte, without Lackman being able to mount a defense. Bailiffs took control of TVAddons’ domains but the most controversial move was the granting of an Anton Piller order, a civil search warrant which granted the plaintiffs no-notice permission to enter Lackman’s premises to secure evidence before it could be tampered with.

The order was executed June 12, 2017, with Lackman’s home subjected to a lengthy search during which the Canadian was reportedly refused his right to remain silent. Non-cooperation with an Anton Piller order can amount to a contempt of court, he was told.

With the situation seemingly spinning out of Lackman’s control, unexpected support came from the Honourable B. Richard Bell during a subsequent June 29, 2017 Federal Court hearing to consider the execution of the Anton Piller order.

The Judge said that Lackman had been subjected to a search “without any of the protections normally afforded to litigants in such circumstances” and took exception to the fact that the plaintiffs had ordered Lackman to spill the beans on other individuals in the Kodi addon community. He described this as a hunt for further evidence, not the task of preserving evidence it should’ve been.

Justice Bell concluded by ruling that while the prima facie case against Lackman may have appeared strong before the judge who heard the matter ex parte, the subsequent adversarial hearing undermined it, to the point that it no longer met the threshold.

As a result of these failings, Judge Bell vacated the Anton Piller order and dismissed the application for interlocutory injunction.

While this was an early victory for Lackman and TVAddons, the plaintiffs took the decision to an appeal which was heard November 29, 2017. Determined by a three-judge panel and signed by Justice Yves de Montigny, the decision was handed down Tuesday and it effectively turns the earlier ruling upside down.

The appeal had two matters to consider: whether Justice Bell made errors when he vacated the Anton Piller order, and whether he made errors when he dismissed the application for an interlocutory injunction. In short, the panel found that he did.

In a 27-page ruling, the first key issue concerns Justice Bell’s understanding of the nature of both Lackman and TVAddons.

The telecoms companies complained that the Judge got it wrong when he characterized Lackman as a software developer who came up with add-ons that permit users to access material “that is for the most part not infringing on the rights” of the telecoms companies.

The companies also challenged the Judge’s finding that the infringing add-ons offered by the site represented “just over 1%” of all the add-ons developed by Lackman.

“I agree with the [telecoms companies] that the Judge misapprehended the evidence and made palpable and overriding errors in his assessment of the strength of the appellants’ case,” Justice Yves de Montigny writes in the ruling.

“Nowhere did the appellants actually state that only a tiny proportion of the add-ons found on the respondent’s website are infringing add-ons.”

The confusion appears to have arisen from the fact that while TVAddons offered 1,500 add-ons in total, the heavily discussed ‘featured’ addon category on the site contained just 22 add-ons, 16 of which were considered to be infringing according to the original complaint. So, it was 16 add-ons out of 22 being discussed, not 16 add-ons out of a possible 1,500.

“[Justice Bell] therefore clearly misapprehended the evidence in this regard by concluding that just over 1% of the add-ons were purportedly infringing,” the appeals Judge adds.

After gaining traction with Justice Bell in the previous hearing, Lackman’s assertion that his add-ons were akin to a “mini Google” was fiercely contested by the telecoms companies. They also fell flat before the appeal hearing.

Justice de Montigny says that Justice Bell “had been swayed” when Lackman’s expert replicated the discovery of infringing content using Google but had failed to grasp the important differences between a general search engine and a dedicated Kodi add-on.

“While Google is an indiscriminate search engine that returns results based on relevance, as determined by an algorithm, infringing add-ons target predetermined infringing content in a manner that is user-friendly and reliable,” the Judge writes.

“The fact that a search result using an add-on can be replicated with Google is of little consequence. The content will always be found using Google or any other Internet search engine because they search the entire universe of all publicly available information. Using addons, however, takes one to the infringing content much more directly, effortlessly and safely.”

With this in mind, Justice de Montigny says there is a “strong prima facie case” that Lackman, by hosting and distributing infringing add-ons, made the telecoms companies’ content available to the public “at a time of their choosing”, thereby infringing paragraph 2.4(1.1) and section 27 of the Copyright Act.

On TVAddons itself, the Judge said that the platform is “clearly designed” to facilitate access to infringing material since it targets “those who want to circumvent the legal means of watching television programs and the related costs.”

Turning to Lackman, the Judge said he could not claim to have no knowledge of the infringing content delivered by the add-ons distributed on this site, since they were purposefully curated prior to distribution.

“The respondent cannot credibly assert that his participation is content neutral and that he was not negligent in failing to investigate, since at a minimum he selects and organizes the add-ons that find their way onto his website,” the Judge notes.

In a further setback, the Judge draws clear parallels with another case before the Canadian courts involving pre-loaded ‘pirate’ set-top boxes. Justice de Montigny says that TVAddons itself bears “many similarities” with those devices that are already subjected to an interlocutory injunction in Canada.

“The service offered by the respondent through the TVAddons website is no different from the service offered through the set-top boxes. The means through which access is provided to infringing content is different (one relied on hardware while the other relied on a website), but they both provided unauthorized access to copyrighted material without authorization of the copyright owners,” the Judge finds.

Continuing, the Judge makes some pointed remarks concerning the execution of the Anton Piller order. In short, he found little wrong with the way things went ahead and also contradicted some of the claims and beliefs circulated in the earlier hearing.

Citing the affidavit of an independent solicitor who monitored the order’s execution, the Judge said that the order was explained to Lackman in plain language and he was informed of his right to remain silent. He was also told that he could refuse to answer questions other than those specified in the order.

The Judge said that Lackman was allowed to have counsel present, “with whom he consulted throughout the execution of the order.” There was nothing, the Judge said, that amounted to the “interrogation” alluded to in the earlier hearing.

Justice de Montigny also criticized Justice Bell for failing to take into account that Lackman “attempted to conceal crucial evidence and lied to the independent supervising solicitor regarding the whereabouts of that evidence.”

Much was previously made of Lackman apparently being forced to hand over personal details of third-parties associated directly or indirectly with TVAddons. The Judge clarifies what happened in his ruling.

“A list of names was put to the respondent by the plaintiffs’ solicitors, but it was apparently done to expedite the questioning process. In any event, the respondent did not provide material information on the majority of the aliases put to him,” the Judge reveals.

But while not handing over evidence on third-parties will paint Lackman in a better light with concerned elements of the add-on community, the Judge was quick to bring up the Canadian’s history and criticized Justice Bell for not taking it into account when he vacated the Anton Piller order.

“[T]he respondent admitted that he was involved in piracy of satellite television signals when he was younger, and there is evidence that he was involved in the configuration and sale of ‘jailbroken’ Apple TV set-top boxes,” Justice de Montigny writes.

“When juxtaposed to the respondent’s attempt to conceal relevant evidence during the execution of the Anton Piller order, that contextual evidence adds credence to the appellants’ concern that the evidence could disappear without a comprehensive order.”

Dismissing Justice Bell’s findings as “fatally flawed”, Justice de Montigny allowed the appeal of the telecoms companies, set aside the order of June 29, 2017, declared the Anton Piller order and interim injunctions legal, and granted an interlocutory injunction to remain valid until the conclusion of the case in Federal Court. The telecoms companies were also awarded costs of CAD$50,000.

It’s worth noting that despite all the detail provided up to now, the case hasn’t yet got to the stage where the Court has tested any of the claims put forward by the telecoms companies. Everything reported to date is pre-trial and has been taken at face value.

TorrentFreak spoke with Adam Lackman but since he hadn’t yet had the opportunity to discuss the matter with his lawyers, he declined to comment further on the record. There is a statement on the TVAddons website which gives his position on the story so far.

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