Security updates for Tuesday

Post Syndicated from corbet original https://lwn.net/Articles/1029919/

Security updates have been issued by Debian (ffmpeg), Fedora (gnutls, linux-firmware, mingw-djvulibre, mingw-python-requests, and salt), Mageia (qtimageformats6), Oracle (gnome-remote-desktop, golang, kernel, libxml2, and perl-File-Find-Rule), SUSE (gstreamer-plugins-base, gstreamer-plugins-good, kernel, and protobuf), and Ubuntu (apport, glibc, gnutls28, and roundcube).

Ядрената дилема на Иран: Към сделка или към нова война?

Post Syndicated from Искрен Иванов original https://www.toest.bg/yadrenata-dilema-na-iran-kum-sdelka-ili-kum-nova-voyna/

Ядрената дилема на Иран: Към сделка или към нова война?

Голяма част от анализите за региона на Близкия изток приемат за отправна точка на хипотезите си съществуващата дилема за сигурност между Държавата Израел и Ислямска република Иран заедно със съвременните тенденции във външната политика на САЩ. Въпреки предимствата си този подход крие един голям риск – ролята на Иран в региона далеч не се свежда до познатото ни уравнение в учебниците – когато една страна напада, другата се отбранява. Това е доста наивна представа за политическите реалности в Близкия изток, която не ни позволява правилно да оценим какви рискове крият иранските ядрени амбиции и защо ядрената програма на страната има глобални измерения. В този анализ ще се постараем да хвърлим светлина върху скритите аспекти на ядрената дилема на Иран и да отговорим на въпроса дали мечтаната ядрена сделка е постижима геополитическа реалност.

Стратегическата култура на Иран и ядрените ѝ амбиции

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

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

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

Това е силно идеологизирана презумпция, която не отговаря на историческата истина. От културно-историческа и политическа гледна точка Ислямска република Иран не може да се счита дори за правоприемник на шиитските империи от времето на Сефевидите по една основна причина: след Ислямската революция от 1979 г. шиитската традицията в страната се пречупва през визията на Рухола Хомейни – вилаят-е факих, която значително модифицира шиитската доктрина, отстоявана от иранските монархии в продължения на столетия. Хомейни „революционизира“ шиитската традиция, връчвайки политическата власт еднолично на духовенството – аятоласите, като отхвърля напълно принципа на секуларизма в политиката.

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

Наред с това, като оставим настрана и доктриналната сунитска несъвместимост с шиитския клон на исляма, идеите на Хомейни се сблъскват със сериозни критики от влиятелни шиитски учени, като Ал ал-Шишани и Садик ал-Ширази, които дефинират вилаят-е факих като тоталитарна религиозно-политическа доктрина. Тя циментира управлението на един лидер – аятолаха, лишавайки мюсюлманите от справедливото право да го свалят в случай на недоволство.

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

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

Възможните отговори са много, но най-прагматичният е един: той би бил много по-склонен да го използва, тъй като, за разлика от студения прагматизъм на Пхенян и Москва, политическата формула на властта в Техеран съдържа силен теократичен елемент, което я прави по-малко рационална и от Северна Корея, и от Русия. Да не говорим, че Иран няма да членува в нито един формат за ядрено сдържане, което ще го направи неуправляем дори за Русия.

Вторият е какво би се случило, ако иранските проксита в лицето на „Хизбула“ и на това, което е останало от „Хамас“, се сдобият с ядрен потенциал.

Тази опция не бива да се изключва, тъй като иранските управляващи на няколко пъти казаха каква е истинската им цел – унищожаването на Държавата Израел. Ако тези групировки се сдобият макар и с ограничен ядрен арсенал, тогава всички, които са убедени, че държавите са рационални актьори и няма да използват оръжия за масово унищожение, ще трябва да проверят дали валидността на теорията им може да бъде съотнесена и към трансграничните терористични мрежи.

Кои са сдържащите сили пред Иран в Близкия изток?

На този етап се очертават няколко актьора, които ефективно биха могли да сдържат Техеран. Първият е Израел. Причината е новата отбранителна доктрина на страната, която беше модифицирана в месеците след атаките на „Хамас“ от 7 октомври 2023 г. В своя оригинален вариант израелската отбранителна доктрина „Дахия“ съдържа постановката, че Израел си запазва правото да действа диспропорционално, в случай че бъде нападнат, но с презумпцията, че приоритетно трябва да бъдат поразени властовите и ресурсните центрове на агресора. Тази доктрина доминираше в израелското стратегически мислене в годините след 11 септември 2001 г. и многократно беше критикувана от европейските правителства под предлог, че взема много цивилни жертви. 

Подобна логика обаче е погрешна, тъй като по обхват доктрината е избирателна (може да се приложи или не в зависимост от решението на командването), а ако Европа има НАТО, Израел е сам срещу много противници в Близкия изток. Ето защо през 2024 г. Военното командване на Израел реши да реформира доктрината си, включвайки в нея концепцията за pre-emptive strike (изпреварващ удар): правото на един държавен актьор да нанесе предварителен военен удар върху друг, ако са налице доказателства, че действията на отсрещната страна са заплаха за националната сигурност на нападащата, един вид, „нападам, за да не бъда нападнат“. Тук е мястото да кажем, че това понятие няма общо с друго понятие – preventive war (превантивна война), при което държавите прилагат сила само въз основа на предположения, а не на реални доказателства за неизбежно нападение. 

Първото понятие попада под юрисдикцията на международните отношения като част от правото на всяка суверенна държава да се защитава, а второто е акт на военна агресия. В този смисъл руската военна интервенция срещу Украйна е израз на превантивна война (агресия) с предлога, че действията на Киев са заплаха за националната сигурност на Москва. Израелските удари върху иранската ядрена програма, от друга страна, са предварителен военен удар с цел ликвидирането на реално съществуваща заплаха за националната сигурност на страната. Взети заедно, доктрината „Дахия“ и концепцията за предварителния военен удар на този етап се явяват единствената регионална сдържаща сила пред ядрените амбиции на Иран.

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

Както историята често си прави шеги, изборът за това се падна на президент, който дълго време обещаваше на американците, че ще се грижи преди всичко за Америка, а след това за нейните съюзници. Доналд Тръмп се озова в същата роля като Удроу Уилсън и Франклин Рузвелт, чиято съпротива срещу влизането на САЩ в двете световни войни в крайна сметка беше победена от нуждата някой да балансира разрушителните амбиции на агресорите. Вашингтон попадна в тази позиция за пореден път, тъй като обективният баланс на силите в системата на международните отношения го позиционира като единствения държавен актьор, който разполага с военностратегическите, икономическите и културните ресурси да реагира във всяка точка на света. В допълнение, лобито на изолационистите в американската външна политика е изключително малко и влиянието му върху Тръмп е по-скоро периферно. 

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

Последната сдържаща сила пред Иран са останалите арабски държави, и по-точно Кралство Саудитска Арабия.

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

Република Турция, от друга страна, като част от НАТО и бидейки под американския ядрен чадър, си позволява лукса да флиртува с Иран. Това ѝ дава възможност да балансира между САЩ и Иран в позицията си и донякъде е мотив за Вашингтон да пуска покрай ушите си турските критики към Израел. Дали обаче Анкара ще продължи в същия дух при една повторна намеса на САЩ в Близкия изток или ако в близко бъдеще иранските шиитски проксита опитат терористичен атентат на турска територия – предстои да видим.

Какво ни чака оттук нататък?

Най-лесният начин да предвидим какво ни чака оттук нататък, е не чрез напразни идеологически догадки и политически мотивирани лозунги, а на базата на ясни емпирични изчисления. Теорията за войната на Фиърън е ценен източник на модел за бъдещето на региона и мястото на Иран в него. В същността си тази теория е много подходяща за конкретния конфликт, тъй като посочва като причини за всяка война липсата на информация (дезинформацията) и невъзможността да се установи диалог. Това са и двете причини, поради които днес Близкият изток е пред дилемата на затворника, както се нарича на езика на международните отношения. От нея не може да избяга нито един актьор, колкото и силен да е той.

Първият формат, в който може да се реализира политиката на Иран в региона, е конфронтационният.

Това е най-лошият възможен сценарий, тъй като при него дезинформацията, разпространявана от Техеран посредством „Хизбула“ и „Хамас“, ще продължава да се засилва, което ще доведе до липса на всякакъв диалог с Америка и съюзниците ѝ. Резултатите от такъв курс на събитията са ясни: нова война, в която Вашингтон ще се включи активно, за да защити Израел, а европейските държави вероятно ще участват избирателно. 

Позицията на Франция ще е решаваща за Европа в този случай, тъй като само американската и френската армия разполагат със сили, които могат да бъдат разгърнати зад граница в най-кратък период. Такава война вероятно ще доведе до края на режима в Техеран и до окончателното унищожение на иранската ядрена програма. И нека не си правим илюзии, че в един такъв конфликт най-сетне ще видим кои държави ще застанат в лагера на демокрациите начело със САЩ и кои с мълчаливото си съгласие ще споделят симпатиите си към Иран и Русия. Във втория лагер по всяка вероятност ще попаднат традиционните партньори на Москва и Техеран, които са обединени от идеята да детронират глобалното лидерство на Вашингтон, а в първия – онези съюзници и партньори на САЩ, които прозират, че въпреки грешките си демокрациите остават най-добрият източник на сигурност и свобода.

Вторият сценарий не би бил толкова разрушителен за региона, но ще е най-мъчителен за Израел.

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

Ако Доналд Тръмп се съгласи с такова статукво в Близкия изток, за да си осигури подкрепата на консервативните републиканци изолационисти, той ще се върне към т.нар. политика на офшорно балансиране. САЩ ще продължат да снабдяват Израел с оръжия и ресурси, намесвайки се директно само ако иранските атаки застрашават пряко американските интереси. Ще станем свидетели на дирижирани битки и добре обмислени „сблъсъци“, което ще уеднакви политиката на Тръмп в региона с тази на Байдън. 

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

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

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

И накрая – нека си представим, че Иран просто спира с дезинформацията, без да води диалог, затваря се в себе си и не пречи на никого.

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

Днес обаче времената са други. Но да се върнем към розовия сценарий. Той е най-опасният, тъй като един ден Близкият изток ще се събуди на прага на втора Кубинска ракетна криза. В случай че това стане, Иран вече ще разполага с ракети, които могат да достигнат територията на европейските съюзници от НАТО, както и на Русия, Индия, Пакистан, Китай, а в дългосрочен план – и Източното крайбрежие на САЩ. Парадоксално е, че Америка осъзна тази реалност и без да е заплашена в краткосрочен план, се намеси, докато Европа, която е пряко застрашена, не го стори. 

