Властта на алгоритмите

Post Syndicated from Bozho original https://blog.bozho.net/blog/4463

Днес са изборите в Германия, а преди няколко дни излезе изследване, че X (twitter) промотира повече съдържание на Алтернатива за Германия (AfD) и на другата популистка партия BSW.

Изследването установява, че в подбраните за потребителите публикации в X, от профили, които те НЕ следват, има несъразмерно повече такива от AfD и BSW. Като особен ръст има в последните две седмици.

Мъск не крие, че подкрепя AfD, но явно, директно или индиректно, прави това и чрез платформата си X. Алгоритъмът за препоръчване на съдържание на X уж е публичен, но всъщност последно публикуваното е от 2023 г, и то без данните, с които е „захранен“ модела, т.е. на практика не е публичен.

Занимавал съм се професионално с алгоритми за препоръчване на съдържание преди 12 години, а преди 6 имах лекция, озаглавена „алгоритмична и технологична прозрачност“, в която излагам нуждата от прозрачност на алгоритмите, моделите и техните данни, вкл. за препоръчване на съдържание, както и рисковете, които произтичат от „черните кутии“, каквито са в момента.

За съжаление през 2022 г, когато бях министър, вече беше твърде късно в процеса по приемане на Акта за цифровите услуги на ЕС, за да бъдат отразени моите предложения и акът остана с твърде бланкетни текстове по отношение на алгоритмите.

А малка промяна в алгоритъма може да доведе до заливане на потребителите със съдържание, което те не са искали да видят, не следват, не очакват, но въпреки това виждат. Всяка платформа, с политически цели, може да бъде пропагандна машина. Например, ако тежестта на т.нар. суперразпространители бъде увеличена, без значение от държавата, то постоянното цитиране на AfD от страна на Мъск би промотирало съдържание дори към хора, които не следват Мъск.

Европейската комисия (ЕК) може да използва правомощията си, за да получи данни за наблюденията в изследването, но Мъск, както и преди, вероятно ще използва и това за политическа атака – вероятно ще каже как ЕК го натиска да ограничава AfD.

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

А реакцията може да бъде само предварителна – ако след дадени избори има оправдание „ама те алгоритмите са лоши“, това ще звучи фалшиво в ушите на избирателите.

Алгоритмите за препоръчване на съдържание представляват системен риск, когато са непрозрачни и когато са на едно телефонно обаждане от превръщането им в геополитически инструмент. Но сме закъснели с решаването и на този проблем.

Материалът Властта на алгоритмите е публикуван за пръв път на БЛОГодаря.

Седмицата 17–22 февруари

Post Syndicated from Боряна Телбис original https://www.toest.bg/sedmitsata-17-22-fevruari/

Седмицата 17–22 февруари

Преди да ви кажа какво сме публикували тази седмица в „Тоест“, ще ви предупредя най-приятелски много да внимавате какво пишете в социалните мрежи, как си вършите работата и изобщо какво правите в живота си, защото ви грози опасността да дойде Илон Мъск и да ви се скара от висотата на кетаминовия си ентусиазъм и на 400-те си милиарда долара нетна стойност. Като нищо може да ви и обиди на „бавноразвиващ се“ или пък на „тиранин“, а както знаем, повечето от нас са тънкообидни и не е ясно къде ще му излезе краят. 

За щастие, краят на тази седмица, в която медийният поток приличаше на кръвожадно цунами, готово да ни удави поголовно, е тук. Предлагам всички да се въздържат от новини, изказвания и военни разходки в съседни държави поне до понеделник, за да вземем дъх на седмия ден, както повелява християнската традиция, разбира се.

Ако много страдате, че сте изпуснали важни неща, не се притеснявайте – то така си е по план. Нали трябва да гледаме в другата посока, като излиза зайчето от шапката, че инак съвсем ще се стопи магията. В „Тоест“ обаче има хора, които все гледат в ръцете на фокусника, да им се не види, и кротко и напоително описват къде какво става. Така прави тази седмица Емилия Милчева, която в политическия си обзор разказва за избирането на регулаторите, за Украйна, за бюджета и всички важни теми от седмицата, които може и да сте изпуснали, докато в парламента си подаряват калкулатори и розови маркери

