Tag Archives: Uncategorized

За украинските бежанци… и за нас

Post Syndicated from original http://www.gatchev.info/blog/?p=2457

Напоследък чух тонове плювни срещу украинските бежанци:

– че са гадове, понеже имат хубави коли и домове
– че искат да наливат бензин и да ядат в ресторанти, без да плащат
– че ние им даваме по 40 лева на ден от джоба си, а те искат повече
– (въпреки че имат цели куфари с пачки долари и евро, и мезонети по Черноморието)
– че им плащаме от джоба си да живеят в петзвездни хотели, докато българските пенсионери мрат от глад
– че са неблагодарници, понеже не им харесва да ги тъпчем по 6 души в стари ЖП контейнери
– че са неблагодарници, понеже се възмущават, че някой тук им обстрелвал децата с въздушна пушка
– че са неблагодарници, понеже не им харесва български патриоти да ги пребиват на улицата
– че са претенциозни, понеже някои искат да имат достъп до аптека, а някои – даже до лекар
– че са нагли, понеже се учудват, ако към храната няма прибори
– че нямат място тук, след като за по цяла седмица все още не са научили български добре
– че ако ги подслоняваме, Русия ще ни атакува (заслужено – украинците са нацисти!)
– че а пък в Германия умните германци не им дават никакви помощи
– че а пък в Германия тъпите германци им дават по 200 евро помощ на ден, и проклетите мръсници си живеят безгрижно
– накрая и че хич не са бежанци, след като след известен престой тук започват да бягат от България, обратно в Украйна, при войната…

(Съкратил съм списъка няколко пъти, читателю – нищо лошо не си ми направил…)

Срещу тези приказки стои само една, простичка и обикновена – че украинските бежанци бягат от война и имат нужда от помощ. Не са и нужни повече – истината по всеки въпрос е една, безкрайно много и различни могат да са лъжите.

Но има нещо, още по-важно от това.

На какви струни в човешката душа се опитват да свирят тези твърдения?
Какви качества и черти са нужни, за да им вярва човек?
И какви качества и черти са нужни, за да ги разпространява?
Що за човек трябва да е – отвътре, под маската, която носи?

И какви струни в душата докосва другото – че бежанците бягат от зло и имат нужда от помощ?
Какви качества трябва да има човек, за да мисли първо за това, а после дали имат пари?
Какви качества са нужни, за да им помага с каквото може – подслон, дарения, добра дума в Интернет?…
Какъв трябва да е такъв човек отвътре, под маската на ежедневието?

С кой от тези два типа хора искате да сте близки, приятели… свои?
А от кой е добре да се пазите и да стоите по-далече?
На кой от тези два типа хора бихте вярвали, а на кой – не?
Кой от тях ще ви се отплати дори за доброто със зло, а кой – дори за прегрешенията с добро?

Сред кой от тези типове хора искате да живеете и да бъдете?

В момента правите именно този избор.

Нямам какво да добавя.

Me on Public-Interest Tech

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2022/06/me-on-public-interest-tech.html

Back in November 2020, in the middle of the COVID-19 pandemic, I gave a virtual talk at the International Symposium on Technology and Society: “The Story of the Internet and How it Broke Bad: A Call for Public-Interest Technologists.” It was something I was really proud of, and it’s finally up on the net.

Running AWS Lambda functions on AWS Outposts using AWS IoT Greengrass

Post Syndicated from Sheila Busser original https://aws.amazon.com/blogs/compute/running-aws-lambda-functions-on-aws-outposts-using-aws-iot-greengrass/

This blog post is written by Adam Imeson, Sr. Hybrid Edge Specialist Solution Architect.

Today, AWS customers can deploy serverless applications in AWS Regions using a variety of AWS services. Customers can also use AWS Outposts to deploy fully managed AWS infrastructure at virtually any datacenter, colocation space, or on-premises facility.

AWS Outposts extends the cloud by bringing AWS services to customers’ premises to support their hybrid and edge workloads. This post will describe how to deploy Lambda functions on an Outpost using AWS IoT Greengrass.

Consider a customer who has built an application that runs in an AWS Region and depends on AWS Lambda. This customer has a business need to enter a new geographic market, but the nearest AWS Region is not close enough to meet application latency or data residency requirements. AWS Outposts can help this customer extend AWS infrastructure and services to their desired geographic region. This blog post will explain how a customer can move their Lambda-dependent application to an Outpost.

Overview

In this walkthrough you will create a Lambda function that can run on AWS IoT Greengrass and deploy it on an Outpost. This architecture results in an AWS-native Lambda function running on the Outpost.

Architecture overview - Lambda functions on AWS Outposts

Deploying Lambda functions on Outposts rack

Prerequisites: Building a VPC

To get started, build a VPC in the same Region as your Outpost. You can do this with the create VPC option in the AWS console. The workflow allows you to set up a VPC with public and private subnets, an internet gateway, and NAT gateways as necessary. Do not consume all of the available IP space in the VPC with your subnets in this step, because you will still need to create Outposts subnets after this.

Now, build a subnet on your Outpost. You can do this by selecting your Outpost in the Outposts console and choosing Create Subnet in the drop-down Actions menu in the top right.

Confirm subnet details

Choose the VPC you just created and select a CIDR range for your new subnet that doesn’t overlap with the other subnets that are already in the VPC. Once you’ve created the subnet, you need to create a new subnet route table and associate it with your new subnet. Go into the subnet route tables section of the VPC console and create a new route table. Associate the route table with your new subnet. Add a 0.0.0.0/0 route pointing at your VPC’s internet gateway. This sets the subnet up as a public subnet, which for the purposes of this post will make it easier to access the instance you are about to build for Greengrass Core. Depending on your requirements, it may make more sense to set up a private subnet on your Outpost instead. You can also add a route pointing at your Outpost’s local gateway here. Although you won’t be using the local gateway during this walkthrough, adding a route to the local gateway makes it possible to trigger your Outpost-hosted Lambda function with on-premises traffic.

Create a new route table

Associate the route table with the new subnet

Add a 0.0.0.0/0 route pointing at your VPC’s internet gateway

Setup: Launching an instance to run Greengrass Core

Create a new EC2 instance in your Outpost subnet. As long as your Outpost has capacity for your desired instance type, this operation will proceed the same way as any other EC2 instance launch. You can check your Outpost’s capacity in the Outposts console or in Amazon CloudWatch:

