Metasploit Weekly Wrap-Up 08/02/2024

Post Syndicated from Zachary Goldman original https://blog.rapid7.com/2024/08/02/metasploit-weekly-wrap-up-08-02-2024/

Metasploit goes to Hacker Summer Camp

Metasploit Weekly Wrap-Up 08/02/2024

Next week, Metasploit will have demos at both Black Hat and DEF CON where the latest functionality from this year will be presented. The Black Hat demo will be on Thursday the 8th from 10:10 to 11:25 and the DEF CON demo will be on Saturday the 10th from 12:00 to 13:45.

The highlights will include demonstrations of:

New module content (2)

OpenMediaVault rpc.php Authenticated Cron Remote Code Execution

Authors: Brandon Perry [email protected] and h00die-gr3y [email protected]
Type: Exploit
Pull request: #19298 contributed by h00die-gr3y
Path: unix/webapp/openmediavault_auth_cron_rce
AttackerKB reference: CVE-2013-3632

Description: This adds a new module that leverages a vulnerability in OpenMediaVault versions starting from 1.0 until the recent release 7.4.2-2. This vulnerability (CVE-2013-3632) allows an authenticated user to create cron jobs as root on the system and achieve remote code execution.

mySCADA MyPRO Authenticated Command Injection (CVE-2023-28384)

Author: Michael Heinzl
Type: Exploit
Pull request: #19337 contributed by h4x-x0r
Path: windows/scada/mypro_cmdexe
AttackerKB reference: CVE-2023-28384

Description: This adds an exploit module for CVE-2023-28384, a command injection vulnerability in MySCADA MyPRO versions before and including 2.28 allowing the execution of arbitrary commands as NT AUTHORITY\SYSTEM.

Enhanced Modules (2)

Modules which have either been enhanced, or renamed:

  • #19331 from Takahiro-Yoko – This update the linux/http/empire_skywalker exploit module to add a new technique that leverages a path traversal vulnerability in BC Security Empire versions before 5.9.3 (CVE-2024-6127). An attacker can achieve unauthenticated remote code execution over HTTP by acting as a normal agent. It is still possible to use this module with older versions from ProjectEmpire/Empire by setting a specific datastore option.
  • #19344 from jheysel-r7 – This updates the windows/http/forticlient_ems_fctid_sqli exploit module to gain code execution on FortiClient EMS FCTID for the affected version within the range 7.2.x.

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

Metasploit Weekly Wrap-Up 08/02/2024

Amazon OpenSearch Serverless cost-effective search capabilities, at any scale

Post Syndicated from Satish Nandi original https://aws.amazon.com/blogs/big-data/amazon-opensearch-serverless-cost-effective-search-capabilities-at-any-scale/

We’re excited to announce the new lower entry cost for Amazon OpenSearch Serverless. With support for half (0.5) OpenSearch Compute Units (OCUs) for indexing and search workloads, the entry cost is cut in half. Amazon OpenSearch Serverless is a serverless deployment option for Amazon OpenSearch Service that you can use to run search and analytics workloads without the complexities of infrastructure management, shard tuning or data lifecycle management. OpenSearch Serverless automatically provisions and scales resources to provide consistently fast data ingestion rates and millisecond query response times during changing usage patterns and application demand. 

OpenSearch Serverless offers three types of collections to help meet your needs: Time-series, search, and vector. The new lower cost of entry benefits all collection types. Vector collections have come to the fore as a predominant workload when using OpenSearch Serverless as an Amazon Bedrock knowledge base. With the introduction of half OCUs, the cost for small vector workloads is halved. Time-series and search collections also benefit, especially for small workloads like proof-of-concept deployments and development and test environments.

A full OCU includes one vCPU, 6GB of RAM and 120GB of storage. A half OCU offers half a vCPU, 3 GB of RAM, and 60 GB of storage. OpenSearch Serverless scales up a half OCU first to one full OCU and then in one-OCU increments. Each OCU also uses Amazon Simple Storage Service (Amazon S3) as a backing store; you pay for data stored in Amazon S3 regardless of the OCU size. The number of OCUs needed for the deployment depends on the collection type, along with ingestion and search patterns. We will go over the details later in the post and contrast how the new half OCU base brings benefits. 

OpenSearch Serverless separates indexing and search computes, deploying sets of OCUs for each compute need. You can deploy OpenSearch Serverless in two forms: 1) Deployment with redundancy for production, and 2) Deployment without redundancy for development or testing.

Note: OpenSearch Serverless deploys two times the compute for both indexing and searching in redundant deployments.

OpenSearch Serverless Deployment Type

The following figure shows the architecture for OpenSearch Serverless in redundancy mode.

