AWS Week in Review – April 4, 2022

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/aws-week-in-review-april-4-2022/

This post is part of our Week in Review series. Check back each week for a quick round up of interesting news and announcements from AWS!

Welcome to the April 4 edition of the AWS Week in Review. This week, alongside the main launches, I also captured a couple of new capabilities, such as a new API to manage your AWS accounts within AWS Organizations, an easier process to update your AWS Lambda layers, and a new behavior of Amazon Elastic Compute Cloud (Amazon EC2).

Last Week’s Launches
Here are some launches that caught my attention last week:

Sustainability Pillar is now available in the Well Architect Tool – The Well Architected Tool is a central place for cloud architecture best practices and guidance. The Sustainability Pillar was announced at the re:Invent 2021 conference. It helps you to learn, measure, and improve your workloads using environmental best practices for cloud computing.

Close an AWS Member Account with an API Call – This feature was launched with little fanfare, but it is a big deal for those of you managing large numbers of AWS accounts through Organizations.  The Twitter community first spotted the change, noticing a commit in the AWS SDK for Go. See the official blog post announcement for more information!

The Lambda Console Now Allows Updates a Lambda Layer in All or a Subset of Functions – Lambda layers provide a convenient way to package libraries and other dependencies that you can use with your Lambda functions. Using layers reduces the size of uploaded deployment archives and makes it faster to deploy your code. Previously, it was challenging to identify and update all the functions that used a specific layer version. With this release, the Lambda console displays a list of all the functions using a given layer and allows you to select multiple functions to be updated with a newer layer version. It eliminates the need to update one function at a time or utilize an external script to perform the update on multiple functions.

Amazon EC2 Launched Automatic Recovery on Hardware Failure by Default – This new feature makes it easier to recover your instance when it becomes unreachable. Automatic recovery improves instance availability by recovering the instance if it becomes impaired due to an underlying hardware issue. Automatic recovery migrates the instance to another hardware during an instance reboot while retaining its instance ID, private IP addresses, Elastic IP addresses, and all instance metadata. You can choose to disable automatic recovery for your instance if you wish.

For a full list of AWS announcements, be sure to keep an eye on the What’s New at AWS page.

Other AWS News
Beside launches, here are other news worthy items and a blog that caught my attention:

New AWS podcast for Sub-Saharan AWS communities – There are AWS podcasts in many different languages: English, French, Italian, German, three in Spanish, and Russian just to name a few. This week, my colleague Veliswa launched an English podcast aimed at highlighting the Sub-Saharian AWS communities and customers. You can listen to it using any good podcast application (including but not only Spotify and Apple).

100th episode of Le Podcast AWS en Français – This week also marked the publication of the 100th episode of the AWS French Podcast. Since its start in 2019, the podcast has seen 250k downloads. Thank you for listening.

AWS Open Source News and Updates – My colleague Ricardo writes this weekly open-source newsletter. In the 106th edition, I noticed two pieces of information important for the Java community:

First, we released Amazon Corretto 18. This version supports the latest Java feature release OpenJDK 18, and is available on Linux, Windows, and macOS. OpenJDK 18 offers a new internet-address resolution capability, a Simple Web Server, an updated Vector API, a new @snippet Tag for JavaDoc, a new implementation of Core Reflection, a change to UTF-8 as the default character set (charset) of the standard Java APIs, a second iteration of the foreign memory API, advancements in pattern matching for switch statements, and the deprecation of finalization.

Second, we published a blog post showing how to reduce Lambda cold start time by deploying your Java-based Lambda function on Quarkus. Quarkus was created by Java Champion Emmanuel Bernard. It is an open-source native Java stack tailored for GraalVM and OpenJDK HotSpot, crafted from the best of breed Java libraries and standards. It is designed to have an extremely low memory footprint and fast startup time. And yes, Quarkus runs on Corretto too.

A Cloud Guru Answers a Common Question – Nearly every week, people ask me what AWS certification they should take. A Cloud Guru walks through the decision in Which AWS certification is right for me?

Upcoming AWS Events
Check your calendars and sign up for these AWS events:

The AWS Summit season has started – The Brussels Summit was last week, and the next ones are Paris, San Francisco, and London, in that order. I will be delivering the closing keynote at the Paris Summit and will be around the Formula1 GameDay area in London. Be sure to stop by and say “Hi!” if you’re around. You can sign up to receive a notification when registration opens for a Summit in your area. If you can’t attend a Summit in person this year, we will have an online Summit for EMEA in June (at European time, but all sessions will stay available on-demand until September).

.NET Enterprise Developer Day EMEA registrations are open – .NET Enterprise Developer Day EMEA 2022 is a free, one-day virtual conference providing enterprise developers with the most relevant information to swiftly and efficiently migrate and modernize their .NET applications and workloads on AWS. It will happen online on April 26, 2022.

re:Mars conference registrations are open – Mars stands for Machine learning, Automation, Robotics, and Space. You will learn from recognized thought leaders and technical experts who are building the future of AI/ML. It will happen in Las Vegas, Nevada, between June 21 and 24, 2022.

re:Inforce conference registrations are open – Security is our first priority at AWS, and it deserves its own two-day conference to reinforce your AWS security posture. You’ll hear the latest from industry-leading speakers in security, compliance, identity, and privacy. It will happen in Boston, Massachusetts, on July 26 and 27, 2022.

That’s all for this week. Come back next Monday for another Week in Review!

— seb

Cloud Pentesting, Pt. 3: The Impact of Ecosystem Maturity

Post Syndicated from Eric Mortaro original https://blog.rapid7.com/2022/04/04/cloud-pentesting-pt-3-the-impact-of-ecosystem-maturity/

Cloud Pentesting, Pt. 3: The Impact of Ecosystem Maturity

Now that we’ve covered the basics of cloud pentesting and the style in which a cloud environment could be attacked, let’s turn our attention to the entirety of this ecosystem. This environment isn’t too different from the on-premise ecosystem that traditional penetration testing is performed on. Who doesn’t want to gain internal access to the client’s environment from an external perspective? Recently, one consultant obtained firewall access due to default credentials never being changed, and the management interface was being publicly exposed. Or how about gaining a shell on a web server because of misconfigurations?  

Typically, a client who has a bit more maturity beyond just a vulnerability management program will shift gears to doing multiple pentests against their environments, which are external, internal, web app, mobile app, wireless, and potentially more. By doing these types of pentests, clients can better understand which aspects of their ecosystem are failing and which are doing fine. This is no different than when their infrastructure is deployed in the cloud.

Cloud implementation maturity

There’s an old saying that one must learn how to crawl before walking and how to walk before running. That same adage runs true for pentesting. Pentesting a network before ever having some sort of vulnerability management program can certainly show the weaknesses within the network, but it may not show the true depth of the issue.

The same holds true with Red Teams. You wouldn’t want to immediately jump on the Red Team pentesting bandwagon without having gone through multiple iterations of pentesting to true up gaps within the environment. Cloud pentesting should be treated in the same manner.  

The maturity of a company’s cloud implementation will help determine the depth in which a cloud pentest can occur, if it can occur at all! To peel this orange back a bit, let’s say a company wants a cloud ecosystem pentest. Discovery calls to scope the project will certainly help uncover how a customer implements their cloud environment, but what if it’s a basic approach? As in, there is no use of cloud-native deployments, all user accounts have root access, tagging of assets within the environment is not implemented, and so on. Where does this leave a pentest?  

In this particular case, an ecosystem pentest is not feasible at this juncture. The more basic approaches, such as vulnerability management or scanning of built-in cloud vendor-specific checks, would most certainly be ideal. Again, crawl before you walk, and walk before you run.This would look more like a traditional pentest, where an external and an internal test are performed.

What if the client is very mature in their implementation of cloud? Now we’re talking! User accounts are not root, IAM roles are leveraged instead of users, departments have separate permission profiles, the environment utilizes cloud native deployments as much as possible, and there’s separation of department environments by means of accounts, access control lists (ACLs), or virtual private clouds (VPCs). This now becomes the cloud ecosystem pentest that will show gaps within the environment — with the understanding that the customer has implemented, to the best of their abilities, controls that are baked into the cloud platform.

Maturity example

I’ve had the absolute pleasure of chatting with a ton of potential customers that are interested in performing a cloud ecosystem pentest. This not only helps to understand how the customer needs their pentest to be structured, but it also helps me to understand how we can improve our offering at Rapid7. There’s one particular case that stood out to me, which helped me understand that some customers are simply not ready to move into a cloud-native deployment.  

In discussing Rapid7’s approach to cloud ecosystem pentesting, we typically ask what types of services the customer uses with their respective cloud vendor. In this discussion with this particular customer, we discovered they were using Kubernetes (K8s) quite extensively. After we asked a few more questions, it turned out that the customer wasn’t using K8s from a cloud-native perspective — rather, they had installed Kubernetes on their own virtual machines and were administering it from there. The reason behind this was that they just weren’t ready yet to fully transition to a cloud vendor running other parts of their infrastructure.  

Now, this is a bit of a head-scratcher, because in this type of scenario, they’re taking on more of the support than is necessary. Who am I to argue, though?  The customer and I had a very fruitful conversation, which actually led us both to a deeper understanding of not only their business approach but also their IT infrastructure strategy.

So, in this particular instance, if we were to pentest K8s that this customer deployed onto their virtual machines, how far could we go? Well, since they own the entire stack — from the operating system, to the software, to the actual containers — we can go as far as we can go. If, however, this had been deployed from a cloud-native perspective, we would have restrictions due to the cloud vendor’s terms of services.

One major restriction is container escapes, which are out of scope. This goes back to the shared environment that has made cloud so successful. If Rapid7 were capable of performing a container escape, not only would this have been severely out of scope, but Rapid7 would most certainly be reporting the exploit to the cloud vendor themselves. These are the dreams of a white hat hacker, who signed up to perform a bug bounty and get paid out potentially tens of thousands of dollars!