I used a c5.large instance running Amazon Linux 2 with 20 GiB of Amazon EBS storage for this walkthough. You can pick a different instance size or a different operating system in accordance with your application’s needs and the AWS IoT Greengrass documentation. For the purposes of this tutorial, we assign a public IP address to the EC2 instance on creation.

Step 1: Installing the AWS IoT Greengrass Core software

Once your EC2 instance is up and running, you will need to install the AWS IoT Greengrass Core software on the instance. Follow the AWS IoT Greengrass documentation to do this. You will need to do the following:

  1. Ensure that your EC2 instance has appropriate AWS permissions to make AWS API calls. You can do this by attaching an instance profile to the instance, or by providing AWS credentials directly to the instance as environment variables, as in the Greengrass documentation.
  2. Log in to your instance.
  3. Install OpenJDK 11. For Amazon Linux 2, you can use sudo amazon-linux-extras install java-openjdk11 to do this.
  4. Create the default system user and group that runs components on the device, with
    sudo useradd —system —create-home ggc_user
    sudo groupadd —system ggc_group
  5. Edit the /etc/sudoers file with sudo visudosuch that the entry for the root user looks like root ALL=(ALL:ALL) ALL
  6. Enable cgroups and enable and mount the memory and devices cgroups. In Amazon Linux 2, you can do this with the grubby utility as follows:
    sudo grubby --args="cgroup_enable=memory cgroup_memory=1 systemd.unified_cgroup_hierarchy=0" --update-kernel /boot/vmlinuz-$(uname -r)
  7. Type sudo reboot to reboot your instance with the cgroup boot parameters enabled.
  8. Log back in to your instance once it has rebooted.
  9. Use this command to download the AWS IoT Greengrass Core software to the instance:
    curl -s https://d2s8p88vqu9w66.cloudfront.net/releases/greengrass-nucleus-latest.zip > greengrass-nucleus-latest.zip
  10. Unzip the AWS IoT Greengrass Core software:
    unzip greengrass-nucleus-latest.zip -d GreengrassInstaller && rm greengrass-nucleus-latest.zip
  11. Run the following command to launch the installer. Replace each argument with appropriate values for your particular deployment, particularly the aws-region and thing-name arguments.
    sudo -E java -Droot="/greengrass/v2" -Dlog.store=FILE \
    -jar ./GreengrassInstaller/lib/Greengrass.jar \
    --aws-region region \
    --thing-name MyGreengrassCore \
    --thing-group-name MyGreengrassCoreGroup \
    --thing-policy-name GreengrassV2IoTThingPolicy \
    --tes-role-name GreengrassV2TokenExchangeRole \
    --tes-role-alias-name GreengrassCoreTokenExchangeRoleAlias \
    --component-default-user ggc_user:ggc_group \
    --provision true \
    --setup-system-service true \
    --deploy-dev-tools true
  12. You have now installed the AWS IoT Greengrass Core software on your EC2 instance. If you type sudo systemctl status greengrass.service then you should see output similar to this:

Step 2: Building and deploying a Lambda function

Now build a Lambda function and deploy it to the new Greengrass Core instance. You can find example local Lambda functions in the aws-greengrass-lambda-functions GitHub repository. This example will use the Hello World Python 3 function from that repo.

  1. Create the Lambda function. Go to the Lambda console, choose Create function, and select the Python 3.8 runtime:

  1. Choose Create function at the bottom of the page. Once your new function has been created, copy the code from the Hello World Python 3 example into your function:

  1. Choose Deploy to deploy your new function’s code.
  2. In the top right, choose Actions and select Publish new version. For this particular function, you would need to create a deployment package with the AWS IoT Greengrass SDK for the function to work on the device. I’ve omitted this step for brevity as it is not a main focus of this post. Please reference the Lambda documentation on deployment packages and the Python-specific deployment package docs if you want to pursue this option.

  1. Go to the AWS IoT Greengrass console and choose Components in the left-side pop-in menu.
  2. On the Components page, choose Create component, and then Import Lambda function. If you prefer to do this programmatically, see the relevant AWS IoT Greengrass documentation or AWS CloudFormation documentation.
  3. Choose your new Lambda function from the drop-down.

Create component

  1. Scroll to the bottom and choose Create component.
  2. Go to the Core devices menu in the left-side nav bar and select your Greengrass Core device. This is the Greengrass Core EC2 instance you set up earlier. Make a note of the core device’s name.

  1. Use the left-side nav bar to go to the Deployments menu. Choose Create to create a new deployment, which will place your Lambda function on your Outpost-hosted core device.
  2. Give the deployment a name and select Core device, providing the name of your core device. Choose Next.

  1. Select your Lambda function and choose Next.

  1. Choose Next again, on both the Configure components and Configure advanced settings On the last page, choose Deploy.

You should see a green message at the top of the screen indicating that your configuration is now being deployed.

Clean up

  1. Delete the Lambda function you created.
  2. Terminate the Greengrass Core EC2 instance.
  3. Delete the VPC.

Conclusion

Many customers use AWS Outposts to expand applications into new geographies. Some customers want to run Lambda-based applications on Outposts. This blog post shows how to use AWS IoT Greengrass to build Lambda functions which run locally on Outposts.

To learn more about Outposts, please contact your AWS representative and visit the Outposts homepage and documentation.

Remotely Controlling Touchscreens

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2022/06/remotely-controlling-touchscreens.html

Researchers have demonstrated controlling touchscreens at a distance, at least in a laboratory setting:

The core idea is to take advantage of the electromagnetic signals to execute basic touch events such as taps and swipes into targeted locations of the touchscreen with the goal of taking over remote control and manipulating the underlying device.

The attack, which works from a distance of up to 40mm, hinges on the fact that capacitive touchscreens are sensitive to EMI, leveraging it to inject electromagnetic signals into transparent electrodes that are built into the touchscreen so as to register them as touch events.

The experimental setup involves an electrostatic gun to generate a strong pulse signal that’s then sent to an antenna to transmit an electromagnetic field to the phone’s touchscreen, thereby causing the electrodes ­ which act as antennas themselves ­ to pick up the EMI.

Paper: “GhostTouch: Targeted Attacks on Touchscreens without Physical Touch“:

