As we wrap up 2022, we want to take a moment to shine a bright light on our readers, who spend their time exploring our posts, providing generous feedback, and asking poignant questions! Much appreciation goes to our Solutions Architects, who work tirelessly to identify and produce what our customers need.
Without any further ado, here are the top 10 AWS Architecture Blog posts of 2022…
Joe Chapman, Senior Solutions Architect, and Seth Eliot, Principal Developer Advocate, come in at #1 with a review of AWS services that offer cross-Region data replication—getting data where in needs to be, quickly!
Nigel Harris and team. explain the benefits of using Amazon VPC endpoints, and how to appropriately restrict access to endpoints and the services they connect to. Learn more by taking the VPC Endpoint Workshop in the AWS Workshop Studio!
In this technical how-to post, Shreya Pathak and Medha Shree demonstrate how to configure AWS Application Migration Service to migrate workloads from one AWS Region to another.
The Let’s Architect! Team claims 4 of the top 10 spots for 2022! Luca, Laura, Vittorio, and Zamira kick-off the series by providing material to help our customers design sustainable architectures and create awareness on the topic of sustainability.
In this post, the Let’s Architect! Team shares insights into reimagining a serverless environment, including how to start prototype and scale to mass adoption using decoupled systems, integration approaches, serverless architectural patterns and best practices, and more!
For a three-in-a-row, the Let’s Architect! Team shares tools and methodologies for architects to learn and experiment with. This post was also a celebration of International Women’s Day, with half of the tools detailed developed with or by women!
Well-Architected is tried and true AWS, describing key concepts, design principles, and architecture best practices for cloud workloads. In this post, Haleh Najafzadeh, Senior Solutions Architecture Manager for AWS Well-Architected, updates our readers on improvements to the Well-Architected Framework across all six pillars.
Joe and Seth are back at #8, covering AWS services and features used for messaging, deployment, monitoring, and management in multi-Region applications.
“The need for resilient workloads transcends all customer industries…” In their last top 10 post, the team provides resources to help build resilience into your AWS architecture.
Subrahmanyam Madduru and team demonstrate how to automate release deployments in a repeatable and agile manner, reducing manual errors and increasing the speed of delivery for business capabilities.
Goodbye, 2022!
A big thank you to all our readers and authors! Your feedback and collaboration are appreciated and help us produce better content every day.
From all of us at the AWS Architecture Blog, happy holidays!
Security updates have been issued by Debian (libcommons-net-java), Fedora (python3.6), and SUSE (conmon, polkit-default-privs, thunderbird, and webkit2gtk3).
It’s been another gangbusters year for Metasploit, and the holidays are a time to give thanks to all the people that help make our load a little bit lighter. So, while this end-of-year wrap-up is a highlight reel of the headline features and extensions that landed in Metasploit-land in 2022, we also want to express our gratitude and appreciation for our stellar community of contributors, maintainers, and users. The Metasploit team merged 824 pull requests across Metasploit-related projects in 2022, more than 650 of which were incorporated into the main metasploit-framework repository. If you fixed a typo, linked a new reference, or cleaned up some code spaghetti, thank you!
Active Directory Certificate Services attacks
For years now, penetration testers and attackers have emphasized Active Directory as a particularly juicy and valuable attack surface area. In 2021, we saw fresh attack research that outlined new techniques for targeting Active Directory Certificate Services, or AD CS, including multiple configuration flaws that can be leveraged to escalate permissions from a domain user to a privileged account. In response to requests from our user community, Metasploit released two modules in the second half of 2022 that support AD CS attack techniques:
auxiliary/gather/ldap_esc_vulnerable_cert_finder can be used by an authenticated AD user to enumerate Certificate Authorities (CAs) and find vulnerable certificate templates.
auxiliary/admin/dcerpc/icpr_cert allows users to issue certificates from AD CS with a few options that are used for exploiting some escalation (ESC) scenarios. Currently only escalation technique 1 (ESC1) can be exploited with the available options, but support for more techniques is planned.
Linux credential extraction with Mimipenguin
Metasploit expanded our post-exploitation capabilities for extracting plaintext credentials on Linux systems by porting the Mimipenguin utility to Metasploit. This allows users to extract credentials for a variety of services from an established Meterpreter session, including the gnome-keyring-daemon, vsftpd and sshd. Under the hood, this functionality uses a new Meterpreter API that allows searching through process memory.
Metasploit plays well with others
This year Metasploit added a few different ways of supporting interoperability with other offensive security tools. First up is the BOF Loader for COFF files, which enables usage of Cobalt Strike’s Beacon Object File format from within the Windows Meterpreter. This extension can also use BOF files written for Sliver. We’ve also made an improvement this year to allow users to bring their own payloads and stages from other tools and formats. If you’re a Sliver user, you can now deploy a Sliver agent as a custom payload stage, and we will use our own Metasploit stagers to upload and run the custom shellcode on the target.
Holiday hacking challenge
Metasploit teamed up with TryHackMe to deliver a challenge as part of their Advent of Cyber event, which ran for the month of December. The Metasploit challenge debuted on December 9 and walked users through a fun Christmas-themed story where they were able to use some of Metasploit’s latest pivoting capabilities. A walk-through is available under Task 9 on the official event page.
Sixth getsystem technique
Metasploit added a new technique to everyone’s favorite Meterpreter command in the middle of 2022 with help from cdelafuente-r7, who incorporated the newest named-pipe impersonation-based technique (the EfsPotato variant). This particular vulnerability affects Windows Vista / Server 2008 and later can be executed entirely in memory to escalate the current session to NT AUTHORITY\SYSTEM without spawning a new process. For more information about this and other getsystem techniques, check out the new module documentation. (Pro tip: Specific techniques can be used by number!)
Post API improvements and maintenance
Community member bcoles made more than 100 pull requests to improve and maintain the post-exploitation API used by Metasploit’s 400+ post modules. This enormous effort is greatly appreciated and has fixed numerous bugs, added new functionality, and made general improvements that benefit both end users and module developers alike. Among those improvements are removing quite a few lingering Meterpreter scripts (which were replaced by post modules in 2011) and adding shell session support for a few enumeration modules. The shell session support is particularly useful when combined with 2021’s payload-less session improvements because it bypasses the need to address evasion with Meterpreter.
New contributors
We would like to thank the community for all the work done this year. Particularly, we want to give a big shout out to the 45 new contributors that added great content to Metasploit. Some of these folks even added modules for celebrity vulnerabilities or flaws that were being actively exploited in the wild, such as Apache Spark RCE (CVE-2022-33891), Spring Cloud Gateway RCE (CVE-2022-22947) or Spring Framework RCE (CVE-2022-22965). We’re grateful to all our contributors for submitting modules that help organizations test their defenses, demonstrate risk, and prioritize mitigations.
exploit/linux/http/vmware_nsxmgr_xstream_rce_cve_2021_39144 – Despite having a 2021 CVE, this particular vulnerability, contributed by community member h00die-gr3y, gained attention in 2022 for being an unauthenticated RCE in VMware’s NSX product. Being a deserialization vulnerability, exploitation is smooth and reliable.
auxiliary/gather/ldap_query – This new module allows users to gather useful information from an Active Directory Domain Services (AD DS) LDAP server. Metasploit currently includes 28 predefined queries for common actions like enumerating LAPS passwords, computer accounts, and users with configured Service Principal Names (SPNs) for Kerberoasting. Metasploit users can even define their own queries for use with the module.
exploit/linux/local/vcenter_java_wrapper_vmon_priv_esc – This module, from community contributor h00die, added in support for CVE-2021-22015. vCenter is frequently targeted by attackers, so h00die’s contribution goes a long way in helping pen testers better assess the security of vCenter servers during their engagements.
exploit/linux/http/cisco_asax_sfr_rce – This module was added by jbaines-r7 and incorporated an exploit for CVE-2022-20828 that allows authenticated attackers to gain root-level shells on vulnerable Cisco ASA-X devices with FirePOWER Services enabled. These devices are frequently positioned in sensitive pivots within networks, and are prime targets for attackers, so gaining RCE on these devices often results in access to privileged networks and/or data.
exploit/multi/veritas/beagent_sha_auth_rce – This module from community contributor c0rs exploits CVE-2021-27876, CVE-2021-27877 and CVE-2021-27878 in Veritas Backup Exec Agent to bypass authentication and gain remote code execution as SYSTEM/root. This is quite a nice vulnerability since backup agents typically have access to sensitive information, so any compromise of such devices typically leads to access to sensitive company data. Combine this with SYSTEM/root privileges as an unauthenticated remote user, and you have a decent vulnerability for gaining initial access into a network and gaining information to start your pivoting attempts to other segments of that network.
Version 6.2 released
Over the summer, the Metasploit team announced the release of Metasploit Framework 6.2, which included a number of new features. Some of the highlights:
A streamlined authentication capturing plugin
An SMB 2 and 3-capable file server
Improved options for handling NATed services
Improved SMB relaying
We’re planning a 6.3 feature release in early 2023, so stay tuned for the next round of new Metasploit capabilities and improvements!
E-Z-2-contribute documentation
As of the 6.2 release, Metasploit has a new, user-contributable docs site at https://docs.metasploit.com/. Want to contribute to Metasploit, but don’t want to monkey around with Ruby or exploit code? We can always use more and better documentation on your favorite Metasploit features, workflows, and improvements. Get in there and help us teach people how hacking works!
From all of us at Rapid7, we wish you a very happy new year. As always, you can get the latest Metasploit updates every Friday in our weekly wrap-up, and you can stay up-to-date on vulnerability intelligence with AttackerKB.
At over thirty years old, HTTP is still the foundation of the web and one of the Internet’s most popular protocols—not just for browsing, watching videos and listening to music, but also for apps, machine-to-machine communication, and even as a basis for building other protocols, forming what some refer to as a “second waist” in the classic Internet hourglass diagram.
What makes HTTP so successful? One answer is that it hits a “sweet spot” for most applications that need an application protocol. “Building Protocols with HTTP” (published in 2022 as a Best Current Practice RFC by the HTTP Working Group) argues that HTTP’s success can be attributed to factors like:
– familiarity by implementers, specifiers, administrators, developers, and users; – availability of a variety of client, server, and proxy implementations; – ease of use; – availability of web browsers; – reuse of existing mechanisms like authentication and encryption; – presence of HTTP servers and clients in target deployments; and – its ability to traverse firewalls.
Another important factor is the community of people using, implementing, and standardising HTTP. We work together to maintain and develop the protocol actively, to assure that it’s interoperable and meets today’s needs. If HTTP stagnates, another protocol will (justifiably) replace it, and we’ll lose all the community’s investment, shared understanding and interoperability.
Cloudflare and many others do this by sending engineers to participate in the IETF, where most Internet protocols are discussed and standardised. We also attend and sponsor community events like the HTTP Workshop to have conversations about what problems people have, what they need, and understand what changes might help them.
So what happened at all of those working group meetings, specification documents, and side events in 2022? What are implementers and deployers of the web’s protocol doing? And what’s coming next?
New Specification: HTTP/3
Specification-wise, the biggest thing to happen in 2022 was the publication of HTTP/3, because it was an enormous step towards keeping up with the requirements of modern applications and sites by using the network more efficiently to unblock web performance.
Way back in the 90s, HTTP/0.9 and HTTP/1.0 used a new TCP connection for each request—an astoundingly inefficient use of the network. HTTP/1.1 introduced persistent connections (which were backported to HTTP/1.0 with the `Connection: Keep-Alive` header). This was an improvement that helped servers and the network cope with the explosive popularity of the web, but even back then, the community knew it had significant limitations—in particular, head-of-line blocking (where one outstanding request on a connection blocks others from completing).
That didn’t matter so much in the 90s and early 2000s, but today’s web pages and applications place demands on the network that make these limitations performance-critical. Pages often have hundreds of assets that all compete for network resources, and HTTP/1.1 wasn’t up to the task. After some false starts, the community finally addressed these issues with HTTP/2 in 2015.
However, removing head-of-line blocking in HTTP exposed the same problem one layer lower, in TCP. Because TCP is an in-order, reliable delivery protocol, loss of a single packet in a flow can block access to those after it—even if they’re sitting in the operating system’s buffers. This turns out to be a real issue for HTTP/2 deployment, especially on less-than-optimal networks.
HTTP/3 is the version of HTTP that uses QUIC. While the working group effectively finished it in 2021 along with QUIC, its publication was held until 2022 to synchronise with the publication of other documents (see below). 2022 was also a milestone year for HTTP/3 deployment; Cloudflare saw increasing adoption and confidence in the new protocol.
While there was only a brief gap of a few years between HTTP/2 and HTTP/3, there isn’t much appetite for working on HTTP/4 in the community soon. QUIC and HTTP/3 are both new, and the world is still learning how best to implement the protocols, operate them, and build sites and applications using them. While we can’t rule out a limitation that will force a new version in the future, the IETF built these protocols based upon broad industry experience with modern networks, and have significant extensibility available to ease any necessary changes.
New specifications: HTTP “core”
The other headline event for HTTP specs in 2022 was the publication of its “core” documents — the heart of HTTP’s specification. The core comprises: HTTP Semantics – things like methods, headers, status codes, and the message format; HTTP Caching – how HTTP caches work; HTTP/1.1 – mapping semantics to the wire, using the format everyone knows and loves.
Additionally, HTTP/2 was republished to properly integrate with the Semantics document, and to fix a few outstanding issues.
This is the latest in a long series of revisions for these documents—in the past, we’ve had the RFC 723x series, the (perhaps most well-known) RFC 2616, RFC 2068, and the grandparent of them all, RFC 1945. Each revision has aimed to improve readability, fix errors, explain concepts better, and clarify protocol operation. Poorly specified (or implemented) features are deprecated; new features that improve protocol operation are added. See the ‘Changes from…’ appendix in each document for the details. And, importantly, always refer to the latest revisions linked above; the older RFCs are now obsolete.
Deploying Early Hints
HTTP/2 included server push, a feature designed to allow servers to “push” a request/response pair to clients when they knew the client was going to need something, so it could avoid the latency penalty of making a request and waiting for the response.
After HTTP/2 was finalised in 2015, Cloudflare and many other HTTP implementations soon rolled out server push in anticipation of big performance wins. Unfortunately, it turned out that’s harder than it looks; server push effectively requires the server to predict the future—not only what requests the client will send but also what the network conditions will be. And, when the server gets it wrong (“over-pushing”), the pushed requests directly compete with the real requests that the browser is making, representing a significant opportunity cost with real potential for harming performance, rather than helping it. The impact is even worse when the browser already has a copy in cache, so it doesn’t need the push at all.
As a result, Chrome removed HTTP/2 server push in 2022. Other browsers and servers might still support it, but the community seems to agree that it’s only suitable for specialised uses currently, like the browser notification-specific Web Push Protocol.
That doesn’t mean that we’re giving up, however. The 103 (Early Hints) status code was published as an Experimental RFC by the HTTP Working Group in 2017. It allows a server to send hints to the browser in a non-final response, before the “real” final response. That’s useful if you know that the content is going to include some links to resources that the browser will fetch, but need more time to get the response to the client (because it will take more time to generate, or because the server needs to fetch it from somewhere else, like a CDN does).
Early Hints can be used in many situations that server push was designed for — for example, when you have CSS and JavaScript that a page is going to need to load. In theory, they’re not as optimal as server push, because they only allow hints to be sent when there’s an outstanding request, and because getting the hints to the client and acted upon adds some latency.
In practice, however, Cloudflare and our partners (like Shopify and Google) spent 2022 experimenting with Early Hints and finding them much safer to use, with promising performance benefits that include significant reductions in key web performance metrics.
We’re excited about the potential that Early Hints show; so excited that we’ve integrated them into Cloudflare Pages. We’re also evaluating new ways to improve performance using this new capability in the protocol.
Privacy-focused intermediation
For many, the most exciting HTTP protocol extensions in 2022 focused on intermediation—the ability to insert proxies, gateways, and similar components into the protocol to achieve specific goals, often focused on improving privacy.
The MASQUE Working Group, for example, is an effort to add new tunneling capabilities to HTTP, so that an intermediary can pass the tunneled traffic along to another server.
While CONNECT has enabled TCP tunnels for a long time, MASQUE enabled UDP tunnels, allowing more protocols to be tunneled more efficiently–including QUIC and HTTP/3.
At Cloudflare, we’re enthusiastic to be working with Apple to use MASQUE to implement iCloud Private Relay and enhance their customers’ privacy without relying solely on one company. We’re also very interested in the Working Group’s future work, including IP tunneling that will enable MASQUE-based VPNs. Another intermediation-focused specification is Oblivious HTTP (or OHTTP). OHTTP uses sets of intermediaries to prevent the server from using connections or IP addresses to track clients, giving greater privacy assurances for things like collecting telemetry or other sensitive data. This specification is just finishing the standards process, and we’re using it to build an important new product, Privacy Gateway, to protect the privacy of our customers’ customers.
We and many others in the Internet community believe that this is just the start, because intermediation can partition communication, a valuable tool for improving privacy.
Protocol security
Finally, 2022 saw a lot of work on security-related aspects of HTTP. The Digest Fields specification is an update to the now-ancient `Digest` header field, allowing integrity digests to be added to messages. The HTTP Message Signatures specification enables cryptographic signatures on requests and responses — something that has widespread ad hoc deployment, but until now has lacked a standard. Both specifications are in the final stages of standardisation.
A revision of the Cookie specification also saw a lot of progress in 2022, and should be final soon. Since it’s not possible to get rid of them completely soon, much work has taken place to limit how they operate to improve privacy and security, including a new `SameSite` attribute.
Another set of security-related specifications that Cloudflare has invested in for many years is Privacy Pass also known as “Private Access Tokens.” These are cryptographic tokens that can assure clients are real people, not bots, without using an intrusive CAPTCHA, and without tracking the user’s activity online. In HTTP, they take the form of a new authentication scheme.
While Privacy Pass is still not quite through the standards process, 2022 saw its broad deployment by Apple, a huge step forward. And since Cloudflare uses it in Turnstile, our CAPTCHA alternative, your users can have a better experience today.
At the 2022 HTTP Workshop, the community also talked about what new work we can take on to improve the protocol. Some ideas discussed included improving our shared protocol testing infrastructure (right now we have a few resources, but it could be much better), improving (or replacing) Alternative Services to allow more intelligent and correct connection management, and more radical changes, like alternative, binary serialisations of headers.
There’s also a continuing discussion in the community about whether HTTP should accommodate pub/sub, or whether it should be standardised to work over WebSockets (and soon, WebTransport). Although it’s hard to say now, adjacent work on Media over QUIC that just started might provide an opportunity to push this forward.
Of course, that’s not everything, and what happens to HTTP in 2023 (and beyond) remains to be seen. HTTP is still evolving, even as it stays compatible with the largest distributed hypertext system ever conceived—the World Wide Web.
Abstract: Eavesdropping from the user’s smartphone is a well-known threat to the user’s safety and privacy. Existing studies show that loudspeaker reverberation can inject speech into motion sensor readings, leading to speech eavesdropping. While more devastating attacks on ear speakers, which produce much smaller scale vibrations, were believed impossible to eavesdrop with zero-permission motion sensors. In this work, we revisit this important line of reach. We explore recent trends in smartphone manufacturers that include extra/powerful speakers in place of small ear speakers, and demonstrate the feasibility of using motion sensors to capture such tiny speech vibrations. We investigate the impacts of these new ear speakers on built-in motion sensors and examine the potential to elicit private speech information from the minute vibrations. Our designed system EarSpy can successfully detect word regions, time, and frequency domain features and generate a spectrogram for each word region. We train and test the extracted data using classical machine learning algorithms and convolutional neural networks. We found up to 98.66% accuracy in gender detection, 92.6% detection in speaker detection, and 56.42% detection in digit detection (which is 5X more significant than the random selection (10%)). Our result unveils the potential threat of eavesdropping on phone conversations from ear speakers using motion sensors.
Amazon Web Services (AWS) customers are deploying AWS Outposts as a fully managed solution that delivers AWS infrastructure and services to on-premises or edge locations for a truly consistent hybrid experience. Those hybrid cloud workloads can require highly available Oracle databases running on- or close-to premises. One way to meet this requirement is Oracle Real Application Clusters (RAC) on top of two or more AWS Outposts racks using the FlashGrid Cluster solution.
In this post, we follow up on a Marketplace blog that describes how to deploy Oracle RAC via FlashGrid Cluster in the AWS regions. Deploying the solution onto AWS Outposts requires additional steps as the Outpost racks communicate between VPCs and across the on-premises network. In the following we explain how to configure the network for a multi-Outpost setup, how to deploy FlashGrid Cluster with Oracle RAC, and how to connect to the database cluster from the on-premises network.
Solution overview
This architecture uses two logical Outposts (42U racks) that are connected to different Availability Zones (AZs) in the same region for high availability. The networking is configured such that the communication between Amazon Elastic Compute Cloud (Amazon EC2) instances on two distinct Outpost racks uses Outpost’s local gateways and the corporate network. Therefore, data will not leave the premises unless explicitly copied to the Cloud region.
The FlashGrid Cluster solution deploys one node to each Outpost rack and an additional quorum node to the Cloud region. The cluster nodes provide the Oracle ASM disk groups and the Oracle RAC nodes. FlashGrid Cluster for Oracle RAC ensures that storage is replicated between nodes (Figure 1).
Figure 1. Architecture for a deployment across two logical AWS Outposts
We provide a complete, step-by-step guide that deploys an Oracle RAC database across two Outpost racks.
It takes three steps to get your database up and running:
Networking: prepare the virtual private clouds (VPCs), subnets, and route tables
FlashGrid Cluster: use the FlashGrid Launcher to create an Oracle RAC cluster
Database: configure Oracle RAC and connect to the database
The deployment uses a CloudFormation template that is generated based on the workload’s specific parameters.
Basic Oracle database knowledge for the database configuration
Networking setup
A single VPC cannot span multiple Outposts. Therefore, each Outpost should have a separately configured VPC.
A security group allowing traffic between the nodes of the cluster must be created in each VPC. Private IP addresses of the other nodes in the cluster should be configured as allowed sources of the traffic. (A security group rule cannot reference a security group in a different VPC.)
The steps suggested for configuring the network, as in Figure 2:
Create a VPC for each Outpost and a VPC between those VPCs. Ensure that the VPCs are associated with the respective local gateways on each Outpost.
Within each VPC, create a subnet for the corresponding Outpost and a subnet in the Region. Add route tables to each Outpost subnet that allow cross-VPC routing (as in Table 1).Table 1. Main route table for VPC ‘Outpost 1’
Destination
Target
10.0.1.0/24
local
10.0.2.0/25
lgw-11111111111111111
10.0.2.128/25
pcx-11223344556677889
pl-12345678
vpce-12345678901234567
For each of the cluster nodes, allocate a private IP address within the corresponding subnet.
Within each VPC create a separate security group for each cluster. The security group must allow all inbound and outbound traffic from all nodes of the same cluster using their private IP addresses.
Optional: Create a public subnet in the region in either one of the VPCs. Deploying a bastion host EC2 instance into this subnet will allow you to connect by SSH to the Oracle RAC nodes later.
Open SSH access (TCP 22) and Oracle client access (default ports: TCP 1521, 1522) either by adding the corresponding rules to the same security groups or assigning additional security groups to all cluster node instances after the cluster deployment is complete.
Creating an S3 bucket for Oracle installation files
During cluster provisioning, Oracle installation files are downloaded from an S3 bucket. The list of files that must be placed in the S3 bucket is displayed on the Oracle Files tab of the FlashGrid Launcher tool (next step). The S3 bucket is not supposed to have any sensitive data in it and can be hosted in any AWS Region. You can use the same bucket for multiple deployments.
To create an S3 bucket with the correct IAM role access:
Create an S3 bucket or folder for uploading the installation files
Within the IAM console, create a policy named GetOracleFilesFromS3, which allows the s3:GetObject action on all uploaded files
Create an EC2 instance role named GetOracleFilesFromS3 and attach the GetOracleFilesFromS3 policy to it
Use the GetOracleFilesFromS3 role when configuring cluster parameters in the FlashGrid Launcher
Once the FlashGrid Launcher has provided a list of required Oracle installation files, place those into the S3 bucket
Modifying the cluster configuration template with parameters specific to Outposts
Download the configuration file template, and open it in a text editor. The template is for a two-node RAC cluster on Outposts in Multi-AZ configuration.
For the database node instances in the configuration file, manually set the following attributes:
outpost_arn: ARN of the target Outpost
ip: private IP address assigned to the EC2 instance
sg: security group ID
ins_type: instance type (ensure that this matches the available types for the Outposts)
Creating a cluster configuration file using FlashGrid Launcher tool
FlashGrid Launcher is an online tool that allows creating your desired configuration for the cluster and then generating a CloudFormation template for it.
Open FlashGrid Launcher and upload the customized configuration file created at the previous step.
Follow the step-by-step instructions in the Launcher tool (see Figure 3) until you get to the last Launch step. a. In the Oracle Files step, there is a list of installer files. Upload these files into the S3 bucket from the previous section (Creating an S3 bucket for Oracle installation files). b. In the Storage step, ignore the IOPS and MBPS parameters, as these parameters will not be used because Outposts uses the GP2 type of volumes. c. In the Network step, provide the Security Group ID that will be used for the quorum node located in the Region. Make sure to use a security group from the quorum node’s VPC.
At the Launch step, click Launch FlashGrid. This generates a CloudFormation template and takes you to the AWS CloudFormation console.
Figure 3. The FlashGrid Launcher generates a CloudFormation template based on various input parameters
Deploying the CloudFormation template
Once you are in AWS CloudFormation console, select Next.
Select the SSH key; do not change network parameters if you set them correctly in the Launcher. Select Next.
On the Options page, if you added tags in FlashGrid Launcher, then do not add the same tags in CloudFormation console. You are free to add further tags in this step. Select Next.
Select Create, and wait until the status of the stack changes to CREATE_COMPLETE.
Connect by using SSH from the bastion host to the first cluster node as ec2-user with the SSH key you were provided when the stack was deployed.
The welcome message details the current initialization status of the cluster: in progress, failed, or completed.
If initialization is still in progress, wait for it to complete (this includes Oracle software installation and configuration). A broadcast message is delivered when initialization completes or fails. Cluster initialization takes 1 to 2 hours, depending on configuration.
Oracle database configuration
You can create an Oracle RAC database (or multiple databases) using Oracle DBCA tool and following standard Oracle best practices.
To connect to the Oracle RAC database using the SCAN listener, configure the Domain Name System (DNS) records and the connection string on client side:
On the DNS server(s) used by clients, add a record resolving to the VPC Private IP address of the node instance for each database node. In a test environment without a DNS server, the entries can be added to /etc/hosts on the clients instead of the DNS server.
It is important that hostnames and domain names in the DNS records exactly match the hostnames as reported by the hostname command on the database servers.
Finally, define a connection string with the addresses of all database nodes listed:
Visit the FlashGrid Help Center for more information on creating and connecting to a database.
Cleanup
The Oracle RAC instance together with the FlashGrid Cluster solution is deployed as a single CloudFormation stack. Deleting this stack will remove all associated resources, including the EBS volumes. Follow the approach detailed in the Delete Your Stacks But Keep Your Data blog post at the deployment stage to retain snapshots of all volumes automatically. You can also take snapshots of all EBS volumes manually before deleting the stack.
Conclusion
In this blog post, we have explored how to deploy Oracle RAC across two or more Outpost racks using FlashGrid Cluster. Running Oracle RAC on top of Outposts provides a highly available database solution for use cases that require you to run the workload on-premises, as in data-residency or latency-critical scenarios. Using the growing number of features for AWS Outposts rack, and you can more efficiently run hybrid workloads using the same tools and automation both in Cloud Regions and on-premises.
MariaDB 11.0 should be of interest to you if any of the following scenarios match your typical queries:
Your queries are
using more than two tables
using indexes that have lot of identical values.
using ranges that cover more than 10% of a table.
WHERE key between 1 and 1000 — Table has values 1-2000
using complex queries where not all used columns are or can be indexed.
In which case you may need to depend on selectivity to get the right plan.
mixing different storage engines.
Like using tables from both InnoDB and Memory in the same query.
using FORCE INDEX to force an index
getting worse (or not good enough) when using ANALYZE TABLE.
depending on –optimizer-use-condition-selectivity > 1 (using selectivity to find out how many accepted rows there are in a table).
using lots of derived tables (subselects).
using ORDER BY / GROUP BY that could be resolved via indexes
using table scans when it should use keys and vice versa.
First a bit of history
When I created the original MySQL optimizer in 1995, it was quite simple. A big part of the plans were based on costs, but there where also a lot of rule based choices. The original ‘base of cost’ was “one disk seek”. The cost of key read was also a disk seek.
Over time a lot of developers have worked on the optimizer and added many new features, but the original cost model has stayed the same (until now). Most new features was done with based on a cost model, but still some new things (like deciding which index to use for sorting) were still partly rule based.
If there was only one or a few choices for a plan, the old optimizer was reasonably good in finding a good plan. But the more complex the queries got (complex = a lot of different choices could be made for each table) the more chance that it would not find the optimal plan. This goes all back to the original cost model not being ‘good enough’.
The main developers of the 11.0 optimizer changes in MariaDB 11.0 are Sergei Petrunia and me. Vicențiu Ciorbaru has also provided some code and help.
The optimizer changes consist of more than 100 commits, starting from October 2021!
It has been a long project!
What is new
In 11.0 the costs are based on the expected microseconds spent in the storage engine, in filesort and in filtering code. Almost all cost factors have been calculated base on result from performance tests. The costs can be viewed and changed by the end user, either globally or for a specific storage engine. A few top level costs can be changed per query.
As part of the above work, a lot of other improvements have gone into the optimizer:
New cost for:
All storage engine low level index/row read calls (read key, read row, fetch next etc)
Filesort
Unique
Join_cache
Materialization
Disk access costs are by default based on modern SSD (can be changed by the end user).
A lot of improvements (including bug fixes):
Selectivity, when using –optimizer-use-condition-selectivity > 1.
Choosing right index for scanning the table as part of GROUP BY/ORDER BY optimization.
Performance improvements:
Derived tables and unions now creates a distinct key in the derived table (when possible). This adds automatic duplicate elimination to the derived table (which makes it smaller) and improves performance when using the derived table.
A lot of small optimization in all parts of the optimizer
Other things:
A lot more information in optimizer trace (which makes it easier to help customers and users to find out what the optimizer is doing).
What are the notable consequences of moving to MariaDB 11.0?
First note that MariaDB 11.0 is based on the stable MariaDB 10.11 release with just the optimizer changes + a few small safe features. My expectations is that 11.0 should be stable (no major showstopper bug) from the start (beta).
The MariaDB optimizer team will do its best to quickly address any issues with the new code. We plan to do spot-releases with bug fixes if anything serious is found to ensure that there is a short feedback loop between users and developers! If there is a major uptake of MariaDB 11.0, it will get updates regularly.
Most applications, which are properly using keys, should be unaffected:
Simple queries will work as before
Most complex queries (with many tables) should perform equal or better than before.
Some things that you may see based on the above cost changes:
The optimizer is more likely to use an index to resolve ORDER BY.
Very small tables are more likely to use table scan (as it’s very fast for small tables).
The optimizer will use rowid_filters a bit more than before.
The optimizer will use “index for group by” optimization more optimal now
The optimizer will use materialization a bit less as it’s cost is now a bit higher.
The optimizer should be able to do a better choice when deciding when to use table scan, index scan, index_merge, hash and other join methods needed when key lookup cannot be used.
Complex queries may get a different (better) plan.
If you have problems with some queries, MariaDB allows you to change costs to match your hardware/environment or data access patterns much better than any previous MariaDB release!
If you find anything that is wrong or can be improved, please report a bug in MariaDB bug tracker and link it to the optimizer entry, MDEV-26974.
If possible, put MariaDB 11.0 as an extra slave and add a comment to this blog on how things work (bug reports should still go to the MariaDB bug tracker).
You can help ensuring that MariaDB 11.0 gets/is proven stable ASAP!
Security updates have been issued by Debian (multipath-tools), Fedora (containerd and trafficserver), Gentoo (libksba and openssh), and SUSE (webkit2gtk3).
Is there a defined ecosystem, similar to what we encountered with the Internet of Things (IoT), that can be charted out as it relates to smart city technology and its security implications?
While evaluating IoT I struggled with defining what IoT is. I found that there were varying definitions out there, but none that helped me fully understand what constitutes IoT and how to approach evaluating its security posture. To solve that dilemma in my mind and to better be able to discuss it with vendors and consumers I finally landed on the concept that IoT is often better defined as a series of traits that can be used to explain it, its structure, and better understand the components and their interaction with each other. This concept and approach also allowed me to properly map out all of the interlinking mechanisms as it relates to security testing of the IoT technology’s full ecosystem.
Looking at it from this perspective we see that Smart Cities leverage IoT technology and concepts at its core but in many cases with a much more defined relationship to data. With this in mind, I have started looking at the various components that make up Smart Cities, abstracting out their specific purposes, with the goal of having a model to help better understand the various security concerns as we plan for our Smart City future.
Through general observation we can see that Smart City solutions consist of the following five general areas:
Embedded technology
Sensors
Actuators
Aggregators & Edge or Fog appliances
Management and control
Client-side application
Cloud application
APIs
Server application
Data storage
Cloud storage
On-premises storage
Edge or Fog storage
Data access
Cloud application
Client-side application
Server-side application
Communication
Ethernet
WiFi (802.11abgn)
Radio frequency (RF) ( BLE, Zigbee, Z-wave, LoRa, etc.…)
Cellular communication ( GSM, LTE, 3,4,5G)
Mapping these various components to a specific smart city solutions ecosystem, we can better establish the relationship between all the components in that solution. This in turn allows us to improve our threat modeling processes by including those interrelationships. Also, similar to general IoT security testing, understanding the interconnected relationships allows us to take a more holistic approach to security testing.
The typical approach of testing each component only as a stand-alone entity is always a short-sighted approach and misses the mark when identifying attack vectors and associated risk that often come to light only when security testing takes into consideration the interaction of these components. This approach leads us to always ask the question: what happens to the security posture of one set of components if there is a security failure in another set of components? Also, the holistic approach helps us better map the security risk levels across the entire ecosystem. Just because a low-risk condition is found in a single item does not mean that the risk is not compounded into a higher risk category due to some interaction within other components.
So, in conclusion, the solution to establishing a solid security testing response for Smart City technologies is to map out the entire ecosystem of the solution that is being designed and deployed. Define a solid understanding of the various components and their interaction with each other; then, conduct threat modeling to determine the possible risks and threats that are expected to come against the smart city solutions.
Public service announcement: разни хора са възродили ИББ – пак така, всяка сряда, само че в бирария “Дондуковъ” (на бул. Дондуков 14, пак на ъгъла с “Будапеща”, ама диаметрално противоположно спрямо старото “Криво”). Масите са запазени на името на “ИББ”.
Мястото не е лошо, яденето става, бирата става, няма от спирта, дето аз харесвам.
Струпването на голям брой хора на едно място неизменно идва със своите проблеми. Някои злободневни, някои по-сериозни. Това важи както за единичен блок, така и за цял град. За да може да се спогаждаме, следва да има правила, които да се спазват, но най-вече някакво ниво на съобразителност и обръщане на внимание на околните. Не може, а и не следва всичко да се кодифицира, така че трябва да използваме здрав разум и съобразителност, както във всичко друго. За блока това може да значи да не къртиш по никое време и да не си хвърляш боклука през прозореца. За градовете – да не паркираш където и да е, да не замърсяваш, да не трошиш и да не гърмиш пиротехника когато и както ти падне.
Както повечето знаят от опит, здравият разум е трудно нещо за някои хора. Затова някои от тези неща са регламентирани и имат своите санкции. Целта им често е да пресече особено наглото пренебрегване на правата и спокойствието на околните. В случая с пиротехниката конкретно в София проблем имаше предимно с няколко заведения из града. Като цяло обаче на повечето места в било приемливо до скоро.
Решението на Столичният общински съвет
Дали покрай пандемията, дали заради друго обаче през 2021-ва ситуацията се влоши значително и се чуваха гърмежи из целия град по няколко пъти на седмица. Нещата ескалираха до там, че отдавна обсъждана промяна от Общинския съвет накрая беше приета въвеждаща разрешителен режим за пиротехниката. Едното изключение е на 31 декември до 1 часа. Другите изключения са важни и ще говорим за тях след малко.
Местните кметове трябваше да публикуват информация на страницата си, да дават разрешения както и да публикуват всяко едно. Имаха право да отказват, ако искането е за след 22 часа, при лоши метеорологични условия, както и ако се стреля в междублокови пространства в допълнение на забраните в чл. 60 на Закона за оръжията, боеприпасите, взривните вещества и пиротехническите изделия. Изискването влезе в сила от началото на март 2022.
В следващите два месеца имаше забележимо намаление на пиротехниката, поне в сравнение със същия период на предходната година. След няколко гърмежа около полунощ реших да подам сигнал да видя как работи контролът. Краткият извод е, че не работи. Подадох няколко сигнала в call.sofia и на 112. От общината отговориха, че нямат правомощия и само СДВР може да санкционира. В два от случаите дадох точно описания кой е ресторанта и че съм видял лично фойерверките да се изстрелват конкретно от персонала. Последствия нямаше. Единият път ми звънна само да ми се кара районният от къде съм знаел, че ония нямали разрешение да гърмят. Отговорих, че съм проверил и щом няма публикувано такова, значи нямат право.
Заявления, разрешения и глоби… може би
Стана ми интересно колко всъщност такива разрешения са искани и дадени. Затова в края на август пуснах искане по ЗДОИ до общината. Отговориха ми всички райони освен Студентски и Младост. За първите малко повече от 6 месеца ми казаха, че са подадени 38 заявления, от които 30 са приети и са издадени разрешения. Интересното в случая е, че в някои райони е имало издадени разрешения направо от Фандъкова в разрез с решението на СО. Те не са публикувани на страницата на Столична община обаче. Тук съм отбелязал местата, за които са искани разрешения. На някои има по две или три такива през месец.
За да следя бъдещи решения, направих скрипт, който да ги намира и да ме уведомява до час. Така откриха, че от искането ми по ЗДОИ до сега е имало само още две заявления – на 2-ри септември в Искър и на 7-ми декември в Студентски. Последното е единственото издадено разрешение за декември, а за октомври и ноември няма никакви. Гърмежи очаквано тогава имаше.
Преглед на заявленията показва някои интересни неща. Нито едно не отговаря стриктно на условията, а няколко дори не отговарят на формалните изисквания в решението на СО. Например, заявления във Витоша, Нови Искър и Изгрев са подадени и решения са публикувани по-малко от 3 дни преди събитието. В един случай – няколко часа преди гърмежите. В един случай в Банкя е разрешена пиротехника до 23:00, макар СО да са решили, че може до 22:00. Четири разрешения са в междублоково пространство. Половината са на по-малко от 300 метра от училища или детски градини. Седем са на по-малко от 500 метра от болница или медицински център. Три разрешения са точно до бензиностанция, а едно е било на 330 метра от резиденция Бояна.
Тук проблемът не е в местните кметове, макар да следва да съблюдават поне часа на исканията. Дефинициите в решението на СО и Законът за оръжията са свободни за интерпретация. Освен да се ходи на място или да се търси подробно на картата къде ще се стреля, трудно може да се разбере кое е междублоково пространство и какво всъщност се счита за такова. Има определение в други нормативни актове, но надали някой е обръщал внимание. Лоши метеорологични условия също може да значат каквото и да е. По-важното е, че не ясно какво означава „в близост“ според ЗОБВПИ. В строгия смисъл може да значи на територията или двора на училище или църква. Тъй като видимо е оставено на здравия разум и собствена преценка на полицията, то има повече смисъл да се гледа далечината, на която може да измине изстреляна ракета. При грешно боравене, това хоризонтално може да е между 300 и 500 метра в зависимост от ракетата.
Това би означавало, че на 300 и 500 метра от изброените в закона и решението на СО обекти в София не трябва да се използва пиротехника. Ако прегледате картата на столицата колко училища, градини, болници, медицински центрове, бензиностанции, църкви и други защитени обекти има, то консервантивно поне 2/3 от жилищната площ на града не следва да се използва пиротехника. Това особено важи за жилищните квартали.
Гръмката тишина извън наредби и закони
Тези 20 души заявили пиротехника поне са се постарали да минат както си му е реда. Към тях има поне пет пъти повече, които разчитат на бездействието на контролните органи. Част от искането ми по ЗДОИ беше и броят подадени сигнали и наложени санкции. Същите ония санкции, за които СО припомни вчера, че щели да глобяват, освен на 31-ви срещу 1-ви. Впрочем, толкова не са в час хората на Фандъкова, че вчера даже са объркали пред БТА, че можело да се гърми до 2 часа на 1-ви януари – по наредба в до 1 часа. Та на моето запитване отговорът беше, че между март и август тази година е нямало нито един регистриран сигнал за такова нарушение в което и да е районно кметство. Никой в София не се бил оплакал според тях над 6 месеца. Съответно няма и нито една наложена санкция. Това е абсурдно, защото аз лично съм подавал няколко по телефона и през call.sofia. Знам за поне 10 сигнала в район Изгрев и Красно село. Някои от тях лесно могат да се намерят в портала на общината по ключови думи.
Въпреки настоятелните ми напомняния МВР реши да не отговори на това колко сигнала са получили, включително от телефон 112. Отговориха обаче, че не са санкционирали никого между март и август 2022 нито във връзка с решението на СО, нито по чл. 60, ал. 1, т. 6 от ЗОБВПИ. С други думи, практически няма контрол над използването на пиротехника в София.
Причини за това има няколко. Обективната е, че се стреля 2-3 минути и се бяга. Това дори е услуга, която някои доставчици на фойерверки предоставят – идват с буса, правят шоу, събират нещата и си тръгват. Известно е обаче, както с шума, някои заведения имат уговорка с местните патрули да не им правят особен проблем. Известни са и заведнията, от които редовно се стреля – най-вече по празници. Някои дори го предлагат неофициално като част от пакета.
Тук идва един любопитен аспект от Наредбата за опазване на обществения ред в София. Чл. 8 прави изключение за пиротехника при масови мероприятия, включително „сватбени, семейни и фирмени тържества“. До тук добре. Алинея 2 обаче изисква да се иска разрешение за това мероприятие и то може да бъде отказано от общината. Ал. 7 пък забранява „внасянето, продажбата и употребата на спиртни напитки“. С други думи, поне де юре, сватбите следва да изберат или алкохола, или фойерверките.
Основната причина за бездействието обаче е нехайството на СДВР и принципно лошата координация между полиция и община за проблемите на града. Много от проблемите като безразборното паркиране, опасното каране и фойерверките не се решават с акции и индивидуална инициатива на някой полицай, а със системни действия и надзор. Ясно е, че не може да се хване всеки, който гърми, за да избива комплекси, но в повечето случаи говорим за едни и същи извършители, често като част от бизнес. В основата си причината за липса на контрол е, че СДВР не разпознава пиротехниката като проблем и не работи добре с хората и месната власт, също както цялата структура по други теми.
С още санкции и регистри не се решават проблеми
Липсата на активност от страна на Фандъкова и СДВР доказано не може да се реши, освен с избори. По инерция, към това нехайство и бездействие се подхожда с още забрани и наредби. В случая обаче тази на СО допълва Закона за оръжията добавяйки междублоковите пространства и лошото време като фактор за отказ. В началото на ноември Административен съд София отмени тази част от наредбата с аргумента, че вече е уреден този режим на разрешение и не е работа на районните кметове да дават още едно разрешение. Отсъждането се обжалва и няма да влезе в сила до тогава.
Районните кметове може би биха се съгласили, че не им е работа. Факт е, че ЗОБВПИ в голяма степен урежда правата и задълженията при боравене с пиротехника. Факт е обаче и че полицията абсолютно бездейства в контрола над въпросния член. Отделно има хипотези, които изискват разбиране за спецификите на района. Отделно е добре да се уведомяват хората в съседство, че ще има гърмене. В този смисъл решението на СО от преди година, въпреки недостатъците си, постигна напредък.
Истината е, че закон има, но за пореден път не се спазва, както по много други параграфи. СДВР оплита всичко в административни безсмислици и дори препраща към прокуратурата, които симулират дейност на принципна основа. Отчасти ги разбирам – заради беззаконието и безсметните чадъри в институциите не знаят дали ще попаднат на човек, дето има човек и после ще им трият сол на главите. Ако мога да цитирам познат в СДВР – ако утре направи проблем на мутра и ония го пребие, не знае дали ръководството няма да го накаже, че си е изцапал с кръв униформата. В този смисъл може само да аплодираме онези 20-тина души, които все пак са си направили труда да поискат разрешение за пиротехника.
Тука е така… както си го направим
Започнах с това, че съвместното съжителство се базира на компромиси. Това важи както за дома, така и за блока и на ниво град. Всеки може да прави каквото си иска, стига да не пречи на другите в разумни граници. Това, което се случва с пиротехниката в последните две години в София надхвърли отдавна тези граници и разума.
Навярно всичко това ви се струва излишно, стъпкване на правата на хората да правят каквото си искат или неизбежна част от градската среда. Градът обаче е такъв, какъвто си го направим. Голяма част от него е кочина, защото именно ние сме си го направили такава. В случая с пиротехниката има редица обективни причини да се търси силно ограничаване, особено имайки предвид взривоопасните вещества, които се складират на територията на болници и бензиностанции. Отделно не следва да чакаме отново да се запали нечия тераса или училище от „заблудила“ се ракета, за да се замислим, дали всъщност не е добра идея да се поспре с това. Не на последно място, макар явно да предпочитаме да не ги виждаме много съдейки по сегрегирането на училищата наложено от директори и родители, децата със специални потребности съществуват и фойерверките им се отразяват доста различно от на вашите деца, например. Сигурен съм, че някои хора с домашни любимци биха се включили с подобни притеснения и опит. Да не започвам дори за замърсяването на въздуха, за което говорим особено активно в последните години.
Затова обръщайте внимание на този и подобни проблеми, защото са неразделна част от качеството на градската среда. Мислете добре на изборите тази година. А в следващите дни – не забравяйте, че няма нито едно издадено разрешително за пиротехника до 8 часа на 31 декември, но и на Фандъкова не и пука, а на структурата под Милтенов не изглежда да иска да направи нещо по въпроса.
HardCIDR is a Linux Bash script to discover the netblocks, or ranges, (in CIDR notation) owned by the target organization during the intelligence gathering phase of a penetration test.
The NTPsec Project is pleased to announce the tagging of version 1.2.2
Restore/cleanup NTPv1 support
ntpq sysstats now shows NTPv1 traffic.
NTPv1 counter added to sysstats log file.
NTS supports partial wildcards, for example *.example.com
Work on documentation, ntpdate, ntpheat, ntploggpg, ntpq’s sysstats, ntpviz,
and seccomp.
NTP auth no longer breaks on NULs.
The NTS server now saves 10 days worth of cookie keys. This will allow clients
that only poll once a day to use NTS without using NTS-KE to keep cookies up to
date.
rawstats now logs dropped packets and their BOGON code
Only one per request to avoid DoSing the log file
This lets you see packets that take too long.
Add 4 or 6 to DNS/NTS RefID tags to indicate that the
DNS or NTS-KE has succeeded but NTP has not worked yet.
Build improvements
Respect --notests configure option for build
Add --enable-attic (default off)
Restore Python 2.6 support
Restore LibreSSL support
Add support for OpenSSL 3.0
Fix hash validation in ntpleapfetch again.
FreeBSD now gets nanosecond resolution on receive time stamps.
This release is signed with the GPG key id
E57235D22764129FA4F2F4D17F52608ED0E49D76
The collective thoughts of the interwebz
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
![[Earlier, at the eye doctor] 'No, for the last time, the numerals on the paper aren't my prescription, it's the shape I want you to make with the laser.'](https://imgs.xkcd.com/comics/new_years_eve_party.png "[Earlier, at the eye doctor] 'No, for the last time, the numerals on the paper aren't my prescription, it's the shape I want you to make with the laser.'")