In redundancy mode, OpenSearch Serverless deploys two base OCUs for each compute set (indexing and search) across two Availability Zones. For small workloads under 60GB, OpenSearch Serverless uses half OCUs as the base size. The minimum deployment is four base units, two each for indexing and search. The minimum cost is approximately $350 per month (four half OCUs). All prices are quoted based on the US-East region and 30 days a month. During normal operation, all OCUs are in operation to serve traffic. OpenSearch Serverless scales up from this baseline as needed.

For non-redundant deployments, OpenSearch Serverless deploys one base OCU for each compute set, costing $174 per month (two half OCUs).

Redundant configurations are recommended for production deployments to maintain availability; if one Availability Zone goes down, the other can continue serving traffic. Non-redundant deployments are suitable for development and testing to reduce costs. In both configurations, you can set a maximum OCU limit to manage costs. The system will scale up to this limit during peak loads if necessary, but will not exceed it.

OpenSearch Serverless collections and resource allocations

OpenSearch Serverless uses compute units differently depending on the type of collection and keeps your data in Amazon S3. When you ingest data, OpenSearch Serverless writes it to the OCU disk and Amazon S3 before acknowledging the request, making sure of the data’s durability and the system’s performance. Depending on collection type, it additionally keeps data in the local storage of the OCUs, scaling to accommodate the storage and computer needs.

The time-series collection type is designed to be cost-efficient by limiting the amount of data kept in local storage, and keeping the remainder in Amazon S3. The number of OCUs needed depends on amount of data and the collection’s retention period. The number of OCUs OpenSearch Serverless uses for your workload is the larger of the default minimum OCUs, or the minimum number of OCUs needed to hold the most recent portion of your data, as defined by your OpenSearch Serverless data lifecycle policy. For example, if you ingest 1 TiB per day and have 30 day retention period, the size of the most recent data will be 1 TiB. You will need 20 OCUs [10 OCUs x 2] for indexing and another 20 OCUS [10 OCUs x 2] for search (based on the 120 GiB of storage per OCU). Access to older data in Amazon S3 raises the latency of the query responses. This tradeoff in query latency for older data is done to save on the OCUs cost.

The vector collection type uses RAM to store vector graphs, as well as disk to store indices. Vector collections keep index data in OCU local storage. When sizing for vector workloads both needs into account. OCU RAM limits are reached faster than OCU disk limits, causing vector collections to be bound by RAM space. 

OpenSearch Serverless allocates OCU resources for vector collections as follows. Considering full OCUs, it uses 2 GB for the operating system, 2 GB for the Java heap, and the remaining 2 GB for vector graphs. It uses 120 GB of local storage for OpenSearch indices. The RAM required for a vector graph depends on the vector dimensions, number of vectors stored, and the algorithm chosen. See Choose the k-NN algorithm for your billion-scale use case with OpenSearch for a review and formulas to help you pre-calculate vector RAM needs for your OpenSearch Serverless deployment.

Note: Many of the behaviors of the system are explained as of June 2024. Check back in coming months as new innovations continue to drive down cost.

Supported AWS Regions

The support for the new OCU minimums for OpenSearch Serverless is now available in all regions that support OpenSearch Serverless. See AWS Regional Services List for more information about OpenSearch Service availability. See the documentation to learn more about OpenSearch Serverless.

Conclusion

The introduction of half OCUs gives you a significant reduction in the base costs of Amazon OpenSearch Serverless. If you have a smaller data set, and limited usage, you can now take advantage of this lower cost. The cost-effective nature of this solution and simplified management of search and analytics workloads ensures seamless operation even as traffic demands vary.

About the authors 

Satish Nandi is a Senior Product Manager with Amazon OpenSearch Service. He is focused on OpenSearch Serverless and Geospatial and has years of experience in networking, security and ML and AI. He holds a BEng in Computer Science and an MBA in Entrepreneurship. In his free time, he likes to fly airplanes, hang glide, and ride his motorcycle.

Jon Handler is a Senior Principal Solutions Architect 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 that they want to move to the AWS Cloud. 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 of Science and a Ph. D. in Computer Science and Artificial Intelligence from Northwestern University.

Improve Apache Kafka scalability and resiliency using Amazon MSK tiered storage

Post Syndicated from Sai Maddali original https://aws.amazon.com/blogs/big-data/improve-apache-kafka-scalability-and-resiliency-using-amazon-msk-tiered-storage/

Since the launch of tiered storage for Amazon Managed Streaming for Apache Kafka (Amazon MSK), customers have embraced this feature for its ability to optimize storage costs and improve performance. In previous posts, we explored the inner workings of Kafka, maximized the potential of Amazon MSK, and delved into the intricacies of Amazon MSK tiered storage. In this post, we deep dive into how tiered storage helps with faster broker recovery and quicker partition migrations, facilitating faster load balancing and broker scaling.

Apache Kafka availability