Abstract: Capacitive touchscreens have become the primary human-machine interface for personal devices such as smartphones and tablets. In this paper, we present GhostTouch, the first active contactless attack against capacitive touchscreens. GhostTouch uses electromagnetic interference (EMI) to inject fake touch points into a touchscreen without the need to physically touch it. By tuning the parameters of the electromagnetic signal and adjusting the antenna, we can inject two types of basic touch events, taps and swipes, into targeted locations of the touchscreen and control them to manipulate the underlying device. We successfully launch the GhostTouch attacks on nine smartphone models. We can inject targeted taps continuously with a standard deviation of as low as 14.6 x 19.2 pixels from the target area, a delay of less than 0.5s and a distance of up to 40mm. We show the real-world impact of the GhostTouch attacks in a few proof-of-concept scenarios, including answering an eavesdropping phone call, pressing the button, swiping up to unlock, and entering a password. Finally, we discuss potential hardware and software countermeasures to mitigate the attack.

Making your Go workloads up to 20% faster with Go 1.18 and AWS Graviton

Post Syndicated from Sheila Busser original https://aws.amazon.com/blogs/compute/making-your-go-workloads-up-to-20-faster-with-go-1-18-and-aws-graviton/

This blog post was written by Syl Taylor, Professional Services Consultant.

In March 2022, the highly anticipated Go 1.18 was released. Go 1.18 brings to the language some long-awaited features and additions, such as generics. It also brings significant performance improvements for Arm’s 64-bit architecture used in AWS Graviton server processors. In this post, we show how migrating Go workloads from Go 1.17.8 to Go 1.18 can help you run your applications up to 20% faster and more cost-effectively. To achieve this goal, we selected a series of realistic and relatable workloads to showcase how they perform when compiled with Go 1.18.

Overview

Go is an open-source programming language which can be used to create a wide range of applications. It’s developer-friendly and suitable for designing production-grade workloads in areas such as web development, distributed systems, and cloud-native software.

AWS Graviton2 processors are custom-built by AWS using 64-bit Arm Neoverse cores to deliver the best price-performance for your cloud workloads running in Amazon Elastic Compute Cloud (Amazon EC2). They provide up to 40% better price/performance over comparable x86-based instances for a wide variety of workloads and they can run numerous applications, including those written in Go.

Web service throughput

For web applications, the number of HTTP requests that a server can process in a window of time is an important measurement to determine scalability needs and reduce costs.

To demonstrate the performance improvements for a Go-based web service, we selected the popular Caddy web server. To perform the load testing, we selected the hey application, which was also written in Go. We deployed these packages in a client/server scenario on m6g Graviton instances.

Relative performance comparison for requesting a static webpage

The Caddy web server compiled with Go 1.18 brings a 7-8% throughput improvement as compared with the variant compiled with Go 1.17.8.

We conducted a second test where the client downloads a dynamic page on which the request handler performs some additional processing to write the HTTP response content. The performance gains were also noticeable at 10-11%.

Relative performance comparison for requesting a dynamic webpage

Regular expression searches

Searching through large amounts of text is where regular expression patterns excel. They can be used for many use cases, such as:

  • Checking if a string has a valid format (e.g., email address, domain name, IP address),
  • Finding all of the occurrences of a string (e.g., date) in a text document,
  • Identifying a string and replacing it with another.

However, despite their efficiency in search engines, text editors, or log parsers, regular expression evaluation is an expensive operation to run. We recommend identifying optimizations to reduce search time and compute costs.

The following example uses the Go regexp package to compile a pattern and search for the presence of a standard date format in a large generated string. We observed a 13.5% increase in completed executions with a 12% reduction in execution time.

Relative performance comparison for using regular expressions to check that a pattern exists

In a second example, we used the Go regexp package to find all of the occurrences of a pattern for character sequences in a string, and then replace them with a single character. We observed a 12% increase in evaluation rate with an 11% reduction in execution time.

Relative performance comparison for using regular expressions to find and replace all of the occurrences of a pattern

As with most workloads, the improvements will vary depending on the input data, the hardware selected, and the software stack installed. Furthermore, with this use case, the regular expression usage will have an impact on the overall performance. Given the importance of regex patterns in modern applications, as well as the scale at which they’re used, we recommend upgrading to Go 1.18 for any software that relies heavily on regular expression operations.

Database storage engines

Many database storage engines use a key-value store design to benefit from simplicity of use, faster speed, and improved horizontal scalability. Two implementations commonly used are B-trees and LSM (log-structured merge) trees. In the age of cloud technology, building distributed applications that leverage a suitable database service is important to make sure that you maximize your business outcomes.

B-trees are seen in many database management systems (DBMS), and they’re used to efficiently perform queries using indexes. When we tested a sample program for inserting and deleting in a large B-tree structure, we observed a 10.5% throughput increase with a 10% reduction in execution time.

Relative performance comparison for inserting and deleting in a B-Tree structure

On the other hand, LSM trees can achieve high rates of write throughput, thus making them useful for big data or time series events, such as metrics and real-time analytics. They’re used in modern applications due to their ability to handle large write workloads in a time of rapid data growth. The following are examples of databases that use LSM trees:

  • InfluxDB is a powerful database used for high-speed read and writes on time series data. It’s written in Go and its storage engine uses a variation of LSM called the Time-Structured Merge Tree (TSM).
  • CockroachDB is a popular distributed SQL database written in Go with its own LSM tree implementation.
  • Badger is written in Go and is the engine behind Dgraph, a graph database. Its design leverages LSM trees.

When we tested an LSM tree sample program, we observed a 13.5% throughput increase with a 9.5% reduction in execution time.

We also tested InfluxDB using comparison benchmarks to analyze writes and reads to the database server. On the load stress test, we saw a 10% increase of insertion throughput and a 14.5% faster rate when querying at a large scale.

Relative performance comparison for inserting to and querying from an InfluxDB database

In summary, for databases with an engine written in Go, you’ll likely observe better performance when upgrading to a version that has been compiled with Go 1.18.

Machine learning training

A popular unsupervised machine learning (ML) algorithm is K-Means clustering. It aims to group similar data points into k clusters. We used a dataset of 2D coordinates to train K-Means and obtain the cluster distribution in a deterministic manner. The example program uses an OOP design. We noticed an 18% improvement in execution throughput and a 15% reduction in execution time.