Ако трябва да обобщим, съдбата на иранския ядрен въпрос не е просто политическа прищявка на Израел или пък популистки опит на Доналд Тръмп да докаже военностратегическото превъзходство на САЩ. То е геополитическа реалност, която засяга целия свят и за която изобщо не сме подготвени. А Европа закъснява отново. Фатално.

Hyper-volumetric DDoS attacks skyrocket: Cloudflare’s 2025 Q2 DDoS threat report

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/ddos-threat-report-for-2025-q2/

Welcome to the 22nd edition of the Cloudflare DDoS Threat Report. Published quarterly, this report offers a comprehensive analysis of the evolving threat landscape of Distributed Denial of Service (DDoS) attacks based on data from the Cloudflare network. In this edition, we focus on the second quarter of 2025. To view previous reports, visit www.ddosreport.com.

June was the busiest month for DDoS attacks in 2025 Q2, accounting for nearly 38% of all observed activity. One notable target was an independent Eastern European news outlet protected by Cloudflare, which reported being attacked following its coverage of a local Pride parade during LGBTQ Pride Month.

Key DDoS insights

  • DDoS attacks continue to break records. During 2025 Q2, Cloudflare automatically blocked the largest ever reported DDoS attacks, peaking at 7.3 terabits per second (Tbps) and 4.8 billion packets per second (Bpps).

  • Overall, in 2025 Q2, hyper-volumetric DDoS attacks skyrocketed. Cloudflare blocked over 6,500 hyper-volumetric DDoS attacks, an average of 71 per day. 

  • Although the overall number of DDoS attacks dropped compared to the previous quarter — which saw an unprecedented surge driven by a large-scale campaign targeting Cloudflare’s network and critical Internet infrastructure protected by Cloudflare — the number of attacks in 2025 Q2 were still 44% higher than in 2024 Q2. Critical infrastructure continues to face sustained pressure, with the Telecommunications, Service Providers, and Carriers sector jumping again to the top as the most targeted industry.

All the attacks in this report were automatically detected and blocked by our autonomous defenses.


To learn more about DDoS attacks and other types of cyber threats, refer to our Learning Center. Visit Cloudflare Radar to view an interactive version of this report where you can drill down further. Radar also offers a free API for those interested in investigating Internet trends. You can also learn more about the methodologies used in preparing these reports.

DDoS attacks in numbers

In 2025 Q2, Cloudflare mitigated 7.3 million DDoS attacks — down sharply from 20.5 million in Q1, when an 18-day campaign against Cloudflare’s own and other critical infrastructure protected by Cloudflare, drove 13.5 million of those attacks. 


DDoS attacks by quarter

We’ve just crossed halfway through 2025, and so far Cloudflare has already blocked 27.8 million DDoS attacks, equivalent to 130% of all the DDoS attacks we blocked in the full calendar year 2024.


DDoS attacks by year

Breaking it down further, Layer 3/Layer 4 (L3/4) DDoS attacks plunged 81% quarter-over-quarter to 3.2 million, while HTTP DDoS attacks rose 9% to 4.1 million. Year-over-year changes remain elevated. Overall attacks were 44% higher than 2024 Q2, with HTTP DDoS attacks seeing the largest increase of 129% YoY.


DDoS attacks by month

Hyper-volumetric DDoS attacks

In 2025 Q2, Cloudflare blocked over 6,500 hyper-volumetric DDoS attacks, averaging 71 hyper-volumetric attacks per day. Hyper-volumetric attacks include L3/4 DDoS attacks exceeding 1 Bpps or 1 Tbps, and HTTP DDoS attacks exceeding 1 million requests per second (Mrps).

The number of hyper-volumetric DDoS attacks exceeding 100 million packets per second (pps) surged by 592% compared to the previous quarter, and the number exceeding 1 billion pps and 1 terabits per second (Tbps) doubled compared to the previous quarter. The number of HTTP DDoS attacks exceeding 1 million rps (rps) remained the same at around 20 million in total, an average of almost 220,000 attacks every day.


Hyper-volumetric DDoS attacks in 2025 Q2

Threat actors

When asked who was behind the DDoS attacks they experienced in 2025 Q2, the majority (71%) of respondents said they didn’t know who attacked them. Of the remaining 29% of respondents that claimed to have identified the threat actor, 63% pointed to competitors, a pattern especially common in the Gaming, Gambling and Crypto industries. Another 21% attributed the attack to state-level or state-sponsored actors, while 5% each said they’d inadvertently attacked themselves (self-DDoS), were targeted by extortionists, or suffered an assault from disgruntled customers/users.


Top threat actors reported in 2025 Q2

Ransom DDoS attacks

The percentage of attacked Cloudflare customers that reported being targeted by a Ransom DDoS attack or that were threatened increased by 68% compared to the previous quarter, and by 6% compared to the same quarter in 2024. 


Ransom DDoS attacks by quarter 2025 Q2

Diving deeper, Ransom DDoS attacks soared in June 2025. Around a third of respondents reported being threatened or subjected to Ransom DDoS attacks.


Ransom DDoS attacks by month 2025 Q2

Top attacked locations

The ranking of the top 10 most attacked locations in 2025 Q2 shifted significantly. China climbed two spots to reclaim first place, Brazil jumped four spots to second place, Germany slipped two spaces to third place, India edged up one to fourth, and South Korea rose four to fifth. Turkey fell four places to sixth, Hong Kong dropped three to seventh, and Vietnam vaulted an astonishing fifteen spots into eighth. Meanwhile, Russia rocketed forty places to ninth, and Azerbaijan surged thirty-one to round out the top ten.


The locations most targeted by DDoS attacks for 2025 Q2

It’s important to note that these attacked locations are determined by the billing country of the Cloudflare customer whose services were targeted — not that those nations themselves are under attack. In other words, a high rank simply means more of our registered customers in that billing jurisdiction were targeted by DDoS traffic, rather than implying direct geopolitical targeting.

Top attacked industries

The ranking of the top 10 most attacked industries in 2025 Q2 also saw notable movement. Telecommunications, Service Providers and Carriers climbed one spot to claim first place, while the Internet sector jumped two spots to second place. Information Technology & Services held its placement as third most attacked, and Gaming rose one spot to fourth place. Gambling & Casinos slipped four spots to fifth place, and the Banking & Financial Services industry remained in sixth place. Retail inched up one spot to seventh place, and Agriculture made a dramatic 38-place leap into eighth. Computer Software climbed two spots to ninth place, and Government hopped two places to round out the top ten most attacked industries.


The top attacked industries of DDoS attacks for 2025 Q2

Top sources of DDoS attacks

The ranking of the top 10 largest sources of DDoS attacks in 2025 Q2 also saw several shifts compared to the previous quarter. Indonesia climbed one spot to claim the first place, Singapore jumped two places to second place, Hong Kong dropped two places to third, Argentina slipped one space as fourth and Ukraine held on as the fifth-largest source of DDoS attacks. Russia surged six spots as the sixth-largest source, followed by Ecuador who jumped seven places. Vietnam inched up one place as the eighth-largest source. The Netherlands moved up four places as the ninth-largest source, and Thailand fell three places as the tenth-largest source of DDoS attacks.


The top sources of DDoS attacks for 2025 Q2

It’s important to note that these “source” rankings reflect where botnet nodes, proxy or VPN endpoints reside — not the actual location of threat actors. For L3/4 DDoS attacks, where IP spoofing is rampant, we geolocate each packet to the Cloudflare data center that first ingested and blocked it, drawing on our presence in over 330 cities for truly granular accuracy.

Top source networks of DDoS attacks

An ASN (Autonomous System Number) is a unique identifier assigned to a network or group of IP networks that operate under a single routing policy on the Internet. It’s used to exchange routing information between systems using protocols like BGP (Border Gateway Protocol).

For the first time in about a year, the German-based Hetzner (AS24940) network dropped from the first place as the largest source of HTTP DDoS attack to the third place. In its place, Austrian-based Drei (AS200373) jumped 6 places as the number one largest source of HTTP DDoS attacks. The US-based DigitalOcean (AS14061) hopped one spot to the second place.


The top 10 ASN sources of HTTP DDoS attacks

As can be seen in the chart above, 8 out of 10 ASNs listed offer virtual machines (VMs), hosting, or cloud services which indicate the common use of VM-based botnets. These botnets are estimated to be 5,000x stronger than IoT-based botnets. Only Drei (AS200373) and ChinaNet Backbone (AS4134) are primarily ISPs or telecom carriers without significant public VM/cloud offerings.


IoT-based botnets versus VM-based botnets

To help hosting providers, cloud computing providers and any Internet service providers identify and take down the abusive accounts that launch these attacks, we leverage Cloudflare’s unique vantage point to provide a free DDoS Botnet Threat Feed for Service Providers. Over 600 organizations worldwide have already signed up for this feed, and we’ve already seen great collaboration across the community to take down botnet nodes. This is possible thanks to the threat feed which provides these service providers a list of offending IP addresses from within their ASN that we see launching HTTP DDoS attacks. It’s completely free and all it takes is opening a free Cloudflare account, authenticating the ASN via PeeringDB, and then fetching the threat intelligence via API.

With a simple API call, service providers can get a list of offending IPs from within their network. An example response is provided below.

{
  "result": [
    {
      "cidr": "127.0.0.1/32",
      "date": "2024-05-05T00:00:00Z",
      "offense_count": 10000
    },
    // ... other entries ...
  ],
  "success": true,
  "errors": [],
  "messages": []
}

Example response from the free ISP DDoS Botnet Threat Feed API

Attack vectors

Defending against DDoS Botnets

In Q2 2025, the majority (71%) of HTTP DDoS attacks were launched by known botnets. Rapid detection and blocking of these attacks was possible as a result of operating a massive network and seeing many different types of attacks and botnets. By leveraging real-time threat intelligence, our systems are able to incriminate DDoS botnets very fast, contributing to a more effective mitigation. Even if a DDoS botnet has been incriminated while targeting only one website or IP address, our entire network and customer base is immediately protected against it. This real-time threat intelligence system adapts with botnets as they morph and change nodes.


The top HTTP DDoS attack vectors for 2025 Q2

L3/4 attack vectors

In Q2 2025, DNS flood attacks were the top L3/4 attack vector accounting for almost a third of all L3/4 DDoS attacks. SYN floods was the second most common attack vector, dipping from 31% in Q1 to 27% in Q2. 

In third place, UDP floods also grew meaningfully, rising from 9% in Q1 to 13% in Q2. RST floods, another form of TCP-based DDoS attacks, accounting for 5% of all L3/4 attacks, was the fourth most common vector. Rounding out the top five, SSDP floods edged into fifth place at 3% despite a decline from 4.3% last quarter, but enough to push the previously prevalent Mirai attacks (which fell from 18% in Q1 to just 2% in Q2) out of the top five altogether.