Apache Kafka is a distributed log service designed to provide high availability and fault tolerance. At its core, Kafka employs several mechanisms to provide reliable data delivery and resilience against failures:

  • Kafka replication – Kafka organizes data into topics, which are further divided into partitions. Each partition is replicated across multiple brokers, with one broker acting as the leader and the others as followers. If the leader broker fails, one of the follower brokers is automatically elected as the new leader, providing continuous data availability. The replication factor determines the number of replicas for each partition. Kafka maintains a list of in-sync replicas (ISRs) for each partition, which are the replicas that are up to date with the leader.
  • Producer acknowledgments – Kafka producers can specify the required acknowledgment level for write operations. This makes sure the data is durably persisted on the configured number of replicas before the producer receives an acknowledgment, reducing the risk of data loss.
  • Consumer group rebalancing – Kafka consumers are organized into consumer groups, where each consumer in the group is responsible for consuming a subset of the partitions. If a consumer fails, the partitions it was consuming are automatically reassigned to the remaining consumers in the group, providing continuous data consumption.
  • Zookeeper or KRaft for cluster coordination – Kafka relies on Apache ZooKeeper or KRaft for cluster coordination and metadata management. It maintains information about brokers, topics, partitions, and consumer offsets, enabling Kafka to recover from failures and maintain a consistent state across the cluster.

Kafka’s storage architecture and its impact on availability and resiliency

Although Kafka provides robust fault-tolerance mechanisms, in the traditional Kafka architecture, brokers store data locally on their attached storage volumes. This tight coupling of storage and compute resources can lead to several issues, impacting availability and resiliency of the cluster:

  • Slow broker recovery – When a broker fails, the recovery process involves transferring data from the remaining replicas to the new broker. This data transfer can be slow, especially for large data volumes, leading to prolonged periods of reduced availability and increased recovery times.
  • Inefficient load balancing – Load balancing in Kafka involves moving partitions between brokers to distribute the load evenly. However, this process can be resource-intensive and time-consuming, because it requires transferring large amounts of data between brokers.
  • Scaling limitations – Scaling a Kafka cluster traditionally involves adding new brokers and rebalancing partitions across the expanded set of brokers. This process can be disruptive and time-consuming, especially for large clusters with high data volumes.

How Amazon MSK tiered storage improves availability and resiliency

Amazon MSK offers tiered storage, a feature that allows configuring local and remote tiers. This greatly decouples compute and storage resources and thereby addresses the aforementioned challenges, improving availability and resiliency of Kafka clusters. You can benefit from the following:

  • Faster broker recovery – With tiered storage, data automatically moves from the faster Amazon Elastic Block Store (Amazon EBS) volumes to the more cost-effective storage tier over time. New messages are initially written to Amazon EBS for fast performance. Based on your local data retention policy, Amazon MSK transparently transitions that data to tiered storage. This frees up space on the EBS volumes for new messages. When broker fails and recovers either due to node or volume failure, the catch-up is faster because it only needs to catch up data stored on the local tier from the leader.
  • Efficient load balancing – Load balancing in Amazon MSK with tiered storage is more efficient because there is less data to move while reassigning partition. This process is faster and less resource-intensive, enabling more frequent and seamless load balancing operations.
  • Faster scaling – Scaling an MSK cluster with tiered storage is a seamless process. New brokers can be added to the cluster without the need for a large amount of data transfer and longer time for partition rebalancing. The new brokers can start serving traffic much faster, because the catch-up process takes less time, improving the overall cluster throughput and reducing downtime during scaling operations.

As shown in the following figure, MSK brokers and EBS volumes are tightly coupled. On a three-AZ deployed cluster, when you create a topic with replication factor three, Amazon MSK spreads those three replicas across all three Availability Zones and the EBS volumes attached with that broker store all the topic data spread across three Availability Zones. If you need to move a partition from one broker to another, Amazon MSK needs to move all the segments (both active and closed) from the existing broker to the new brokers, as illustrated in the following figure.

However, when you enable tiered storage for that topic, Amazon MSK transparently moves all closed segments for a topic from EBS volumes to tiered storage. That storage provides the built-in capability for durability and high availability with virtually unlimited storage capacity. With closed segments moved to tiered storage and only active segments on the local volume, your local storage footprint remains minimal regardless of topic size. If you need to move the partition to a new broker, the data movement is very minimal across the brokers. The following figure illustrates this updated configuration.

Amazon MSK tiered storage addresses the challenges posed by Kafka’s traditional storage architecture, enabling faster broker recovery, efficient load balancing, and seamless scaling, thereby improving availability and resiliency of your cluster. To learn more about the core components of Amazon MSK tiered storage, refer to Deep dive on Amazon MSK tiered storage.

A real-world test

We hope that you now understand how Amazon MSK tiered storage can improve your Kafka resiliency and availability. To test it, we created a three-node cluster with the new m7g instance type. We created a topic with a replication factor of three and without using tiered storage. Using the Kafka performance tool, we ingested 300 GB of data into the topic. Next, we added three new brokers to the cluster. Because Amazon MSK doesn’t automatically move partitions to these three new brokers, they will remain idle until we rebalance the partitions across all six brokers.