Relative performance comparison for training a K-means model

A widely-used and supervised ML algorithm for both classification and regression is Random Forest. It’s composed of numerous individual decision trees, and it uses a voting mechanism to determine which prediction to use. It’s a powerful method for optimizing ML models.

We ran a deterministic example to train a dense Random Forest. The program uses an OOP design and we noted a 20% improvement in execution throughput and a 15% reduction in execution time.

Relative performance comparison for training a Random Forest model

Recursion

An efficient, general-purpose method for sorting data is the merge sort algorithm. It works by repeatedly breaking down the data into parts until it can compare single units to each other. Then, it decides their order in the intermediary steps that will merge repeatedly until the final sorted result. To implement this divide-and-conquer approach, merge sort must use recursion. We ran the program using a large dataset of numbers and observed a 7% improvement in execution throughput and a 4.5% reduction in execution time.

Relative performance comparison for running a merge sort algorithm

Depth-first search (DFS) is a fundamental recursive algorithm for traversing tree or graph data structures. Many complex applications rely on DFS variants to solve or optimize hard problems in various areas, such as path finding, scheduling, or circuit design. We implemented a standard DFS traversal in a fully-connected graph. Then we observed a 14.5% improvement in execution throughput and a 13% reduction in execution time.

Relative performance comparison for running a DFS algorithm

Conclusion

In this post, we’ve shown that a variety of applications, not just those primarily compute-bound, can benefit from the 64-bit Arm CPU performance improvements released in Go 1.18. Programs with an object-oriented design, recursion, or that have many function calls in their implementation will likely benefit more from the new register ABI calling convention.

By using AWS Graviton EC2 instances, you can benefit from up to a 40% price/performance improvement over other instance types. Furthermore, you can save even more with Graviton through the additional performance improvements by simply recompiling your Go applications with Go 1.18.

To learn more about Graviton, see the Getting started with AWS Graviton guide.

The Limits of Cyber Operations in Wartime

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2022/05/the-limits-of-cyber-operations-in-wartime.html

Interesting paper by Lennart Maschmeyer: “The Subversive Trilemma: Why Cyber Operations Fall Short of Expectations“:

Abstract: Although cyber conflict has existed for thirty years, the strategic utility of cyber operations remains unclear. Many expect cyber operations to provide independent utility in both warfare and low-intensity competition. Underlying these expectations are broadly shared assumptions that information technology increases operational effectiveness. But a growing body of research shows how cyber operations tend to fall short of their promise. The reason for this shortfall is their subversive mechanism of action. In theory, subversion provides a way to exert influence at lower risks than force because it is secret and indirect, exploiting systems to use them against adversaries. The mismatch between promise and practice is the consequence of the subversive trilemma of cyber operations, whereby speed, intensity, and control are negatively correlated. These constraints pose a trilemma for actors because a gain in one variable tends to produce losses across the other two variables. A case study of the Russo-Ukrainian conflict provides empirical support for the argument. Qualitative analysis leverages original data from field interviews, leaked documents, forensic evidence, and local media. Findings show that the subversive trilemma limited the strategic utility of all five major disruptive cyber operations in this conflict.

Security and Human Behavior (SHB) 2022

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2022/05/security-and-human-behavior-shb-2022.html

Today is the second day of the fifteenth Workshop on Security and Human Behavior, hosted by Ross Anderson and Alice Hutchings at the University of Cambridge. After two years of having this conference remotely on Zoom, it’s nice to be back together in person.

SHB is a small, annual, invitational workshop of people studying various aspects of the human side of security, organized each year by Alessandro Acquisti, Ross Anderson, Alice Hutchings, and myself. The forty or so attendees include psychologists, economists, computer security researchers, sociologists, political scientists, criminologists, neuroscientists, designers, lawyers, philosophers, anthropologists, geographers, business school professors, and a smattering of others. It’s not just an interdisciplinary event; most of the people here are individually interdisciplinary.

For the past decade and a half, this workshop has been the most intellectually stimulating two days of my professional year. It influences my thinking in different and sometimes surprising ways—and has resulted in some unexpected collaborations.

Our goal is always to maximize discussion and interaction. We do that by putting everyone on panels, and limiting talks to six to eight minutes, with the rest of the time for open discussion. Because everyone was not able to attend in person, our panels all include remote participants as well. The hybrid structure is working well, even though our remote participants aren’t around for the social program.

This year’s schedule is here. This page lists the participants and includes links to some of their work. As he does every year, Ross Anderson is liveblogging the talks.

Here are my posts on the first, second, third, fourth, fifth, sixth, seventh, eighth, ninth, tenth, eleventh, twelfth, thirteenth, and fourteenth SHB workshops. Follow those links to find summaries, papers, and occasionally audio/video recordings of the various workshops. Ross also maintains a good webpage of psychology and security resources.

Помните ли?

Post Syndicated from original http://www.gatchev.info/blog/?p=2440

Този текст във Фейсбук профила на Вихрен Стоев ми се видя отначало дългичък. След това осъзнах, че може да бъде удължен десетки пъти – има с какво. И че е важно.

Затова го копирам тук. С подкана към всеки, който иска да го допълни – добре дошъл е в коментари отдолу!

(С изключение на творците на съдържанието му. Включително ако пищят за свобода на словото. Свобода на словото в блога ми имат колкото имат свобода на придвижване в дома ми, неканени. И свободата на лъжата не е свобода на словото – тя е смъртта на свободата на словото. Където я има, словото вече е преносител не на знание, а на измама и само вреди. Затова и несвободата на лъжата е не просто важна, а задължителна за да има свобода на словото.)

И не съм съгласен, че не е за днес, а да си го прочитаме след време. И за днес е.

—-

Тоя пост не е за днес, а да си го прочитаме пак след дни, месеци, години, когато има нужда.