The top L3/4 DDoS attack vectors for 2025 Q2

Breakdown of the top 3 L3/4 DDoS attack vectors

Below are details about the top 3 most common L3/4 DDoS attacks. We provide recommendations on how organizations can avoid becoming a reflection and amplification element, and also recommendations on how to defend against these attacks whilst avoiding impact to legitimate traffic. Cloudflare’s customers are protected against these attacks.

DNS Flood Attack

  • Type: Flood

  • How it works: A DNS flood aims to overwhelm a DNS server with a high volume of DNS queries—either valid, random, or malformed—to exhaust CPU, memory, or bandwidth. Unlike amplification attacks, this is a direct flood aimed at degrading performance or causing outages, often over UDP port 53, but sometimes over TCP as well (especially for DNS-over-TCP or DNSSEC-enabled zones).

  • How to defend against the attack: Use Cloudflare DNS as primary or secondary, Cloudflare DNS Firewall and/or Cloudflare Magic Transit to absorb and mitigate query floods before they reach your origin. Cloudflare’s global network handles tens of millions of DNS queries per second with built-in DDoS filtering and query caching, blocking malformed or excessive traffic while answering legitimate requests.

  • How to avoid unintended impact: Avoid blocking all DNS traffic or disabling UDP port 53, which would break normal resolution. Rely on Cloudflare’s DNS-specific protection such as the Advanced DNS Protection system, and deploy DNSSEC-aware protection to handle TCP-based query floods safely.

SYN Flood Attack

  • Type: Flood

  • How it works: In a SYN flood, threat actors  send a large volume of TCP SYN packets—often with spoofed IP addresses—to initiate connections that are never completed. This leaves the target system with half-open connections, consuming memory and connection tracking resources, potentially exhausting server limits and preventing real clients from connecting.

  • How to defend against the attack: Use Cloudflare Magic Transit to intercept and mitigate TCP SYN floods at the edge. Cloudflare leverages SYN cookies, connection tracking, and behavioral analysis to distinguish real clients from spoofed or malicious sources, ensuring legitimate TCP connections are completed successfully. Using Cloudflare’s CDN/WAF services or Cloudflare Spectrum which are both reverse-proxy services for HTTP or TCP, respectively. Using a reverse-proxy basically eliminates the possible impact of TCP-based DDoS attacks.

  • How to avoid unintended impact: Blocking all SYN traffic or applying aggressive timeouts can block real users. Instead, rely on Cloudflare’s Advanced TCP protection system, which uses SYN rate shaping, anomaly detection, and spoofed-packet filtering to mitigate attacks without affecting genuine client connections.

UDP DDoS attack

  • Type: Flood

  • How it works: A high volume of UDP packets is sent to random or specific ports on the target IP address(es). It may attempt to saturate the Internet link or overwhelm its in-line appliances with more packets than it can handle in order to create disruption or an outage.

  • How to defend against the attack: Deploy cloud-based volumetric DDoS protection that can fingerprint attack traffic in real-time such as Cloudflare Magic Transit or Cloudflare Spectrum, apply smart rate-limiting on UDP traffic, and drop unwanted UDP traffic altogether with the Magic Firewall.

  • How to avoid unintended impact: Aggressive filtering may disrupt legitimate UDP services such as VoIP, video conferencing, or online games. Apply thresholds carefully.

Emerging threats

Among emerging L3/4 DDoS threats in 2025 Q2, Teeworlds flood saw the biggest spike. These attacks jumped 385% QoQ, followed by the RIPv1 flood, which surged 296%. RDP floods climbed by 173%, and Demon Bot floods increased by 149%. Even the venerable VxWorks flood made a comeback, rising 71% quarter-over-quarter. These dramatic upticks highlight threat actors’ ongoing experimentation with lesser-known and legacy protocols to evade standard defenses.


The top emerging threats for 2025 Q2

Breakdown of the top emerging threats

Below are details about the emerging threats for 2025 Q2, mostly recycling of very old attack vectors. We provide recommendations on how organizations can avoid becoming a reflection and amplification element, and also recommendations on how to defend against these attacks whilst avoiding impact to legitimate traffic. Cloudflare’s customers are protected against these attacks.

Teeworlds DDoS Attack

  • Type: Flood

  • How it works: Teeworlds is a fast-paced, open-source 2D multiplayer shooter game that uses a custom UDP-based protocol for real-time gameplay. Threat actors flood the target’s game server with spoofed or excessive UDP packets that mimic in-game actions or connection attempts. This can overwhelm server resources and cause lag or outages.

  • How to defend against the attack: Use Cloudflare Spectrum or Cloudflare Magic Transit to protect the servers. Cloudflare automatically detects and mitigates these types of attacks using real-time fingerprinting, blocking attack traffic while allowing real players through. Magic Transit also provides a packet-level firewall capability, the Magic Firewall which can be used to craft custom protection.

  • How to avoid unintended impact: When crafting custom rules, avoid blocking or aggressively rate-limiting UDP port 8303 directly as it can disrupt overall gameplay. Instead, rely on intelligent detection and mitigation services to avoid affecting legitimate users.


Teeworlds Screenshot Jungle. Source: Wikipedia

RIPv1 DDoS attack

  • Type: Reflection + (Low) Amplification

  • How it works: Exploits the Routing Information protocol version 1 (RIPv1), an old unauthenticated distance-vector routing protocol that uses UDP/520. Threat actors send spoofed routing updates to flood or confuse networks.

  • How to prevent becoming a reflection / amplification element: Disable RIPv1 on routers. Use RIPv2 with authentication where routing is needed.

  • How to defend against the attack: Block inbound UDP/520 from untrusted networks. Monitor for unexpected routing updates.

  • How to avoid unintended impact: RIPv1 is mostly obsolete; disabling it is generally safe. If legacy systems rely on it, validate routing behavior before changes.

RDP DDoS Attack

  • Type: Reflection + Amplification

  • How it works: The Remote Desktop Protocol (RDP) is used for remote access to Windows systems and typically runs over TCP port 3389. In some misconfigured or legacy setups, RDP can respond to unauthenticated connection attempts, making it possible to abuse for reflection or amplification. Threat actors send spoofed RDP initiation packets to exposed servers, causing them to reply to a victim, generating high volumes of unwanted traffic.

  • How to defend against the attack: Use Cloudflare Magic Transit to protect your network infrastructure. Magic Transit provides L3/L4 DDoS protection, filtering out spoofed or malformed RDP traffic before it reaches your origin. For targeted application-layer abuse, Cloudflare Gateway or Zero Trust Network Access (ZTNA) can help secure remote desktop access behind authenticated tunnels.

  • How to avoid unintended impact: Do not block TCP/3389 globally if RDP is actively used. Instead, restrict RDP access to known IPs or internal networks, or use Cloudflare Tunnel with Zero Trust Network Access (ZTNA) to remove public exposure altogether while maintaining secure access for legitimate users.

DemonBot DDoS Attack

  • Type: Botnet-based Flood

  • How it works: DemonBot is a malware strain that infects Linux-based systems—particularly unsecured IoT devices—via open ports or weak credentials. Once infected, devices become part of a botnet that can launch high-volume UDP, TCP, and application-layer floods. Attacks are typically command-and-control (C2) driven and can generate significant volumetric traffic, often targeting gaming, hosting, or enterprise services. To avoid infection, leverage antivirus software and domain filtering. 

  • How to defend against the attack: Use Cloudflare Magic Transit to absorb and filter large-scale network-layer floods before they reach your infrastructure. Cloudflare’s real-time traffic analysis and signature-based detection neutralize traffic originating from DemonBot-infected devices. For application-layer services, Cloudflare DDoS protection and WAF can mitigate targeted HTTP floods and connection abuse.

  • How to avoid unintended impact: Instead of broadly blocking traffic types or ports, rely on Cloudflare’s adaptive mitigation to distinguish between legitimate users and botnet traffic. Combine with IP reputation filtering, geo-blocking, and rate limiting to reduce false positives and maintain service availability.


VxWorks Flood DDoS Attack

  • Type: Flood (IoT-based)

  • How it works: VxWorks is a real-time operating system (RTOS) used in millions of embedded and IoT devices (e.g., routers, industrial controllers). Devices running outdated or misconfigured versions of VxWorks can be compromised and used to launch DDoS attacks. Once infected—often via public exploits or weak credentials—they send high volumes of UDP, TCP, or ICMP traffic to overwhelm targets, similar to traditional IoT botnets.

  • How to defend against the attack: Deploy Cloudflare Magic Transit to block volumetric traffic at the network edge. Cloudflare uses real-time fingerprinting and  proprietary heuristics to identify traffic from compromised VxWorks devices and mitigate it in real-time. For application services, Cloudflare’s DDoS mitigation and Gateway services provide additional protection against protocol-level abuse.

  • How to avoid unintended impact: Avoid over-blocking UDP or ICMP traffic, as it may disrupt legitimate diagnostics or real-time services. Instead, use Cloudflare’s intelligent filtering, rate limiting, and geo/IP reputation tools to safely mitigate attacks while avoiding impact to legitimate traffic.


Cloudflare’s real-time fingerprint generation flow

Attack size & duration

Most DDoS attacks are small and short. In 2025 Q2, 94% of L3/4 DDoS attacks didn’t exceed 500 Mbps. Similarly, around 85% of L3/4 DDoS attacks didn’t exceed 50,000 pps. The majority of HTTP DDoS attacks are also small, 65% stay below 50K rps. “Small”, though, is a relative term.

An average modern server typically refers to a general-purpose physical or virtual machine with around 4–8 CPU cores (e.g. Intel Xeon Silver), 16–64 GB RAM, and a 1 Gbps NIC, running a Linux OS like Ubuntu or CentOS with NGINX or similar software. This setup can handle ~100,000–500,000 pps, up to ~940 Mbps throughput, and around 10,000–100,000 rps for static content or 500–1,000 rps for database-backed dynamic applications, depending on tuning and workload.

Assuming the server is unprotected by a cloud DDoS protection service, if it’s targeted by “small” DDoS attacks during peak time traffic rates, it is very likely that the server won’t be able to handle it. Even “small” DDoS attacks can cause significant impact to unprotected servers.


DDoS attacks size and duration in 2025 Q2

While the majority of DDoS attacks are small, hyper-volumetric DDoS attacks are increasing in size and frequency. 6 out of every 100 HTTP DDoS attacks exceed 1M rps, and 5 out of every 10,000 L3/4 DDoS attacks exceed 1 Tbps — a 1,150% QoQ increase.


The largest attack in the world: 7.3 Tbps