Let’s consider a scenario where we need to move all the partitions from the existing three brokers to the three new brokers. We used the kafka-reassign-partitions tool to move the partitions from the existing three brokers to the newly added three brokers. During this partition movement operation, we observed that the CPU usage was high, even though we weren’t performing any other operations on the cluster. This indicates that the high CPU usage was due to the data replication to the new brokers. As shown in the following metrics, the partition movement operation from broker 1 to broker 2 took approximately 75 minutes to complete.

Additionally, during this period, CPU utilization was elevated.

After completing the test, we enabled tiered storage on the topic with local.retention.ms=3600000 (1 hour) and retention.ms=31536000000. We continuously monitored the RemoteCopyBytesPerSec metrics to determine when the data migration to tiered storage was complete. After 6 hours, we observed zero activity on the RemoteCopyBytesPerSec metrics, indicating that all closed segments had been successfully moved to tiered storage. For instructions to enable tiered storage on an existing topic, refer to Enabling and disabling tiered storage on an existing topic.

We then performed the same test again, moving partitions to three empty brokers. This time, the partition movement operation was completed in just under 15 minutes, with no noticeable CPU usage, as shown in the following metrics. This is because, with tiered storage enabled, all the data has already been moved to the tiered storage, and we only have the active segment in the EBS volume. The partition movement operation is only moving the small active segment, which is why it takes less time and minimal CPU to complete the operation.

Conclusion

In this post, we explored how Amazon MSK tiered storage can significantly improve the scalability and resilience of Kafka. By automatically moving older data to the cost-effective tiered storage, Amazon MSK reduces the amount of data that needs to be managed on the local EBS volumes. This dramatically improves the speed and efficiency of critical Kafka operations like broker recovery, leader election, and partition reassignment. As demonstrated in the test scenario, enabling tiered storage reduced the time taken to move partitions between brokers from 75 minutes to just under 15 minutes, with minimal CPU impact. This enhanced the responsiveness and self-healing ability of the Kafka cluster, which is crucial for maintaining reliable, high-performance operations, even as data volumes continue to grow.

If you’re running Kafka and facing challenges with scalability or resilience, we highly recommend using Amazon MSK with the tiered storage feature. By taking advantage of this powerful capability, you can unlock the true scalability of Kafka and make sure your mission-critical applications can keep pace with ever-increasing data demands.

To get started, refer to Enabling and disabling tiered storage on an existing topic. Additionally, check out Automated deployment template of Cruise Control for Amazon MSK for effortlessly rebalancing your workload.

About the Authors

Sai Maddali is a Senior Manager Product Management at AWS who leads the product team for Amazon MSK. He is passionate about understanding customer needs, and using technology to deliver services that empowers customers to build innovative applications. Besides work, he enjoys traveling, cooking, and running.

Nagarjuna Koduru is a Principal Engineer in AWS, currently working for AWS Managed Streaming For Kafka (MSK). He led the teams that built MSK Serverless and MSK Tiered storage products. He previously led the team in Amazon JustWalkOut (JWO) that is responsible for real time tracking of shopper locations in the store. He played pivotal role in scaling the stateful stream processing infrastructure to support larger store formats and reducing the overall cost of the system. He has keen interest in stream processing, messaging and distributed storage infrastructure.

Masudur Rahaman Sayem is a Streaming Data Architect at AWS. He works with AWS customers globally to design and build data streaming architectures to solve real-world business problems. He specializes in optimizing solutions that use streaming data services and NoSQL. Sayem is very passionate about distributed computing.

Триизмерна карта на бъдещото строителство в София

Post Syndicated from Боян Юруков original https://yurukov.net/blog/2024/sgradite-sofia/

През декември направих пилотен проект, в който отбелязах на триизмерна карта всички сгради в район Изгрев, София, които са предвидени да се построят. Целта ми беше да разширя картата с документите за строителството, която макар и полезна, не дава добра представа за измеренията на промените.

От тогава се случиха няколко неща. Първо се свързах с новата администрация на Столична община с цел съвместна работа. Първи резултат от това, че направих за тях вариация на картата ми с документите, но показваща само планираните промени на ПУП. Линк към картата ще намерите на страницата с регистъра на съответните документи. Това е важно, тъй като тези решения са първата индикация, че някъде нещо ще се строи и съответно е най-ранния момент, в който хората загрижени за градската среда биха могли да повлияят. Ключова роля тук играят районните кметове и архитекти, които публикуват документите.

Картата на общината с отбелязани места, където има промени по ПУП

Картата се развива постоянно и ще пиша скоро подробно за нея. Като част от нея добавих експерименталния триизмерен слой специално за очакваното височинно застрояване на парцелите засегнати от ПУП-овете. След това реших да копирам същата функционалност и на основната ми карта.