Помните ли как има нацистки режим в Украйна? Аз помня.
А помните ли, че нямаше война, а само специална операция? Аз помня.
А помните ли, че Украйна се нападна сама, за да инициира война? Аз помня.
А помните ли, че украинците посрещаха руснаците като освободители? Аз помня.
А помните ли, че Русия няма намерение да окупира украински територии? Аз помня.
А помните ли, че Украйна не е регистрирана в ООН и не съществува? Аз помня.
А помните ли как целият свят подкрепи Русия? Аз помня.
А помните ли, че нямаше да има санкции щото ЕС е разединен и разпадащ се? Аз помня.
А помните ли, че санкциите не работеха изобщо? Аз помня.
А помните ли, че това е краят на долара като резервна валута? Аз помня.
А помните ли, че военните щяха да направят преврат в Киев? Аз помня.
А помните ли, че Беларус се включи във войната, за да довършат заедно? Аз помня.
А помните ли, че Полша ще нападне Украйна от запад за да си я подели? Аз помня.
А помните ли, че всъщност причината за операцията бяха гей-парадите? Аз помня.
А помните ли, че Украйна разработваше ядрено оръжие? Аз помня.
А помните ли как се намериха лаборатории за биологично оръжие? Аз помня.
А помните ли, че имаше споразумение НАТО да не расте на изток? Аз помня.
А помните ли, че имаше 60 американски бази в Украйна? Аз помня.
А помните ли убитите българи в Одеса? Аз помня.
А помните ли насилственото налагане на украинския език? Аз помня.
А помните ли, че в Донецк убили толкоз деца, че чак алея има? Аз помня.
А помните ли че Малайзиския самолет го свали Украйна? Аз помня.
А помните ли, че Киев щеше да падне до часове? Аз помня.
А помните ли, че оттеглянето от Киев беше планът през цялото време? Аз помня.
А помните ли, че в Буча имаше актьори? Аз помня.
А помните ли, че всъщност не бяха актьори, а манекени? Аз помня.
А помните ли, че и манекени не бяха, а избити от украинците местни? Аз и това помня.
А помните ли, че украинската армия беше в котел и всеки момент ще бъде обкръжена? Аз помня.
А помните ли, че корабът Москва не е потъвал изобщо? Аз помня.
А помните ли, че все пак потъна от цигара? И от лошото време? Аз помня.
А помните ли, че Русия се удържаше, защото я е грижа за цивилните? Аз помня.
А помните ли, че Херсон иска да стане провинция на Русия? Аз помня.
А помните ли, че някакви хора в мазата на завод са най-злите нацисти на света? Аз помня.
А помните ли, че се оказа, че и в Приднестровието има геноцид? Аз помня.
А помните ли, че ако някой даде оръжие на Украйна, Русия веднага ще го смели? Аз помня.
А помните ли, че протестите с руските знамена бяха “за неутралитет”? Аз помня.
А помните ли, че всички щяха да плащат газ в рубли? Аз помня.
А помните ли, че газ освен в Русия няма никъде? Аз помня.
А помните ли, че всички спряха да дават оръжия на Украйна като спря газът? Аз помня.
A помните ли, че България е под робство на НАТО? Аз помня.
А помните ли, че има обявено гражданско неподчинение? Аз помня.
А помните ли, че Крим е руски? Аз помня.

Трябва да помним лъжите. Да разказваме историята им. Да ги познаем, когато изскочат пак след дни, години, десетилетия. Да помним кой ги е приказвал, откъде са идвали, кой ги е повтарял.

Аз помня. А вие?

—-

И „малко“ допълнения от мен:

Помните ли, че Русия никога не започва войни? Тя само ги завършва?
Че само луд би повярвал, че тя ще атакува Украйна?
Или че ще се опита да окупира Украйна – украинците са братя славяни, защо ѝ е?
И че тези слухове са само мръсен опит на Запада да отвлича хората от проблемите му?
Че Русия не краде от окупираните области всичко, което може?
Че няма да атакува и други държави, не само Украйна – защо ѝ е?
И как ако Западът ѝ позволи да окупира цяла Украйна, няма да поиска повече?
А как НАТО трябва да се изтегли напълно от цяла Източна Европа, и да не я защитава вече?…

Помните ли, че руската армия е непобедима и велика, и като нея няма втора?
И че ако поиска, за две седмици ще прегази НАТО и ще стигне на Атлантика?
Как тя не използва свръх-оръжията си, за да не ги видят САЩ и НАТО и да ги изкопират?
И се бави, понеже украинската армия е много по-голяма и по-добре въоръжена?
Че воюва в Украйна, за да опазва отечеството си?
И че в в Украйна няма руски наборници?
А как те не бяха пратени да копаят на ръка окопи в „рижия лес“?
Как служещи на крайцера „Москва“ са не загинали, а в самоотлъчка?
Как в Русия нямаше да има мобилизация?

Помните ли как Русия никога нямаше да напусне Змийския остров?
А как това, че го напусна, е жест на добра воля?
Как вече е унищожила три пъти повече украински самолети, отколкото Украйна има?
И два пъти повече западни артилерийски установки, отколкото са доставени?
Помните ли как няма убити руски генерали?
А как украинците бяха ударили в Нова Каховка склад не за оръжие, а за торове?
И как летището в Крим експлодира заради запалена цигара?
Как руската армия не избяга от Изюм и Купянск, а се прегрупира стратегически?
И от Лиман? Берислав? Нова Каховка? Херсон?

Помните ли как Зеленски беше избягал на Запад още първия ден от войната?
Че украинците са нацисти и бандеровци?
И че Русия воюва, понеже се бори срещу нацизма в Украйна?
А че Украйна е изкуствена държава, която не е легитимна?
И че населението в нея – и руско, и украинско – чака руската армия да го освободи?
Как ще я посрещне с цветя и само ще арестува украинските войници?
И как ще гласува щастливо за присъединяване към Русия?

Помните ли как гарата в Краматорск не е бомбардирана?
А че е бомбардирана, но от украинците?
И че избитите там цивилни са само манекени?
А че не са манекени, а актьори? Същите като в Буча?
И че в Буча загиналите също ги избиха украинците, с артилерийски обстрел?
А спътниковите снимки, които го опровергават, са западни фалшификати?
А как „Офицерския дом“ във Виница бил ударен, защото бил военен обект?
И още хиляди други „военни обекти“?
И как цивилни бяха бомбардирани не за отмъщение за Кримския мост?
С бомбардировка, подготвена дни преди взрива му?

