Our very own adfoster-r7 has added a new feature that adds module actions, targets, and aliases to the search feature in Metasploit Framework. As we continue to add modules with diverse goals or targets, we’ve found ourselves leaning on these flags more and more recently, and this change will help users better locate the modules that let them do what they want.
Right now, the feature is behind a feature flag as we work out how to make it as user-friendly as possible. If you would like to use it, turn on the feature by running features set hierarchical_search_table true. Please let us know how it works for you!
New module content (2)
ownCloud Phpinfo Reader
Authors: Christian Fischer, Ron Bowes, creacitysec, h00die, and random-robbie
Type: Auxiliary
Pull request: #18591 contributed by h00die
Path: gather/owncloud_phpinfo_reader
Description: This adds an auxiliary module for CVE-2023-49103 which can extract sensitive environment variables from ownCloud targets including ownCloud, DB, Redis, SMTP, and S3 credentials.
Docker cgroups Container Escape
Authors: Kevin Wang, T1erno, Yiqi Sun, and h00die
Type: Exploit
Pull request: #18578 contributed by h00die
Path: linux/local/docker_cgroup_escape
Description: This adds a new module to exploit CVE-2022-0492, a docker escape for root on the host OS.
Enhancements and features (5)
#17667 from h00die – Makes various performance and output readability improvements to Metasploit’s password cracking functionality. Now, hash types without a corresponding hash are skipped, invalid hashes are no longer output, cracking stops for a hash type when there’s no hashes left, and empty tables are no longer printed. Other code optimizations include added support for Hashcat username functionality, a new quiet option, and documentation updates to the wiki.
#18446 from zeroSteiner – This makes the DomainControllerRhost option optional, even when the authentication mode is set to Kerberos. It does so by looking up the Kerberos server using the SRV records that Active Directory publishes by default for the specified realm.
#18463 from h00die-gr3y – This updates the linux/upnp/dlink_upnp_msearch_exec exploit module to be more generic and adds an advanced detection logic (check method). The module leverages a command injection vulnerability that exists in multiple D-Link network products, allowing an attacker to inject arbitrary command to the UPnP via a crafted M-SEARCH packet. This also deprecates the modules/exploits/linux/upnp/dlink_dir859_exec_ssdpcgi module, which uses the same attack vector and can be replaced by this updated module.
#18570 from adfoster-r7 – Updates Metasploit’s Docker ruby version from 3.0.x to 3.1.x.
#18581 from adfoster-r7 – Adds hierarchical search table support to Metasploit’s search command functionality. The search table now includes a module’s actions, targets, and alias metadata. This functionality requires the user to opt-in with the command features set hierarchical_search_table true.
Bugs fixed (1)
#18603 from h00die – Updates the auxiliary/scanner/snmp/snmp_enum and auxiliary/scanner/snmp/snmp_login module metadata to include metadata references to CVE-1999-0516 (guessable SNMP community string) and CVE-1999-0517 (default/null/missing SNMP community string).
Documentation added (1)
#18592 from loredous – Fixes a typo in the SMB pentesting documentation.
You can always find more 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:
For ISO 27001, we updated our ISO 27001:2013 certification to the 27001:2022 version.
For ISO 9001:2015, 27001:2022, 27017:2015, 27018:2019, 27701:2019, and 22301:2019, we added seven additional AWS services to the scope of this surveillance audit since the last certification issued on May 23, 2023. The seven additional services are:
For 20000-1:2018, we added additional 65 services (including the seven noted previously) to the scope of this surveillance audit since the last certification issued on Dec 13, 2022.
For a full list of AWS services that are certified under ISO and CSA STAR, please see the AWS ISO and CSA STAR Certified page. Customers can also access the certifications in the AWS Management Console through AWS Artifact.
If you have feedback about this post, submit comments in the Comments section below.
Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.
It can be instructive to pull down the dog-eared copy of the first edition
of The C Programming Language that many of us still have on our
bookshelves; the language has changed considerably since that book was
published. Many “features” of early C have been left behind, usually for
good reasons, but there is still a lot of code in the wild that is still
using those features. A concerted effort is being made in both the Fedora
and GCC communities to fix that old code and enable some new errors in the
GCC 14 release (which is in
stage 3 of its development cycle and likely to be released by
mid-2024), but a fair amount of work remains to be done.
Part of Flutter Entertainment, FanDuel Group is a gaming company that offers sportsbooks, daily fantasy sports, horse racing, and online casinos. The company operates sportsbooks in a number of US and Canadian states. Fanduel first carved out a niche in the US through daily fantasy sports, such as their most popular fantasy sport: NFL football.
As FanDuel’s business footprint grew, so too did the complexity of their analytical needs. More and more of FanDuel’s community of analysts and business users looked for comprehensive data solutions that centralized the data across the various arms of their business. Their individual, product-specific, and often on-premises data warehouses soon became obsolete. FanDuel’s data team solved the problem of creating a new massive data store for centralizing the data in one place, with one version of the truth. At the heart of this new Global Data Platform was Amazon Redshift, which fast became the trusted data store from which all analysis was derived. Users could now assess risk, profitability, and cross-sell opportunities not only for piecemeal divisions or products, but also globally for the business as a whole.
FanDuel’s journey on Amazon Redshift
FanDuel’s first Redshift cluster was launched using Dense Compute (DC2) nodes. This was chosen over Dense Storage (DS2) nodes in order to take advantage of the greater compute power for the complex queries in their organization. As FanDuel grew, so did their data workloads. This meant that there was a constant challenge to scale and overcome contention while providing the performance their user community needed for day-to-day decision-making. FanDuel met this challenge initially by continuously adding nodes and experimenting with workload management (WLM), but it became abundantly obvious that they needed to take a more significant step to meet the needs of their users.
In 2021, FanDuel’s workloads almost tripled since they first started using Amazon Redshift in 2018, and they started evaluating Redshift RA3 nodes vs. DC2 nodes to take advantage of the storage and compute separation and deliver better performance at lower costs. FanDuel wanted to make the move primarily to separate storage and compute, and evaluate data sharing in the hopes of bringing different compute to the data to alleviate user contention on their primary cluster. FanDuel decided to launch a new RA3 cluster when they were satisfied that the performance matched that of their existing DC2 architecture, providing them the ability to scale storage and compute independently.
In 2022, FanDuel shifted their focus to using data sharing. Data sharing allows you to share live data securely across Redshift data warehouses for read and write (in preview) purposes. This means that workloads can be isolated to individual clusters, allowing for a more streamlined schema design, WLM configuration, and right-sizing for cost optimization. The following diagram illustrates this architecture.
To achieve a data sharing architecture, the plan was to first spin up consumer clusters for development and testing environments for their data engineers that were moving key legacy code to dbt. FanDuel wanted their engineers to have access to production datasets to test their new models and match the results from their legacy SQL-based code sets. They also wanted to ensure that they had adequate compute to run many jobs concurrently. After they saw the benefits of data sharing, they spun up their first production consumer cluster in the spring of 2022 to handle other analytics use cases. This was sharing most of the schemas and their tables from the main producer cluster.
Benefits of moving to a data sharing architecture
FanDuel saw a lot of benefits from the data sharing architecture, where data engineers had access to real production data to test their jobs without impacting the producer’s performance. Since splitting the workloads through a data sharing architecture, FanDuel has doubled their query concurrency and reduced the query queuing, resulting in a better end-to-end query time. FanDuel received positive feedback on the new environment and soon reaped the rewards of increased engineering velocity and reduced performance issues in production after deployments. Their initial venture into the world of data sharing was definitely considered a success.
Given the successful rollout of their first consumer in a data sharing architecture, they looked for opportunities to meet other users’ needs with new targeted consumers. With the assistance of AWS, FanDuel initiated the development of a comprehensive strategy aimed at safeguarding their extract, load, and transform (ELT) jobs. This approach involved implementing workload isolation and allocating dedicated clusters for these workloads, designated as the producer cluster within the data sharing architecture. Simultaneously, they planned to migrate all other activities onto one or more consumer clusters, apart from the existing cluster utilized by their data engineering team.
They spun up a second consumer in the summer of 2022 with the hopes of moving some of their more resource-intensive analytical processes off the main cluster. In order to empower their analysts over time, they had allowed a pattern in which users other than data engineers could create and share their own objects.
As the calendar flipped from 2022 to 2023, several developments changed the landscape of architecture at FanDuel. For one, FanDuel launched their initial event-based streaming work for their sportsbook data, which allowed them to micro-batch data into Amazon Redshift at a much lower latency than their previous legacy batch approach. This allowed them to generate C-Suite revenue reports at a much earlier SLA, which was a big win for the data team, because this was never achieved before the Super Bowl.
FanDuel introduced a new internal KPI called Query Efficiency, a measure to capture the amount of time users spent waiting for their queries to run. As the workload started increasing exponentially, FanDuel also noticed an increase in this KPI, specifically for risk and trading workloads.
Working with AWS Enterprise Support and the Amazon Redshift service team, FanDuel soon realized that the risk and trading use case was a perfect opportunity to move it to Amazon Redshift Serverless. Redshift Serverless offers scalability across dimensions such a data volume changes, concurrent users and query complexity, enabling you to automatically scale compute up or down to manage demanding and unpredictable workloads. Because billing is only accrued while queries are run, it also means that you no longer need to cover costs for compute you’re not utilizing. Redshift Serverless also manages workload management (WLM) entirely, allowing you to focus only on the query monitoring rules (QMRs) you want and usage limits, further limiting the need for you to manage your data warehouses. This adoption also complimented data sharing, where Redshift Serverless endpoints can read and write (in preview) from provisioned clusters during peak hours, offering flexible compute scalability and workload isolation and avoiding the impact on other mission-critical workloads. Seeing the benefits of what Redshift Serverless offers for their risk and trading workloads, they also moved some of their other workloads like business intelligence (BI) dashboards and risk and trading (RT) to a Redshift Serverless environment.
Benefits of introducing Redshift Serverless in a data sharing architecture
Through a combination of data sharing and a serverless architecture, FanDuel could elastically scale their most critical workloads on demand. Redshift Serverless Automatic WLM allowed users to get started without the need to configure WLM. With the intelligent and automated scaling capabilities of Redshift Serverless, FanDuel could focus on their business objectives without worrying about the data warehouse capacity. This architecture alleviated the constraints of a single predefined Redshift provisioned cluster and reduced the need for FanDuel to manage data warehouse capacity and any WLM configuration.
In terms of cost, Redshift Serverless enabled FanDuel to elegantly handle the most demanding workloads with a pay-as-you-go model, paying only when the data warehouse is in use, along with complete separation of compute and storage.
Having now introduced workload isolation and Redshift Serverless, FanDuel is able to achieve a more granular understanding of each team’s compute requirements without the noise of ELT and contending workloads all in the same environment. This allowed comprehensive analytics workloads to be conducted on consumers with vastly minimized contention while also being serviced with the most cost-efficient configuration possible.
The following diagram illustrates the updated architecture.
Results
FanDuel’s re-architecting efforts for workload isolation with risk and trading (RT) workloads using Redshift data sharing and Redshift Serverless resulted in the most critical business SLAs finishing three times faster, along with an increase in average query efficiency of 55% for overall workloads. These SLA improvements have resulted into an overall saving of tenfold in business cost, and they have been able to deliver business insights to other verticals such as product, commercial, and marketing much faster.
Conclusion
By harnessing the power of Redshift provisioned clusters and serverless endpoints with data sharing, FanDuel has been able to better scale and run analytical workloads without having to manage any data warehouse infrastructure. FanDuel is looking forward to future Amazon partnerships and is excited to embark on a journey of new innovation with Redshift Serverless and continued enhancements such as machine learning optimization and auto scaling.
If you’re new to Amazon Redshift, you can explore demos, other customer stories, and the latest features at Amazon Redshift. If you’re already using Amazon Redshift, reach out to your AWS account team for support, and learn more about what’s new with Amazon Redshift.
About the authors
Sreenivasa Munagala is a Principal Data Architect at FanDuel Group. He defines their Amazon Redshift optimization strategy and works with the data analytics team to provide solutions to their key business problems.
Matt Grimm is a Principal Data Architect at FanDuel Group, moving the company to an event-based, data-driven architecture using the integration of both streaming and batch data, while also supporting their Machine Learning Platform and development teams.
Luke Shearer is a Cloud Support Engineer at Amazon Web Services for the Data Insight Analytics profile, where he is engaged with AWS customers every day and is always working to identify the best solution for each customer.
Dhaval Shah is Senior Customer Success Engineer at AWS and specializes in bringing the most complex and demanding data analytics workloads to Amazon Redshift. He has more then 20 years of experiences in different databases and data warehousing technologies. He is passionate about efficient and scalable data analytics cloud solutions that drive business value for customers.
Ranjan Burman is an Sr. Analytics Specialist Solutions Architect at AWS. He specializes in Amazon Redshift and helps customers build scalable analytical solutions. He has more than 17 years of experience in different database and data warehousing technologies. He is passionate about automating and solving customer problems with cloud solutions.
Sidhanth Muralidhar is a Principal Technical Account Manager at AWS. He works with large enterprise customers who run their workloads on AWS. He is passionate about working with customers and helping them architect workloads for cost, reliability, performance, and operational excellence at scale in their cloud journey. He has a keen interest in data analytics as well.
Security updates have been issued by Fedora (chromium), Mageia (firefox, thunderbird, and vim), SUSE (kubevirt, virt-api-container, virt-controller-container, virt-handler-container, virt-launcher-container, virt-libguestfs-tools- container, virt-operator-container), and Ubuntu (freerdp2, glibc, and tinyxml).
BLUFFS is a series of exploits targeting Bluetooth, aiming to break Bluetooth sessions’ forward and future secrecy, compromising the confidentiality of past and future communications between devices.
This is achieved by exploiting four flaws in the session key derivation process, two of which are new, to force the derivation of a short, thus weak and predictable session key (SKC).
Next, the attacker brute-forces the key, enabling them to decrypt past communication and decrypt or manipulate future communications.
The vulnerability has been around for at least a decade.
Обидно за демокрацията, срамно за държавата, печелившо за управляващата коалиция, която си е съвсем истинска сглобка. Така изглежда политическата ситуация в България, вместена в малко думи. В дългия вариант за всяко от тези съждения има куп аргументи.
Пари и власт и тяхното разпределение между трите политически сили ПП–ДБ, ГЕРБ–СДС и ДПС – това са ябълките на раздора в последните седмици на 2023 г. За първи път, откакто ГЕРБ падна от власт през 2021 г., партиите на Бойко Борисов и на Ахмед Доган (пак) се включват в разпределението на разходите в бюджета – като част от конституционноТО, евроатлантическоТО и изобщо управляващоТО мнозинство. А тези партии стомаси са известни с апетитите си – „хранят“ доста бизнеси. Значително по-обиграни са в политически план от ПП–ДБ, а разполагат и с друго тактическо предимство – „играли“ са заедно и преди, сглобката им е смазана от години.
За ПП–ДБ правителството е безалтернативно и затова се налага да го подкрепят съвместно с ГЕРБ. Присъствието на ДПС също обясняват с крайна необходимост, но не и с партньорство – нужни са 160 гласа за конституционните промени. Какво тогава търсят ДПС и председателят на парламентарната му група Делян Пеевски при вземането на всички решения от управляващото мнозинство?!
Квоти за регулаторите
Освен за бюджетните разходи, неминуеми са кавгите за назначенията в регулаторите и кадровиците на съдебната система, които ще се състоят след конституционните промени, насрочени за гласуване през декември. Дотогава се очаква да е готов и регламент за назначенията, за какъвто се договориха ПП–ДБ, ГЕРБ и ДПС, но не пречи да има назначени и преди приемането му. Как ще се поделят позициите в регулаторите, изглежда най-парливият въпрос, след като всички вече приехме, че най-нормалното нещо на света е това да стане в рамките на новия триъгълник на властта.
Допреди няколко месеца върли политически противници, днес „добрите“ и „лошите“ управляват заедно, заедно ще реформират съдебната система и най-големият проблем, изглежда, са квотите в регулаторите. Назначените в тях ще укрепят всяка политическа сила, тъй като са с мандати от по няколко години, които надхвърлят средната продължителност на живот на правителствата, и контролират пазари за милиарди, както и информационни масиви.
Оказа се, че в тази категория са и шефовете на спецслужбите. Но без реформата им, заложена в приоритетите, върху които стъпи правителството на Денков–Габриел. За отсъствието ѝ мълчаливо се съгласиха и трите политически сили.
Пред bTV тази седмица председателят на ПГ на ГЕРБ Десислава Атанасова обяви, че членовете на регулаторите ще се назначават с мнозинство от 160 гласа – и ДПС ще участва в процеса, получавайки 1/3 тежест. От ПП–ДБ са уклончиви дали това е така, след като процесът още не е започнал. Но всъщност е – с избора на ръководство на БНБ, където ГЕРБ си запази гуверньора, избран още при управлението на Бойко Борисов, а ПП–ДБ и ДПС получиха по един подуправител. Публично потвърждение на думите на Атанасова обаче няма да донесе позитиви на ПП–ДБ, които бездруго понасят негативите от управлението.
Отговорът на най-съществения за общественото благо въпрос – как това кадруване ще повлияе на зле изградените и поради това неработещи демократични институции, ще дойде много по-късно.
Блокадата за бюджета падна
Бюджетът за 2023 г. се прие в средата на годината и нямаше как да предизвика особени крамоли поради крайно належащата необходимост да го има. Предишният за 2022 г. също закъсня, макар и с по-малко. Гласуваха го в края на февруари и също не вдигна по-голям от обичайния шум, въпреки че правителството беше излъчено от широка коалиция между „Продължаваме промяната“, БСП, „Има такъв народ“ и „Демократична България“.
Освобождаването на директора на „Пирогов“ от здравния министър д-р Христо Хинков блокира за кратко обсъждането на проектобюджета за 2024 г. От ГЕРБ обявиха, че са имали уговорка да не се пипа д-р Валентин Димитров – шефът на най-голямото лечебно заведение за спешна помощ в България, „ако няма доклади, които да показват обратното“.
Преди това обаче с гласовете не само на ГЕРБ и ДПС, но и на други политически сили (без ПП–ДБ), бяха окастрени всички предложения на ръководеното от Асен Василев Министерство на финансите. Отпадна идеята за бонус, ако бъде подаден сигнал до данъчните за укрити данъци и осигуровки, стига да бъдат събрани поне 100 000 лева. Отпадна и предложението ресторантьорите да плащат заплати по банков път, в това число и за работодатели с под 100 работници. Отпаднаха и данък „бакшиш“ и превръщането на гражданските договори в трудови по преценка на НАП. Депутатите обаче одобриха предложение на Десислава Танева от ГЕРБ, макар да не беше подкрепено от бюджетната комисия. Става въпрос за данъчно облекчение за земеделските стопани – субсидии до 100 000 лв. няма да бъдат облагаеми, с тази сума ще се намалява данъчната основа преди облагане.
Но странното е, че Василев не се ядоса на тeзи промени, а на бавенето на бюджета, и заяви, че:
Ако един министър не може да си осигури подкрепа за политиката, която провежда, най-правилно е да си подаде оставката, вместо да прави циркове и да блокира държавата.
Де факто искането му за оставка на проф. Хинков беше подкрепено от лидера на ГЕРБ и разгневи ДБ – здравният министър е от тяхната квота (номинация на ДСБ).
Но бюджетът все пак ще влезе в пленарна зала, след като парламентарната здравна комисия, чийто председател е Костадин Ангелов от ГЕРБ, предложи на министъра да оттегли протокола за отстраняването на шефа на „Пирогов“ до приключване на проверки от външни одити и останалите органи, които го проверяват. Остава въпросът дали Хинков ще се съобрази с тази… препоръка.
Напрежението около отстраняването на д-р Димитров извади наяве и вътрешни конфликти в коалицията ПП–ДБ, тъй като депутати от „Продължаваме промяната“ застанаха (не за първи път) срещу Хинков – било поради лични амбиции за постове или с други мотиви.
Конституционните промени – в галоп
Бързината, с която е програмирано да се приемат конституционните промени – на три четения през декември, изненада мнозина юристи. „Нямам обяснение за бързането с гласуването на промените в Конституцията“, каза тази седмица по БНР проф. Екатерина Михайлова, преподавател по конституционно право в НБУ и зам.-председател на 40-тото и 41-вото Народно събрание. Тя припомни и призива на правосъдния министър Атанас Славов:
Депутатите да не пришпорват процеса, а по-скоро да се търси качество и сигурност в предлагането на окончателните текстове.
Но вече стана ясно, че проектът ще претърпи доста промени, част от които свързани с правомощията на президента при назначаване на служебно правителство. Изглежда, че те няма да са така радикални, както беше обявено, а ще се търси възможност за колаборация между двете институции – президент и парламент, при подбора на фигурите в кабинета.
Други основни промени са свързани със съдебната реформа – най-съществената част от проекта, от която зависи дали Висшият съдебен съвет ще бъде разделен на прокурорска и съдийска колегия, в която съдиите да имат мнозинство, и дали прокуратурата ще има по-голяма отчетност и по-малко правомощия. По третата промяна – отпадане на изискването министрите и депутатите да са само български граждани, просто се мълчи.
Тази седмица по bTV депутатът от ПП–ДБ Ивайло Мирчев каза:
Ако Конституцията не бъде приета под тази форма, ключовите министри подават оставка. До момента такива индикации по отношение на Конституцията няма.
Значи няма да има оставки, но най-вероятно ще се чака произнасяне на Конституционния съд.
„Лукойл“ се изтегля от България
Игрите с премахване на дерогацията за „Лукойл“, което ГЕРБ и ДПС уж все се опитват да изтеглят за 1 януари 2024 г. вместо за март, както се договориха трите политически сили, показват, че развръзката е близо. Предстоящата продажба на бургаската рафинерия очевидно е навлязла в крайна фаза и изостря апетитите на местните (политически) играчи. След като ГЕРБ и ДПС сменяха позиции на 180 градуса буквално за часове, в крайна сметка се разбраха с ПП–ДБ, че дерогацията се прекратява на 1 март 2024 г. – тоест от тази дата рафинерията трябва да преработва само неруски петрол. Това е 7 месеца по-рано от крайния срок, отпуснат от Европейската комисия миналото лято.
Няма потвърждение с кой инвеститор преговаря частната руска компания – с азерската държавна петролна и газова компания SOCAR, която вече осигурява 30% от газа за България, с инвеститор от Дубай или с американска компания. Появиха се слухове за полския енергиен концерн Orlen и дори за купувачи от Украйна. Едно е сигурно – български политици играят за интересите на някои от потенциалните купувачи. Само така може да бъде обяснена настойчивостта на ГЕРБ и ДПС да бъде отменено изключението за внос на руски суров петрол по море колкото се може по-бързо. Но не и с евроатлантизма на „Д2“, както бяха наречени Делян Добрев от ГЕРБ и Делян Пеевски, които в продължение на дни размахваха пръст, че продажбите на „Лукойл“ финансират войната на Путин в Украйна.
Според енергийния експерт Мартин Владимиров към „Лукойл“ има интерес и от Азербайджан, и от Турция. Пред „Фрогнюз“ експертът от Центъра за изследване на демокрацията отбелязва, че в съседна Турция SOCAR оперира най-голямата рафинерия, като внася основно руски, а не азерски петрол. „В замяна е получила огромен заем от „Литаско“, която е собственик на бургаската рафинерия“, казва Владимиров. Ако тази сделката с азерския купувач се състои, България ще намали зависимостта си от руския петрол само на хартия, прогнозира той.
След като премине през всички тези плитчини, сглобката ще се закали още повече и догодина може и да не е така паянтова, както я нарича Бойко Борисов. Но на политически трусове тези постройки са по-издръжливи от монолитните – защото са си безалтернативни.
В четвъртата част от поредицата ни за бизнеса ще разгледаме една не съвсем позната, но все по-важна част от българската икономика – финтех. Какво значи финтех, какви проблеми решават финтех компаниите и с какви предизвикателства се сблъскват? Отговорите ще потърсим с директора на Българската финтех асоциация – Георги Пенев.
Георги Пенев започва работа в ИТ сектора преди 8 години, след което бързо преминава към водеща роля в бизнес развитието на печелеща награди българска финтех компания. Има бакалавърска степен по политически науки от УНСС и магистърска степен по публична политика и мениджмънт от Университета в Глазгоу.
Георги, може ли да обясните накратко какво стои зад понятието финтех?
Терминът е съчетание от думите финанси и технологии. Финтех се отнася за компаниите, които прилагат технологии за улесняване, дигитализиране и автоматизиране на финансовите услуги. Може би най-известният пример за технологии във финансите е банкоматът. В най-общ смисъл обаче финтех обхваща иновациите във финансовия сектор, които конкурират традиционните финансови процеси и институции, като банките например.
Как се развива секторът у нас през годините?
Историята всъщност е много интересна. Ровейки се из различни източници, открих, че през 1968 г. Българската народна банка (БНБ) започва да използва компютър – колкото стая, за изчисляване на сметки. Затова може да приемем тази година за отправна точка. Финтех всъщност започва от банките. Първата финтех компания след падането на тоталитарния режим у нас е добре познатата на всички „Борика“, в която участие има и държавата.
С технологичния бум обаче тежестта постепенно се измества към услуги, сходни на банковите и предлагани от малки и средни предприятия, но с по-високо качество от гледна точка на бързина, достъпност и цена. Днес финансите на всеки от нас са на само няколко клика разстояние през телефона. А разплащанията, кредитите и застраховките например са само част от широката гама от услуги и продукти, които обхваща финтех индустрията.
Имате ли данни колко голяма всъщност е финтех индустрията в България и какъв дял представлява от икономиката ни?
В България оперират 156 финтех компании, без да броим банките, а заетите наброяват приблизително 12 000 души. По данни на годишните ни отчети приблизително 44% от служителите в сектора са жени. За сравнение, заетите във Великобритания жени в нашата сфера са едва 30%. Средната брутна заплата на работещите пък надхвърля 3000 лв. Редно е да отбележим, че извадката за данните е от 22 компании. Над 80% от финтех компаниите в България са малки и средни предприятия. И не са само български – на нашия пазар оперират около 60 чуждестранни компании с българските си дружества или с офиси у нас.
Бихте ли ни разказал как технологиите променят финансовия свят?
С развитието на компютърните и информационните технологии финансовият свят става все по-достъпен за все повече хора. Процесът на financial inclusion, или включването на повече хора във финансовия свят, се ускори драстично през последните години. Необходимостта да посещаваме физически банкови офиси например става все по-малка. С едно обаждане можем да решаваме финансови въпроси, а с електронна идентификация през телефона можем да изпълним административни задачи бързо и лесно.
Всяка страна върви по този път, адаптирайки се към собствените си особености и развитие. Страните от Африка също търсят креативни решения и модернизация на финансовия сектор въпреки лошата си инфраструктура и условия. Хората в Кения например имат възможност за банкиране чрез SMS система, известна като M-PESA, която улеснява трансфера на средства, предоставяйки значителна сигурност на потребителите.
С какво финтех е ценен за българската икономика?
Компаниите в сектора са предимно малки и средни предприятия, които играят ключова роля във финансовия сектор, без да имат банков лиценз. Тоест те не оперират като банки, но предлагат сходни услуги и продукти по много по-лесен и удобен начин. В същото време финтех компаниите не подлежат на всички тежки финансови регулации като банките, което ги прави много по-гъвкави.
Финтех практически съществува, защото финансовите иновации, технологии и дигитализацията изпреварват съществуващото законодателство, което трябва да ги регулира. А това води до няколко важни предимства за пазара.
Четири от пет компании в сектора са с реализиран висок експортен потенциал и са около четири пъти по-добре позиционирани на чуждестранните пазари от средното за българските фирми.
Българската финтех асоциация работи за най-добро позициониране на страната ни на европейско и световно ниво. Добрият имидж и подготвените ИТ кадри у нас носят изключителна добавена стойност на страната ни, защото привличат ключови чуждестранни инвестиции и предприемачи. Немската Commerzbank например разкри отдела си за дигитална трансформация от около 300 души именно в България.
Сама по себе си финтех индустрията произведе малко над 1,5 млрд. лв. приходи за 2021 г. И макар да е все още малка като дял от брутния вътрешен продукт, финтех нишата придобива все по-ключово значение за българската икономика заради високата конкурентоспособност на компаниите на европейските и глобалните пазари.
А с какви предизвикателства се сблъсква развитието на финтех средата?
Освен финтех компаниите, екосистемата обхваща множество други компании и хора с подпомагащи функции, например специалисти по киберсигурност, адвокати и кантори, специализирани в сферата, и др. За да продължи да се развива финтех екосистемата, е нужно засилено взаимодействие както с държавата, така и с академичните среди.
Предизвикателствата пред сектора са свързани най-вече със създаването на устойчиви връзки между бизнеса и институциите. Преди всичко е нужно да се обясни важността на сектора както от икономическа, така и от чисто практическа перспектива за потребителите. БНБ като висш надзорен орган и Комисията за финансов надзор (КФН) като регулатор все още не третират финтех компаниите с нужното внимание. Липсата на надзор обаче крие рискове и създава условия за злоупотреби.
Същевременно БНБ няма дългосрочна стратегия за развитието на финансовия сектор у нас, което води до липса на сигурност и предвидимост за компаниите. Затова е нужно спешно осъвременяване на работата на надзорните органи и регулаторите, за да посрещат изискванията на динамичната финансова среда.
Какви са конкретните стъпки за осъвременяването им?
Преди всичко трябва да се подобри комуникационната инфраструктура между институциите и бизнеса. Това може да стане чрез въвеждане на т.нар. иновационни фасилитатори. Те представляват единна централизирана точка за комуникация между БНБ, регулаторите и бизнеса. Може да звучи сложно, но всъщност става въпрос за създаване на обикновени канали за комуникация, като телефонна връзка и имейл, чрез които компаниите да имат постоянен достъп до експертност от БНБ, КФН и Комисията за защита на личните данни.
Идеята е финтех компаниите и предприемачите в сектора да могат да предоставят своите идеи и план за развитие (pitch deck), да разберат дали са приложими спрямо местното законодателство, да научат на какви регулации трябва да отговарят, за да установят бизнеса си, трябва ли им определен лиценз и т.н. Въпреки че информацията, предоставена от органите, няма как да е законово обвързваща – тоест не можеш да се позоваваш на нея в съда например, – тя би била изключително ценна за компаниите, защото идва от най-висша инстанция. Такива иновационни фасилитатори действат успешно в прибалтийските държави. Само за миналата година в Естония са постъпили близо 300 запитвания към финансовия регулатор относно правенето на финтех бизнес в страната, 70% от които на английски език. Това свидетелства за огромния интерес към разгръщане на чужди бизнеси на територията на страната.
С какво могат да допринесат политиците?
Липсата на адекватно законодателство към момента крие както рискове, така и възможности. Политиците могат да отключат солиден потенциал за развитие с правилните промени, от което да спечелим всички ние като граждани. Ето и един важен пример. Всеки от нас плаща данъци. Това става дигитално с карта или на установените физически локации. Законът досега не позволява транзакциите да се извършват през финтех платформи.
Проблемът тук е, че при всяко картово разплащане държавата плаща на съответната банка такса под формата на процент от сумата. Финтех компаниите могат да предоставят същата услуга, но на много по-ниска цена – таксите могат да бъдат намалени с поне 50%, което по наши изчисления би спестило на държавата и данъкоплатеца десетки милиони левове годишно.
В по-глобален мащаб политиците ни трябва да издигнат развитието на финансовия сектор и иновациите като приоритет. Друга постсоциалистическа страна, като Литва, вече има над 200 финтех компании. Това в голяма степен е резултат от обявената през 2016 г. национална цел страната да се превърне в стартъп нация. Точно заради държавната подкрепа една от най-популярните финтех компании – Revolut, получи банков лиценз точно от Литва. Лиценз, който използва из целия Европейски съюз.
Ако погледнем към образованието, Финтех асоциацията е известна и с тясното си сътрудничество с академичните среди. Как си взаимодействате с учебните заведения?
В колаборация със Стопанския факултет на Софийския университет „Св. Климент Охридски“ подкрепяме магистърската програма по финанси, инвестиции и финтех с преподаватели и практици от частния сектор. Заедно провеждаме ежегодно и финтех хакатон – From Zero to Fintech, с идеята да дадем възможност на студентите да създадат собствена финтех компания. В рамките на семинарите и уъркшопите участниците имат възможност да развият бизнес модела си, да тестват продукта си и да предоставят решение на реален финтех казус.
Освен на ниво висше образование подкрепяме въвеждането на образователни програми за финансова грамотност сред учениците. Целта е да се запознаят с функционирането на финансовия свят и да придобият чисто практически знания за традиционните и алтернативните финансови услуги и продукти, за положителните им страни и рисковете, които крият.
Over 15 years ago, GitHub started as a Ruby on Rails application with a single MySQL database. Since then, GitHub has evolved its MySQL architecture to meet the scaling and resiliency needs of the platform—including building for high availability, implementing testing automation, and partitioning the data. Today, MySQL remains a core part of GitHub’s infrastructure and our relational database of choice.
This is the story of how we upgraded our fleet of 1200+ MySQL hosts to 8.0. Upgrading the fleet with no impact to our Service Level Objectives (SLO) was no small feat–planning, testing and the upgrade itself took over a year and collaboration across multiple teams within GitHub.
Motivation for upgrading
Why upgrade to MySQL 8.0? With MySQL 5.7 nearing end of life, we upgraded our fleet to the next major version, MySQL 8.0. We also wanted to be on a version of MySQL that gets the latest security patches, bug fixes, and performance enhancements. There are also new features in 8.0 that we want to test and benefit from, including Instant DDLs, invisible indexes, and compressed bin logs, among others.
GitHub’s MySQL infrastructure
Before we dive into how we did the upgrade, let’s take a 10,000-foot view of our MySQL infrastructure:
Our fleet consists of 1200+ hosts. It’s a combination of Azure Virtual Machines and bare metal hosts in our data center.
We store 300+ TB of data and serve 5.5 million queries per second across 50+ database clusters.
Our data is partitioned. We leverage both horizontal and vertical sharding to scale our MySQL clusters. We have MySQL clusters that store data for specific product-domain areas. We also have horizontally sharded Vitess clusters for large-domain areas that outgrew the single-primary MySQL cluster.
We have a large ecosystem of tools consisting of Percona Toolkit, gh-ost, orchestrator, freno, and in-house automation used to operate the fleet.
All this sums up to a diverse and complex deployment that needs to be upgraded while maintaining our SLOs.
Preparing the journey
As the primary data store for GitHub, we hold ourselves to a high standard for availability. Due to the size of our fleet and the criticality of MySQL infrastructure, we had a few requirements for the upgrade process:
We must be able to upgrade each MySQL database while adhering to our Service Level Objectives (SLOs) and Service Level Agreements (SLAs).
We are unable to account for all failure modes in our testing and validation stages. So, in order to remain within SLO, we needed to be able to roll back to the prior version of MySQL 5.7 without a disruption of service.
We have a very diverse workload across our MySQL fleet. To reduce risk, we needed to upgrade each database cluster atomically and schedule around other major changes. This meant the upgrade process would be a long one. Therefore, we knew from the start we needed to be able to sustain operating a mixed-version environment.
Preparation for the upgrade started in July 2022 and we had several milestones to reach even before upgrading a single production database.
Prepare infrastructure for upgrade
We needed to determine appropriate default values for MySQL 8.0 and perform some baseline performance benchmarking. Since we needed to operate two versions of MySQL, our tooling and automation needed to be able to handle mixed versions and be aware of new, different, or deprecated syntax between 5.7 and 8.0.
Ensure application compatibility
We added MySQL 8.0 to Continuous Integration (CI) for all applications using MySQL. We ran MySQL 5.7 and 8.0 side-by-side in CI to ensure that there wouldn’t be regressions during the prolonged upgrade process. We detected a variety of bugs and incompatibilities in CI, helping us remove any unsupported configurations or features and escape any new reserved keywords.
To help application developers transition towards MySQL 8.0, we also enabled an option to select a MySQL 8.0 prebuilt container in GitHub Codespaces for debugging and provided MySQL 8.0 development clusters for additional pre-prod testing.
Communication and transparency
We used GitHub Projects to create a rolling calendar to communicate and track our upgrade schedule internally. We created issue templates that tracked the checklist for both application teams and the database team to coordinate an upgrade.
Project Board for tracking the MySQL 8.0 upgrade schedule
Upgrade plan
To meet our availability standards, we had a gradual upgrade strategy that allowed for checkpoints and rollbacks throughout the process.
Step 1: Rolling replica upgrades
We started with upgrading a single replica and monitoring while it was still offline to ensure basic functionality was stable. Then, we enabled production traffic and continued to monitor for query latency, system metrics, and application metrics. We gradually brought 8.0 replicas online until we upgraded an entire data center and then iterated through other data centers. We left enough 5.7 replicas online in order to rollback, but we disabled production traffic to start serving all read traffic through 8.0 servers.
The replica upgrade strategy involved gradual rollouts in each data center (DC).
Step 2: Update replication topology
Once all the read-only traffic was being served via 8.0 replicas, we adjusted the replication topology as follows:
An 8.0 primary candidate was configured to replicate directly under the current 5.7 primary.
Two replication chains were created downstream of that 8.0 replica:
A set of only 5.7 replicas (not serving traffic, but ready in case of rollback).
A set of only 8.0 replicas (serving traffic).
The topology was only in this state for a short period of time (hours at most) until we moved to the next step.
To facilitate the upgrade, the topology was updated to have two replication chains.
Step 3: Promote MySQL 8.0 host to primary
We opted not to do direct upgrades on the primary database host. Instead, we would promote a MySQL 8.0 replica to primary through a graceful failover performed with Orchestrator. At that point, the replication topology consisted of an 8.0 primary with two replication chains attached to it: an offline set of 5.7 replicas in case of rollback and a serving set of 8.0 replicas.
Orchestrator was also configured to blacklist 5.7 hosts as potential failover candidates to prevent an accidental rollback in case of an unplanned failover.
Primary failover and additional steps to finalize MySQL 8.0 upgrade for a database
Step 4: Internal facing instance types upgraded
We also have ancillary servers for backups or non-production workloads. Those were subsequently upgraded for consistency.
Step 5: Cleanup
Once we confirmed that the cluster didn’t need to rollback and was successfully upgraded to 8.0, we removed the 5.7 servers. Validation consisted of at least one complete 24 hour traffic cycle to ensure there were no issues during peak traffic.
Ability to Rollback
A core part of keeping our upgrade strategy safe was maintaining the ability to rollback to the prior version of MySQL 5.7. For read-replicas, we ensured enough 5.7 replicas remained online to serve production traffic load, and rollback was initiated by disabling the 8.0 replicas if they weren’t performing well. For the primary, in order to roll back without data loss or service disruption, we needed to be able to maintain backwards data replication between 8.0 and 5.7.
MySQL supports replication from one release to the next higher release but does not explicitly support the reverse (MySQL Replication compatibility). When we tested promoting an 8.0 host to primary on our staging cluster, we saw replication break on all 5.7 replicas. There were a couple of problems we needed to overcome:
In MySQL 8.0, utf8mb4 is the default character set and uses a more modern utf8mb4_0900_ai_ci collation as the default. The prior version of MySQL 5.7 supported the utf8mb4_unicode_520_ci collation but not the latest version of Unicode utf8mb4_0900_ai_ci.
MySQL 8.0 introduces roles for managing privileges but this feature did not exist in MySQL 5.7. When an 8.0 instance was promoted to be a primary in a cluster, we encountered problems. Our configuration management was expanding certain permission sets to include role statements and executing them, which broke downstream replication in 5.7 replicas. We solved this problem by temporarily adjusting defined permissions for affected users during the upgrade window.
To address the character collation incompatibility, we had to set the default character encoding to utf8 and collation to utf8_unicode_ci.
For the GitHub.com monolith, our Rails configuration ensured that character collation was consistent and made it easier to standardize client configurations to the database. As a result, we had high confidence that we could maintain backward replication for our most critical applications.
Challenges
Throughout our testing, preparation and upgrades, we encountered some technical challenges.
What about Vitess?
We use Vitess for horizontally sharding relational data. For the most part, upgrading our Vitess clusters was not too different from upgrading the MySQL clusters. We were already running Vitess in CI, so we were able to validate query compatibility. In our upgrade strategy for sharded clusters, we upgraded one shard at a time. VTgate, the Vitess proxy layer, advertises the version of MySQL and some client behavior depends on this version information. For example, one application used a Java client that disabled the query cache for 5.7 servers—since the query cache was removed in 8.0, it generated blocking errors for them. So, once a single MySQL host was upgraded for a given keyspace, we had to make sure we also updated the VTgate setting to advertise 8.0.
Replication delay
We use read-replicas to scale our read availability. GitHub.com requires low replication delay in order to serve up-to-date data.
Earlier on in our testing, we encountered a replication bug in MySQL that was patched on 8.0.28:
Replication: If a replica server with the system variable replica_preserve_commit_order = 1 set was used under intensive load for a long period, the instance could run out of commit order sequence tickets. Incorrect behavior after the maximum value was exceeded caused the applier to hang and the applier worker threads to wait indefinitely on the commit order queue. The commit order sequence ticket generator now wraps around correctly. Thanks to Zhai Weixiang for the contribution. (Bug #32891221, Bug #103636)
We happen to meet all the criteria for hitting this bug.
We use replica_preserve_commit_order because we use GTID based replication.
We have intensive load for long periods of time on many of our clusters and certainly for all of our most critical ones. Most of our clusters are very write-heavy.
Since this bug was already patched upstream, we just needed to ensure we are deploying a version of MySQL higher than 8.0.28.
We also observed that the heavy writes that drove replication delay were exacerbated in MySQL 8.0. This made it even more important that we avoid heavy bursts in writes. At GitHub, we use freno to throttle write workloads based on replication lag.
Queries would pass CI but fail on production
We knew we would inevitably see problems for the first time in production environments—hence our gradual rollout strategy with upgrading replicas. We encountered queries that passed CI but would fail on production when encountering real-world workloads. Most notably, we encountered a problem where queries with large WHERE IN clauses would crash MySQL. We had large WHERE IN queries containing over tens of thousands of values. In those cases, we needed to rewrite the queries prior to continuing the upgrade process. Query sampling helped to track and detect these problems. At GitHub, we use Solarwinds DPM (VividCortex), a SaaS database performance monitor, for query observability.
Learnings and takeaways
Between testing, performance tuning, and resolving identified issues, the overall upgrade process took over a year and involved engineers from multiple teams at GitHub. We upgraded our entire fleet to MySQL 8.0 – including staging clusters, production clusters in support of GitHub.com, and instances in support of internal tools. This upgrade highlighted the importance of our observability platform, testing plan, and rollback capabilities. The testing and gradual rollout strategy allowed us to identify problems early and reduce the likelihood for encountering new failure modes for the primary upgrade.
While there was a gradual rollout strategy, we still needed the ability to rollback at every step and we needed the observability to identify signals to indicate when a rollback was needed. The most challenging aspect of enabling rollbacks was holding onto the backward replication from the new 8.0 primary to 5.7 replicas. We learned that consistency in the Trilogy client library gave us more predictability in connection behavior and allowed us to have confidence that connections from the main Rails monolith would not break backward replication.
However, for some of our MySQL clusters with connections from multiple different clients in different frameworks/languages, we saw backwards replication break in a matter of hours which shortened the window of opportunity for rollback. Luckily, those cases were few and we didn’t have an instance where the replication broke before we needed to rollback. But for us this was a lesson that there are benefits to having known and well-understood client-side connection configurations. It emphasized the value of developing guidelines and frameworks to ensure consistency in such configurations.
Prior efforts to partition our data paid off—it allowed us to have more targeted upgrades for the different data domains. This was important as one failing query would block the upgrade for an entire cluster and having different workloads partitioned allowed us to upgrade piecemeal and reduce the blast radius of unknown risks encountered during the process. The tradeoff here is that this also means that our MySQL fleet has grown.
The last time GitHub upgraded MySQL versions, we had five database clusters and now we have 50+ clusters. In order to successfully upgrade, we had to invest in observability, tooling, and processes for managing the fleet.
Conclusion
A MySQL upgrade is just one type of routine maintenance that we have to perform – it’s critical for us to have an upgrade path for any software we run on our fleet. As part of the upgrade project, we developed new processes and operational capabilities to successfully complete the MySQL version upgrade. Yet, we still had too many steps in the upgrade process that required manual intervention and we want to reduce the effort and time it takes to complete future MySQL upgrades.
We anticipate that our fleet will continue to grow as GitHub.com grows and we have goals to partition our data further which will increase our number of MySQL clusters over time. Building in automation for operational tasks and self-healing capabilities can help us scale MySQL operations in the future. We believe that investing in reliable fleet management and automation will allow us to scale github and keep up with required maintenance, providing a more predictable and resilient system.
The lessons from this project provided the foundations for our MySQL automation and will pave the way for future upgrades to be done more efficiently, but still with the same level of care and safety.
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.
Sreenivasa Munagala is a Principal Data Architect at FanDuel Group. He defines their Amazon Redshift optimization strategy and works with the data analytics team to provide solutions to their key business problems.
Matt Grimm is a Principal Data Architect at FanDuel Group, moving the company to an event-based, data-driven architecture using the integration of both streaming and batch data, while also supporting their Machine Learning Platform and development teams.
Luke Shearer is a Cloud Support Engineer at Amazon Web Services for the Data Insight Analytics profile, where he is engaged with AWS customers every day and is always working to identify the best solution for each customer.
Dhaval Shah is Senior Customer Success Engineer at AWS and specializes in bringing the most complex and demanding data analytics workloads to Amazon Redshift. He has more then 20 years of experiences in different databases and data warehousing technologies. He is passionate about efficient and scalable data analytics cloud solutions that drive business value for customers.
Ranjan Burman is an Sr. Analytics Specialist Solutions Architect at AWS. He specializes in Amazon Redshift and helps customers build scalable analytical solutions. He has more than 17 years of experience in different database and data warehousing technologies. He is passionate about automating and solving customer problems with cloud solutions.
Sidhanth Muralidhar is a Principal Technical Account Manager at AWS. He works with large enterprise customers who run their workloads on AWS. He is passionate about working with customers and helping them architect workloads for cost, reliability, performance, and operational excellence at scale in their cloud journey. He has a keen interest in data analytics as well.