Да минат да ни подарят нещо и на нас. Както става ясно от третия епизод на рубриката ни „Т.Е. от Е.Т.“, на Е.Т. ѝ е свършил тонерът за принтера, Добрев и Василев може да помислят по въпроса. Даже, ако искат, и дарители на „Тоест“ могат да станат, за да можем още да пишем и да говорим за тях и техните песни все да се четат, както е казал поетът.

Вижте целия епизод 3 тук:

За по-сериозни политически анализи четете редовно „Тоест“, но то в тези анализи все за същите хора ще става въпрос, така че не знам дали ще ви устройва.

Категорично сериозен е текстът на Валентин Вълканов „България в епохата на автократите“, в който той обяснява, че бъркаме, ако си мислим, че все още не живеем в автокрация. Всички предпоставки са налице: завладени медии, потъпкано върховенство на закона, популизъм, откраднати избори… Няма да продължавам, ще си го прочетете сами. Текст, предназначен за „либерали със соево лате в ръка“, които се оказаха най-големият проблем на държавата, понеже всичко друго ни е топ.

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

Прогонвам бързо мисълта за ядрена война, защото и бездруго нищо не мога да направя по отношение на хората и тяхното желание да натискат копчета, и продължавам със съдържанието на „Тоест“ тази седмица. 

Имаме си две продължения на текстове в две от най-любопитните ни рубрики, които, сигурна съм, верните им читатели чакат с голям интерес.

Втора част на „Истории на върха на налъма“ от рубриката на Атанас Шиников „Ориент кафе“ е в играта. В нея става дума за налъми, както сигурно се досещате, особено ако сте чели първата част. Атанас прелиства стари арабски текстове, за да научи повече за санкциониращата употреба на налъмите, както и за превръщането им в талисман. И съответно, като го научи той, го научавате и вие, ако си прочетете статията.

Казах „игра“ и веднага отиграваме и с другото продължение на текст в тазседмичния ни брой: „В отбор със себе си. Между настолните ролеви игри и техните компютърни адаптации“ от рубриката ни „Игромислие“. В него Николай Генов и Чавдар Парушев разсъждават доколко разказът във видеоиграта е разписан и несвободен, а този в настолната – по-скоро спонтанен и импровизиран. Въобще не е необходимо да си падате по настолни или компютърни игри, за да се потопите в този прекрасен философски разговор, който съвсем спокойно може да съотнесете към какво ли не в битието ни, което „се играе“.

Седмицата в „Тоест“ закрива Антония Апостолова с текст в рубриката „На второ четене“, посветен на „Дъхът на ближните“ от кипърския писател Андонис Георгиу. Това е сборник с разкази, събиращ актуални теми, доколкото те са част от традиционната динамика в ежедневието и разговорите на обикновените кипърци, както пише Антония. „Но някак над това като че ли стоят най-вечните теми: преди всичко тленността и смъртта, но и извечната самота на човека, желанието да се свържеш някак с „дъха на другите“, прошката и любовта“, казва още тя в рецензията си. 

И понеже на този бюлетин му е време да приключва, оставям една препоръка (не че сте ми я искали). Гледайте при първа възможност филма „Милен“, посветен на Милен Цветков. После може пак да си говорим, ако искате. 

Айде, със здраве!

Improve search results for AI using Amazon OpenSearch Service as a vector database with Amazon Bedrock

Post Syndicated from Jon Handler original https://aws.amazon.com/blogs/big-data/improve-search-results-for-ai-using-amazon-opensearch-service-as-a-vector-database-with-amazon-bedrock/

Artificial intelligence (AI) has transformed how humans interact with information in two major ways—search applications and generative AI. Search applications include ecommerce websites, document repository search, customer support call centers, customer relationship management, matchmaking for gaming, and application search. Generative AI use cases include chatbots with Retrieval-Augmented Generation (RAG), intelligent log analysis, code generation, document summarization, and AI assistants. AWS recommends Amazon OpenSearch Service as a vector database for Amazon Bedrock as the building blocks to power your solution for these workloads.

In this post, you’ll learn how to use OpenSearch Service and Amazon Bedrock to build AI-powered search and generative AI applications. You’ll learn about how AI-powered search systems employ foundation models (FMs) to capture and search context and meaning across text, images, audio, and video, delivering more accurate results to users. You’ll learn how generative AI systems use these search results to create original responses to questions, supporting interactive conversations between humans and machines.