Помните ли как Мариупол нямаше да бъде бомбардиран, понеже е руски град?
Как театърът му беше бомбардиран, понеже там бил щабът на „Азов“?
И на практика всички други цивилни сгради, защото и в тях бил щабът на „Азов“?
И че всъщност не е бомбардиран – спътниковите снимки са фалшиви?
Как скрилите се в Азовстал мариуполци ги беше отвлякла там украинската армия?
А как там има и 20 000 западни и израелски военни? И натовски генерали?
Как от „Азов“ се предадоха след евакуирането на цивилните в Азовстал, понеже си нямат жив щит?
А как в руски плен масово измират от инфаркт – от страх, че ще ги съдят?
Как Северодонецк и Рубижне нямаше да бъдат бомбардирани, понеже са руски градове?
А как ги бомбардират, понеже там е щабът на „Азов“?
Как Одеса нямаше да бъде бомбардирана, понеже е руски град?
И как там запушват прозорците с торби пясък, за да скрият щабовете на нацисти?…

Помните ли как през 2014 г. 97% процента от Крим гласува за присъединяване към Русия?
Как „учтивите хора“, които проведоха референдума, не бяха руската армия?
Как Евгений Пригожин не беше организаторът на наемниците от „Вагнер“?
Как армията на ДНР и ЛНР също не е руска армия със сменени опознавателни знаци?
Как обкръжените при Иловайск украинци щяха си тръгнат свободно, ако оставят оръжието си?
Как украинците в окупираните райони се евакуират в Русия доброволно?
Как доброволно отиват да работят за руската армия в концентрационни лагери?
Как украинските военни престъпници сред тях ще бъдат наказани най-сурово?…

Помните ли, че Украйна беше забранила изучаването на руски език?
И на български, в селата на българи в Южна Украйна?
И как не е вярно, че след Майдана тези села почнаха масово да отварят български училища?
И как не е вярно, че руските окупатори са забранили изучаването на украински език?
И как не е вярно, че са затворили българските училища и са забранили българския език?
А че на български език вече не се преподава поради липса на учители?

Помните ли, че Финландия ще загине без руските доставки, ако влезе в НАТО?
Как това е опасно за нея? Че НАТО няма да я пази?
Както нямаше да пази и Украйна, ако тя беше негов член?
Как влезе ли Швеция в НАТО, Русия веднага ще превземе Готланд?
Как НАТО няма да я опази, въпреки че е негов член?
Как без руските суровини ЕС ще загине?
Как това е краят на ЕС, еврото, долара и мръсния прогнил западен либерализъм?…

Помните ли как отказът на НАТО да напусне Източна Европа го въвличаше във война с Русия?
А как протестът му срещу руското нападение срещу Украйна го въвличаше във война с Русия?
А как доставянето му на Украйна на противотанкови ракети го въвличаше във война с Русия?
А как доставянето му на спътникови снимки на Украйна го въвличаше във война с Русия?
А как обучението му на украински войници го въвличаше във война с Русия?
А как доставянето му на стрелково оръжие на Украйна го въвличаше във война с Русия?
А как санкциите му срещу Русия го въвличаха във война с Русия?
А как доставянето му на Украйна на стари руски танкове го въвличаше във война с Русия?
А как доставянето му на Украйна на стари руски самолети го въвличаше във война с Русия?
А как доставянето му на западни танкове го въвличаше във война с Русия?
А как дипломатическата не-поддръжка от България я въвличаше във война с Русия?
А как изпращането на генератори и консерви за Украйна въвлича България във война с Русия?
А как ако България достави на Украйна оръжие, това ще я въвлече във война с Русия?

Помните ли как не Русия, а САЩ и ЕС блокираха украинските доставки на жито по море?
Как Русия обеща да не ги блокира повече, ако отменят санкциите срещу нея?
Как за недостига на жито в Африка е виновна Украйна, понеже се съпротивлява?
И понеже на преговорите с Русия не приема руската позиция?
Нито пък прави „разумни компромиси“?
И как през зимата-пролетта ще гладува, понеже си е изнесла с кораби храната?

Помните ли, че украинските бежанци у нас са гадове, понеже имат хубави коли?
Как искат да наливат бензин и да ядат в ресторанти, без да плащат?
Как им даваме по 40 лева на ден? И те искат повече?
Въпреки че имат цели куфари с пачки долари и евро?
Как се възмущават за дреболии – някой им обстрелвал децата с въздушна пушка?
Как, когато български патриот ги пребие на улицата, се оплакват в полицията?
Как в Германия не им дават никакви помощи?
Как, ако имат кола за над 10 000 евро, им дават помощи само ако я продадат?
Как им дават по 200 евро помощ на ден, на проклетите мръсници?
Как изобщо украинците са гадове, понеже живеят красиво?…

Помните ли как без руския газ ще останем без ток?
Как Русия ще ни спре газа, ако изнасяме оръжие за Украйна – иначе никога?
Как ние сами сме си виновни, че ни го спря, понеже сме членове на ЕС и НАТО?
Как за нас нямаше да има газ отдругаде – Азърбайджан, САЩ…?
Как щеше да има, но на тройни цени?
Как без договор с Газпром 250 000 българи щяха да останат на улицата?
Как без руското ядрено гориво ще останем без ток?
Как цяла Европа ще измре от студ без руския газ?
Защото няма откъде другаде да си намери?
И как западняците ще се топлят в руските културни центрове?
(Вероятно те са на отделно снабдяване с ток и газ.)
Как мръсната Америка и да прати газ, ще дере горките европейци с десеторни цени?
Как така им се пада на мръсните еврогейове?…

Помните ли как да помагаш на Украйна е лошо за нея, понеже само удължава агонията ѝ?
Как украинското знаме е предателство за българина, а руското е гордост?
Как да подкрепяш Украйна е войнолюбие, а да подкрепяш Русия е миротворчество?
Как е миротворчество да си неутрален, докато агресорът печели войната?
Как да подкрепяш Украйна е национално предателство, а да подкрепяш Русия е патриотизъм?