Most DDoS attacks are short in duration, even the largest and most intense ones. Threat actors often rely on brief bursts of concentrated traffic—sometimes lasting as little as 45 seconds as seen with the monumental 7.3 Tbps DDoS attack — in an attempt to avoid detection, overwhelm targets and cause maximum disruption before defenses can fully activate. This tactic of short, high-intensity bursts makes detection and mitigation more challenging and underscores the need for always-on, real-time protection. Thankfully, Cloudflare’s autonomous DDoS defenses kick in immediately.

Helping build a better Internet

At Cloudflare, we’re committed to helping build a better Internet. A part of that mission is offering free, unmetered DDoS protection regardless of size, duration and quantity. We don’t just defend against DDoS attacks. The best defense is a good offense, and using our free ISP Botnet Threat Feed, we contribute to botnet takedowns. 

While many still adopt protection reactively or rely on outdated solutions, our data shows proactive, always-on security is far more effective. Powered by a global network with 388 Tbps capacity across 330+ cities, we provide automated, in-line, battle-proven defense against all types of DDoS attacks.

Revenue NSW modernises analytics with AWS, enabling unified and scalable data management, processing, and access

Post Syndicated from Saeed Barghi original https://aws.amazon.com/blogs/big-data/revenue-nsw-modernises-analytics-with-aws-enabling-unified-and-scalable-data-management-processing-and-access/

Revenue NSW, in Australia, is New South Wales (NSW) state’s principal revenue management agency and aspires to be the world’s most innovative and customer-centric revenue agency. Revenue NSW exists to administer grants, resolve fines, and collect revenue to fund essential state services for the over 8 million people of NSW in a fair, efficient, and timely manner.

Analytics at Revenue NSW plays a key role in enabling the organization’s goals and purpose by delivering reliable, secure, and authoritative insights. These insights are key to:

  • Understanding customer attributes to enable empathetic and informed actions
  • Supporting policy development
  • Assisting in the sequencing of millions of decisions
  • Maintaining compliance and education
  • Fostering transparency by providing open data and insights directly to the public

The challenge

Revenue NSW Analytics consumes data from a multitude of operational databases and real-time interfaces and through internally generated reports and files received from external data partners such as other government departments and agencies. The varying technologies, formats, and complexities of these data sources created friction and inefficiencies in data transformation, consolidation, and analysis in an environment that is often time-critical. In addition, these analytics systems were previously hosted on dedicated hardware on-premises that was nearing end-of-life and wasn’t easy to scale efficiently. To address these challenges, Revenue NSW Analytics used their partnership with AWS to build a strategic, unified, scalable, frictionless and modern data environment to help them standardize data transformation and consolidation pipelines from the hundreds of data sources. Additionally, the modern data environment must provide a single source of truth and enable secure and seamless access to the data through a unified SQL interface regardless of the data’s original format or technology.

After understanding other offerings, Revenue NSW Analytics decided on a proof of concept (PoC) using Amazon Web Services (AWS) cloud-based services, including Amazon Redshift. The key goals of the PoC were to assess the completeness of the solution, its performance, and the potential change in total cost of ownership compared to their on-premises setup.

Amazon Redshift, with its integration options, columnar storage, and massively parallel processing (MPP) architecture, offered the desired end-state solution. Tests demonstrated a typical speed increase between 5- and 50-fold in query execution, with many results 100 times faster than the existing on-premises solution. Amazon Redshift also performed significantly better compared with other cloud-based solutions, offering up to 6 times better performance. The success of the initial PoC led Revenue NSW Analytics to further collaborate with AWS, working towards developing a prototype that incorporated Amazon Redshift alongside various data ingestion patterns.

The solution

To simplify data ingestion from the operational databases—which run on different database engines including Oracle, PostgreSQL, and Microsoft SQL—Revenue NSW Analytics used AWS Database Migration Service (AWS DMS) to perform a bulk initial load, followed by capturing ongoing changes from these databases into Amazon Redshift in near real time.

For data from Salesforce’s real-time API, Revenue NSW Analytics used Amazon AppFlow to automate the continuous pulling and ingesting of data into Amazon Redshift.

The hundreds of structured and semi-structured data files were handled using AWS Glue. These files are regularly uploaded to Amazon Simple Storage Service (Amazon S3), triggering the relevant AWS Glue extract, transform, and load (ETL) jobs in an event-based architecture to transfer the data into Amazon Redshift.

To facilitate repeatability and enable iteration, Revenue NSW Analytics used infrastructure-as-code (IaC) and continuous integration and delivery (CI/CD) pipelines to deploy the different components of the solution.

The following is a high-level architecture demonstrating how these different components and services fit together.

Along with standardization and unified access, the success criteria of the new data environment included the ease of transition, consolidation of processes to the new standardised pipelines, scalability, language uniformity, and availability. The combination of supporting standard SQL, AWS DMS, and Amazon AppFlow low-code capabilities, and supporting Python in AWS Glue, a popular programming language, played a crucial role in facilitating the successful transition and adoption of the cloud-based data environment.

Other success factors of this environment include the ability to work within current budgets, and the extendibility and modularity of the solution. As shown in the preceding high-level architecture, the solution runs on multiple building blocks that are decoupled, modular, and either serverless—like AWS Glue—or managed services that support seamless scalable configurations that don’t require rebuilds. This allowed Revenue NSW Analytics to start small with each use case, expand and grow as required, and pay only for what they need.

Moreover, with the new cloud-based data environment, Revenue NSW Analytics can access to up-to-date data in near real time, which is essential to fulfilling critical use cases such as information requests and assisting with compliance case identification. The automated data ingestion pipelines removed much of the boilerplate and heavy lifting, allowing Revenue NSW teams to work more efficiently and focus on the differentiators of their business, and in some cases, shorten workflow times from months to weeks or days.

Another significant factor contributing to the project’s success is the people at the heart of Revenue NSW Analytics. The teams allocated to own and deliver this platform are cross-functional, with adjoining responsibilities and skills, and were prepared through multiple in-person and online training sessions. The teams were empowered to trial individual services to deliver new use cases and iterate on the solution to learn from successes and innovate progressively. This approach, together with support Revenue NSW received from AWS specialist solution architects, helped to minimize the risk of knowledge gaps that often arise when separate teams are responsible for building and operating a system.

The hard work of the Analytics team, the investment of Revenue NSW Analytics leadership in its people, and the continuous support from AWS can truly be seen throughout the delivery of the data environment, resulting in the achievement of the intended outcomes.

Conclusion and call to action

Since going live with their cloud-based data environment on AWS, Revenue NSW has onboarded dozens of analysts who can get more done in less time. This is a result of establishing a single source of truth from different data sources in Amazon Redshift, so that analysts and data consumers don’t need to shop around to find the data that they need to complete their tasks. This new data environment also provides Revenue NSW with the ability to create improved conditions for:

  • Increasing agility by exposing reusable, trusted data services for people and AI
  • Empowering operational systems with services best provided by analytical approaches
  • Decommissioning heritage, costly infrastructure and data practices.

Successful delivery of the cloud-based data environment on AWS has led to further collaboration between AWS and Revenue NSW. This includes exploring the adoption of AI and machine learning (AI/ML) and generative AI to further improve the delivery of services for the people of NSW.

To learn more about customer success stories like this or how to get started with building a data environment on AWS, contact your AWS account team. You can read about similar customers by browsing Customer Success Stories on our website.


About the authors

Saeed BarghiSaeed Barghi is a Sr. Specialist Solutions Architect at Amazon Web Services (AWS) specializing in architecting enterprise data platforms and AI solutions. Based in Melbourne, Australia, Saeed works with public sector customers in Australia and New Zealand and helps his customers build fit-for-purpose and future-proof data platforms and AI solutions.

Miroslaw (Mick) Mioduszewski is the Director of Analytics at Revenue NSW Department of Customer service in NSW. He held multiple C-level roles in private and public companies as well as government, e.g. COO and CIO, as well as serving as company director. Mick holds computer science and business degrees, is a fellow of the Australian Institute of Company Directors and an industry fellow at the University of technology, Sydney.

Moha Alsouli is a Public Sector Solutions Architect at Amazon Web Services (AWS) in Sydney. He is dedicated to supporting state and local government customers deliver citizen services, through solution design, reviews, optimisation, and architecture guidance. Moha is also specialising in generative artificial intelligence (AI) on AWS.

Любомир Попйорданов – за волята и волния човешки дух

Post Syndicated from Ина Иванова original https://www.toest.bg/lyubomir-popyordanov-za-volyata-i-volniya-choveshki-duh/

Любомир Попйорданов – за волята и волния човешки дух

Когато се спомене името Любомир Попйорданов, всички, които го познават, обикновено възкликват: „Любо!“ По светналите им очи се вижда колко откровен, активен и търсещ човек е.

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

Роден е в България, но детството му преминава основно в Тунис, където баща му д-р Йордан Попйорданов работи като лекар. Впоследствие завършва Френската гимназия в София и право в Софийския университет.

Баща е на две пораснали дъщери, художнички, и син – студент по архитектура. Страстен планинар. Основател е на агенциите за приключенски туризъм „Одисея-ин“ и „Зиг-Заг Холидейз“, основател и дългогодишен председател на Управителния съвет на Българската асоциация за алтернативен туризъм (БААТ) – организация, която е ангажирана с опазването и устойчивото използване на българското природно, културно и историческо наследство. Именно БААТ въведе в законодателството правната рамка на къщите за гости. Любомир Попйорданов създава първия публичен фестивал за зелен туризъм – „Зелени дни“ – и намира време да основе „Стената“ (магазини, предлагащи специализирана екипировка за туризъм, къмпинг и катерене), да издава книги и да публикува собствена. Вече близо две десетилетия организира Фестивала за приключенско кино и екстремни спортове „Дни на предизвикателствата“. Носител е на награди за отговорен туризъм и корпоративно дарителство. Зад гърба си има залесителни кампании в Пирин и Витоша (конкретно – Софийското Светогорие и Сеславския манастир). Това са част от каузите, на които е посветен, но зад наименованията им стои мрежа от сърцати хора, с които е по човешки свързан.

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

Всуе или с променлив успех, но Любомир Попйорданов не спира да опитва. Колективните каузи и механизмите на гражданското общество изискват не просто ентусиазъм, а и умението да не се отказваш.

Любомир Попйорданов винаги остро се е противопоставял на опитите туристическият сектор да бъде използван за оправдание на лобистки инвестиционни интереси. Той е активен участник в борбата за защита на националните и природните паркове и срещу опитите за застрояване им – бори се с еднаква страст за морето и за планините на България.


Няма как да не започнем от високото, от планината. Без какво не може в нея? 

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

Изборът е, който ни определя като хора. 

Какво Ви е нужно, за да се усетите цялостен?

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

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

Чистото преживяване в планината с хора, които са ни важни, или с приятели по свръзка; или приключение с лодка в горещите южни ширини; самотно или споделено навлизане в джунглата на Амазонка; или срещата и вечерта, прекарана в някоя откъсната от света родопска махала – ето това е откъсване от консуматорството. 