Данните обаче бяха проблем – не може да се изведат автоматично и се наложи да ги въвеждам на ръка, както правих през декември. Сега обаче си направих инструмент, с който това става много по-бързо и точно. Включително мога да го правя на телефона между другото. За няколко дни събирах по няколко стотин сгради на ден из целия град. До тук бих казал, че съм покрил всичко в районите Лозенец, Изгрев, Сердика и оборище. Въвел съм и сгради, които са мащабни или са ми направили впечатление из града. Ще продължа с Овча купел и Люлин преди да продължа към другите.

Условностите на данните

Преди да ви покажа самата карта, трябва да минем през задължителното за мен описание какво не е наред в картата ми и данните.

Първо, рисувам основите на сградите на ръка върху комбинираните слоеве на застрояване от iSofMap на ГИС София, след което въвеждам височината според посочените метри или етажи. Тези слоеве от своя страна се въвеждат от оператори във фирмата на база документи и скици. Не всички документи имат скици, не винаги това, което е въведено е актуално и слоевете се променят постоянно. В този смисъл ще намерите сгради, които са одобрени или дори построени вече в друга форма или височина. В първа фаза ще въвеждам това, което има на слоя, а нататък ще разширя инструмента да зарежда последните скици и да ги позиционира правилно на слоя, за да въвеждам правилната форма на сградите.

Тъй като чертая на ръка, не винаги границите на сградата са точни, а по-ниски съпътстващи постройки или снишения на сградата липсват. Тъй като използвам фотореалистични 3D карти на Google, вижда се лесно, че изображенията и сградите там са от преди година. Тоест някои от вече построените сгради, които ще видите на улицата, не са на тази карта. В такива случаи ги отбелязвам, за да са видими. Когато Google обновят снимките, ще ги махна.

Това, че на някое място е отбелязана сграда с дадена височина или площ, не означава, че непременно ще бъде застроено по този начин. Тези скици посочват какво е предвидено/заявено или разрешено на това място. Параметрите може да се променят при визите, при обратна връзка от обществото и районните кметове или при разрешението за строеж. Може да се намали като площ, но да се вдигнат етажите. Това, че нещо е предвидено обаче не значи, че ще се построи някога. Това може да е заради проблеми със собствеността, съдебни дела или просто защото собственикът иска да живее в хубава двуетажна къща и няма намерение да вдига 5 етажен блок. Не на последно място – посочените измерения са по-скоро външните очертания. В зависимост от кинт и други параметри е възможно части от сградата да са по-малки, други да са покриви и паркинги и прочие. Някои от отбелязаните сгради може да са и индустриални.

Картата, която ще споделя, не е обвързана с общината или НАГ и не претендира за точност. Целта ѝ е да даде представа къде какво ще се строи и колко високо, тъй като дори с първата ми карта, това е изключително трудно. Ще добавя всички сгради в града преди да започна с конкретните документи. Новите сгради се появяват веднага на картата, така че очаквайте нещо ново всеки път като я отворите. Ако видите нещо, което не е така, оставете коментар.

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

Изглед към горната част на бул. Черни връх

Бъдещото строителство в София

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

От години се ровя в разрешителни, ПУП-ове и визи, но нямах идея за някои от сградите. Например не знаех за 200 метровите кули срещу мол Парадайз и нагоре по бул. Цар Борис III от Пирогов. Не знаех за 130 метровата кула по Тодор Александров и въобще какви стени от сгради се готвят от двете страни на този булевард. Бях виждал снимки на плановете около Централна гара, но не осъзнавах мащабите или че ще има още една 100 метрова кула зад нея. В централната чат има десетки къщи, някои отбелязани като паметници на културата, които са предвидени да се бутат и застрояват с четири, пет и дори шест етажни сгради. В долната част на Лозенец положението е по-добре, но в горната и въобще около южната дъга е вече презастроено, а се предвиждат двойно повече сгради. Аналогично по бул. България.

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

Изглед към бул. Тодор Александров.

В същото време основният проблем тук е в местната и централната власт. Започваме с решенията на СОС за безразборна продажба на общинска собственост – данните за която най-яростно пазената тайна в Столична община. Следва и отлагането на придобиване на ключови имоти за градини, училища и паркове. Решения на СОС могат да изменят регулация и планове, но това се блокира умишлено от години. Това важи както за интензивността, така и за фасадите, стратегия, достъпност и визия града. Главният архитект има ключова роля в този процес, но при липса на такава визия до сега тази роля е била обвързвана само със скандали.