Помните ли как нямаше да има българи доброволци да се бият за Украйна?
А как има, ама защото Украйна им плаща милиони долари?
Как никой от тях няма да се върне жив, защото руските лъвове ще ги изядат с кокалите?
А как тези, които се връщат за малко, няма да отидат там никога повече?
И как ще измамят хората, които им дават пари за оръжие, и ще избягат с парите?
И как че се връщат там с оръжие и материали е война на България срещу майчица Русия?
Как да събираш пари за храна и генератори за украинското население е русофобия?
И как тези пари ще бъдат откраднати от събиращите и с тях няма да се купи нищо?
А как купените с тях генератори и храна ще бъдат откраднати, вместо да идат в Украйна?
Как доброволци ще ги карат дотам само за да се разхождат и ядат пари?
И как няма да посмеят да се доближат до фронта, и украинците няма да получат нищо?
А как ги обстрелва с артилерия не руската армия, а мирното украинско население?
Понеже е толкова про-руско, че мрази помощите, а обича руските обстрели?
И изобщо, който помага на мирното население в Украйна, е изрод и предател на България?

Помните ли как светът нямаше да разследва руските престъпления в Украйна?
Как и да ги разследва, нямаше да намери нищо, защото ги няма?
Как разследващият ги екип е от платени лъжци и ще фалшифицира доказателства?
И спътникови снимки, ранени лекувани в болници в ЕС и т.н.?
И как няма да има международен съд за руските лидери и военни престъпници?
И плюс това този съд е нелегитимен и няма право да ги съди?

И как Русия няма да употреби в Украйна оръжие за масово поразяване?

Аз помня. И ще помня.

Помнете и вие. Не само лъжите – най-вече лъжците.
Защото стигне ли любимата им армия тук, вече не само ще ви лъжат.

Building resilient private APIs using Amazon API Gateway

Post Syndicated from Eric Johnson original https://aws.amazon.com/blogs/compute/building-resilient-private-apis-using-amazon-api-gateway/

This post written by Giedrius Praspaliauskas, Senior Solutions Architect, Serverless.

Modern architectures meet recovery objectives (recovery time objective, RTO, and recovery point objective, RPO) by being resilient to routine and unexpected infrastructure disruptions. Depending on the recovery objectives and regulatory requirements, developers must choose the disaster recovery strategy. For more on disaster recovery strategies, see this whitepaper.

AWS’ global infrastructure enables customers to support applications with near zero RTO requirements. Customers can run workloads in multiple Regions, in a multi-site active/active manner, and serve traffic from all Regions. To do so, developers often must implement private multi-regional APIs for use by the applications.

This blog describes how to implement this solution using Amazon API Gateway and Amazon Route 53.

Overview

The first step is to build a REST API that uses private API Gateway endpoints with custom domain names as described in this sample. The next step is to deploy APIs in two AWS Regions and configure Route 53, following a disaster recovery strategy.
This architecture uses the following resources in each Region:

Two region architecture example

Two region architecture example

  • API Gateway with an AWS Lambda function as integration target.
  • Amazon Virtual Private Cloud (Amazon VPC) with two private subnets, used to deploy VPC endpoint and Network Load Balancers (NLB).
  • AWS Transit Gateway to establish connectivity between the two VPCs in different Regions.
  • VPC endpoint to access API Gateway from a private VPC.
  • Elastic network interfaces (ENIs) created by the VPC endpoint.
  • A Network Load Balancer with ENIs in its target group and a TLS listener with an AWS Certificate Manager (ACM) certificate, used as a facade for the API.
  • ACM issues and manages certificates used by the NLB TLS listener and API Gateway custom domain.
  • Route 53 with private hosted zones used for DNS resolution.
  • Amazon CloudWatch with alarms used for Route 53 health checks.

This sample implementation uses a Lambda function as an integration target, though it can target on-premises resources accessible via AWS Direct Connect, and applications running on Amazon EKS. For more information on best practices designing API Gateway private APIs, see this whitepaper.

This post uses AWS Transit Gateway with inter-Region peering to establish connectivity between the two VPCs. Depending on the networking needs and infrastructure already in place, you may tailor the architecture and use a different approach. Read this whitepaper for more information on available VPC-to-VPC connectivity options.

Implementation

Prerequisites

You can use existing infrastructure to deploy private APIs. Otherwise check the sample repository for templates and detailed instructions on how to provision the necessary infrastructure.

This post uses the AWS Serverless Application Model (AWS SAM) to deploy private APIs with custom domain names. Visit the documentation to install it in your environment.

Deploying private APIs into multiple Regions

To deploy private APIs with custom domain names and CloudWatch alarms for health checks into the two AWS Regions:

  1. Download the AWS SAM template file api.yaml from the sample repository. Replace default parameter values in the template with ones that match your environment or provide them during the deployment step.
  2. Navigate to the directory containing the template. Run following commands to deploy the API stack in the us-east-1 Region:
    sam build --template-file api.yaml
    sam deploy --template-file api.yaml --guided --stack-name private-api-gateway --region us-east-1
  3. Repeat the deployment in the us-west-2 Region. Update the parameters values in the template to match the second Region (or provide them as an input during the deployment step). Run the following commands:
    sam build --template-file api.yaml
    sam deploy --template-file api.yaml --guided --stack-name private-api-gateway --region us-west-2

Setting up Route 53

With the API stacks deployed in both Regions, create health checks to use them in Route 53:

  1. Navigate to Route 53 in the AWS Management Console. Use the CloudWatch alarms created in the previous step to create health checks (one per Region):
    Configuring the health check for region 1

    Configuring the health check for region 1

    Configuring the health check for region 2

    Configuring the health check for region 2

    This Route 53 health check uses the CloudWatch alarms that are based on a static threshold of the NLB healthy host count metric in each Region. In your implementation, you may need more sophisticated API health status tracking. It can use anomaly detection, include metric math, or use a composite state of the multiple alarms. Check this documentation article for more information on CloudWatch alarms. You can also use the approach documented in this blog post as an alternative. It will help you to create a health check solution that observes the state of the private resources and creates custom metrics that are more specific to your use case. For example, such metrics could include increased database transactions’ failure rate, number of timed out requests to a downstream legacy system, status of an external system that your workload depends on, etc.

  2. Create a private Route 53 hosted zone. Associate this with the VPCs where the client applications that access private APIs reside:

    Create a private hosted zone

    Create a private hosted zone

  3. Create Route 53 private zone alias records, pointing to the NLBs in both Regions and VPCs, using the same name for both records (for example, private.internal.example.com):

    Create alias records

    Create alias records

This post uses Route 53 latency-based routing for private DNS to implement resilient active-active private API architecture. Depending on your use case and disaster recovery strategy, you can change this approach and use geolocation-based routing, failover, or weighted routing. See the documentation for more details on supported routing policies for the records in a private hosted zone.