За съжаление, приключенският туризъм също върви в руслото на масовия. Важното е тези, които създават пътуванията, а и самите пътуващи, да си дадат сметка за своя социален и екологичен отпечатък достатъчно навреме. Да се опитат да върнат на туризма онзи смисъл, с който той се е родил като такъв: порива към непознатото, мечтата, изследователския стремеж. 

Любомир Попйорданов – за волята и волния човешки дух
Любомир Попйорданов © личен архив

Има ли потенциал алтернативният туризъм да развива дребно предприемачество в изоставените от държавата региони?

Той го и прави, и то далеч преди България да бъде приета в ЕС и да навлязат разните програми, които бяха прочетени и приложени с корист и оставиха петно върху домашното гостоприемство и развитието на туризма. В продължение на над 15 години чрез създадената от съмишленици БААТ успяхме да внесем революционни идеи, за които администрацията и предприемачите в голямата си част не бяха готови. 

Все пак именно в този период (до 2012–2015 г.) се родиха най-добрите примери за устойчив и отговорен туризъм. След това термините бяха употребени, така както и идеите за възобновяеми енергийни източници и Зелената сделка. Политическият елит, който управлява държавата ни, с няколко малки изключения, от 2001 г. насам не работи за обществения интерес. 

По образование сте юрист. По призвание – пишете и рисувате. А по характер?

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

Какво Ви тревожи напоследък?

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

Любомир Попйорданов – за волята и волния човешки дух
Автопортрет на Любомир Попйорданов

Какъв искахте да станете, когато бяхте дете?

Четях много история на старите цивилизации. Другата посока беше архитектурата. Рисуването беше нещо, което също си позволявах, без да питам дали мога или трябва и дали ще ставам художник. 

Човек не става нещо, той е. 

Когато видя археологически разкопки, съм археолог, а архитектурата продължава да ме изкушава.

Какво научихте за себе си от рисуването? В тишина ли предпочитате да създавате платната си?

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

Бавно живеене или живот на скорост?

Въпросът е стар колкото света. Festina lente („Бързай бавно“, лат. – б.р.). Зад историята на сградите, които бележат епохи, както и при литературните произведения и голямото кино винаги има натрупвания, които в един момент достигат до взрив, задават нова посока в естетическите търсения и внушения, забързват обществените отношения и нашия личен живот. 

Да бързаме бавно. Да внасяме смисъл в скоростта.


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

Transforming IT Infrastructure Visibility at Doğan Trend Automotive

Post Syndicated from Michael Kammer original https://blog.zabbix.com/transforming-it-infrastructure-visibility-at-dogan-trend-automotive/30715/

Established in 2020 to consolidate Doğan Group’s automotive and mobility companies and brands under a single entity, Doğan Trend Automotive is a prominent player in their industry. Representing a diverse portfolio ranging from automobiles, motorcycles, and marine engines to electric commercial vehicles, Doğan Trend also delivers innovative solutions to customers through its e-commerce platforms, such as suvmarket.com and vespastoreturkey.com.

The challenge

Doğan Trend’s IT ecosystem spans data centers, remote locations, and multiple units, necessitating seamless operations as well as an efficient monitoring and alert system. The existing infrastructure posed challenges in monitoring, making it difficult to detect potential issues in a timely manner, thus increasing operational risks.

The solution

To address Doğan Trend’s needs, our associates at ASNSKY implemented a Zabbix-based monitoring system. Key highlights of the project included:

  • Centralized dashboards: Custom dashboards were designed for data centers and remote locations, enabling the unified monitoring of IT locations and components from a single interface.
  • A dynamic alert system: Alerts prioritized based on predefined conditions allowed for the swift and effective resolution of critical issues.
  • Seamless operations: Early detection of potential issues prevented operational disruptions and ensured continuity.

Throughout the integration process, ASNSKY’s team collaborated closely with Doğan Trend’s IT department, addressing the specific requirements of different units and providing training for effective system use.

The results

Implementing the new monitoring system rapidly delivered the following results:

  • Enhanced visibility: Real-time monitoring of all IT locations and components made potential issues easy to spot.
  • Proactive issue management: Early detection of critical issues reduced operational downtime.
  • Increased efficiency: The centralized monitoring system drastically improved the responsiveness and effectiveness of Doğan Trend’s IT team.

“This project with the ASNSKY team made our IT infrastructure more transparent and manageable. With Zabbix’s flexible and effective monitoring capabilities, we gained active control over our critical operations. We thank the ASNSKY team for this successful collaboration.” – Burak Altunalan, IT System Management Specialist at Doğan Trend Automotive

In conclusion

Doğan Trend plans to further take advantage of Zabbix’s flexibility to strengthen their resilience and operational efficiency. Their association with ASNSKY marks a significant step toward achieving these objectives.

To learn more about what Zabbix can do for retail customers in every sector, get in touch with us. 

About ASNSKY

ASNSKY enhances its customers’ competitiveness by integrating the power of enterprise-grade open-source-solutions in security and infrastructure with a professional service approach and high quality standards.

Backed by deep industry expertise and a team of seasoned professionals, ASNSKY stands as a trusted partner in your digital transformation journey.

The post Transforming IT Infrastructure Visibility at Doğan Trend Automotive appeared first on Zabbix Blog.

Равенството като инвестиция. Разговор с проф. Лий Баджет

Post Syndicated from original https://www.toest.bg/ravenstvoto-kato-investitsiya-razgovor-s-prof-lee-badgett/

Равенството като инвестиция. Разговор с проф. Лий Баджет

Проф. Мери Вирджиния Лий Баджет (известна като проф. Лий Баджет) е главна икономистка в Koppa LGBTI+ Economic Power Lab и водеща изследователка в областта на равенството за ЛГБТИ+ хора. Преподавала е икономика в Масачузетския университет в Амхърст и е била съдиректорка на Центъра за равенство в заетостта. Тя е старша изследователка в Института „Уилямс“ към Калифорнийския университет в Лос Анджелис (UCLA). Авторка е на книгата „Икономическите аргументи за ЛГБТИ+ равенство. Защо справедливото и равно третиране е от полза за всички нас“, в която анализира икономическите загуби, произтичащи от хомофобията и трансфобията. Проф. Баджет е консултирала Световната банка, Програмата за развитие на ООН и други международни организации по теми, свързани с политиките в областта на ЛГБТИ+ равенството.

Докладът на Института за пазарна икономика (ИПИ) „Икономическата цена на хомофобията в България“, изготвен по поръчка на Фондация GLAS, използва методологията на проф. Баджет и екипа ѝ. Един от изводите на експертите от ИПИ е, че в резултат от дискриминацията на ЛГБТИ+ хората към 2022 г. България е загубила между 2,5 и 4,3 млрд. евро само от чуждестранни инвестиции. 


Проф. Баджет, в книгата си описвате как дискриминацията срещу ЛГБТИ+ хората води до значителни икономически загуби. За какъв вид загуби става дума?

Съществуват различни оценки в зависимост от държавата и използваната методология, но всички показват, че икономическите загуби могат да бъдат сериозни – до 1% от брутния вътрешен продукт (БВП) на една страна. Това е огромна сума. Правила съм такива изследвания за Индия и няколко държави в Югоизточна Азия. Подобни оценки са направени от институции като Световната банка за други страни. Организацията за икономическо сътрудничество и развитие (ОИСР) също публикува основен доклад със заглавие „Икономическите аргументи за по-голямо равенство на ЛГБТИ+ в САЩ“, според който намаляването на ефектите от дискриминацията и стигмата би увеличило БВП на САЩ с 2,6%. Друг добър източник е платформата Open For Business, която анализира как приобщаващата среда подпомага привличането на инвестиции и таланти. В крайна сметка, когато ЛГБТИ+ хората са изключени, техните умения и продуктивност остават неизползвани и това намалява цялостната ефективност на икономиката.

Ако загубите са толкова големи, защо виждаме толкова много анти-ЛГБТИ+ реторика и политики, които набират сила в някои страни със средни и ниски доходи – а дори и в части от ЕС и Съединените щати?

За съжаление, тази реакция често е резултат от дълбоко вкоренена хомофобия и трансфобия. Тези нагласи са ирационални от гледна точка на икономиката, която е насочена към това какво могат да допринесат хората. Уви, хомофобията и трансфобията могат да бъдат политически ефективни. Понякога политици експлоатират тези нагласи, за да привлекат подкрепа от определени групи. Има случаи, в които това се прави и за отвличане на вниманието – например от лошото управление или икономическите неуспехи. От гледна точка на икономистите такава дискриминация просто е неефективна. Ако някой не бъде нает или повишен заради своята сексуална ориентация или джендърна идентичност, а не въз основа на таланта и продуктивността си, икономиката губи. Това е неправилно разпределение на човешкия капитал. Същото важи и за отношението на работното място – ако ЛГБТИ+ служителите са тормозени или се чувстват несигурни сред колегите си, те не могат да дадат най-доброто от себе си, а това е загуба за всички.

Равенството като инвестиция. Разговор с проф. Лий Баджет
С Фил Криън, съучредител на Koppa LGBTI+ Economic Power Lab. Снимка: личен архив

Може ли да споделите примери или данни, които показват как включването на ЛГБТИ+ хора в икономиката носи ползи за обществото като цяло?

Да, включването носи ползи за всички. Когато ЛГБТИ+ хората имат равен достъп до образование и заетост, те по-лесно развиват своите умения, идеи и креативност и допринасят повече. Това увеличава производителността и иновациите. Премахването на дискриминацията и подобряването на достъпа до възможности води до положителни резултати във всички сектори. Бихме могли да видим и по-ниски разходи за здравеопазване, когато дискриминацията намалява, тъй като стигмата, тормозът и страхът са също така основни фактори за психични и физически здравословни проблеми сред ЛГБТИ+ общностите. Икономиките просперират, когато всички хора могат да участват равноправно, без страх.

Кои са основните предизвикателства при събирането на данни за икономическите ефекти от дискриминацията срещу ЛГБТИ+ хора?

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

Но това започва да се променя. В Европейския съюз, Австралия, Нова Зеландия и САЩ се провеждат анкети, които помагат за създаването на политики. Страни като Мексико, Бразилия, Колумбия и Еквадор започнаха да включват въпроси за сексуалната ориентация и джендърната идентичност в националните си проучвания. В Южна Азия някои страни признават „трети пол“ в преброяванията. Правителствата могат да събират такива данни безопасно и етично – така, както правят с друга чувствителна информация. Разполагаме и с дигитални методи, които по-добре защитават поверителността на данните на ЛГБТИ+ хората и позволяват на статистическите агенции да събират тези данни по-ефективно. Когато имаме повече и по-добри данни, това ни помагат да създаваме приобщаващи политики и да проследяваме напредъка.