The post addresses common questions such as:

  1. What is a vector database and how does it support generative AI applications?
  2. Why is Amazon OpenSearch Service recommended as a vector database for Amazon Bedrock?
  3. How do vector databases help prevent AI hallucinations?
  4. How can vector databases improve recommendation systems?
  5. What are the scaling capabilities of OpenSearch as a vector database?

How vector databases work in the AI workflow

When you’re building for search, FMs and other AI models convert various types of data (text, images, audio, and video) into mathematical representations called vectors. When you use vectors for search, you encode your data as vectors and store those vectors in a vector database. You further convert your query into a vector and then query the vector database to find related items by minimizing the distance between vectors.

When you’re building for generative AI, you use FMs such as large language models (LLMs), to generate text, video, audio, images, code, and more from a prompt. The prompt might contain text, such as a user’s question, along with other media such as images, audio, or video. However, generative AI models can produce hallucinations—outputs that appear convincing but contain factual errors. To solve for this challenge, you employ vector search to retrieve accurate information from a vector database. You add this information to the prompt in a process called Retrieval-Augmented Generation (RAG).

Why is Amazon OpenSearch Service the recommended vector database for Amazon Bedrock?

Amazon Bedrock is a fully managed service that provides FMs from leading AI companies, and the tools to customize these FMs with your data to improve their accuracy. With Amazon Bedrock, you get a serverless, no-fuss solution to adopt your selected FM and use it for your generative AI application.

Amazon OpenSearch Service is a fully managed service that you can use to deploy and operate OpenSearch in the AWS Cloud. OpenSearch is an open source search, log analytics, and vector database solution, composed of a search engine and vector database; and OpenSearch Dashboards, a log analytics, observability, security analytics, and dashboarding solution. OpenSearch Service can help you to deploy and operate your search infrastructure with native vector database capabilities, pre-built templates, and simplified setup. API calls and integration templates streamline connectivity with Amazon Bedrock FMs, while the OpenSearch Service vector engine can deliver as low as single-digit millisecond latencies for searches across billions of vectors, making it ideal for real-time AI applications.

OpenSearch is a specialized type of database technology that was originally designed for latency- and throughput-optimized matching and retrieval of large and small blocks of unstructured text with ranked results. OpenSearch ranks results based on a measure of similarity to the search query, returning the most similar results. This similarity matching has evolved over time. Before FMs, search engines used a word-frequency scoring system called term frequency/inverse document frequency (TF/IDF). OpenSearch Service uses TF/IDF to score a document based on the rarity of the search terms in all documents and how often the search terms appeared in the document it’s scoring.

With the rise of AI/ML, OpenSearch added the ability to compute a similarity score for the distance between vectors. To search with vectors, you add vector embeddings produced by FMs and other AI/ML technologies to your documents. To score documents for a query, OpenSearch computes the distance from the document’s vector to a vector from the query. OpenSearch further provides field-based filtering and matching and hybrid vector and lexical search, which you use to incorporate terms in your queries. OpenSearch hybrid search performs a lexical and a vector query in parallel, producing a similarity score with built-in score normalization and blending to improve the accuracy of the search result compared with lexical or vector similarity alone.

OpenSearch Service supports three vector engines: Facebook AI Similarity (FAISS), Non-Metric Space Library (NMSLib), and Apache Lucene. It supports exact nearest neighbor search, and approximate nearest neighbor (ANN) search with either hierarchical navigable small world (HNSW), or Inverted File (IVF) engines. OpenSearch Service supports vector quantization methods, including disk-based vector quantization so you can optimize cost, latency, and retrieval accuracy for your solution.

Use case 1: Improve your search results with AI/ML

To improve your search results with AI/ML, you use a vector-generating ML model, most frequently an LLM or multi-modal model that produces embeddings for text and image inputs. You use Amazon OpenSearch Ingestion, or a similar technology to send your data to OpenSearch Service with OpenSearch Neural Plugin to integrate the model, using a model ID, into an OpenSearch ingest pipeline. The ingest pipeline calls Amazon Bedrock to create vector embeddings for every document during ingestion.