But while that isn’t exactly how all cloud pentests turn out, they can still be done just as effectively as traditional on-premise pentests. It just requires a clear understanding of how the customer has deployed their cloud ecosystem, how mature their implementation is, and what is in and out of scope for a pentest based on those factors.

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Claws Mail 4.1.0 released

Post Syndicated from original https://lwn.net/Articles/890213/

Version 4.1.0 of the Claws Mail email client is out. New features include
text zooming in the message view, improvements to a number of preferences,
a “keyword warner” plugin to give a warning before sending a message
containing any (user-defined) keywords, and more.

New features from Apache Hudi 0.9.0 on Amazon EMR

Post Syndicated from Kunal Gautam original https://aws.amazon.com/blogs/big-data/new-features-from-apache-hudi-0-9-0-on-amazon-emr/

Apache Hudi is an open-source transactional data lake framework that greatly simplifies incremental data processing and data pipeline development. It does this by providing transaction support and record-level insert, update, and delete capabilities on data lakes on Amazon Simple Storage Service (Amazon S3) or Apache HDFS. Apache Hudi is integrated with open-source big data analytics frameworks, such as Apache Spark, Apache Hive, Presto, and Trino. Furthermore, Apache Hudi lets you maintain data in Amazon S3 or Apache HDFS in open formats such as Apache Parquet and Apache Avro.

Common use cases where we see customers use Apache Hudi are as follows:

  • To simplify data ingestion pipelines that deal with late-arriving or updated records from streaming and batch data sources.
  • To ingest data using Change Data Capture (CDC) from transactional systems.
  • To implement data-deletion pipelines to comply with data privacy regulations, e.g., GDPR (General Data Protection Regulation) compliance. Conforming to GDPR is a necessity of today’s modern data architectures, which includes the features of “right to erasure” or “right to be forgotten”, and it can be implemented using Apache Hudi capabilities in place of deletes and updates.

We are excited to announce that Apache Hudi 0.9.0 is available on Amazon EMR 5.34 and EMR 6.5.0. This is a major release, which includes Spark SQL DML and DDL support as its highlight, along with several other writer/reader side improvements. The 3x query performance improvement that we observe over Hudi 0.6.0 is especially remarkable so if you are looking to implement a transactional data lake with record level upserts and deletes or are using an older version of Hudi, this is a great version to use. In this post, we’ll focus on the following new features and improvements that come with the 0.9.0 release:

  • Spark SQL DML and DDL Support: Explore Spark SQL DML and DDL support.
  • Performance Improvements: Explore the performance improvements and new performance related features introduced on the writer and query side.
  • Additional Features: Explore additional useful features, such as Amazon DynamoDB-based locks for Optimistic Concurrency Control (OCC), delete partitions operation, etc.

Spark SQL DML and DDL support

The most exciting new feature is that Apache Hudi 0.9.0 adds support for DDL/DMLs using Spark SQL. This takes a huge step toward making Hudi more easily accessible, operable by all people (non-engineers, analysts, etc.). Moreover, it enables existing datasets to be easily migrated to Apache Hudi tables, and it takes a step closer to a low-code paradigm using Spark SQL DML and DDL hence eliminating the need to write scala/python code.

Users can now create tables using CREATE TABLE....USING HUDI and CREATE TABLE .. AS SELECT SQL statements to directly manage tables in AWS Glue catalog.

Then, users can use INSERT, UPDATE, MERGE INTO, and DELETE SQL statements to manipulate data. The INSERT OVERWRITE statement can be used to overwrite existing data in the table or partition for existing batch ETL pipelines.

Let’s run through a quick example where we create a Hudi table amazon_customer_review_hudi resembling the schema of Amazon Customer reviews Public Dataset and perform the following activities:

  • Pre-requisite: Create Amazon Simple Storage Service (S3) Buckets s3://EXAMPLE-BUCKET and s3://EXAMPLE-BUCKET-1
  • Create a partitioned Hudi table amazon_product_review_hudi
  • Create a source Hudi table amazon_customer_review_parquet_merge_source with contents that will be merged with the amazon_product_review_hudi table
  • Insert data into amazon_customer_review_parquet_merge_source and amazon_product_review_hudi as well as perform a merge operation by reading the data from
    amazon_customer_review_parquet_merge_source and merging with the Hudi table amazon_product_review_hudi
  • Perform a delete operation on amazon_customer_review_hudi over the previously inserted records

Configure Spark Session

We use the following script via EMR studio notebook, to configure Spark Session to work with Apache Hudi DML and DDL support. The following examples demonstrate how to launch the interactive Spark shell, use Spark submit, or use Amazon EMR Notebooks to work with Hudi on Amazon EMR. We recommend launching your EMR cluster with the following Apache Livy configuration:

[
    {
        "Classification": "livy-conf",
        "Properties": {
            "livy.file.local-dir-whitelist": "/usr/lib/hudi"
        }
    }
]

The above configuration lets you directly refer to the local /usr/lib/hudi/hudi-spark-bundle.jar on the EMR leader node while configuring the Spark session. Alternatively, you can also copy /usr/lib/hudi/hudi-spark-bundle.jar over to an HDFS location and refer to that while initializing Spark session. Here is a command for initializing the Spark session from a notebook:

%%configure -f
{
    "conf" : {
        "spark.jars":"file:///usr/lib/hudi/hudi-spark-bundle.jar",
        "spark.serializer":"org.apache.spark.serializer.KryoSerializer",
        "spark.sql.extensions":"org.apache.spark.sql.hudi.HoodieSparkSessionExtension"
    }
}

Create a Table

Let’s create the following Apache Hudi tables amazon_customer_review_hudi and amazon_customer_review_parquet_merge_source

amazon_customer_review_hudi and amazon_customer_review_parquet_merge_source

%%sql 

/****************************
Create a HUDI table having schema same as of Amazon customer reviews table containing selected columns 
*****************************/

-- Hudi 0.9.0 configuration https://hudi.apache.org/docs/configurations
-- Hudi configurations can be set in options block as hoodie.datasource.hive_sync.assume_date_partitioning = 'false',


create table if not exists amazon_customer_review_hudi
    ( marketplace string, 
      review_id string, 
      customer_id string,
      product_title string,
      star_rating int,
      timestamp long ,
      review_date date,
      year string,
      month string ,
      day string
      )
      using hudi
      location 's3://EXAMPLE-BUCKET/my-hudi-dataset/'
      options ( 
      type = 'cow',  
      primaryKey = 'review_id', 
      preCombineField = 'timestamp',
      hoodie.datasource.write.hive_style_partitioning = 'true'
      )
      partitioned by (year,month,day);
      

-- Change Location 's3://EXAMPLE-BUCKET/my-hudi-dataset/' to appropriate S3 bucket you have created in your AWS account

%%sql 
/****************************
Create amazon_customer_review_parquet_merge_source  to be used as source for merging into amazon_customer_review_hudi.
The table contains deleteRecord column to track if deletion of record is needed
*****************************/


create table if not exists amazon_customer_review_parquet_merge_source 
       (
        marketplace string, 
        review_id string, 
        customer_id string,
        product_title string,
        star_rating int,
        review_date date,
        deleteRecord string
       )
       STORED AS PARQUET
       LOCATION 's3://EXAMPLE-BUCKET-1/toBeMergeData/'