Какво послание бихте искали да отправите към българските читатели?

Колкото повече научаваме за ЛГБТИ+ хората, толкова по-ясно виждаме колко много допринасят те за нашето общество и икономика. Моето послание към българските читатели е: срещнете се с ЛГБТИ+ хора. Опознайте ги, опознайте ЛГБТИ+ общностите и предизвикателствата, с които се сблъскват – изслушайте ги, чуйте ги, научете се от тях, – и ги подкрепяйте.


Мнението на автора, изразено в този текст, е лично и не отразява позициите на ООН или на нейните държави членки.

Gigabyte G893-ZX1-AAX2 AMD Instinct MI325X Server Review

Post Syndicated from Patrick Kennedy original https://www.servethehome.com/gigabyte-g893-zx1-aax2-amd-instinct-mi325x-server-review/

In our Gigabyte G893-ZX1-AAX2 review, we see how this 8x GPU AMD Instinct MI325X system (2TB of HBM3E!) with dual AMD EPYC CPUs works

The post Gigabyte G893-ZX1-AAX2 AMD Instinct MI325X Server Review appeared first on ServeTheHome.

Announcing the end of support for Node.js 18.x in AWS CDK

Post Syndicated from Charles Meruwoma original https://aws.amazon.com/blogs/devops/announcing-the-end-of-support-for-node-js-18-x-in-aws-cdk/

On November 30th, 2025, the AWS Cloud Development Kit (CDK) will no longer support Node.js 18.x, which reached end of life on April 30, 2025. This change applies to all AWS CDK components that depend on Node.js, including the AWS CDK CLI, the Construct Library, and broader CDK ecosystem projects such as JSII, Projen, and CDK8s.

We encourage you to upgrade to a Node.js Active Long Term Support (LTS) version, which is Node.js 22.x as of July 6, 2025. Given that Node.js 18.x is past end of life, we recommend migrating your CDK projects to newer Node.js LTS versions as soon as possible.

Why are we doing this?

Node.js 18.x reached its End of Life support on April 30, 2025, per the Node.js Release Schedule. This means the Node.js community no longer provides bug fixes or security updates for this version. By dropping support for end-of-life versions, we ensure that AWS CDK users benefit from the latest security patches, performance improvements, and modern Node.js capabilities. This approach aligns with AWS’s commitment to security best practices and our standard policy of supporting only actively maintained runtime versions.

What’s changing?

Starting December 1, 2025, AWS CDK will officially end support for Node.js 18.x. While your existing CDK deployments may continue to function, we will no longer address issues, provide bug fixes, or offer technical support for problems that occur specifically with Node.js 18.x. Any support cases or bug reports related to Node.js 18.x will require reproduction on a supported Node.js version (20.x or 22.x as of June 2025) before we can assist.

Key points

Moving forward, projects that remain on Node.js 18.x will gradually lose access to new AWS CDK capabilities as we develop features using modern Node.js APIs that are not available in older versions. This creates a growing compatibility gap that will make it increasingly challenging to leverage CDK innovations and improvements. The security implications are equally concerning, as any vulnerabilities discovered in the unsupported Node.js 18.x runtime will not receive patches or workarounds from our development team, potentially exposing your infrastructure to known security risks.

The challenges extend throughout the development lifecycle. Without regular compatibility testing against Node.js 18.x, we cannot ensure reliable CDK behavior, and you may encounter unexpected issues in production environments. When problems do arise, our support team will need to reproduce any reported issues on supported Node.js versions before providing assistance, which could delay resolution during critical incidents. Additionally, the broader CDK ecosystem, including third-party libraries and tools your projects depend on, will likely follow similar deprecation schedules, creating compounding compatibility challenges that become more difficult to resolve over time.

Timeline

We’re announcing this change in July 2025, to provide you with a five-month transition period before support officially ends on November 30th, 2025. During this transition window, our team will continue to address issues that arise with Node.js 18.x, giving you time to plan, test, and execute your upgrade strategy without immediate pressure. This period is designed to help you thoroughly validate your CDK projects against newer Node.js versions and ensure smooth deployments in your production environment.

Beginning December 1st, 2025, AWS CDK will officially discontinue support for Node.js 18.x across all components and ecosystem projects. From this point forward, all bug fixes, security patches, and new feature development will target only supported Node.js versions, currently 20.x and 22.x as of June 2025. We strongly recommend using this transition period to migrate to Node.js 22.x, the current Active Long Term Support version, which will provide the longest runway for future compatibility as the Node.js release cycle continues.

Version validation and update steps

Begin your migration by checking which Node.js version you’re currently running across all environments where you deploy CDK projects. Run `node -v` in your local development environment, CI/CD pipelines, and any automated deployment systems to get a complete picture of your current setup.

Once you’ve identified all instances of Node.js 18.x, update your runtime to a supported version using either a version manager like nvm or by downloading the official installer from nodejs.org. We recommend upgrading directly to Node.js 22.x since it’s the current Active Long Term Support version and will provide the longest compatibility runway. After updating your runtime, thoroughly test your CDK projects in non-production environments to ensure your deployment scripts and third-party dependencies work correctly with the new version. Pay particular attention to any custom constructs or complex deployment workflows that may be sensitive to changes in Node.js versions.

Finally, establish a process for staying current with future Node.js releases by bookmarking the AWS CDK Node.js Version Support Timeline, which provides up-to-date information on runtime compatibility and upcoming deprecations. This proactive approach will help you anticipate future changes and plan your upgrade strategies well in advance, avoiding the pressure of last-minute migrations when support windows close.

Conclusion

This deprecation is part of our ongoing commitment to provide a secure, high-quality experience for AWS CDK users. By migrating to a Node.js Active Long Term Support (LTS) version, you will benefit from enhanced performance, ongoing security updates, and continued AWS CDK advancements. If you have any questions or concerns about this deprecation, please reach out and open an issue in our GitHub repo.

Modernizing SOAP applications using Amazon API Gateway and AWS Lambda

Post Syndicated from Daniel Abib original https://aws.amazon.com/blogs/compute/modernizing-soap-applications-using-amazon-api-gateway-and-aws-lambda/

This post demonstrates how you can modernize legacy SOAP applications using Amazon API Gateway and AWS Lambda to create bidirectional proxy architectures that enable integration between SOAP and REST systems without disrupting existing business operations.

Many organizations today face the challenge of maintaining critical business systems that were built decades ago. These legacy applications power essential business operations despite relying on outdated technologies and integration patterns. Although complete system replacement would be ideal, practical constraints such as budget limitations, resource availability, technical complexity, and missing documentation often make modernization efforts challenging.

This post first shows proxy architecture patterns to expose a legacy SOAP server over a REST API. It then shows how to integrate a legacy SOAP client with applications using a REST API.

While SOAP and REST APIs share HTTP as their foundation, SOAP has some limitations compared to REST, like limited HTTP methods (GET/POST only) and mandatory XML formatting. REST is more flexible with multiple HTTP methods and diverse payload formats (plain text, binary, HTML, JSON, XML).

Using API Gateway and Lambda to proxy SOAP service

Consider a legacy solution that only supports SOAP. The following diagram shows the architecture for a SOAP proxy server using API Gateway and Lambda.

Figure 1: SOAP Server Proxy for modernized architecture

Figure 1: SOAP Server Proxy for modernized architecture

The proxy exposes the APIs hosted on the SOAP Server (on the right side of the image) over a REST interface. A SOAP service expects the HTTP Content-Type header set to text/xml, and a XML format payload that follows the WSDL specification defined by the server.

In the proposed architecture, the Lambda function is the core transformation engine, handling the bidirectional conversion between JSON and XML formats. Lambda functions can be developed in multiple programming languages such as Python, Node.js, Java, C#, Go, Ruby, and PowerShell, allowing you to use your existing development expertise. The serverless nature of Lambda provides automatic scaling to handle traffic spikes without needing infrastructure management or capacity planning.

API Gateway acts as the intelligent front door, managing all incoming requests and routing them appropriately. It provides enterprise-grade features such as request throttling to protect backend systems from overload, comprehensive authentication and authorization mechanisms, API key management for partner access control, request and response validation, caching capabilities for improved performance, and detailed monitoring and logging. These built-in features remove the need for custom middleware development and provide immediate operational benefits. API Gateway can receive multiple payload format such as XML, JSON, binary data, and plain text. This makes it suitable for diverse integration scenarios.

Using API Gateway and Lambda to support legacy SOAP clients

The previous section focused on exposing SOAP services over REST APIs. Organizations also face the reverse challenge where legacy SOAP client applications must access REST services. The architecture for supporting legacy SOAP clients follows a similar pattern but with reversed data flow. In this case, the legacy SOAP client sends XML-formatted requests to what it believes is a SOAP server. However, behind the scenes API Gateway and Lambda work together to translate these requests into REST API calls.

Figure 2: Legacy SOAP client modernization architecture

Figure 2: Legacy SOAP client modernization architecture

The legacy SOAP client application sends XML SOAP messages to API Gateway. The Lambda function receives these SOAP requests, extracts the relevant data from the XML envelope, and transforms it into JSON format for the modern REST service.

The Lambda function wraps the JSON response from the REST services into the SOAP XML format that the legacy client expects. It recreates the appropriate XML structure, SOAP headers, and ensures that the response conforms to the WSDL specification that the client application was designed to consume.

Example scenario

Let’s suppose our legacy client application needs to send a SOAP request to convert an integer number to its word form. The SOAP envelop to convert the number 1519 to its long form “one thousand, five hundred and nine” looks like this:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body> \
        <ConvertNumberToWordsSoapIn>
            <NumberToWordsRequest>1519</NumberToWordsRequest>
        </ConvertNumberToWordsSoapIn>
    </soap:Body>
</soap:Envelope>

The REST conversion service expects a JSON payload the as follownig:

jsonObject = {
	"data" : 1519
}

The following code block shows a sample Lambda function implementation for this. This function converts the SOAP XML envelop to JSON, changes the http header to application/json, and converts response from REST service to SOAP format.

var parseString = require('xml2js').parseString;
const axios = require('axios');