To query OpenSearch Service as a vector database, you use an OpenSearch neural query to call Amazon Bedrock to create an embedding for the query. The neural query uses the vector database to retrieve nearest neighbors.

The service offers pre-built CloudFormation templates that construct OpenSearch Service integrations to connect to Amazon Bedrock foundation models for remote inference. These templates simplify the setup of the connector that OpenSearch Service uses to contact Amazon Bedrock.

After you’ve created the integration, you can refer to the model_id when you set up your ingest and search pipelines.

Use case 2: Amazon OpenSearch Serverless as an Amazon Bedrock knowledge base

Amazon OpenSearch Serverless offers an auto-scaled, high-performing vector database that you can use to build with Amazon Bedrock for RAG, and AI agents, without having to manage the vector database infrastructure. When you use OpenSearch Serverless, you create a collection—a collection of indexes for your application’s search, vector, and logging needs. For vector database use cases, you send your vector data to your collection’s indices, and OpenSearch Serverless creates a vector database that provides fast vector similarity and retrieval.

When you use OpenSearch Serverless as a vector database, you pay only for storage for your vectors and the compute needed to serve your queries. Serverless compute capacity is measured in OpenSearch Compute Units (OCUs). You can deploy OpenSearch Serverless starting at just one OCU for development and test workloads for about $175/month. OpenSearch Serverless scales up and down automatically to accommodate your ingestion and search workloads.

With Amazon OpenSearch Serverless, you get an autoscaled, performant vector database that is seamlessly integrated with Amazon Bedrock as a knowledge base for your generative AI solution. You use the Amazon Bedrock console to automatically create vectors from your data in up to five data stores, including an Amazon Simple Storage Service (Amazon S3) bucket and store them in an Amazon OpenSearch Serverless collection.

When you’ve configured your data source, and selected a model, select Amazon OpenSearch Serverless as your vector store, and Amazon Bedrock and OpenSearch Serverless will take it from there. Amazon Bedrock will automatically retrieve source data from your data source, apply the parsing and chunking strategies you have configured, and index vector embeddings in OpenSearch Serverless. An API call will synchronize your data source with OpenSearch Serverless vector store.

The Amazon Bedrock retrieve_and_generate() runtime API call makes it straightforward for you to implement RAG with Amazon Bedrock and your OpenSearch Serverless knowledge base.

response = bedrock_agent_runtime_client.retrieve_and_generate(
  input={
    'text': prompt,
  },
  retrieveAndGenerateConfiguration={
    'type': 'KNOWLEDGE_BASE',
    'knowledgeBaseConfiguration': {
      'knowledgeBaseId': knowledge_base_id,
      'modelArn': model_arn,
}})

Conclusion

In this post, you learned how Amazon OpenSearch Service and Amazon Bedrock work together to deliver AI-powered search and generative AI applications and why OpenSearch Service is the AWS recommended vector database for Amazon Bedrock. You learned how to add Amazon Bedrock FMs to generate vector embeddings for OpenSearch Service semantic search to bring meaning and context to your search results. You learned how OpenSearch Serverless provides a tightly integrated knowledge base for Amazon Bedrock that simplifies using foundation models for RAG and other generative AI. Get started with Amazon OpenSearch Service and Amazon Bedrock today to enhance your AI-powered applications with improved search capabilities with more reliable generative AI outputs.


About the author

Jon Handler is Director of Solutions Architecture for Search Services at Amazon Web Services, based in Palo Alto, CA. Jon works closely with OpenSearch and Amazon OpenSearch Service, providing help and guidance to a broad range of customers who have search and log analytics workloads for OpenSearch. Prior to joining AWS, Jon’s career as a software developer included four years of coding a large-scale ecommerce search engine. Jon holds a Bachelor of the Arts from the University of Pennsylvania, and a Master’s of Science and a PhD in Computer Science and Artificial Intelligence from Northwestern University.

Metasploit Weekly Wrap-Up 02/21/2025

Post Syndicated from Diego Ledda original https://blog.rapid7.com/2025/02/21/metasploit-weekly-wrap-up-46/

BeyondTrust and Fetch Payload

Metasploit Weekly Wrap-Up 02/21/2025