In this implementation, client applications that connect to the private APIs reside in the VPCs and can access Route 53 private hosted zones. You may also operate an application that runs on-premises and must access the private APIs. Read this blog post for more information on how to create DNS naming that spans the entire network.

Validating the configuration

To validate this implementation, I use a bastion instance in each of the VPCs. I connect to them using SSH or AWS Systems Manager Session Manager (see this documentation article for details).

  1. Run the following command from both bastion instances:
    dig +short private.internal.com

    The response should contain IP addresses of the NLB in one VPC:

    10.2.2.188
    10.2.1.211
  2. After DNS resolution verification, run the following command in each of the VPCs:
    curl -s -XGET https://private.internal.example.com/demo

    The response should include event data as the Lambda function received it.

  3. To simulate an outage, navigate to Route 53 in the AWS Management Console. Select the health check that corresponds to the Region where you received the response, and invert the health status:
  4. After a few minutes, retry the same DNS resolution and API response validation steps. This time, it routes all your requests to the remaining healthy API stack.

Cleaning Up

To avoid incurring further charges, delete all the resources that you have created in Route 53 records, health checks, and private hosted zones.

Run the following commands to delete API stacks in both Regions:

sam delete --stack-name private-api-gateway --region us-west-2
sam delete --stack-name private-api-gateway --region us-east-1

If you used the sample templates to provision the infrastructure, follow the steps listed in the Cleanup section of the sample repository instructions.

Conclusion

This blog post walks through implementing a multi-Regional private API using API Gateway with custom domain names. This approach allows developers to make their internal applications and workloads more resilient, react to disruptions, and meet their disaster recovery scenario objectives.

For additional guidance on such architectures, including multi-Region application architecture, see this solutionblog post, re:Invent presentation.

For more serverless learning resources, visit Serverless Land.

Malware-Infested Smart Card Reader

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2022/05/malware-infested-smart-card-reader.html

Brian Krebs has an interesting story of a smart ID card reader with a malware-infested Windows driver, and US government employees who inadvertently buy and use them.

But by all accounts, the potential attack surface here is enormous, as many federal employees clearly will purchase these readers from a myriad of online vendors when the need arises. Saicoo’s product listings, for example, are replete with comments from customers who self-state that they work at a federal agency (and several who reported problems installing drivers).

Manipulating Machine-Learning Systems through the Order of the Training Data

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2022/05/manipulating-machine-learning-systems-through-the-order-of-the-training-data.html

Yet another adversarial ML attack:

Most deep neural networks are trained by stochastic gradient descent. Now “stochastic” is a fancy Greek word for “random”; it means that the training data are fed into the model in random order.

So what happens if the bad guys can cause the order to be not random? You guessed it—all bets are off. Suppose for example a company or a country wanted to have a credit-scoring system that’s secretly sexist, but still be able to pretend that its training was actually fair. Well, they could assemble a set of financial data that was representative of the whole population, but start the model’s training on ten rich men and ten poor women drawn from that set ­ then let initialisation bias do the rest of the work.

Does this generalise? Indeed it does. Previously, people had assumed that in order to poison a model or introduce backdoors, you needed to add adversarial samples to the training data. Our latest paper shows that’s not necessary at all. If an adversary can manipulate the order in which batches of training data are presented to the model, they can undermine both its integrity (by poisoning it) and its availability (by causing training to be less effective, or take longer). This is quite general across models that use stochastic gradient descent.

Research paper.

The Justice Department Will No Longer Charge Security Researchers with Criminal Hacking

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2022/05/the-justice-department-will-no-longer-charge-security-researchers-with-criminal-hacking.html

Following a recent Supreme Court ruling, the Justice Department will no longer prosecute “good faith” security researchers with cybercrimes:

The policy for the first time directs that good-faith security research should not be charged. Good faith security research means accessing a computer solely for purposes of good-faith testing, investigation, and/or correction of a security flaw or vulnerability, where such activity is carried out in a manner designed to avoid any harm to individuals or the public, and where the information derived from the activity is used primarily to promote the security or safety of the class of devices, machines, or online services to which the accessed computer belongs, or those who use such devices, machines, or online services.

[…]

The new policy states explicitly the longstanding practice that “the department’s goals for CFAA enforcement are to promote privacy and cybersecurity by upholding the legal right of individuals, network owners, operators, and other persons to ensure the confidentiality, integrity, and availability of information stored in their information systems.” Accordingly, the policy clarifies that hypothetical CFAA violations that have concerned some courts and commentators are not to be charged. Embellishing an online dating profile contrary to the terms of service of the dating website; creating fictional accounts on hiring, housing, or rental websites; using a pseudonym on a social networking site that prohibits them; checking sports scores at work; paying bills at work; or violating an access restriction contained in a term of service are not themselves sufficient to warrant federal criminal charges. The policy focuses the department’s resources on cases where a defendant is either not authorized at all to access a computer or was authorized to access one part of a computer—such as one email account—and, despite knowing about that restriction, accessed a part of the computer to which his authorized access did not extend, such as other users’ emails.

News article.

Forging Australian Driver’s Licenses

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2022/05/forging-australian-drivers.html

The New South Wales digital driver’s license has multiple implementation flaws that allow for easy forgeries.

This file is encrypted using AES-256-CBC encryption combined with Base64 encoding.

A 4-digit application PIN (which gets set during the initial onboarding when a user first instals the application) is the encryption password used to protect or encrypt the licence data.

The problem here is that an attacker who has access to the encrypted licence data (whether that be through accessing a phone backup, direct access to the device or remote compromise) could easily brute-force this 4-digit PIN by using a script that would try all 10,000 combinations….

[…]

The second design flaw that is favourable for attackers is that the Digital Driver Licence data is never validated against the back-end authority which is the Service NSW API/database.

This means that the application has no native method to validate the Digital Driver Licence data that exists on the phone and thus cannot perform further actions such as warn users when this data has been modified.

As the Digital Licence is stored on the client’s device, validation should take place to ensure the local copy of the data actually matches the Digital Driver’s Licence data that was originally downloaded from the Service NSW API.

As this verification does not take place, an attacker is able to display the edited data on the Service NSW application without any preventative factors.

There’s a lot more in the blog post.