exports.handler = async (event, context) => {
    var valueNumber;
    
    try {
        console.log("Parsing XML string");

        // Parsing the XML to obtain data needed for conversion (number to words)
        parseString(event.body, function (err, result) {
            if (!err) {
                valueNumber = result['soap:Envelope']['soap:Body'][0]
                              ['ConvertNumberToWordsSoapIn'][0]
                              ['NumberToWordsRequest'][0];
            } else { 
                console.log (err);
                throw (err);
            }
        });
        console.log("Creating JSON for calling the service");
        // Creating JSON to call service
        var jsonObject = {
            "data" : valueNumber
        }
        
        console.log("Calling Microservice (NumberToWords)");
        const headers = { 
            'Content-Type': 'Application/json'
        };
        
        console.log ("Parameter for NumberToWords URL:" + 
                    JSON.stringify(process.env.NumberToWordMicroservice));

        // Calling numberToWords REST Server
        var resultNumberToWords = await 
            axios.post(process.env.NumberToWordMicroservice, jsonObject, { headers });
        
        // Creating the response
        console.log("Creating response XML");

        var resp =  create_response (JSON.stringify(resultNumberToWords.data.message));
        console.log("Response in XML: "+ resp);
        
        // Returning the value in XML using text/xml content type
        let response = {'statusCode': 200, headers: {"content-type": "text/xml"}, 
                        'body': JSON.stringify(resp)}
        return response;
        
    } catch (err) {
        console.log ("Error: " + err);
        let response = {'statusCode': 500, 
                        headers: {"content-type": "text/xml"}, 'body': err}
        return response;
    }
};

// Function to create a SOAP XML envelope with the result value
function create_response(numberInWords) {
  return '<?xml version="1.0" encoding="utf-8"?> \
            <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">\
            <soap:Body>\
              <m:ConvertNumberToWordsResponse xmlns:m="http://www.dataaccess.com/webservicesserver/"> \
                  <m:ConvertNumberToWordsResponseResult>' + numberInWords + '</m:ConvertNumberToWordsResponseResult> \
              </m:ConvertNumberToWordsResponse> \
            </soap:Body>\
            </soap:Envelope>';
}

With this approach, you can maintain your existing SOAP client applications without modification, allowing them to consume modern REST services. You can preserve investments in legacy client applications while gradually modernizing the overall system. This architecture is particularly valuable in scenarios where multiple legacy SOAP clients need to access the same modern REST services. This is because a single proxy can serve multiple client applications simultaneously. The serverless nature of the architecture makes sure that it scales automatically based on the number of client requests, providing cost-effective operation regardless of usage patterns.

Alternative approach using API Gateway transformation capabilities

The Lambda-based approach provides maximum flexibility and control. API Gateway also offers built-in transformation capabilities that can handle certain SOAP modernization scenarios without the need for compute resources.

The native API Gateway transformation uses Apache Velocity Template Language mapping templates. It converts the payload directly at the gateway, offering a streamlined solution for specific modernization scenarios.

The VTL approach works by defining mapping templates that handle the conversion process between different payload formats. When modernizing SOAP services, these templates can intercept REST requests with JSON payloads, restructure the data into XML format compatible with your legacy SOAP endpoints, and reverse the process for responses returning to the client.

Figure 3: API Gateway with velocity template language transformation

Figure 3: API Gateway with velocity template language transformation

This gateway-native transformation strategy offers several operational advantages. You benefit from streamlined architecture because the transformation logic resides entirely within the API Gateway service. There are no other infrastructure components to manage or monitor, and the solution avoids the complexity of coordinating between multiple AWS services. Cost efficiency is another key benefit, as there are no compute charges beyond the standard API Gateway pricing.

Consider the previous example of converting a number to its word format. The VTL transformation in API Gateway will look like this:

## Parse the SOAP envelope and extract the number value
#set(\$xmlDoc = \$input.path('\$'))
#set(\$numberToWords = \$xmlDoc.Envelope.Body.ConvertNumberToWordsSoapIn.NumberToWordsRequest)

## Convert to integer if it's a string
#if(\$numberToWords.toString().matches("^\d+\$"))
  #set(\$dataValue = \$numberToWords.toInteger())
#else
  #set(\$dataValue = \$numberToWords)
#end

{
  "data": \$dataValue
}

You should consider VTL transformations when your SOAP services have predictable, stable schemas with relatively direct XML structures. This approach works particularly well for legacy systems that rarely undergo changes and have clear request-response patterns. For more dynamic environments or complex transformation requirements, the Lambda-based solution provides superior flexibility and maintainability.

Security considerations

An important consideration when working with legacy SOAP services is understanding their authentication mechanisms. SOAP protocols often implement authentication through security standards, where authentication credentials and security tokens are embedded directly within the SOAP envelope headers. This includes username tokens, digital signatures, and encryption elements that are part of the XML structure.

When SOAP envelopes contain unencrypted authentication information in the headers, the proxy architecture typically functions without more modifications. This is because the Lambda function can pass through these authentication elements transparently to the backend SOAP service. However, due to the nature of SOAP authentication being tightly integrated with the XML envelope structure, certain scenarios may need custom handling within the Lambda function.

For example, if the SOAP service uses timestamp-based authentication tokens, session management, or needs specific security header modifications, the Lambda function may need customization to properly handle, validate, or refresh these authentication elements during the JSON-to-XML transformation process. Organizations should carefully analyze their SOAP service authentication requirements to determine if more Lambda logic is needed to maintain security compliance.

Moreover, make sure that any SOAP authentication credentials processed by the Lambda function are handled securely and never logged in plain text.

Conclusion

In this post, you learned how cloud-native services can bridge the gap between legacy systems and modern application architectures, allowing you to use your existing investments while adopting contemporary development practices and technologies.

Amazon API Gateway and AWS Lambda enable organizations to create REST services that proxy legacy SOAP servers, allowing modern applications to consume legacy services through JSON payloads while preserving existing SOAP infrastructure. This serverless solution provides cost-effectiveness, automatic scaling, and reduced operational overhead while facilitating company modernization through scalable APIs without abandoning legacy software investments.

This modernization strategy allows you to gradually transition from legacy SOAP services to modern REST APIs without disrupting existing business operations. As your modernization journey progresses, you can extend this pattern to support more SOAP services or implement more sophisticated transformation logic based on your specific business requirements.

For more serverless learning resources, visit Serverless Land.

Parrot 6.4 released

Post Syndicated from corbet original https://lwn.net/Articles/1029857/

Parrot is a Debian-based
distribution with an emphasis on security improvement and tools; the 6.4
release
is now available. “Many tools, like Metasploit, Sliver,
Caido and Empire received important updates, the Linux kernel was updated
to a more recent version, and the latest LTS version of Firefox was
provided with all our privacy oriented patches.
“.

How Scale to Win uses AWS WAF to block DDoS events

Post Syndicated from Ben "Fuzzy" Shonaldmann original https://aws.amazon.com/blogs/architecture/how-scale-to-win-uses-aws-waf-to-block-ddos-events/

This is a guest post coauthored by Ben “Fuzzy” Shonaldmann of Scale to Win.

Scale to Win was created for organizers by organizers. Born out of the 2020 election cycle, a group of friends and former colleagues came out of a whirlwind presidential primary season with frustrations and ideas to improve campaign technology. With extensive outreach experience on high-profile presidential campaigns such as Biden/Harris 2020, Bernie 2016 and 2020, Warren 2020, and Clinton 2016, we knew the power of organizing. We saw how conversations—neighbor to neighbor, friend to friend, volunteer to voter—could transform communities and drive movements. Yet, the tools available for voter contact programs regularly fell short of our needs. We built and launched our first product in April 2020, a peer-to-peer (P2P) texting tool. We’ve since added a dialer tool that allows organizations to easily call voters, and Scale to Win Text, an all-in-one texting tool for organizing and fundraising.

During the 2024 US presidential election campaign season, we were the target of distributed denial of service (DDoS) events. These events reached peaks of over 2 million requests per second from nearly ten thousand unique IPs. After a brief window of downtime at the start of these events, Scale to Win partnered with Amazon Web Services (AWS) to implement AWS WAF, AWS Shield Advanced, and Amazon CloudFront to mitigate these targeted DDoS events.

One key element of our defense was AWS WAF support for Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) to automatically present a challenge to suspicious-looking clients. We used this to provide a per-IP rate limit for traffic we expected to see from legitimate clients behind a single IP. For IPs that exceed this rate limit, we present a CAPTCHA and provide a higher rate limit to the maximum amount of traffic we expect to come from a single IP, like a campaign office or college campus.

However, the AWS WAF out-of-the-box CAPTCHA had an important caveat—it doesn’t provide protection against an event using a token that is solved and distributed across a network of machines behind multiple IPs. To prevent this class of event, AWS WAF users need to identify CAPTCHA tokens that are being used from multiple IPs and automatically block this traffic.In this post, you’ll learn how Scale to Win configured our network topology to maximize DDoS protection capacity, configured AWS WAF to block DDoS events, segmented machine-to-machine and browser-to-machine traffic to target CAPTCHA interventions, and blocked token reuse across IP addresses.

Network Topology Overview

The Scale to Win application runs behind an Application Load Balancer (ALB) that serves as the single point of entry to our application servers. Before implementing AWS WAF, our DNS records resolved to the ALB as shown in the following diagram. The diagram shows a path from users to Elastic Load Balancing to an auto scaling group of Amazon Elastic Compute Cloud (Amazon EC2) instances.

Diagram of a VPC with public and private subnets, Elastic Load Balancing, and Amazon EC2 instances

The recommended pattern for using AWS WAF to protect against DDoS events is to instead route traffic through a CloudFront distribution as shown in the following diagram. The diagram shows a path from users to CloudFront with AWS WAF to Elastic Load Balancing to an auto scaling group of EC2 instances.

VPC architecture with AWS WAF, CloudFront, Load Balancing, and EC2 instances

Using this topology, we can take advantage of the following benefits:

  1. The capacity of CloudFront to handle network-layer events sending TCP traffic that aren’t valid HTTP requests is greater than ALB capacity. Network-level protections are strongest when applied by CloudFront before passing traffic to the ALB.
  2. The edge deployment of AWS WAF has higher quotas and capacity than Regional deployments. AWS scales AWS WAF capacity one-to-one with CloudFront capacity, so AWS WAF always has enough capacity to handle incoming traffic.
  3. When implementing a geographic based block strategy, such as blocking specific countries, CloudFront provides a geographic restriction feature. In event patterns we observed, over half of malicious traffic originated from countries that we blocked completely in CloudFront, resulting in cost savings on our AWS WAF deployment.

To prevent threat actors from bypassing our CloudFront distribution and AWS WAF, we implemented a security group that allows traffic only from CloudFront edge IP addresses using the managed prefix list to prevent direct connections to the ALB. We then configured the ALB to require a secret, pre-shared token in a request header, for example, our header x-stw-example-secret. We configured the CloudFront distribution to add that request header when forwarding traffic to the origin. This secret isn’t logged to Application Load Balancer logs but is logged to AWS CloudTrail when setting or updating the CloudFront or ALB configuration. It’s possible to rotate this secret on a schedule by generating a random password with AWS Secrets Manager with an AWS Lambda function to update the CloudFront origin configuration and ALB listener configuration, as shown in the following two screenshots. This shared secret between the CloudFront distribution and ALB means that an event can’t bypass the security group control by configuring its own CloudFront distribution with our ALB as an origin.