This Metasploit release includes an exploit module that chains two vulnerabilities, one exploited in the wild by APT groups and another one, a 0-day discovered by Rapid7 during the vulnerability analysis.
In addition to that, a significant improvement was made to Fetch-Payloads by adding support for the ppc, mips and arm architectures. This allows the payloads to be used in exploits that commonly target embedded systems.

New module content (3)

BeyondTrust Privileged Remote Access (PRA) and Remote Support (RS) unauthenticated Remote Code Execution

Author: sfewer-r7
Type: Exploit
Pull request: #19877 contributed by sfewer-r7
Path: linux/http/beyondtrust_pra_rs_unauth_rce
AttackerKB reference: CVE-2025-1094

Description: The module exploits two bugs CVE-2024-12356 and CVE-2025-1094, an argument injection in BeyondTrust code base and SQL injection in PostgreSQL code base, respectively.

InvokeAI RCE

Authors: Takahiro Yokoyama and jackfromeast
Type: Exploit
Pull request: #19883 contributed by Takahiro-Yoko
Path: linux/http/invokeai_rce_cve_2024_12029
AttackerKB reference: CVE-2024-12029

Description: This adds an exploit module for InvokeAI unauth RCE (CVE-2024-12029).

Fetch Payload Update

Authors: Adam Cammack [email protected], Brendan Watters, and Spencer McIntyre
Type: Payload
Pull request: #19850 contributed by bwatters-r7

Description: This extends the fetch-payload support for aarch64, armbe, armle, mipsbe, mipsle, ppc, ppc64 and ppc64le payloads.

Enhancements and features (3)

  • #19884 from adfoster-r7 – Add OSVDB search functionality to msfconsole e.g. search osvdb:67241.
  • #19885 from adfoster-r7 – Improve msfconsole’s module search performance by caching search regexes.
  • #19887 from adfoster-r7 – Updates the reload_lib command to ignore Gemfiles.

Bugs fixed (3)

  • #19810 from h00die – Adds a verification to the file content checks so that we don’t crash when trying to open files that do not exist and adds proper CVE to references section now that a CVE exists.
  • #19871 from bwatters-r7 – This fix the ELF template file for Linux aarch64 payloads.
  • #19875 from dledda-r7 – Adds a fix for the odd behavior of the read syscall on Raspberrypi 4b. For some reason, on the Raspberry Pi 4B, the data read from the socket is not present immediately after the read syscall, so we added a sync syscall. This behavior is not present in Raspberry Pi 3, Raspberry Pi 5, emulators, or Microsoft’s AARCH64 Devkit.

Documentation

You can find the latest Metasploit documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate
and you can get more details on the changes since the last blog post from
GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest.
To install fresh without using git, you can use the open-source-only Nightly Installers or the
commercial edition Metasploit Pro

Going 800Gbps at up to 1000km with the Marvell COLORZ 800

Post Syndicated from Patrick Kennedy original https://www.servethehome.com/going-800gbps-at-up-to-1000km-with-the-marvell-colorz-iii-800g-zr-osfp/

We take a look at how the Marvell COLORZ 800 can transmit data at 800Gbps across 1000km and get behind the scenes lab access

The post Going 800Gbps at up to 1000km with the Marvell COLORZ 800 appeared first on ServeTheHome.

From log analysis to rule creation: How AWS Network Firewall automates domain-based security for outbound traffic

Post Syndicated from Mary Kay Sondecker original https://aws.amazon.com/blogs/security/from-log-analysis-to-rule-creation-how-aws-network-firewall-automates-domain-based-security-for-outbound-traffic/

When it comes to controlling incoming (ingress) and outgoing (egress) network traffic, organizations typically focus heavily on inbound traffic controls—carefully restricting what traffic can enter their network perimeter. However, this approach addresses only inbound security challenges. Modern applications rely heavily on third-party code through operating systems, libraries, and packages. This dependency can create potential security vulnerabilities. If these components are compromised, affected workloads might attempt to connect to unauthorized command and control servers or send sensitive data to unauthorized destinations on the internet.