-- Change Location (s3://EXAMPLE-BUCKET-1/toBeMergeData/') to appropriate S3 bucket you have created in your AWS account

For comparison if, amazon_customer_review_hudi was to be created using programmatic approach the PySpark sample code is as follows.

# Create a DataFrame
inputDF = spark.createDataFrame(
    [
         ("Italy", "11", "1111", "table", 5, 1648126827, "2015/05/02", "2015", "05", "02"),
         ("Spain", "22", "2222", "chair", 5, 1648126827, "2015/05/02", "2015", "05", "02")        
    ],
    ["marketplace", "review_id", "customer_id", "product_title", "star_rating", "timestamp", "review_date", "year", "month", "day" ]
)

# Print Schema of inputDF 
inputDF.printSchema()

# Specify common DataSourceWriteOptions in the single hudiOptions variable
hudiOptions = {
"hoodie.table.name": "amazon_customer_review_hudi",
"hoodie.datasource.write.recordkey.field": "review_id",
"hoodie.datasource.write.partitionpath.field": "year,month,day",
"hoodie.datasource.write.precombine.field": "timestamp",
"hoodie.datasource.write.hive_style_partitioning": "true", 
"hoodie.datasource.hive_sync.enable": "true",
"hoodie.datasource.hive_sync.table": " amazon_customer_review_hudi",
"hoodie.datasource.hive_sync.partition_fields": "year,month,day",
"hoodie.datasource.hive_sync.partition_extractor_class": "org.apache.hudi.hive.MultiPartKeysValueExtractor"
}


# Create Hudi table and insert data into my_hudi_table_1 hudi table at the S3 location specified 
inputDF.write \
       .format("org.apache.hudi")\
       .option("hoodie.datasource.write.operation", "insert")\
       .options(**hudiOptions)\
       .mode("append")\
       .save("s3://EXAMPLE-BUCKET/my-hudi-dataset/") 

Insert data into the Hudi tables

Let’s insert records into the table amazon_customer_review_parquet_merge_source to be used for the merge operation. This includes inserting a row for fresh insert, update, and delete.

%%sql 

/****************************
 Insert a record into amazon_customer_review_parquet_merge_source for deletion 
*****************************/

-- The record will be deleted from amazon_customer_review_hudi after merge as deleteRecord  is set to yes

insert into amazon_customer_review_parquet_merge_source
    select
    'italy',
    '11',
    '1111',
    'table',
     5,
    TO_DATE(CAST(UNIX_TIMESTAMP('2015/05/02', 'yyyy/MM/dd') AS TIMESTAMP)) as  review_date,
    'yes' 
    
   

%%sql
/****************************
 Insert a record into amazon_customer_review_parquet_merge_source used for update
*****************************/

-- The record will be updated from amazon_customer_review_hudi with new Star rating and product_title after merge

insert into amazon_customer_review_parquet_merge_source
    select
    'spain',
    '22',
    '2222',
    'Relaxing chair',
     4,
    TO_DATE(CAST(UNIX_TIMESTAMP('2015/05/02', 'yyyy/MM/dd') AS TIMESTAMP)) as  review_date,
    'no' 


%%sql
/****************************
 Insert a record into amazon_customer_review_parquet_merge_source for insert 
*****************************/

-- The record will be inserted into amazon_customer_review_hudi after merge 

insert into amazon_customer_review_parquet_merge_source
    select
    'uk',
    '33',
    '3333',
    'hanger',
     3,
    TO_DATE(CAST(UNIX_TIMESTAMP('2015/05/02', 'yyyy/MM/dd') AS TIMESTAMP)) as  review_date,
    'no' 

Now let’s insert records into the amazon_customer_review_hudi table used as the destination table for the merge operation.

%%sql

/****************************
 Insert a record into amazon_customer_review_hudi table for deletion after merge 
*****************************/

-- Spark SQL date time functions https://spark.apache.org/docs/latest/api/sql/index.html#date_add

insert into amazon_customer_review_hudi 
    select 
    'italy',
    '11',
    '1111',
    'table',
     5,
    unix_timestamp(current_timestamp()) as timestamp,
    TO_DATE(CAST(UNIX_TIMESTAMP('2015/05/02', 'yyyy/MM/dd') AS TIMESTAMP)) as  review_date,
    date_format(date '2015-05-02', "yyyy") as year, 
    date_format(date '2015-05-02', "MM") as month,
    date_format(date '2015-05-02', "dd") as day  


%%sql
/****************************
 Insert a record into amazon_customer_review_hudi table for update after merge 
*****************************/

insert into  amazon_customer_review_hudi
    select 
    'spain',
    '22',
    '2222',
    'chair ',
     5,
    unix_timestamp(current_timestamp()) as timestamp,
    TO_DATE(CAST(UNIX_TIMESTAMP('2015/05/02', 'yyyy/MM/dd') AS TIMESTAMP)) as  review_date,
    date_format(date '2015-05-02', "yyyy") as year, 
    date_format(date '2015-05-02', "MM") as month,
    date_format(date '2015-05-02', "dd") as day  

Merge into

Let’s perform the merge from amazon_customer_review_parquet_merge_source into amazon_customer_review_hudi.

%%sql 

/*************************************
MergeInto : Merge Source Into Traget 
**************************************/

-- Source amazon_customer_review_parquet_merge_source 
-- Taget amazon_customer_review_hudi

merge into amazon_customer_review_hudi as target
using ( 
        select
        marketplace, 
        review_id, 
        customer_id,
        product_title,
        star_rating,
        review_date,
        deleteRecord,
        date_format(review_date, "yyyy") as year,
        date_format(review_date, "MM") as month,
        date_format(review_date, "dd") as day
        from amazon_customer_review_parquet_merge_source ) source
on target.review_id = source.review_id 
when matched and deleteRecord != 'yes' then 

update set target.timestamp = unix_timestamp(current_timestamp()),  
target.star_rating = source.star_rating, 
target.product_title = source.product_title

when matched and deleteRecord = 'yes' then delete

when not matched then insert 
      ( target.marketplace, 
        target.review_id, 
        target.customer_id,
        target.product_title,
        target.star_rating,
        target.timestamp ,
        target.review_date,
        target.year ,
        target.month  ,
        target.day
      ) 
      values
      (
        source.marketplace,
        source.review_id, 
        source.customer_id,
        source.product_title,
        source.star_rating,
        unix_timestamp(current_timestamp()),
        source.review_date,
        source.year , 
        source.month ,
        source.day 
       )

Considerations and Limitations

  • The merge-on condition can only be applied on primary key as of now.
    -- The merge condition is possible only on primary keys
    on target.review_id = source.review_id
  • Support for partial updates is supported for the Copy on Write (CoW) table, but it isn’t supported for the Merge on Read (MoR) tables.
  • The target table’s fields cannot be the right-value of the update expression for the MoR table:
    -- The update will result in an error as target columns are present on right hand side of the expression
    update set target.star_rating =  target.star_rating +1 

Delete a Record

Now let’s delete the inserted record.

%%sql

/*************************************
Delete the inserted record from amazon_customer_review_hudi table 
**************************************/
Delete from amazon_customer_review_hudi where review_id == '22'


%%sql 
/*************************************
Query the deleted record from amazon_customer_review_hudi table 
**************************************/
select * from amazon_customer_review_hudi where review_id == '22'

Schema Evolution

Hudi supports common schema evolution scenarios, such as adding a nullable field or promoting the datatype of a field. Let’s add a new column ssid (type int) to existing amazon_customer_review_hudi table, and insert a record with extra column. Hudi allows for querying both old and new data with the updated table schema.

%%sql

/*************************************
Adding a new column name ssid of type int to amazon_customer_review_hudi table
**************************************/

ALTER TABLE amazon_customer_review_hudi ADD COLUMNS (ssid int)

%%sql
/*************************************
Adding a new record to altered table amazon_customer_review_hudi 
**************************************/
insert into amazon_customer_review_hudi
    select 
    'germany',
    '55',
    '5555',
    'car',
     5,
    unix_timestamp(current_timestamp()) as timestamp,
    TO_DATE(CAST(UNIX_TIMESTAMP('2015/05/02', 'yyyy/MM/dd') AS TIMESTAMP)) as  review_date,
    10 as ssid,
    date_format(date '2015-05-02', "yyyy") as year, 
    date_format(date '2015-05-02', "MM") as month,
    date_format(date '2015-05-02', "dd") as day  

%%sql 
/*************************************
Promoting ssid type from int to long  
**************************************/
ALTER TABLE amazon_customer_review_hudi CHANGE COLUMN ssid ssid long


%%sql 
/*************************************
Querying data from amazon_customer_review_hudi table
**************************************/
select * from amazon_customer_review_hudi where review_id == '55'

Spark Performance Improvements

Query Side Improvements

Apache Hudi tables are now registered with the metastore as Spark Data Source tables. This enables Spark SQL queries on Hudi tables to use Spark’s native Parquet Reader in case of Copy on Write tables, and Hudi’s custom MergeOnReadSnapshotRelation in case of Merge on Read tables. Therefore, it no longer depends on Hive Input Format fallback within Spark, which isn’t as maintained and efficient as Spark’s native readers. This unlocks many optimizations, such as the use of Spark’s native parquet readers, and implementing Hudi’s own Spark FileIndex implementation. The File Index helps improve file listing performance via optimized caching, support for partition pruning, as well as the ability to list files via Hudi metadata table (instead of listing directly from Amazon S3). In addition, Hudi now supports time travel query via Spark data source, which lets you query snapshot of the dataset as of a historical time instant.

Other important things to note are:

  • Configurations such as spark.sql.hive.convertMetastoreParquet=false and mapreduce.input.pathFilter.class=org.apache.hudi.hadoop.HoodieROTablePathFilter are no longer needed while querying via Spark SQL.
  • Now you can use a non-globbed query path when querying Hudi datasets via Data Source API. This lets you query the table via base path without having to specify * in the query path.

We ran a performance benchmark derived from the 3 TB scale TPC-DS benchmark to determine the query performance improvements for Hudi 0.9.0 on EMR 6.5.0, relative to Hudi 0.6.0 on EMR 6.2.0 (at the beginning of 2021) for Copy on Write tables. The queries were run on 5-node c5.9xlarge EMR clusters.

In terms of Geometric Mean, the queries with Hudi 0.9.0 are three times faster than they were with Hudi 0.6.0. The following graphs compare the total aggregate runtime and geometric mean of runtime for all of the queries in the TPC-DS 3 TB query dataset between the two Amazon EMR/Hudi releases (lower is better):

Hudi-0.9 TPC-DS-1

In terms of Geometric Mean the queries with Hudi 0.9.0 are 3 times faster than they were with Hudi 0.6.0.

Writer side improvements

Virtual Keys Support

Apache Hudi maintains metadata by adding additional columns to the datasets. This lets it support upsert/delete operations and various capabilities around it, such as incremental queries, compaction, etc. These metadata columns (namely _hoodie_commit_time, _hoodie_record_key, _hoodie_partition_path, _hoodie_file_name and _hoodie_commit_seqno) let Hudi uniquely identify a record, the partition/file in which a record exists, and the latest commit that updated a record.

However, generating and maintaining these metadata columns increases the storage footprint for Hudi tables on disk. Some of these columns, such as _hoodie_record_key and _hoodie_partition_path, can be constructed from other data columns already stored in the datasets. Apache Hudi 0.9.0 has introduced support for Virtual Keys. This lets users disable the generation of these metadata columns, and instead depend on actual data columns to construct the record key/partition paths dynamically using appropriate key generators. This helps in reducing the storage footprint, as well as improving ingestion time. However, this feature comes with the following caveats:

  • This is only meant to be used for Append Only / Immutable data. It can’t be used for use cases requiring upserts and deletes, which requires metadata columns such as _hoodie_record_key and _hoodie_partition_path for bloom indexes to work.
  • Incremental queries will not be supported, because they need _hoodie_commit_time to filter records written/updated at a specific time.
  • Once this feature is enabled, it can’t be turned off for an existing table.

The feature is turned off by default, and it can be enabled by setting hoodie.populate.meta.fields to false. We measured the write performance and storage footprint improvements using Bulk Insert with public Amazon Customer Reviews dataset. Here is the code snippet that we used:

import org.apache.hudi.DataSourceWriteOptions
import org.apache.hudi.config.HoodieWriteConfig
import org.apache.spark.sql.SaveMode

var srcPath = "s3://amazon-reviews-pds/parquet/"
var tableName = "amazon_reviews_table"
var tablePath = "s3://<bucket>/<prefix>/" + tableName

val inputDF = spark.read.format("parquet").load(srcPath)

inputDF.write.format("hudi")
 .option(HoodieWriteConfig.TABLE_NAME, tableName)
 .option(DataSourceWriteOptions.OPERATION_OPT_KEY, DataSourceWriteOptions.BULK_INSERT_OPERATION_OPT_VAL)
 .option(DataSourceWriteOptions.TABLE_TYPE_OPT_KEY, DataSourceWriteOptions.COW_TABLE_TYPE_OPT_VAL)
 .option(DataSourceWriteOptions.RECORDKEY_FIELD_OPT_KEY, "review_id")
 .option(DataSourceWriteOptions.PARTITIONPATH_FIELD_OPT_KEY, "product_category") 
 .option(DataSourceWriteOptions.PRECOMBINE_FIELD_OPT_KEY, "review_date")
 .option("hoodie.populate.meta.fields", "<true/false>")
 .mode(SaveMode.Overwrite)
 .save(tablePath)

The experiment was run on a four node c4.2xlarge EMR cluster (one leader, three core). We observed a 10.63% improvement in the write runtime performance, and a 8.67% reduction in storage footprint with virtual keys enabled. The following graph compares the bulk insert runtime and table size with and without virtual keys (lower is better):

BDB-2071-Virtual_key_1

BDB-2071-Virtual_key_2” width=

Timeline Server-based Marker Mechanism

Apache Hudi supports the automatic cleaning up of uncommitted data written during write operations. This cleaning is supported by generating marker files corresponding to each data file, which serves as a method to track data files of interest rather than having to scan the entire table by listing all of the files. Although the existing marker mechanism is much more efficient than scanning the entire table for uncommitted data files, it can still have a performance impact for Amazon S3 data lakes. For example, writing a significant number of marker files (one per-data file) and then deleting them following a successful commit could take a non-trivial amount of time, sometimes in the order of several minutes. In addition, it has the potential to hit Amazon S3 throttling limits when a significant number of data/marker files are being written concurrently.

Apache Hudi 0.9.0 introduces a new timeline server based implementation of this marker mechanism. This makes it more efficient for Amazon S3 workloads by improving the overall write performance, as well as significantly decreasing the probability of hitting Amazon S3 throttle limits. The new mechanism uses Hudi’s timeline server component as a central place for processing all of the marker creation/deletion requests (from all executors), which allows for batching of these requests and reducing the number of requests to Amazon S3. Therefore, users with Amazon S3 data lakes can leverage this to improve write operations performance and avoid throttling due to marker files management. It would be especially impactful for scenarios where a significant number of data files (e.g., 10k or more) are being written.

This new mechanism is not enabled by default, and it can be enabled by setting hoodie.write.markers.type to timeline_server_based, for the write operation. For more details about the feature, refer to this blog post by the Apache Hudi community.

Additional Improvements

DynamoDB-based Locking

Optimistic Concurrency Control was one of the major features introduced with Apache Hudi 0.8.0 to allow multiple concurrent writers to ingest data into the same Hudi table. The feature requires acquiring locks for which either Zookeeper (default on EMR) or Hive Metastore could be used. However, these lock providers require all of the writers to be running on the same cluster on which the Zookeeper/Hive Metastore is running.

Apache Hudi 0.9.0 on Amazon EMR has introduced DynamoDB as a lock provider. This would let multiple writers running across different clusters ingest data into the same Hudi table. This feature was originally added to Hudi 0.9.0 on Amazon EMR, and it contributed back to open source Hudi in version 0.10.0. To configure this, the following properties should be set:

Configuration Value Description Required
hoodie.write.lock.provider org.apache.hudi.client.
transaction.lock.
DynamoDBBasedLockProvider
Lock Provider implementation to be used Yes
hoodie.write.lock.dynamodb.
table
<String> DynamoDB table name to be used for acquiring locks. If the table doesn’t exist, it will be created. The same table can be used across all of your Hudi jobs operating on the same or different tables Yes
hoodie.write.lock.dynamodb.
partition_key
<String> String Value to be used for the locks table partition key attribute. It must be a string that uniquely identifies a Hudi table, such as the Hudi table name No. Default: Hudi Table Name
hoodie.write.lock.dynamodb.
region
<String> AWS Region in which the DynamoDB locks table exists, or must be created.

No. Default:

us-east-1

hoodie.write.lock.dynamodb.
billing_mode
<String> DynamoDB billing mode to be used for the locks table while creating. If the table already exists, then this doesn’t have an effect No. Default:
PAY_PER_REQUEST
hoodie.write.lock.dynamodb.
read_capacity
<Integer> DynamoDB read capacity to be used for the locks table while creating. If the table already exists, then this doesn’t have an effect No. Default: 20
hoodie.write.lock.dynamodb.
write_capacity
<Integer> DynamoDB write capacity to be used for the locks table while creating. If the table already exists, then this doesn’t have an effect No. Default: 10

Furthermore, Optimistic Concurrency Control must be enabled via the following:

hoodie.write.concurrency.mode = optimistic_concurrency_control
hoodie.cleaner.policy.failed.writes = LAZY

You can seamlessly configure these properties at the cluster level, using EMR Configurations API with hudi-defaults classification, to avoid having to configure it with every job.

Delete partitions

Apache Hudi 0.9.0 introduces a DELETE_PARTITION operation for its Spark Data Source API that can be leveraged to delete partitions. Here is a scala example of how to leverage this operation:

import org.apache.hudi.DataSourceWriteOptions
import org.apache.hudi.config.HoodieWriteConfig
import org.apache.spark.sql.SaveMode

val deletePartitionDF = spark.emptyDataFrame

deletePartitionDF.write.format("hudi")
 .option(HoodieWriteConfig.TABLE_NAME, "<table name>")
 .option(DataSourceWriteOptions.OPERATION_OPT_KEY, DataSourceWriteOptions.DELETE_PARTITION_OPERATION_OPT_VAL)
 .option(DataSourceWriteOptions.PARTITIONS_TO_DELETE.key(), "<partition_value1>,<partition_value2>")
 .option(DataSourceWriteOptions.TABLE_TYPE_OPT_KEY, DataSourceWriteOptions.COW_TABLE_TYPE_OPT_VAL)
 .option(DataSourceWriteOptions.RECORDKEY_FIELD_OPT_KEY, "<record key(s)>")
 .option(DataSourceWriteOptions.PARTITIONPATH_FIELD_OPT_KEY, "<partition field(s)>") 
 .option(DataSourceWriteOptions.PRECOMBINE_FIELD_OPT_KEY, "<precombine key>")
 .mode(SaveMode.Append)
 .save("<table path>")

However, there is a known issue:

  • Hive Sync fails when performed along with DELETE_PARTITION operation because of a bug. Hive Sync will succeed for any future insert/upsert/delete operation performed following the delete partition operation. This bug has been fixed in Hudi release 0.10.0.

Asynchronous Clustering

Apache Hudi 0.9.0 introduces support for asynchronous clustering via Spark structured streaming sink and Delta Streamer. This lets users continue ingesting data into the data lake, while the clustering service continues to run in the background to reorganize data for improved query performance and optimal file sizes. This is made possible with the Optimistic Concurrency Control feature introduced in Hudi 0.8.0. Currently, clustering can only be scheduled for partitions that aren’t receiving any concurrent updates. Additional details on how to get started with this feature can be found in this blog post.

Conclusion

In this post, we shared some of the new and exciting features in Hudi 0.9.0 available on Amazon EMR versions 5.34 and 6.5.0 and later. These new features enable the ability for data pipelines to be built solely with SQL statements, thereby making it easier to build transactional data lakes on Amazon S3.

As a next step, for a hands on experience on Hudi 0.9.0 on EMR, try out the notebook here on EMR Studio using Amazon EMR version 6.5.0 and let us know your feedback.


About the Authors

Kunal Gautam is a Senior Big Data Architect at Amazon Web Services. Having experience in building his own Startup and working along with enterprises, he brings a unique perspective to get people, business and technology work in tandem for customers. He is passionate about helping customers in their digital transformation journey and enables them to build scalable data and advance analytics solutions to gain timely insights and make critical business decisions. In his spare time, Kunal enjoys Marathons, Tech Meetups and Meditation retreats.

Gabriele Cacciola is a Senior Data Architect working for the Professional Service team with Amazon Web Services. Coming from a solid Startup experience, he currently helps enterprise customers across EMEA implement their ideas, innovate using the latest tech and build scalable data and analytics solutions to make critical business decisions. In his free time, Gabriele enjoys football and cooking.

Udit Mehrotra is a software development engineer at Amazon Web Services and an Apache Hudi PMC member/committer. He works on cutting-edge features of Amazon EMR and is also involved in open-source projects such as Apache Hudi, Apache Spark, Apache Hadoop, and Apache Hive. In his spare time, he likes to play guitar, travel, binge watch, and hang out with friends.

Understanding the JVMMemoryPressure metric changes in Amazon OpenSearch Service

Post Syndicated from Liz Snyder original https://aws.amazon.com/blogs/big-data/understanding-the-jvmmemorypressure-metric-changes-in-amazon-opensearch-service/

Amazon OpenSearch Service is a managed service that makes it easy to secure, deploy, and operate OpenSearch and legacy Elasticsearch clusters at scale.

In the latest service software release of Amazon OpenSearch Service, we’ve changed the behavior of the JVMMemoryPressure metric. This metric now reports the overall heap usage, including young and old pools, for all domains that use the G1GC garbage collector. If you’re using Graviton-based data nodes (C6, R6, and M6 instances), or if you enabled Auto-Tune and it has switched your garbage collection algorithm to G1GC, this change will improve your ability to detect and respond to problems with OpenSearch’s Java heap.

Basics of Java garbage collection

Objects in Java are allocated in a heap memory, occupying half of the instance’s RAM up to approximately 32 GB. As your application runs, it creates and destroys objects in the heap, leaving the heap fragmented and making it harder to allocate new objects. Java’s garbage collection algorithm periodically goes through the heap and reclaims the memory of any unused objects. It also compacts the heap when necessary to provide more contiguous free space.

The heap is allocated into smaller memory pools:

Young generation – The young generation memory pool is where new objects are allocated. The young generation is further divided into an Eden space, where all new objects start, and two survivor spaces (S0 and S1), where objects are moved from Eden after surviving one garbage collection cycle. When the young generation fills up, Java performs a minor garbage collection to clean up unmarked objects. Objects that remain in the young generation age until they eventually move to the old generation.

Old generation – The old generation memory pool stores long-lived objects. When objects reach a certain age after multiple garbage collection iterations in the young generation, they are then moved to the old generation.

Permanent generation – The permanent generation contains metadata required by the JVM to describe the classes and methods used in the application at runtime. It is not populated when the old generation’s objects reach a certain age.

Java processes can employ different garbage collection algorithms, selected by command-line option.

  • Concurrent Mark Sweep (CMS) – The different pools are segregated in memory. Stop-the-world pauses, and heap compaction are regular occurrences. The young generation pool is small. All non-Graviton data nodes use CMS.
  • G1 Garbage Collection (G1GC) – All heap memory is a single block, with different areas of memory (regions) allocated to the different pools. The pools are interleaved in physical memory. Stop-the-world pauses and heap compaction are infrequent. The young generation pool is larger. All Graviton data nodes use G1GC. Amazon OpenSearch Service’s Auto-Tune feature can choose G1GC for non-Graviton data nodes.

You can use the CloudWatch console to retrieve statistics about those data points as an ordered set of time-series data, known as metrics. Amazon OpenSearch Service currently publishes three metrics related to JVM memory pressure to CloudWatch:

  • JVMMemoryPressure – The maximum percentage of the Java heap used for all data nodes in the cluster.
  • MasterJVMMemoryPressure – The maximum percentage of the Java heap used for all dedicated master nodes in the cluster.
  • WarmJVMMemoryPressure – The maximum percentage of the Java heap used for UltraWarm nodes in the cluster.

In the latest service software update, Amazon OpenSearch Service improved the logic that it uses to compute these metrics in order to more accurately reflect actual memory utilization.

The problem

Previously, all data nodes used CMS, where the young pool was a small portion of memory. The JVM memory pressure metrics that Amazon OpenSearch Service published to CloudWatch only considered the old pool of the Java heap. You could detect problems in the heap usage by looking only at old generation usage.

When the domain uses G1GC, the young pool is larger, representing a larger percentage of the total heap. Since objects are created first in the young pool, and then moved to the old pool, a significant portion of the usage could be in the young pool. However, the prior metric reported only on the old pool. This leaves domains vulnerable to invisibly running out of memory in the young pool.

What’s changing?

In the latest service software update, Amazon OpenSearch Service changed the logic for the three JVM memory pressure metrics that it sends to CloudWatch to account for the total Java heap in use (old generation and young generation). The goal of this update is to provide a more accurate representation of total memory utilization across your Amazon Opensearch Service domains, especially for Graviton instance types, whose garbage collection logic makes it important to consider all memory pools to calculate actual utilization.

What you can expect

After you update your Amazon OpenSearch Service domains to the latest service software release, the following metrics that Amazon OpenSearch Service sends to CloudWatch will begin to report JVM memory usage for the old and young generation memory pools, rather than just old: JVMemoryPressure, MasterJVMMemoryPressure, and WarmJVMMemoryPressure.

You might see an increase in the values of these metrics, predominantly in G1GC configured domains. In some cases, you might notice a different memory usage pattern altogether, because the young generation memory pool has more frequent garbage collection. Any CloudWatch alarms that you have created around these metrics might be triggered. If this keeps happening, consider scaling your instances vertically up to 64 GiB of RAM, at which point you can scale horizontally by adding instances.

As a standard practice, for domains that have low available memory, Amazon OpenSearch Service blocks further write operations to prevent the domain from reaching red status. You should monitor your memory utilization after the update to get a sense of the actual utilization on your domain. The _nodes/stats/jvm API offers a useful summary of JVM statistics, memory pool usage, and garbage collection information.

Conclusion

Amazon OpenSearch Service recently improved the logic that it uses to calculate JVM memory usage to more accurately reflect actual utilization. The JVMMemoryPressure, MasterJVMMemoryPressure, and WarmJVMMemoryPressure CloudWatch metrics now account for both old and young generation memory pools when calculating memory usage, rather than just old generation. For more information about these metrics, see Monitoring OpenSearch cluster metrics with Amazon CloudWatch.

With the updated metrics, your domains will start to more accurately reflect memory utilization numbers, and might breach CloudWatch alarms that you previously configured. Make sure to monitor your alarms for these metrics and scale your clusters accordingly to maintain optimal memory utilization.

Stay tuned for more exciting updates and new features in Amazon OpenSearch Service.


About the Authors

Liz Snyder is a San Francisco-based technical writer for Amazon OpenSearch Service, OpenSearch OSS, and Amazon CloudSearch.

Jon Handler is a Senior Principal Solutions Architect, specializing in AWS search technologies – Amazon CloudSearch, and Amazon OpenSearch Service. Based in Palo Alto, he helps a broad range of customers get their search and log analytics workloads deployed right and functioning well.

Internet disruptions overview for Q1 2022

Post Syndicated from David Belson original https://blog.cloudflare.com/q1-2022-internet-disruption-summary/

Internet disruptions overview for Q1 2022

Internet disruptions overview for Q1 2022

Cloudflare operates in more than 250 cities in over 100 countries, where we interconnect with over 10,000 network providers in order to provide a broad range of services to millions of customers. The breadth of both our network and our customer base provides us with a unique perspective on Internet resilience, enabling us to observe the impact of Internet disruptions. In many cases, these disruptions can be attributed to a physical event, while in other cases, they are due to an intentional government-directed shutdown. In this post, we review selected Internet disruptions observed by Cloudflare during the first quarter of 2022, supported by traffic graphs from Cloudflare Radar and other internal Cloudflare tools, and grouped by associated cause.

Plate tectonics

Internet outages caused by “earth movers” are more frequently caused by errant backhoes. However, two Internet disruptions in the first quarter were caused by more significant earth movement — a volcanic eruption and an earthquake.

The first impacted connectivity on the island nation of Tonga, when the Hunga Tonga–Hunga Ha’apai volcanic eruption damaged the submarine cable connecting Tonga to Fiji, resulting in a 38 day Internet outage. After the January 14 eruption, only minimal Internet traffic (via satellite services) was seen from Tonga. On February 22, Digicel announced that the main island was back online after initial submarine cable repairs were completed – the immediate return of traffic is clearly visible in the figure below. However, it was estimated that repairs to the domestic cable, connecting outlying islands, could take an additional six to nine months.

Internet disruptions overview for Q1 2022

The second disruption, caused by a 7.3 magnitude earthquake off the coast of central Japan on March 16, was significantly shorter, and had a significantly smaller impact. The earthquake occurred around 1436 UTC, causing power outages that resulted in a loss of Internet connectivity in cities including Tokyo for several hours, as seen in the figure below. Almost exactly 11 years prior, a magnitude 8.9 earthquake also had a nominal impact on Internet connectivity in Japan, that time apparently due to damage to subsea cable systems.

Internet disruptions overview for Q1 2022

Infrastructure damage

Internet resilience is, of course, heavily dependent on the resilience of the underlying physical infrastructure, including data centers, terrestrial fiber, and submarine cables. Damage to this infrastructure often disrupts Internet connectivity.

Early in the morning of January 5, the Gambia was completely isolated from the global Internet. As evident in the figure below, the incident lasted over eight hours, between 0117 and 0945 UTC. According to a press release from GAMTEL, after the failure of the primary link (damage to the ACE submarine cable), traffic was routed onto two backup links through Senegal. However, these backup links also failed because they converged in a location that was ultimately identified as a single point of failure.

Internet disruptions overview for Q1 2022

Around 2130 UTC on January 20, Internet traffic to Yemen dropped to near zero, as shown in the figure below, after ongoing airstrikes reportedly hit a telecommunications building in Al-Hudaydah where the FALCON undersea cable lands. The outage lasted four days, finally recovering around 2100 on January 24. The outage primarily affected YemenNet (Public Telecommunication Corporation), the state-owned telecommunications provider.

Internet disruptions overview for Q1 2022

On March 1, Tasmania suffered a 6.5-hour Internet outage after two of the three submarine cables (Basslink, Bass Strait-1, Bass Strait-2) connecting it to the Australian mainland were cut.

According to a published report, one of the cuts was on the Victorian (mainland) end, and the other on the Tasmanian side, with both cuts caused by “third parties”.  A significant reduction in traffic between 0130 – 0800 UTC is visible in the figure below.

Internet disruptions overview for Q1 2022

A reported Telecom Infrastructure Company (TIC) data center fire caused a four-hour Internet disruption in Iran on March 4. Telecom Infrastructure Company (TIC) is the monopoly provider of telecom infrastructure to all public and private operators in Iran. As the figure below shows, Internet traffic to the country dropped by approximately 20% at 0640 UTC, and recovered around 1030 UTC.

Internet disruptions overview for Q1 2022

On March 15, ETECSA, the Cuban state telecommunications company, reported that a fiber optic cable had been cut on a public road in the capital that morning. The impact of this fiber cut on Internet traffic to Cuba and ETECSA is visible in the figures below, starting just after 1200 UTC, lasting for over six hours.

Internet disruptions overview for Q1 2022
Internet disruptions overview for Q1 2022

Although initially believed to be the result of a power outage (all too common in Venezuela), a March 24 Internet disruption in the country was ultimately due to a fiber cut. Internet traffic to CANTV customers in multiple Venezuelan states dropped significantly between 1140 and 1740 UTC, as seen in the figure below. In addition to this disruption, VE sin Filtro reported a number of additional multi-hour, multi-state Internet disruptions in Venezuela during the first quarter.

Internet disruptions overview for Q1 2022

On March 31, Internet traffic to Telenor Pakistan dropped 60% between 0600-0745 UTC, as shown in the figure below. According to Telenor Pakistan responses to hundreds of customer complaints lodged via Twitter, the disruption was due to multiple fiber-optic cable cuts in several locations. Just after 1800 UTC, Telenor Pakistan Tweeted that services had been fully restored.

Internet disruptions overview for Q1 2022

Power outages

In addition to the physical infrastructure, reliable electrical power is also critical for resilient Internet connectivity. At a provider level, loss of power can take key data centers and routers offline, impacting connectivity for customers and other connected networks. Consumer power outages can take home/business routers and connected devices offline, forcing users onto mobile connectivity, assuming that is/remains available.

The interconnected electrical grids of Kazakhstan, Uzbekistan, and Kyrgyzstan all suffered outages on January 24 after Kazakhstan’s North-South power line was disconnected due to “emergency imbalances”. These power outages caused multi-hour Internet disruptions across all three countries starting around 0600 UTC, as the figures below show. The impact to traffic in Kazakhstan appeared to be fairly minor, while traffic declined significantly in Uzbekistan and Kyrgyzstan and took longer to recover.

Internet disruptions overview for Q1 2022
Internet disruptions overview for Q1 2022
Internet disruptions overview for Q1 2022

A power outage across multiple counties and cities in Taiwan starting around 0100 UTC on March 3 caused a brief #Internet disruption. The figure below shows a nominal initial drop in traffic, though traffic remained lower throughout the next several hours. The power outage was reportedly caused by human negligence during annual repairs of a generator at the Hsinta power plant.

Internet disruptions overview for Q1 2022

In addition to the fiber cut discussed above, Cuba’s Internet suffered a second disruption on March 24. A Tweet from ETECSA stated that a power failure had caused a disruption to voice service, SMS, and mobile data. Analysis of Internet traffic for both Cuba and ETECSA finds that the disruption started around 1230 UTC, and lasted for approximately 90 minutes, as shown in the figures below.

Internet disruptions overview for Q1 2022
Internet disruptions overview for Q1 2022

DDoS attack

Although distributed denial of service (DDoS) attacks often target web or application servers in an attempt to knock a given website or application offline, such attacks that target network infrastructure can have more widespread impact, not only restricting access to sites and applications hosted within that network, but also disrupting connectivity for users attached to the network.

Such a DDoS attack targeted AS8867 (E-Gov – Tehila Project) in Israel on March 14. The figure below shows that Internet traffic to that ASN began to decline just before 1530 UTC. A published report notes that the websites of the interior, health, justice and welfare ministries, as well as that of the Prime Minister’s office, were all taken offline as a result of the attack.

Internet disruptions overview for Q1 2022

Unspecified technical causes

As discussed above, the underlying technical or physical causes of Internet disruptions are often easily identified, frequently thanks to social media or other communications from the impacted network providers. However, sometimes disruptions are observed that are correlated with a real-world (often political) event with no specified technical or physical cause, while other times disruptions are observed but are both uncorrelated and unattributed.

In Kazakhstan, an Internet disruption began on January 5 amid mass protests against sudden increases in energy prices. Starting around 1030 UTC, traffic from Kazakhstan dropped to near zero. The figure below shows that traffic returned to a regular diurnal pattern on January 11, but several apparent restorations of connectivity are also visible during the six-day disruption. These brief periods of connectivity appeared to align with televised speeches or announcements from the Zazakh president.

Internet disruptions overview for Q1 2022

In Burkina Faso, heavy gunfire related to an army mutiny was reported early in the morning of January 23. A significant drop in traffic from the country was observed in Cloudflare Radar starting around 0915 UTC, with Orange, FasoNet, and Telecel Faso all seeing lower traffic volumes. As the figure below shows, the disruption lasted for nearly a day and a half, recovering around 2000 UTC on January 24.

Internet disruptions overview for Q1 2022

Just after 2200 UTC on March 15, Yemen experienced a significant, albeit brief, Internet disruption, lasting just 30 minutes. As the figures below show, the disruption was primarily due to an issue at YemenNet. A published report claims that the disruption was due to a deliberate act by the Houthi coup militia.

Internet disruptions overview for Q1 2022
Internet disruptions overview for Q1 2022

Russian invasion of Ukraine

The Russian invasion of Ukraine has now been going on for over a month. In some cases, Internet connectivity has been collateral damage from the kinetic military action, while in other cases, targeted attacks on network providers and power outages have disrupted connectivity. Technicians from Ukrainian service providers have been risking their lives to keep the country online, and have been largely successful – Cloudflare Radar traffic data for Ukraine shows that as of the end of March, peak traffic levels are at 85-90% of pre-invasion peaks. An earlier blog post provides additional details about Internet traffic patterns observed in Ukraine during the first week after the conflict began.

Below we highlight just a few significant disruptions observed on major Ukrainian network providers in March.

Two brief outages were observed at Ukrtelecom during the second week of March, shown in the figure below. The first, on March 8, lasted for just over two hours, while the second one, on March 10, lasted for approximately 40 minutes. No root cause has been reported for these disruptions.

Internet disruptions overview for Q1 2022

Later in the month, on March 28, Ukrtelecom experienced a ~15 hour outage, lasting from 0800 UTC to approximately 0100 on March 29, as seen in the figure below. A Twitter thread from the State Service of Special Communications and Information Protection of Ukraine explained that the outage was caused by “a powerful cyberattack” against Ukrtelecom’s infrastructure, and that “In order to preserve its network infrastructure and to continue providing services to Ukraine’s Armed Forces and other military formations as well as to the customers, Ukrtelecom has temporarily limited providing its services to the majority of private users and business-clients.” A LinkedIn post from Ukrtelecom also highlights the non-stop work that the company has been doing to re-establish telecommunications services in impacted regions across the country.

Internet disruptions overview for Q1 2022

The figure below shows that around 2100 UTC on March 9, Ukrainian Internet service provider Triolan suffered a significant disruption, reportedly resulting from a cyber attack. Traffic began to gradually return after approximately 10 hours.

Internet disruptions overview for Q1 2022

Conclusion

Despite occasional connectivity disruptions, the Internet remains remarkably resilient. This resiliency is increasingly critical as the Internet finds its way into more and more areas of everyday life around the world. In addition to providing a suite of solutions that support that resiliency, we use the data exhaust from these solutions to monitor Internet reliability, availability, security, and performance.

Follow @CloudflareRadar on Twitter for updates on Internet disruptions as they occur, and find up-to-date information on Internet trends using Cloudflare Radar.

Exploring cross-disciplinary computing education in our new seminar series

Post Syndicated from Sue Sentance original https://www.raspberrypi.org/blog/cross-disciplinary-computing-education-research-seminars/

We are delighted to launch our next series of free online seminars, this time on the topic of cross-disciplinary computing, running monthly from May to November 2022. As always, our seminars are for all researchers, educators, and anyone else interested in research related to computing education.

An educator helps two learners set up a Raspberry Pi computer.

Crossing disciplinary boundaries

What do we mean by cross-disciplinary computing? Through this upcoming seminar series, we want to embrace the intersections and interactions of computing with all aspects of learning and life, and think about how they can help us teach young people. The researchers we’ve invited as our speakers will help us shed light on cross-disciplinary areas of computing through the breadth of their presentations.

In a computing classroom, a girl looks at a computer screen.

At the Raspberry Pi Foundation our mission is to make computing accessible to all children and young people everywhere, and because computing and technology appear in all aspects of our and young people’s lives, in this series of seminars we will consider what computing education looks like in a multiplicity of environments.

Mark Guzdial on computing in history and mathematics

We start the new series on 3 May, and are beyond delighted to be kicking off with a talk from Mark Guzdial (University of Michigan). Mark has worked in computer science education for decades and won many awards for his research, including the prestigious ACM SIGCSE Outstanding Contribution to Computing Education award in 2019. Mark has written hundreds of papers about computer science education, and he authors an extremely popular computing education research blog that keeps us all up to date with what is going on in the field.

Mark Guzdial.

Recently, he has been researching the ways in which programming education can be integrated into other subjects, so he is a perfect speaker to start us thinking about our theme of cross-disciplinary computing. His talk will focus on how we can add a teaspoon of computing to history and mathematics classes.

Pratim Sengupta on countering technocentrism

On 7 June, our speaker will be Pratim Sengupta (University of Calgary), who I feel will really challenge us to think about programming and computing education in a new way. He has conducted studies in science classrooms and non-formal learning environments which focus on providing open and engaging experiences for the public to explore code, for example through the Voice your Celebration installation. Recently, he has co-authored a book called Voicing Code in STEM: A Dialogical Imagination (MIT Press, availabe open access).

Pratim Sengupta.

In Pratim’s talk, he will share his thoughts about the ways that more of us can become involved with code through opening up its richness and depth to a wider public audience, and he will introduce us to his ideas about countering technocentrism, a key focus of his new book. I’m so looking forward to being challenged by this talk.

Yasmin Kafai on curriculum design with e-textiles

On 12 July, we will hear from Yasmin Kafai (University of Pennsylvania), who is another legend in computing education in my eyes. Yasmin started her long career in computing education with Seymour Papert, internationally known for his work on Logo and on constructionism as a theoretical lens for understanding the way we learn computing. Yasmin was part of the team that created Scratch, and for many years now has been working on projects revolving around digital making, electronic textiles, and computational participation.

Yasmin Kafai.

In Yasmin’s talk she will present, alongside a panel of teachers she’s been collaborating with, some of their work to develop a high school curriculum that uses electronic textiles to introduce students to computer science. This promises to be a really engaging and interactive seminar.

Genevieve Smith-Nunes on exploring data ethics

In August we will take a holiday, to return on 6 September to hear from the inspirational Genevieve Smith-Nunes (University of Cambridge), whose research is focused on dance and computing, in particular data-driven dance. Her work helps us to focus on the possibilities of creative computing, but also to think about the ethics of applications that involve vast amounts of data.

Genevieve Smith-Nunes.

Genevieve’s talk will prompt us to think about some really important questions: Is there a difference in sense of self (identity) between the human and the virtual? How does sharing your personal biometric data make you feel? How can biometric and immersive development tools be used in the computing classroom to raise awareness of data ethics? Impossible to miss!

Sign up now to attend the seminars

Do enter all these dates in your diary so you don’t miss out on participating — we are very excited about this series. Sign up below, and ahead of every seminar, we will send you the information for joining.

As usual, the seminars will take place online on a Tuesday at 17:00 to 18:30 local UK time. Later on in the series, we will also host a talk by our own researchers and developers at the Raspberry Pi Foundation about our non-formal learning research. Watch this space for details about the October and November seminars, which we are still finalising.

The post Exploring cross-disciplinary computing education in our new seminar series appeared first on Raspberry Pi.

[$] 5.18 Merge window, part 2

Post Syndicated from original https://lwn.net/Articles/889266/

Linus Torvalds released the 5.18-rc1 kernel prepatch on
April 3, after having pulled 13,207 non-merge changesets into the
mainline repository. This merge window has thus not only been
turbulent, with a significant number of regressions and refused pull
requests, it has also been relatively busy. Just over 9,000 of those
changesets were pulled after the first 5.18
merge window summary
was written; the time has come to catch up with
the remainder of changes merged for this development cycle.

Security updates for Monday

Post Syndicated from original https://lwn.net/Articles/890187/

Security updates have been issued by Debian (asterisk, qemu, and zlib), Fedora (389-ds-base, ghc-cmark-gfm, ghc-hakyll, gitit, libkiwix, openssl, pandoc, pandoc-citeproc, patat, phoronix-test-suite, seamonkey, and skopeo), Mageia (libtiff, openjpeg2, and php-smarty), openSUSE (python), Oracle (httpd), Red Hat (httpd), and SUSE (libreoffice, python, and python36).

Sharpen Your IR Capabilities With Rapid7’s Detection and Response Workshop

Post Syndicated from Mikayla Wyman original https://blog.rapid7.com/2022/04/04/sharpen-your-ir-capabilities-with-rapid7s-detection-and-response-workshop/

Sharpen Your IR Capabilities With Rapid7’s Detection and Response Workshop

You’re tasked with protecting your environment, and you’ve invested significant time and resources into deploying and configuring your tools — but how do you know if the security controls you’ve put into place are effective? The challenge continues to grow as attacker tactics, techniques, and procedures (TTPs) constantly evolve. In today’s landscape, a security breach is nearly inevitable.

Amid an ever-changing threat landscape, do you have confidence your tools are able to immediately detect threats when they occur? And more importantly, does your team know how to effectively respond to stop the attack, and do it fast?

While we don’t have a crystal ball to offer, we can help make sure your detection and response plan holds up against a breach.

Say hello to Rapid7’s newest incident response service: the Detection and Response Workshop.

Put your safeguards to the test with a guided attack simulation

The Detection and Response Workshop is a guided exercise led by Rapid7’s digital forensics and incident response (DFIR) experts to confirm that your team can quickly detect threats and evaluate your response procedures against a simulated attack within your environment.

This workshop isn’t a Tabletop Exercise (TTX), an IR Planning engagement, or a Purple Team exercise. We’ll pit your organization’s defenders against the latest attack campaigns, within the tools they use on a daily basis, to test your ability to respond when an incident happens under live conditions, without your company’s reputation at stake.

Each Workshop simulation is tailored to your specific needs and mapped to the MITRE ATT&CK Framework. Throughout the Workshop, our experts make recommendations to help strengthen your program – from existing configurations of tools, products, and devices to analysis processes and documentation.

The workshop itself is hands-on and doesn’t require current use of a Rapid7 product. Any security team can utilize this new service to understand what TTPs an adversary may use against them and make sure their program detects and responds accordingly.

Your team will leave the multi-day workshop feeling confident that you have an understanding of where and how to strengthen your existing IR process and detection and response program. You’ll receive a detailed report of the workshop, including our written assessment and recommendations to build resilience into your response program.

Rapid7 Incident Response consulting services

Security is the core of our business, and IR plays a huge role in the security landscape. Our team of DFIR experts — the same experts that respond to incidents for all 1,200+ of our MDR customers — have decades of experience under their belt that they utilize to analyze your security fit-up from all angles. Our team is complete with experts in threat analysis, forensics, and malware analysis, as well as a deep understanding of industry-leading technologies.

Knowing where your program stands is a crucial part of enhancing it, and our IR team has built specialized services to help your team build resiliency at each stage in the process. We now offer a full Incident Response Service Curriculum, allowing teams to engage in a single course for their IR goals or register for the entire curriculum.

From planning to full attack simulations, your team can level up its skills with tailored guidance and coaching through each course:

  • Course 101: Incident Response Program Development
  • Course 201: Tabletop Exercise (TTX)
  • Course 301: Detection & Response Workshop
  • Course 401: Purple Team Exercise

No matter what stage your team is in building your incident response program, our experts are able to help analyze and provide recommendations for improvement.

The Detection & Response Workshop is available now for all security teams. To learn more, talk to a Rapid7 sales representative by filling out this form today.

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Wyze Camera Vulnerability

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2022/04/wyze-camera-vulnerability.html

Wyze ignored a vulnerability in its home security cameras for three years. Bitdefender, who discovered the vulnerability, let the company get away with it.

In case you’re wondering, no, that is not normal in the security community. While experts tell me that the concept of a “responsible disclosure timeline” is a little outdated and heavily depends on the situation, we’re generally measuring in days, not years. “The majority of researchers have policies where if they make a good faith effort to reach a vendor and don’t get a response, that they publicly disclose in 30 days,” Alex Stamos, director of the Stanford Internet Observatory and former chief security officer at Facebook, tells me.

Selecting the appropriate discovery tool for your cloud migration

Post Syndicated from David Ninnis original https://aws.amazon.com/blogs/architecture/selecting-the-appropriate-discovery-tool-for-your-cloud-migration/

Cloud migrations invariably require the coordination of multiple stakeholders, such as business and technical teams, partners, and third-party providers. As a stakeholder, understanding your portfolio is crucial to determine which workloads to migrate, and their requirements and interdependencies. But manually gathering these insights can be a daunting task. You can inform your decision by provisioning a discovery tool.

Given the variety of choices available, choosing the appropriate discovery tool for your use case can also be challenging. In this blog post, we explain a proven three-step technique to successfully filter and prioritize a list of discovery tools based on the essential features needed for your business.

Diagram of 3 steps to determine your migration discovery tool

Figure 1. Steps to determine your migration discovery tool

Step 1: Review

Review the outcomes that your migration journey should deliver. These will drive your discovery requirements and baseline the features needed. Compare the baseline features with existing tools within your organization such as Configuration Management Databases (CMDBs) or Application Performance Management (APM) tooling. By the end of this Review step, you should establish if your in-house tools are sufficient for your objectives. Here is a list of questions to support your migration analysis.

You may need to collect high-level data or complete datasets depending on your stage in the migration process. You may be exploring migration costs to assess the lift-and-shift migration threshold of a benefit program such as AWS Migration Acceleration Program (MAP). In this case, you probably only need a snapshot of your on-premises environment with a list of servers, their configurations, and attached licenses. You may be evaluating the Total Cost of Ownership (TCO) between your on-premises infrastructure and an elastic deployment model on the cloud. In this case, you’ll want to be able to estimate the cost of a right-sized cloud infrastructure. For that, you will want to run a discovery tool for the duration of a business cycle.

Finally, to decide how and when applications are going to migrate, you will need a complete and accurate dataset with the application and database features to be migrated. This must include network dependencies, non-functional requirements (NFRs), disaster recovery (DR) plans, and third-party licensing terms and conditions (T&C).

Conclude this step by baselining the features that you require in the discovery tool.

Step 2: Refine

This step is an elimination process. One of the resources you can use to compile a list of candidate discovery tools is the Discovery migration tool comparison page. Filter and sort the list using the following criteria categories:

  1. Core features
  2. Common features
  3. Special features
  4. Tool provisioning
  5. Operation

By the end of this step, you should have a prioritized list of the discovery tools that optimally match your requirements.

Core features

Following are the basic set of features that you should expect from any discovery tool. Analysis of the data captured by these features will support your high-level business case.

  • Automatic inventory collection. Reports on the infrastructure profile, such as CPU family, CPU cores, memory size, disk size and speed, and operating system.
  • Utilization. Shows peak and average utilization of CPU, memory, and disk.
  • Network storage discovery. Detects and profiles network shares from network-attached storage (NAS).
  • Software. Identifies running processes and installed software, pinpointing database engines and their versions.
  • Network scanning. Scans network subnets to discover unknown infrastructure assets.

Common features

Here are some common features of discovery tools. With this data, you will be able to create a more detailed TCO analysis and migration plan.

  • Lift-and-shift cost estimation. Maps a recommended target AWS infrastructure for the rehost of the source infrastructure, and calculates the AWS cost.
  • Target sizing recommendation. Maps and calculates the cost for alternative target AWS infrastructures based on the peak and average utilization.
  • TCO analysis. Provides a cost comparison between current on-premises cost and projected AWS cost.
  • Dependency mapping. Collects network connection information and builds inbound and outbound dependency maps of the servers and running applications. Infers applications from groups of infrastructure resources based on communication patterns.
  • Application prioritization. Assigns weight or relevance to application and infrastructure attributes to create prioritization criteria for migration.
  • Wave planning. Recommends groups of applications and the ability to create migration wave plans.

Special features

Special features map to less common requirements, or to a specific set of the workloads you want to migrate. For example, you may require your tools to collect database dependency information if databases form a significant part of your workloads. If you have strict regulatory compliance to follow (HIPAA, GDPR), you’ll need tools that comply with these regulations. Other examples are:

  • Licensing analysis. Provides optimization recommendations for Microsoft SQL Server and Oracle systems in rehosting and replatforming scenarios.
  • Enterprise platforms. Includes the ability to collect details from proprietary operating systems like AIX and Solaris, or infrastructure such as AS/400 and mainframe.

When evaluating each feature, consider how much of your environment it applies to, and how important it is for the overall objective. It’s a good practice to deprioritize rather than completely eliminating tools that don’t provide a specific feature.

Provisioning

Once you run through the minimum, common, and special feature requirements, further refine the tool list by evaluating the challenges associated with the provisioning process of each tool. For example, consider aspects like data residency and the cost model. Read Evaluating the need for discovery tooling for a detailed list of provisioning criteria.

Operations

Finally, refine your tool list further by evaluating the requirements to operate the tool. This includes considerations like the running cost and the support model.

Step 3: Select

At this stage, you should have a shortlist of preferred discovery tools, with only one or two tools remaining for final evaluation.

All of these shortlisted tools should fulfill your requirements. You can further refine your selection by choosing the tool that best fits your priorities. For example, if only two tools remain in your shortlist and ease of installation and operation are paramount, then select the tool with the highest levels of deployment automation. If cost is your main constraint, then select the least expensive tool to acquire and operate.

Conclusion

Tools from AWS and AWS Partners can help accelerate your migration to the AWS Cloud. To select the relevant discovery tool for your specific use case, we recommend the following proven three-step approach:

  1. Review – Start by reviewing existing in-house capabilities, tools, and data sources. By the end of this step, you should establish if your in-house tools are sufficient for your cloud migration objectives.
  2. Refine – Narrow down a list of candidate discovery tools by filtering and prioritizing them based on the requirements from the previous step.
  3. Select – Filter the final list of suitable discovery tools by selecting the tool that best addresses your priorities.

Kernel prepatch 5.18-rc1

Post Syndicated from original https://lwn.net/Articles/890119/

Linus has released 5.18-rc1 and closed the
merge window for the 5.18 release. “In fact, at least in pure
commits, this has been a bigger merge window than we’ve had in some
time. But let’s hope it’s all smooth sailing this release.
” In the
end, 13,207 non-merge changesets were merged during this merge window.

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/what-cloudflare-is-doing-to-keep-the-open-internet-flowing-into-russia-and-keep-attacks-from-getting-out/

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

Following Russia’s unjustified and tragic invasion of Ukraine in late February, the world has watched closely as Russian troops attempted to advance across Ukraine, only to be resisted and repelled by the Ukrainian people. Similarly, we’ve seen a significant amount of cyber attack activity in the region. We continue to work to protect an increasing number of Ukrainian government, media, financial, and nonprofit websites, and we protected the Ukrainian top level domain (.ua) to help keep Ukraine’s presence on the Internet operational.

At the same time, we’ve closely watched significant and unprecedented activity on the Internet in Russia. The Russian government has taken steps to tighten its control over both the technical components and the content of the Russian Internet. For their part, the people in Russia are doing something very different. They have been adopting tools to maintain access to the global Internet, and they have been seeking out non-Russian media sources. This blog post outlines what we’ve observed.

The Russian Government asserts control over the Internet

Over the last five years, the Russian government has taken steps to tighten its control of a sovereign Internet within Russia’s borders, including laws requiring Russian ISPs to install equipment allowing the government to monitor and block Internet activity, and requiring the establishment of an exclusively Russian DNS (outside ICANN).  And it created mechanisms for the Russian government to control how Russia was connected to the global Internet, so they could pull the plug if they wanted.

Since the Russian invasion of Ukraine, the Russian government has made a series of announcements related to implementation of its sovereign Internet laws. Russian government agencies were instructed to switch to Russian DNS servers, move public resources to Russian hosting services, and take a number of other steps designed to reduce reliance on non-Russian providers. Although some took these initiatives as an announcement that Russia intended to disconnect from the global Internet, so far Russia does not appear to have leveraged the tools it has to disconnect itself entirely from the global Internet.  We continue to see connections processing successfully in Russia through non-Russia infrastructure.

In the meantime, authorities in Russia have implemented a series of targeted blocking actions against websites and operators that they find objectionable. Initially, officials targeted popular social media sites like Facebook, Instagram, Twitter, and YouTube, as well as Russian language outlets based outside of the country.

We can see the effect of some of those blocks on traffic from Russian users to different news websites in Russia and Ukraine before and after blocks were implemented.  

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out
What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out
What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

In each case, these news sites saw exponential growth in their traffic in the days around the February 24th invasion of Ukraine.  But that increase was met within a matter of days by actions to block traffic to those sites. The blocks had varying degrees of success over the first few weeks, though each of them seem to have been eventually successful in denying access to those sources of news through traditional Internet channels.  

But that is only half the story.  As the Russian government took steps to control traditional channels for Internet access, there were shifts in the ways many Russians used the Internet.

Russian citizens turning to tools to gain access to the open Internet

Russians have been adopting applications and tools that allow them to engage with the Internet privately and avoid some of the mechanisms that the Russian government is using to control and monitor access to the Internet. Whereas the most popular applications in the Apple App Store in most of the world in March continue to relate to social media and games, the leaderboard in Russia looked very different:

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

All of the top apps in Russia in March were for private and secure Internet access or encrypted messaging apps, including the most downloaded app – Cloudflare’s own WARP / 1.1.1.1 (a privacy-based recursive DNS resolver). This list of popular apps is a stunning contrast with every other country in the world.

Because of the significant and important popularity of WARP (1.1.1.1), we’ve had some detailed insight into exactly how this has played out. If we look back to the beginning of February we see that Cloudflare’s WARP tool was little used in Russia. Its use took off from the first weekend of the war, and peaked two weeks ago. Later, after this virtual migration to such secure tools became apparent, we saw attempts to block access to the tools used to access the Internet securely.

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

While levels have receded from their peak, a large number of Russians continue to use Cloudflare WARP in Russia at massively higher levels than pre-war.

In addition to the ways Russians are using the Internet increasingly relying on private and encrypted communications, we’ve also seen a shift in what they are trying to access. Here’s a chart of DNS requests from Russian users for a well known US newspaper. Recent DNS traffic for the site has quintupled compared to pre-war levels, indicating Russians are trying to access that news source.

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

And here’s DNS traffic for a large French news source. Again, DNS lookups have grown enormously as Russians try to access it.

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

And here’s a British newspaper.

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

The picture is clear from these three charts. Russians want access to non-Russian news sources and based on the popularity of private Internet access tools and VPNs, they are willing to work to get it.

A front line against cyberattack

In addition to the services we’ve been able to provide average citizens in Russia, our servers at the edge of the Internet in-country have also permitted us to detect and block attacks originating there. When attacks are mitigated inside Russia, they never travel outside Russian borders. That’s always been part of the proposition of Cloudflare’s distributed network – to identify and block cyber attacks (especially DDoS attacks) locally and before they can ever get off the ground.

Here’s what DDoS activity originating inside Russia and blocked there by Cloudflare has looked like since the beginning of February. Normal DDoS activity originating from Russian networks and blocked by Cloudflare’s servers there is relatively low throughout February but then grows massively in the middle of March.

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

To be clear, being able to identify where cyber attack traffic originates is not the same as being able to attribute where the attacker is located. Attributing cyber attacks is difficult, and now is a time to be particularly careful with attribution. It is relatively common for cyber attackers to launch attacks from remote locations around the world. This often happens when they are able to hijack devices in other countries through things like IoT (Internet of Things) corruptions.

But even with such subterfuge, we’ve still seen a significant increase in the number of blocked attacks that are hitting our servers inside Russia.

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

A few weeks ago, as the invasion of Ukraine was in its early stages, I noted that “Russia needs more Internet, not less.” At a time of unprecedented economic sanctions by the United States and Europe, there have been calls for all foreign companies to go further and exit Russia completely, including calls for Internet providers to disconnect Russia. To be clear, Cloudflare has minimal sales and commercial activity in Russia – we’ve never had a corporate entity, an office, or employees there – and we’ve taken steps to ensure that we’re not paying taxes or fees to the Russian government. But given the significant impact of our services on the availability and security of the Internet, we believe removing our services from Russia altogether would do more harm than good.

While we deeply appreciate the motivation of the calls for companies to exit Russia, this withdrawal by Internet companies can have the unintended effect of advancing and entrenching the interests of the Russian government to control the Internet in Russia. Efforts to have Russia cut off from the global Internet through ICANN and RIPE will only cut off the Russian people from information about the war in Ukraine that the Russian government doesn’t want them to access.  After a number of U.S.-based certificate authorities stopped issuing SSL certificates for Russian websites, Russia responded in early March by encouraging Russian citizens to download a Russian Root Certificate Authority instead. As observed by EFF, “the Russian state’s stopgap measure to keep its services running also enables spying on Russians, now and in the future.”

This is why there has been near universal agreement by experts that it is imperative the Russian Internet stay as open as possible for the Russian people. Dozens of civil society groups have urged governments to work to counteract authoritarian actions “and ensure that sanctions and other steps meant to repudiate the Russian government’s illegal actions do not backfire, by reinforcing Putin’s efforts to assert information control.” Russian digital rights activists have pleaded with service providers to offer Russians free VPN access so they are not left isolated from global news sources.  Even the U.S. State Department has made clear, “It is critical to maintain the flow of information to the people of Russia to the fullest extent possible.”

Supporting our mission to help build a better Internet, it’s been a busy six weeks for our team monitoring these developments and working around the clock to make sure Ukrainian web properties are defended and that ordinary Russians can access the global Internet. We remain in awe of the brave Ukrainians standing up in defense of their homeland, and continue to hope that peace will prevail.

The collective thoughts of the interwebz