Илюстрация за сенчестите сделки в СОС, които все още виждаме е, че доста от парцелите предвидени за строителство в слоя на НАГ, са общинска собственост. Такова е например пространството между Японския хотел и небезизвестната сграда Златен век. Там на четири парцела общинска частна собственост вече е отбелязана 22 етажна сграда – на метри от прозорците на Златен век. Никой до сега не е успял да ми отговори как става това, а още от години питам за няколко такива случая в Дианабад. Предполага се, че са обещани на някого от години и се чака изгодна политическа ситуация, което беше спънато отчасти с последните избори.

От народното събрание пък зависи как релевантните нормативни актове ще оформят граници на тези стратегии и категоризация. Единственото съществено, което знаем, че се е случило, е промени позволяващи кули където и да е и носещи името на небезизвестен строителен инвеститор и корупционен скандал с политици осигурили тези промени. Впрочем, именно те и практиките им са причината въобще да започна да се вглеждам в темата, така че може да се радват, че са допринесли неволно към този и другите ми проекти, както и всичко останало по темата, което още не съм изкарал.

Триизмерната карта със сградите ще намерите като функция на картата с документите от НАГ натискайки бутона с кубче. Може да я достъпите и директно на http://govalert.eu/cityplan/buildings. В началото ще се отвори указание как се контролира. Най-общо казано използвайте два пръста на екран с докосване или мишка + Ctrl на компютър. Предупреждавам, че използва доста трафик и процесор – може да имате проблеми на по-стари телефони. Ще се радвам на обратна връзка.

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

The post Триизмерна карта на бъдещото строителство в София first appeared on Блогът на Юруков.

[$] Divvi Up: privacy-respecting telemetry aggregation

Post Syndicated from daroc original https://lwn.net/Articles/983843/

There is ongoing discussion about the ethics and effectiveness of
telemetry following some recent LWN articles that touched on

Thunderbird’s use of opt-out
telemetry and planned metrics in Fedora. The

Internet Security Research Group (ISRG), the nonprofit behind

Let’s Encrypt, has a potential solution to the problem of how to collect and
aggregate telemetry without violating users’ privacy. The scheme is based on a
draft
protocol being standardized with the Internet Engineering Task Force (IETF),
and has an
open-source implementation
available.

OSPAR 2024 report now available with 163 services in scope

Post Syndicated from Joseph Goh original https://aws.amazon.com/blogs/security/ospar-2024-report-available-with-163-services-in-scope/

Amazon Web Services (AWS) is pleased to announce the completion of our annual Outsourced Service Provider’s Audit Report (OSPAR) audit cycle on July 1, 2024. The 2024 OSPAR certification cycle includes the addition of 10 new services in scope, bringing the total number of services in scope to 163 in the AWS Asia Pacific (Singapore) Region.

Newly added services in scope include the following:

The Association of Banks in Singapore (ABS) has established the Guidelines on Control Objectives and Procedures for Outsourced Service Providers to provide baseline controls criteria that Outsourced Service Providers (“OSPs”) operating in Singapore should have in place. Successfully completing the OSPAR assessment demonstrates that AWS has implemented a robust system of controls that adhere to these guidelines. This underscores our commitment to fulfill the security expectations for cloud service providers set by the financial services industry in Singapore.

Customers can use OSPAR to streamline their due diligence processes, thereby reducing the effort and costs associated with compliance. OSPAR remains a core assurance program for our financial services customers, as it is closely aligned with local regulatory requirements from the Monetary Authority of Singapore (MAS).

You can download the latest OSPAR report from AWS Artifact, a self-service portal for on-demand access to AWS compliance reports. Sign in to AWS Artifact in the AWS Management Console, or learn more at Getting Started with AWS Artifact. The list of services in scope for OSPAR is available in the report, and is also available on the AWS Services in Scope by Compliance Program webpage.

As always, we’re committed to bringing new services into the scope of our OSPAR program based on your architectural and regulatory needs. If you have questions about the OSPAR report, contact your AWS account team.

If you have feedback about this post, submit comments in the Comments section below.

Joseph Goh

Joseph Goh
Joseph is the APJ ASEAN Lead at AWS, based in Singapore. He leads security audits, certifications, and compliance programs across the Asia Pacific region. Joseph is passionate about delivering programs that build trust with customers and providing them assurance on cloud security.

„Аз, Делян Пеевски, ще дам истината…“

Post Syndicated from Емилия Милчева original https://www.toest.bg/az-delyan-peevski-shte-dam-istinata/

Има папки за всички. За ВСИЧКИ.

„Аз, Делян Пеевски, ще дам истината…“

Обществото е чувало тези фрази много пъти. Разбира се, „папки“ е обозначение за компромати. След като санкционираният за корупция от САЩ и Великобритания съпредседател на ДПС Делян Пеевски публично обеща да демаскира политическия елит в предстоящата предизборна кампания, мнозина основателно се страхуват. Но дали ще се случи?

Едно обещавам: аз, Делян Пеевски, ще дам истината на хората за всички. Моята кампания ще бъде развенчаване на целия политически модел. Хората трябва да видят истината и да получат ново начало.