This is why implementing strong outbound traffic controls—particularly through domain-based allowlisting—has become a critical security best practice. Rather than allowing unrestricted outbound access or maintaining an ever-growing denylist of low-reputation domains, many organizations are shifting to domain-based allowlisting. This approach restricts outbound communications to explicitly trusted domains, reduces potential risk surfaces, and helps to protect against both known and unknown threats. However, manually identifying and maintaining these allowlists has traditionally been a complex and time-consuming process.

AWS Network Firewall automated domain lists improve visibility into network traffic patterns and simplify outbound traffic control management. This feature provides analytics for HTTP and HTTPS network traffic, helping organizations understand domain usage patterns. It also automates firewall log analysis to create rules based on your network traffic. By combining increased visibility with automation, this feature enhances your security awareness and helps to improve the effectiveness of your firewall rules.

In this blog post, we’ll guide you through the implementation of the AWS Network Firewall automated domain list feature, providing a detailed overview, step-by-step instructions, and best practices to optimize your network security.

Overview of automated domain lists and traffic insights

Domain-based security allows you to control network traffic based on the domain names that your applications and users are trying to access. This approach offers a more intuitive and flexible way to create firewall rules, focusing on the destinations your network is trying to reach rather than just IP addresses. However, effectively configuring and managing firewall rules remains challenging for some customers, especially in large environments where connected devices, applications, and traffic patterns are continuously growing and changing. Organizations might struggle to keep up with these changes, leading to outdated or ineffective firewall rules and policies that are either too permissive, exposing the network to risks, or too restrictive, blocking legitimate traffic.

Let’s explore how automated domain lists address these challenges through various use cases and benefits:

Preventive and detective security controls

  1. Domain control through allowlisting – Establishing domain allowlists aligns with the security principle of least privilege for network traffic. A least-privilege model adjusts the scope of what a workload can do across the network, from infinite and undefined to scoped-down and well-defined, enabling better insight into potentially risky behaviors. By limiting outbound connections to only approved domains, organizations can more effectively control and monitor workload communications.
  2. Rule audit and compliance – Domain allowlisting makes it clear which domains are allowed, supporting alignment with standards like the Payment Card Industry Data Security Standard (PCI DSS), Health Insurance Portability and Accountability Act (HIPAA), Cybersecurity Maturity Model Certification (CMMC), and General Data Protection Regulation (GDPR).
  3. Preventive controls enable detection – Preventive controls also act as detective controls, establishing a baseline for normal domain access patterns. With a domain allowlist in place, security teams can better detect workloads that show signs of unauthorized activity.
  4. Incident response support – Domain reporting provides the latest list of workload domains accessed, enabling quick identification of potentially malicious domains during security incidents. This information helps teams prioritize which workloads may need immediate attention.

Operational value

  1. Initial firewall setup and management – Automated allowlisting involves analyzing existing traffic patterns and recommending domain-based rules, which simplifies the process of establishing baseline firewall rules. This helps organizations quickly deploy effective security policies, potentially reducing the time and expertise needed for initial firewall configuration and ongoing management.
  2. Application modernization – Allowlisting supports adjusting firewall rules to accommodate rapidly changing traffic patterns in microservices and containerized environments, helping security to keep pace with evolving architectures.
  3. Cross-environment consistency – Allowlisting enables consistent firewall rule creation and management across multi-cloud and hybrid environments, regardless of where applications or data reside.

How the automated domain list feature works

Automated domain lists work by analyzing your HTTP and HTTPS traffic, generating reports on frequently accessed domains, and providing a convenient way to create rules based on actual network traffic patterns. To begin using automated domain lists in AWS Network Firewall, sign in to the AWS Management Console, access the Network Firewall service, and either work with an existing firewall or create a new one. Then follow the rest of the steps in this post.

Step 1: Enable traffic analysis mode to capture HTTP and HTTPS traffic domain logs

After you’ve selected a firewall, in the left navigation pane, choose Configure advanced settings. Select the Enable traffic analysis mode checkbox to enable it, as shown in Figure 1. Network Firewall uses this logging mode to collect data on observed domains for HTTP and HTTPS traffic to create domain reports.

Figure 1: Enabling traffic analysis mode for a firewall

Figure 1: Enabling traffic analysis mode for a firewall

To stop collecting data on frequently accessed domains in your network traffic, clear the checkbox to disable traffic analysis mode, as shown in Figure 2. Note that if you disable traffic analysis mode, you won’t be able to generate domain reports.