The following screenshot shows configuration of the Application Load Balancer, showing a priority-1 rule to route traffic to our target group only if the x-stw-example-secret is correct. A default rule returns a 403 if it’s not correct.

AWS Elastic Load Balancing configuration details, displaying the protocol, port, load balancer name, and SSL/TLS certificate for a listener.

The following screenshot shows CloudFront origin settings, showing a custom header configuration to add the shared secret to requests to the origin.

AWS CloudFront origin settings showing domain, protocol, SSL, and custom header options

Configuring AWS WAF rules

We use two approaches to identify and block malicious DDoS traffic, a heuristic approach and a hard limit approach.

For the heuristic approach, we observe event traffic in AWS WAF sample requests and AWS WAF logs, identify patterns in the event, and block those specific patterns. To use this tactic in your own AWS WAF configuration, first identify a characteristic that is common to all or most event traffic but rare in legitimate traffic, like a HTTP header or query parameter. Create a AWS WAF rule that blocks the traffic. Using the Count rule action is helpful to test your rule and find false-positive and false-negative rates by correlating requests that match the rule with IPs that are sending high volumes of traffic. You can query AWS WAF logs with Amazon Athena to find these correlations. When you’re satisfied with your false-positive and false-negative rates, set the rule action to Block to actively block the matched traffic.

A motivated threat actor will notice the event is being blocked and randomize these parameters to bypass your rules. For example, they might replay legitimate session parameters, so that request URIs, query parameters, and request bodies are identical to legitimate traffic. Ultimately, the heuristic approach is a useful tool, and a good reason to set up logging and Athena to quickly query your AWS WAF logs, but it’s a solution that requires active reconfiguration of your AWS WAF as event patterns change.

One specific heuristic that’s worth calling out is JA4 fingerprints and their predecessor, JA3 fingerprints. A JA4 fingerprint is a hash of several parameters presented by TLS clients in the client hello packet. JA4 fingerprints roughly correspond to the specific TLS client parameters of the request, so they’re usually stable for a specific type of client. For example, a specific version of Google Chrome on a particular operating system has a fingerprint, but a version on a different operating system would have a different fingerprint. This makes JA4 fingerprints a useful heuristic for blocking malicious traffic because the botnet sending the traffic is likely to have a small number of different fingerprints. However, there are two caveats with blocking requests based on JA4 fingerprints:

  1. Threat actors might have the same JA4 fingerprint as legitimate users. In our case, we saw malicious traffic with the same fingerprint as a common NodeJS API client and were unable to block that fingerprint without blocking legitimate API clients.
  2. A sophisticated threat actor can randomize some of the TLS connection parameters, such as the order of TLS extensions in the client hello packet, which is done by threat actors to avoid JA3 fingerprint blocking and some browsers to preserve user privacy. Although the newer JA4 specification reduces some randomization elements, the fundamental challenge remains—because end users maintain control over the client hello packet, this creates an ongoing challenge of adaptation and response.

For the hard limit approach, we take advantage of request parameters that the event can’t fake, such as the source IP of the request. Although the source IP of a packet can be forged, these requests are dropped because they don’t successfully complete the TCP or TLS handshake. You can create AWS WAF rules that limit how much traffic can be sent from a single source IP using rate-based rule statements, setting the limit above what a legitimate user would send but below what the event needs to be effective.

The simplest approach with rate-based rule statements would be to have a single limit in the AWS WAF policy, but this has challenges. First, we have APIs that receive high volumes of machine-to-machine traffic. For example, we place outbound phone calls using Twilio, and Twilio sends tens of thousands of webhooks to our API per second to relay delivery status, sometimes from a single Twilio IP. Also, our application is often used by campaign offices or student-led phone banks on college campuses that might have hundreds of users behind a single or handful of IPs, so we can’t assume that a single IP is being used by a single user to calculate our acceptable rates of traffic.

Segmenting human and machine traffic

To address these challenges, we structure our AWS WAF rules to segment human and machine traffic. We do this by request path: AWS WAF rules can match based on request path, so we have a set of rules for machine traffic based on the webhook URLs or API paths where we expect machine traffic. For all other paths, we assume the traffic originates from a user visiting the site from their browser.

For machine traffic, we can’t use a CAPTCHA. Our API clients and the Twilio webhook infrastructure can’t solve the CAPTCHA, so we validate traffic differently. For our API clients, we set per-IP rate limits to what we expect from a single API client and return a 429 HTTP status when traffic exceeds our limit. We implement automatic retries to handle the occasional 429 error when sending above the limit. For Twilio or other webhook callbacks, we use published IPs from the service provider to create an IP set in AWS WAF. Then, we block requests to our webhook URL that don’t originate from the IP set. Not all service providers use static IPs—for Twilio specifically, we worked with their team to implement their Static Proxy feature to proxy webhook requests from a stable list of IPs. It also makes sense to implement API key authentication, request signing, and certificate-based authentication when possible for your machine traffic. For requests that originate from the IP set, we apply an Allow action in our AWS WAF rule to allow expected machine traffic through, as shown in the following screenshot. These rules allow high-volume machine-to-machine traffic through our AWS WAF configuration before we apply AWS WAF rules to block high volume user-based traffic. The following screenshot shows an example rule allowing expected machine-to-machine traffic.

WAF rule configuration showing machine traffic allow rules with URI path and IP settings

For our browser-based human traffic, we use a tiered rate limit strategy. We implement two tiers of rate limit: a low-level rate limit that corresponds to the maximum rate we expect two to three users to send, and a high-level rate limit that corresponds to the maximum rate we expect from a single IP with hundreds of users sharing the IP. Our low-level rule uses a CAPTCHA rule action when requests exceed the limit. Our high-level rule applies a Block action when requests exceed the limit. We set the high-level rate limit rule priority lower than the low-level rule so it’s processed first, as shown in the following screenshot.

AWS WAF web ACL interface displaying rules for traffic allow, block, and CAPTCHA actions

When a few users are sharing an IP address, they’re unlikely to hit either limit and can use the application without interruption. If a large group of users share an IP address, they’ll need to solve a CAPTCHA. After they solve it, they’re still limited by the high-level rate limit rule, which will prevent a threat actor from solving the CAPTCHA and then sending unlimited traffic using the token issued by AWS WAF.

Handling CAPTCHA on the frontend

For server-rendered applications, AWS WAF handles CAPTCHA challenges automatically through the following process:

  1. When a request matches a CAPTCHA rule without a valid token, AWS WAF presents an AWS managed CAPTCHA challenge page.
  2. Upon successful CAPTCHA completion, AWS WAF issues a Set-Cookie header containing the CAPTCHA token.
  3. Subsequent requests with valid CAPTCHA tokens can pass through AWS WAF for the configured immunity period.

For single-page applications (SPAs) or applications making API requests to a AWS WAF protected backend, additional implementation steps are required:

  1. Configure your frontend to detect blocked requests (HTTP 405 status code indicates CAPTCHA requirement).
  2. Present the CAPTCHA challenge to the user when required.
  3. Resubmit the original request after successful CAPTCHA completion.

The following sample code demonstrates how to implement CAPTCHA handling in a React component using the AWS WAF CAPTCHA JavaScript API:

import { useState, useRef, useEffect, ReactElement } from "react";

declare global {
  class CaptchaError extends Error {
    constructor(message: string);
    kind: "internal_error" | "network_error" | "token_error" | "client_error";
    statusCode?: number;
  }
  interface Window {
    AwsWafCaptcha: {
      renderCaptcha: (
        targetDiv: HTMLElement,
        options: {
          apiKey: string;
          onSuccess: (token: string) => void;
          onError: (err: CaptchaError) => void;
        }
      ) => void;
    };
    AwsWafIntegration: {
      fetch: typeof fetch;
    },
    awsWafCookieDomainList: string[];
  }
}

type DataLoading = {
  state: "loading";
};

type DataError = {
  state: "error";
  message: string;
};

type DataLoaded = {
  state: "loaded";
  data: any;
};

type Data = DataLoading | DataError | DataLoaded;

function MyComponent(): ReactElement {
  const [data, setData] = useState<Data>({ state: "loading" });
  const captchaDiv = useRef<HTMLDivElement>(null);

  useEffect(() => {
    void (async () => {
      try {
        const response = await window.AwsWafIntegration.fetch('/your/api/url');

        if (response.status === 405) {
          // The user needs to solve a captcha. 
          window.AwsWafCaptcha.renderCaptcha(captchaDiv.current!, {
              apiKey: "...API key goes here...",
              onSuccess: async _wafToken => {
                const response = await window.AwsWafIntegration.fetch('/your/api/url');
    
                if (response.status !== 200) {
                  setData({ state: "error", message: "Unable to load data." });
                }
    
                const data = await response.json();
                setData({ state: "loaded", data });
              },
              onError: e => {
                console.error(e);
                setData({ state: "error", message: "Unable to load data." });
              }
              /* ...other configuration parameters as needed... */
          });
          

          return;
        }

        if (response.status !== 200) {
          throw new Error(`Unexpected response status: ${response.status}`);
        }

        const data = await response.json();
        setData({ state: "loaded", data });
      } catch (e) {
        console.error(e);
        setData({ state: "error", message: "Unable to load data." });
      }
    })();
  }, []);

  return (
    <div>
      <div ref={captchaDiv} />
      <div>
        {/* render the data */}
      </div>
    </div>
  );
}

Preventing CAPTCHA token reuse

Although AWS WAF provides built-in CAPTCHA functionality, additional security measures are necessary to prevent token reuse events. In these events, threat actors can solve a CAPTCHA one time and distribute the token across their botnet. AWS WAF Bot Control offers protection against this vulnerability by detecting and blocking CAPTCHA token reuse across multiple IPs, ASNs, or countries.

To implement this protection:

  1. Configure the AWSManagedRulesBotControlRuleSet managed rule group after your rate-limiting rules.
  2. Use the targeted protection level.
  3. Apply Count or Allow actions to specific rules that you don’t want to apply to your traffic instead of a Block or CAPTCHA action.
  4. Monitor and adjust rule actions based on observed traffic patterns.

Conclusion

In this post, you learned how we implemented comprehensive DDoS protection using AWS WAF by:

  • Implementing best practices for AWS WAF network topology using CloudFront
  • Segmenting human and machine traffic in our AWS WAF configuration
  • Using tiered rate limits and CAPTCHA to allow legitimate requests
  • Preventing CAPTCHA token reuse by using AWS WAF Bot Control

To learn more about fine-tuning and optimizing AWS WAF Bot Control, refer to Fine-tune and optimize AWS WAF Bot Control mitigation capability by Dmitriy Novikov in the AWS Security Blog.


About the authors

The collective thoughts of the interwebz