Използването на компромати и негативна кампания за влияние върху изборите не е от вчера. Въпросът е не колко далече може да стигне една черна кампания, доминирана от олигарх и политик с влияние в съдебната система и службите, а възможен ли е (жълто-кафяв) катарзис и ново начало, което да го последва.

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

През последните години на повърхността излязоха не просто скандали, а разследвания, чиито разкриващи факти за покупко-продажбата на правосъдие в България са омерзителни – „Осемте джуджета“, Пепи Еврото и съпругата му Любена, заснемала оргии с магистрати и посредничила за уреждане на сделките за беззаконията, аферата „Нотариуса“ и разкритията на съдия Владислава Цариградска и др. Преди и по време на тези разобличения на бял свят бяха пуснати записи от политически сбирки на високо ниво, демаскирали някои възвишени партийни послания. 

А още преди тях се чуха пълните с вулгарности записи от телефонни разговори с гласа на Бойко Борисов и разни снимки с негово участие, но не те сложиха края на декадата на Борисов. Макар че компроматът с пачките евро и кюлчетата ще се помни дълго, лидерът на ГЕРБ и партията му продължават да печелят първото място на почти всички избори. Българските граждани са видели предостатъчно от арсенала на жълто-кафявите войни и нямат илюзии за морала на избраниците си. Но държавното обвинение така и не намери убедителни данни за престъпления.

Нечувствителност/безчувственост 

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

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

А санкционираният по „Магнитски“, който плющи като развято срещу корупцията знаме, вече пусна първия списък с „всички касиери в енергетиката на Мистър Кеш“ (така нарича президента Румен Радев). Тези хора са назначени в големите държавни енергийни дружества по време на служебните правителства на президента и на редовните и са останали на позициите си. Че държавната енергетика е парцелирана на зони за влияние – това не е тайна. А дали, като сочи едни назначения, Пеевски ще продължи с втора тема – за корупцията в прокуратурата и сред висшите магистрати, където ще трябва да назове „своите“?

Колеги, списъкът на всички касиери в енергетиката на Мистър Кеш – Румен Радев, и на Николай Копринков – касиера от село Труд, кръчмаря, в момента и днес ограбват енергетиката. Това е първата тема, надявам се да се занимаете с нея.

„Аз, Делян Пеевски, ще дам истината…“
Снимка: Ивайло Мирчев / Facebook

Какво би изненадало българите? 

Политиците са корумпирани? То се знае, защо иначе са в политиката! 

Изневеряват? Е, всички го правят. 

Крият сексуалността си? Амиии… тука е така.

Цинизъм и недоверие

Когато обществото непрекъснато е бомбардирано с компромати, това повишава цинизма и недоверието както към политическите фигури, така и към медиите. Хората започват да вярват, че всички политици са корумпирани, че медиите са манипулирани, което подкопава демократичните процеси и институции​. 

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

Поляризация

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

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

Апатия и оттегляне

Възможно е някои хора да реагират на постоянния негативен фон с апатия и оттегляне от политическия живот. Те се чувстват безпомощни и разочаровани, тъй като са все по-убедени, че техният глас няма значение или че политическата система е твърде корумпирана, за да бъде променена​ („всички са маскари“, „изборите не променят нищо“ и др.).

В България оттеглянето на гражданите от терена на политиката започна с последните няколко вота и постепенния спад на избирателната активност, регистрирала дъното от 34,41%. Ако политиците не успеят да мобилизират хората с нови лица, нови политики и честност за политическите си съюзи, разпадът ще засили идеите за промяна на системата на държавно управление. 

Алтернативни източници на информация 

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

Постепенно дигиталните платформи стават все по-предпочитани пред традиционните медии. В своя доклад за доверието към медиите (2014–2019) Европейският съвет за радио и телевизия установява „безпрецедентно високия нетен индекс на доверие (НИД) към социалните мрежи в България (+20 спрямо общия НИД за ЕС от -45) – абсолютно индивидуална тенденция за страната, която не се наблюдава на други места нито на регионално, нито на европейско ниво“. Това усложнява работата на политиците, които трябва да бъдат все по-изобретателни, за да „достъпват“ избирателите си, също и на медиите – за да популяризират съдържанието си. 

Пеевски не е първият, обещаващ скандални разкрития, които да раздрусат политическата система и гнилите ѝ ябълки да изпадат. Един бивш главен прокурор, който не успя да се справи с делото „КТБ“ като редови, но пък се издигна до Главен обвинител, гръмко обясняваше как не го е страх, как ще направи някакви страховити разкрития (след като го свалиха, не и преди това).