Figure 2: Disabling traffic analysis mode

Figure 2: Disabling traffic analysis mode

Once traffic analysis mode is enabled, you’re ready to generate a domain report based on observed network traffic. Next, you can go to the Monitoring and observability tab and choose Create report.

Figure 3: Traffic analysis mode enabled: Now you’re ready to generate domain-based reports

Figure 3: Traffic analysis mode enabled: Now you’re ready to generate domain-based reports

Step 2: Create a domain report

The domain report summarizes the HTTP and HTTPS traffic observed by your firewall for up to 30 days (or for the duration since firewall activation if less than 30 days). Select the checkbox next to each traffic analysis type you want to include in the report—HTTP, HTTPS, or both.

Important: Use your monthly domain report to examine 30 days of traffic behavior. Each report type (HTTP, HTTPS) is available once every 30 days at no additional cost.

Figure 4: Create a domain report that includes traffic analysis types HTTP, HTTPS, or both

Figure 4: Create a domain report that includes traffic analysis types HTTP, HTTPS, or both

To see the status of your domain report, go to the Reports section in the console for your specific firewall. When the report is ready, you can review the report directly in the console or download it, as shown in Figure 5.

Figure 5: The list of domain reports in the Reports section of the console for your specific firewall

Figure 5: The list of domain reports in the Reports section of the console for your specific firewall

Step 3: Review the report details

The report details include the traffic type (HTTP or HTTPS) and the observation period (start and end dates). By default, the report covers the last 30 days, or the entire period since traffic analysis was enabled if that is less than 30 days. The report also shows these details:

  • The Domain list shows domains that are a fully qualified domain name (FQDN) observed in the network traffic, such as aws.com or subdomain.aws.com.
  • The Access attempt count refers to the overall count of connection requests to the domain, including both successful and failed attempts.
  • The Unique sources field shows the number of distinct source IP addresses connected to the domain, indicating its popularity. For example, if one workload connects to aws.com, then count = 1; if 1000 workloads connect to aws.com, then count = 1,000.
  • The First accessed field shows when the domain was first seen in your traffic, while Last accessed shows when it was most recently seen. This includes both successful and failed attempts to access the domain.
  • The Protocol field indicates how the domain was observed—through either HTTP or HTTPS traffic (in other words, HTTP headers or a TLS handshake).

An example report is shown in Figure 6.

Figure 6: Example domain report details: 30-day analysis

Figure 6: Example domain report details: 30-day analysis

Step 4: (Optional) Create a domain list rule group

You can copy the list of observed domains from the report to a stateful domain list rule group and update your firewall policy. To do so, in the Report details section, choose Create domain list group to use the firewall policy wizard to create or update your firewall rules. The selected domains are automatically copied to a domain list rule group, as shown in Figure 7. For detailed instructions, see the AWS Network Firewall documentation.

Figure 7: Option to copy over the observed domain lists and create a domain list rule group using the firewall policy wizard

Figure 7: Option to copy over the observed domain lists and create a domain list rule group using the firewall policy wizard

Best practices for implementing domain allowlists

When you implement domain allowlisting, consider the following guidelines for operational success. We recommend that you also consult your own internal compliance and security policies.

  1. Start with a strategy of generous allowlisting:
    • Begin with broader and more generous allowlist rules rather than a more refined list, initially, to reduce the risk of accidently blocking legitimate domains.
    • Focus on getting to a Default Deny policy so that you can benefit from its risk surface reduction.
    • Create flexible rules for trusted domains, including second-level domains and top-level domains, such as allowing access to subdomains under your registered second-level domain. Or allow access to second-level domains under top-level domains that your organization trusts—for example, .mil, .gov, or .edu.
    • Use custom Suricata rules with regex capabilities to handle complex traffic efficiently. See Examples of stateful rules for Network Firewall.
    • Remember that even a broad allowlist provides better security than having no allowlist at all.
  2. Make iterative improvements:
    • After you establish an initial generous allowlist and Default Deny rules, evaluate the rules to determine which areas you might want to start narrowing down further. Use alert rules before pass rules in order to log the specific domains a pass rule might be allowing access to.
    • Adjust logging levels based on domain trust levels and monitoring requirements.
    • Review and update rules based on operational insights and changing requirements.
    • Take a pragmatic and iterative approach to rule refinement rather than attempting to make the ruleset very strict.
  3. Set up robust logging:
  4. Additional considerations:
    • After you enable traffic analysis mode, the automated domain lists feature provides visibility into your network traffic, reporting on observed connections. Although it doesn’t distinguish between allowed and blocked traffic, the domain list report can help you identify the most critical domains to include in your firewall rules.
    • The domain traffic data used to generate the list of domain recommendations is available for up to the last 30 days after traffic analysis has been enabled. This allows you to focus on the most relevant and recent network activity when optimizing your firewall policies.
    • Data collection for automated domain lists is opt-in and performed independently of the firewall policy and logging configuration. Enabling the feature doesn’t impact the performance of the firewall itself.