Но Иван Гешев не отиде по далеч от полутвърдението, че пари на Борисов са изнасяни в чували от правителствения „Авиоотряд 28“. По време на 17-годишната си кариера като прокурор, от която последните три години и половина като главен, той не събра смелост и за такова „въпросче“. Вече прекрати и изявите си по медиите след унизителния резултат от 0,14%, или 3003 гласа, за Граждански блок, с който се яви на изборите.

Преди време в едно интервю мажоритарният собственик на КТБ Цветан Василев го определи като „човек, ориентиран към властта и много алчен, но и много слаб човек. Предполагам, че е държан със страхотни компромати от Пеевски и Борисов“.

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

Leaked GitHub Python Token

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/08/leaked-github-python-token.html

Here’s a disaster that didn’t happen:

Cybersecurity researchers from JFrog recently discovered a GitHub Personal Access Token in a public Docker container hosted on Docker Hub, which granted elevated access to the GitHub repositories of the Python language, Python Package Index (PyPI), and the Python Software Foundation (PSF).

JFrog discussed what could have happened:

The implications of someone finding this leaked token could be extremely severe. The holder of such a token would have had administrator access to all of Python’s, PyPI’s and Python Software Foundation’s repositories, supposedly making it possible to carry out an extremely large scale supply chain attack.

Various forms of supply chain attacks were possible in this scenario. One such possible attack would be hiding malicious code in CPython, which is a repository of some of the basic libraries which stand at the core of the Python programming language and are compiled from C code. Due to the popularity of Python, inserting malicious code that would eventually end up in Python’s distributables could mean spreading your backdoor to tens of millions of machines worldwide!

Amazon Q Developer just reached a $260 million dollar milestone

Post Syndicated from Aytul Arisoy Cholkar original https://aws.amazon.com/blogs/devops/amazon-q-developer-just-reached-a-260-million-dollar-milestone/

To help them be more productive, developers all over the world are turning to generative AI-powered assistants like Amazon Q Developer, the most capable assistant for accelerating software development. While Amazon Q Developer is great at providing code suggestions, writing new code is one of many things developers have to do on a day-to-day basis. Amazon Q goes well beyond writing code, helping developers with tasks like testing, debugging, understanding existing code, finding security vulnerabilities, implementing entire new features, and more. One of the most time consuming and frustrating tasks is upgrading applications to the latest version. Developers and IT teams need to modernize their existing applications to take advantage of the latest technologies that help them innovate faster and improve performance – but upgrade campaigns are costly, often taking months or years to complete.

Amazon Q Developer helps alleviate toil for a range of software development tasks using agents that are like giving developers a team to help them complete tasks. Agents can reason and plan with minimal human intervention, and are capable of performing complex, multi-step tasks.

On August 1st, Andy Jassy shared an exciting finding regarding the real and quantifiable impact that the Amazon Q Developer agent for code transformation offers IT and developer teams of any size. Amazon has migrated tens of thousands of production applications from Java 8 or 11 to Java 17 with assistance from Amazon Q Developer. This represents a savings of over 4,000 years of development work for over a thousand developers (when compared to manual upgrades) and performance improvements worth $260 million dollars in annual cost savings.

To determine the true business impact of Q Developer-assisted app upgrades, we estimated the time saved by looking at the number of Java dependencies we migrated. Typically, it can take a day or more of a developer’s time to migrate just one dependency, and many applications have dozens of dependencies that need migrating. With the agent for code transformation, many of these dependencies can be migrated in minutes, resulting in a significant time savings. To estimate cost savings, we looked at the number of hosts we were able to remove from the applications due to the performance improvements achieved by upgrading to Java 17. Both of these estimates are conservative and our actual cost and time saved is likely much greater.

What is the Amazon Q Developer agent for code transformation?

The Amazon Q Developer agent for code transformation automates the complete end-to-end process of upgrading and modernizing applications, significantly reducing the time and costs associated with transformation projects, while enhancing application security and performance. Developers who want to learn about how to get started with the agent can head over to community.aws for tutorials or check out this demo:

Accelerate complex, multi-step tasks to save hours of work every day

Amazon Q Developer has an agent for software development that can autonomously perform a range of tasks–everything from implementing features, to documenting and refactoring code. Developers can simply ask Q to implement an application feature (such as asking it to create an “add to favorites” feature in a social sharing app), and the agent will analyze their existing application code and generate a step-by-step implementation plan. Developers can collaborate with the agent to review and iterate on the plan before the agent implements it, connecting multiple steps together and applying updates across source files, code blocks, and test suites. Customers have reported efficiency improvements of 25% faster initial development and up to a 40% increase in developer productivity.

How can you get started with Amazon Q Developer?

Individual users can get started with Q Developer in the AWS Console, CLI, or in their IDE on the perpetual Free Tier. Try the Pro Tier subscription if you need to manage a team of users and policies via enterprise access controls, to customize the code suggestions Amazon Q Developer makes to include your internal code base, or to add higher limits on advanced features.

The collective thoughts of the interwebz