Conclusion

With AWS Network Firewall automated domain lists, you can simplify your firewall management process, create more effective rules based on actual traffic patterns, and maintain a strong security posture with less manual effort. This feature helps you address common challenges such as keeping up with rapidly changing application landscapes, managing security across complex environments, and adhering to compliance requirements. To learn more about Network Firewall and its features, see the product page and service documentation.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the AWS Network Firewall re:Post forum or contact AWS Support.
 

Mary Kay Sondecker
Mary Kay Sondecker

Mary Kay is a Senior Product Manager at AWS, focused on AWS Network Firewall. With over two decades of experience in the technology industry, she is passionate about helping customers easily implement effective, scalable cloud solutions to drive better business outcomes.
Jesse Lepich
Jesse Lepich

Jesse is a Senior Security Solutions Architect at AWS based in Lake St. Louis, Missouri, focused on helping customers implement native AWS security services. Outside of cloud security, his interests include relaxing with family, barefoot waterskiing, snowboarding and snow skiing, surfing, boating, and mountain climbing.
Michael Leighty
Michael Leighty

Michael is a Senior Security Solutions Architect at AWS, based in Atlanta. He specializes in helping customers design and implement effective network security controls, drawing from extensive experience at leading network security vendors. At AWS, he works closely with service teams to drive continuous improvement in security services based on customer needs and feedback.
Jason Goode
Jason Goode

Jason is a Senior Security GTM Content Specialist at AWS, where he develops content strategies that bridge technical concepts with practical business solutions. Based in Austin, Texas, he leverages his creative background and expertise to help organizations understand and use native AWS security services.

[$] Multi-host testing with the pytest-mh framework

Post Syndicated from jzb original https://lwn.net/Articles/1007724/

The pytest-mh
project is a plugin that provides a multi-host test framework for the
popular pytest
unit-testing framework and test runner. Work on pytest-mh
started in 2023 to solve a multitude of issues that
cropped up for developers and testers when testing the SSSD project, which is a client for
enterprise identity management. I was not happy with the state of
testing of the SSSD project and wanted to create something that would
increase test readability, remove duplication, eliminate errors, and
provide multi-host testing capabilities, while having the flexibility
to build a new API around it. Finally, I also wanted something that
can be used by anyone to test their projects as well.

2025-02-21 разни openfest-овски

Post Syndicated from Vasil Kolev original https://vasil.ludost.net/blog/?p=3497

Още се освестявам от FOSDEM, но вече можем да движим някакви неща около OpenFest – имаме си дати (17-18 октомври), имаме разни забавни идеи и малко по малко време да ги правим.

Едното нещо е, че си сменяме системата за submit-ване на лекции към pretalx. След като дълги години изборът беше pentabarf (чиито сайт даже вече го няма) или да си пишем нещо (както имахме clarion за OpenFest), сега вече има нормално работеща система, която CCC и FOSDEM са проходили доста добре, и успява да свърши работа. Тази година ползвах pretalx-а на FOSDEM и бях приятно изненадан колко човешко е като интерфейс и функционалност.

Та, ако на някой му е скучно, сме започнали превод в translate.pretalx.com. Има 1500 неща за превод, от които в последните дни сме превели около 150.
(а няма начин да пуснем системата за самия фест без български без да бъда линчуван)

Има и разни интересни нововъведения за CfP-то и програмата, но тях ще ги разкажа като ги случим 🙂

The collective thoughts of the interwebz