Tag Archives: Uncategorized

People Are Increasingly Choosing Private Web Search

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2022/01/people-are-increasingly-choosing-private-web-search.html

DuckDuckGo has had a banner year:

And yet, DuckDuckGo. The privacy-oriented search engine netted more than 35 billion search queries in 2021, a 46.4% jump over 2020 (23.6 billion). That’s big. Even so, the company, which bills itself as the “Internet privacy company,” offering a search engine and other products designed to “empower you to seamlessly take control of your personal information online without any tradeoffs,” remains a rounding error compared to Google in search.

I use it. It’s not as a good a search engine as Google. Or, at least, Google often gets me what I want faster than DuckDuckGo does. To solve that, I use use the feature that allows me to use Google’s search engine through DuckDuckGo: prepend “!Google” to searches. Basically, DuckDuckGo launders my search.

EDITED TO ADD (1/12): I was wrong. DuckDuckGo does not provide privacy protections when searching using Google.

Friday Squid Blogging: Deep-Dwelling Squid

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2021/12/friday-squid-blogging-deep-dwelling-squid.html

We have discovered a squid — (Oegopsida, Magnapinnidae, Magnapinna sp.) — that lives at 6,000 meters deep.

:They’re really weird,” says Vecchione. “They drift along with their arms spread out and these really long, skinny, spaghetti-like extensions dangling down underneath them.” Microscopic suckers on those filaments enable the squid to capture their prey.

But the squid that Jamieson and Vecchione saw in the footage captured 6,212 meters below the ocean’s surface is a small one. They estimate that its mantle measured 10 centimeters long — ­about a third the size of the largest-known magnapinnid. And the characteristically long extensions observed on other magnapinnids were nowhere to be seen in the video. That could mean, says Vecchione, that this bigfin squid was a juvenile.

Research paper.

As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.

Read my blog posting guidelines here.

Apple AirTags Are Being Used to Track People and Cars

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2021/12/apple-airtags-are-being-used-to-track-people-and-cars.html

This development suprises no one who has been paying attention:

Researchers now believe AirTags, which are equipped with Bluetooth technology, could be revealing a more widespread problem of tech-enabled tracking. They emit a digital signal that can be detected by devices running Apple’s mobile operating system. Those devices then report where an AirTag has last been seen. Unlike similar tracking products from competitors such as Tile, Apple added features to prevent abuse, including notifications like the one Ms. Estrada received and automatic beeping. (Tile plans to release a feature to prevent the tracking of people next year, a spokeswoman for that company said.)

[…]

A person who doesn’t own an iPhone might have a harder time detecting an unwanted AirTag. AirTags aren’t compatible with Android smartphones. Earlier this month, Apple released an Android app that can scan for AirTags — but you have to be vigilant enough to download it and proactively use it.

Apple declined to say if it was working with Google on technology that would allow Android phones to automatically detect its trackers.

People who said they have been tracked have called Apple’s safeguards insufficient. Ms. Estrada said she was notified four hours after her phone first noticed the rogue gadget. Others said it took days before they were made aware of an unknown AirTag. According to Apple, the timing of the alerts can vary depending on the iPhone’s operating system and location settings.

Мрачни опасения

Post Syndicated from original http://www.gatchev.info/blog/?p=2406

Ситуацията в Украйна хич не ми харесва. Нещата, които стигат до мен иззад кулисите – още повече.

Възможно ли е просто да съм уплашен? Или да ме гони параноята? Разбира се. Но е възможно и да съм прав. А кое от двете е реалното – преценете си вие. Или, ако го покажат фактите, си направете изводи.

Малко скучна теория

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

Всяка икономическа система си има два етапа на развитие – екстензивен и интензивен. Примерно съвременната индустриално-пазарна икономика отначало заменя мотиките с трактори, прави излишните селяни на работници, разорава целините и т.н. Екстензивен растеж – усвояват се налични крайни, изчерпваеми ресурси… Когато се изчерпят – колкото може селяни са направени на работници, колкото има целини са разорани и т.н. – започва интензивният етап. На който вече за да намериш работници за нов завод трябва да закриеш стар (не-заети с високопроизводителен труд вече няма), за да построиш нова сграда трябва да разрушиш стара (свободно място вече няма), и т.н.

Защо е важно това? Авторитарните и демократичните системи имат различни силни и слаби страни. Много опростено: авторитарните са по-силни на екстензивния етап, заради централизираната си координация. Пуснете на два еднакви девствени острова авторитарна и демократична системи – авторитарната ще усвои изцяло своя остров първа. Но пък демократичните системи са по-силни на интензивния етап, при тях съпротивата срещу замяната на старото с ново във всякакви отношения се преодолява по-лесно.

Къде е важната разлика? Екстензивният етап е фон Нойманов като характеристика на развитие, бързо изчерпва наличните ресурси. Затова и трае десетки пъти по-малко от интензивния. Съответно в началото на икономическата система авторитарните икономики дръпват рязко и изпреварват пазарните. Но стигнат ли до интензивния етап, влизат в стагнация. Съответно демократичните постепенно ги настигат, задминават и надконкурирват до разпад. Примерно през 1930-те СССР расте с двуцифрени темпове, докато западните икономики ги тресат кризи и депресии. Или пък Германия след катастрофата от Първата световна прави невиждана експлозия на развитие след централизирането на икономиката си под Хитлер, за няма десет години задминава победителите си Англия и Франция… Но малко след средата на 1930-те екстензивният етап за западните икономики приключва и започват да се съвземат. А пък през 1950-те етапът приключва и за СССР (и сателитите му), и в тях започва стагнация. Как свършва това надпреварване знаем.

(Ако питате къде е в картинката Хитлер – идеологията му го притисна към военна експанзия преди да успее да го притисне икономическия преход. Ако беше лидер с мирна визия, до още година-две щеше да приключи екстензивния етап на развитие, и до още максимум 2-3 години след това нуждата от военна експанзия пак щеше да е дошла, с брутална сила заради бързия растеж. А и неговият тип икономика е доста авторитарен, близо до китайския модел. В такива тя притиска много по-тежко, отколкото би притиснала примерно САЩ или някоя западноевропейска страна… Така че Втората световна беше въпрос не на „дали“, а на „кога“.)

От теорията – към практиката

В момента Русия и Китай са на етапа на преход от екстензивен към интензивен растеж. При Русия този преход е доста замазан и постепенен. Започна още преди към 15 години, на базата на оставеното от СССР наследство, и вероятно ще продължава поне още 20-30. Съответно спадането на растежа и стагнацията са разточени върху няколко десетилетия – руските управници не са твърде притиснати от ситуацията. Китай обаче тръгва от де факто феодализъм, и западните фирми и технологии и безмилостната експлоатация на китаеца съградиха индустриална икономика в него с темпове почти като на Хитлерова Германия. За трийсет години – от дървените мотики до първа по сравними цени икономика на света. Няма как преходът да не е рязък и брутален, със силна стагнация след него.

Какъв е резултатът? Дойде ли стагнацията, авторитарната система реагира според ситуацията си. Ако стагнацията е мека и постепенна, околният свят е тежко въоръжен с атомно оръжие и лидерите са хора без много мечти и амбиции извън техния си санджак, ще си кротуват и ще се радват на султанатите си. Ако обаче стагнацията е рязка, околният свят е слаб и разделен, и лидерите са с амбиции да го тъпчат, имат чудесен вариант – военна експанзия. Хем обявяват военни положения и разстрелват и най-дребното несъгласие в страните си, хем прибавят лебенсраум.

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

(Жокер: нито Путин, нито Кси са компромисни мухльовци.)

Ето затова мине-не мине, войските на Русия нагазват където е по-беззащитно и късат по някое парче, да поддържат широка опора за Фюрера сред „патриотизираната“ тълпа. Кога в Молдова, кога в Грузия, кога в Украйна… Путин не е кръволок, би бил щастлив да минава без това. Или поне да спазва подписа си под гаранцията, че ще пази териториалната цялост на Украйна, ако тя се откаже от ядреното оръжие. Само че би означавало сам да влезе в ковчега…

Проблемите на Путин са проблеми на Кси на десета степен. Ако има около някой трон по-безмилостни главорези от тези около руския, това е китайският. И Китай вече влиза в интензивния етап с трясък. Все още рапортува официално годишен растеж от 5-6-7%, но и това е доста надолу от обичайните за последните десетилетия 10-15%. А косвените данни показват, че е лъжа и че реалният растеж вече е не повече от 2-3%. И вероятно и ще продължава да спада… Така че Кси вече е изправен пред проблема „военна експанзия или смърт“.

Съотборници или противници?

В момента Путин изглежда големият проблем и страшният агресор, но не е. Русия временно е сравнително стабилизирана, той не е в остра нужда от външна агресия. Кси обаче е. И, за разлика от Хитлер, той е не маниакален идеолог, а наследник на 5000 години традиция на манипулиране на околните да се избиват едни други, за да печели Китай. За него Русия е просто средство, с което да отвлече войските на „врага“ (НАТО и САЩ) по-далеч от Тайван, или където другаде Кси реши да атакува.

Какво прави Кси? Съюз с Русия. Срещу мръсния империализъм, който ги обгражда, въоръжава съседните им страни… и абе изобщо, не ще да се предаде доброволно и да признае превъзходството на арийската раса. Малко учения, съвместни действия, един-два тайни договора. И преди към година и половина – договореност как да действат заедно, по взаимна изгода.

Путин също е играч от класа. Хем е щастлив от тази договореност, хем не много. Затова играе с Китай, но и си прави своите сметки.

Защо е щастлив? Ако около Китай има наистина лакома хапка, това е Русия. Огромна територия, огромни ресурси, слабо защитени срещу такъв като Китай. Русия няма и 150 милиона население – Китай може да мобилизира 300 милиона армия. И има индустрията да я снабдява с оръжия, над 20 пъти руската. Да, Русия има купища атомно оръжие и може за минути да анихилира 200-300 милиона китайци. От което другарят Кси ще си го премести в другия крачол. В Китай има точно един китаец, чийто живот струва за Кси повече от нищо, и това е той самият. Десет години по-късно Китай ще е една трета от земното кълбо, ако не и повече, а Кси – най-великият император в историята му… И Путин разбира този начин на мислене много добре, твърде сходен е с неговия собствен. Така че е много щастлив, че подобно развитие се отлага.

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

Генералната репетиция

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

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

(Байдън би трябвало да не е загадка за всеки мислещ българин. Ние вече сме имали управник, който изглеждаше идиот, но 35 години седя на власт сред също жадни за власт психопати и нищо не можеше да го помръдне. Чак докато не направи истинската глупост – да се опъне на промени, наредени от Москва… И Байдън винаги е трупал издънка върху издънка – правел е идиотски лапсуси, изглеждал е палячо и като почне да говори, е забравял да спре. Само че вече почти 50 години е непоклатим конгресмен и сенатор в Сената на САЩ. Също място, където недостатъчно акълните не могат и да припарят, камо ли да се задържат. Не е редно мислещ българин да не си зададе въпроса идиот ли е всъщност, или…)

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

Началото на пиесата

Какво е станало между Русия и Китай през пролетта и началото на лятото на 2021, мога само да се досещам. Май е било по-тайно от повечето дипломатически договорки… Но резултатът започна да се вижда още в началото на лятото. Русия продължи да доставя на ЕС договорените количества газ, но нищо повече. А част от потреблението на руски газ в ЕС винаги е било пряко купуване на борсата… И към началото на зимата всички газохранилища в ЕС, които разчитат на руски газ, се оказаха на практика празни. А ЕС политиците решиха, че руснаците просто ще се опитват да качват цената на газа и да натискат за Северен поток – 2. Къде им беше акълът, та не мислиха за военни развития дори след януарската криза, не знам. Европолитиците често са идиоти в това отношение, историята го доказва.

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

Сега сме в същата ситуация като през януари, но този път много по-сериозна. От видимото: Русия спря доставките на газ за ЕС през украинските газопроводи. Турция беше изкарана от руската орбита и почна да доставя оръжие на Украйна – не ща да мисля какъв натиск е бил, за да огъне Ердоган. Натовски самолети разтоварват в Украйна оръжие и военни инструктори с бесни темпове и правят разузнавателни полети над Източна Украйна – преди първото беше в много по-скромни обеми, а второто изобщо го нямаше. Украйна обяви резервистки списъци за всички мъже и жени под 60 години – както високата възраст, така и ангажирането на жените е без аналог в историята ѝ. Швеция обяви повишена бойна готовност за армията си, и се готви да обяви готовност за евакуация на градовете и мобилизация на населението… Има и още много неща, и всичките ги нямаше при предишната криза. И говорят за същото – този път войната ще е трудна за избягване.

Новостите от последния момент

Планът за преговори беше за 10 януари за телефонен разговор между Путин и Байдън, а на 12 – за преговори между НАТО и Русия. Но от Белия дом днес изнесоха, че Путин е поискал спешен разговор с Байдън тази вечер, в 22:30 българско време… Кой и с какво може да накара Путин да си промени рязко плановете до степен да се моли на Байдън за спешен разговор? Точно един човек – Кси. И с нищо по-малко от директна заплаха или за война с Русия, или за живота на Путин. Добра демонстрация кой от двамата в каква позиция е в техния съюз.

А също и колко сериозно е ангажиран Китай с идеята за война срещу Запада. Или по-точно за война на Русия срещу Запада, за да срещне по-малко съпротива в Тайван. Колко здраво ще бъде притисната Русия да стигне на всяка цена до война с НАТО, и по възможност директно със САЩ… Аз лично смятам да следя изказванията на Белия дом след разговора много внимателно. (Кремъл не вярвам да даде информация по въпроса.)

Възможно ли е избягването на войната?

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

Какво следва?

Путин ще бави нещата колкото може да изтърпи Китай, за да даде на Запада възможност да му даде изход от ъгъла. Но пък Китай ще притиска Путин да бърза колкото се може повече, именно за да не даде на Запада възможност да даде на Путин изход. И очевидно има лостовете да притисне Путин до смърт… Така че нещата нищо чудно да се развият по-бързо, отколкото очакваме. А и да стигнат по-далече – може би много по-далече.

Ако Путин получи изход от ъгъла, Украйна ще се спаси. (Този път. Следващият може да е и много скоро – Китай няма да се откаже от военната експанзия, и успехът му в нея зависи от помощта на Русия. Така че дори този път да се мине с мир…) Ако (май по-скоро когато) не го получи, ще нападне Украйна. Кси ще го подкрепя „прикрито“ икономически (ако се наложи – вероятно и военно) и ще следи развитието. Успее ли Русия да прегази Украйна, Кси ще натисне Путин да продължи и към източноевропейските членки на НАТО, за да ангажира САЩ там, и вероятно ще успее. Путин пък вероятно ще поиска първо Китай да нападне Тайван, за да няма възможност САЩ да анихилират руската армия по бързата процедура, преди военната сила да им е потрябвала извън Европа. Може би също ще успее – руската армия има няколко много боеспособни единици, но масата ѝ е пушечно месо. Бъдат ли унищожени боеспособните единици, Русия може да се окаже неспособна да спре натовските армии. А те вероятно ще са амбицирани да се докажат след потенциална загуба на САЩ в Тайван, и ще се опитат да прегазят останалата без ресурси за съпротива Русия. Стигне ли се дотам, Путин ще си изгуби главата още в хода на войната. Съответно при този вариант той може дори официално да смени страните и да се съюзи със Запада срещу Китай – и Кси знае това. Така че има изгода да му помогне, като се ангажира в Тайван преди или едновременно с нападението на Русия срещу НАТО, и да го подкрепя масивно в Украйна и в Европа.

Как ще протече войната в Украйна? Основният удар ще е срещу източните и южни области, да подсигури на Русия дори при по-нататъшно задавяне до окопна война сухопътна граница с Крим и Приднестровието и да откъсне Украйна от Черно море. Най-вероятно ще бъдат бързо прегазени – украинската армия знае, че няма да може да спре първи удар там, ще съсредоточи основните си сили да отбранява Киев. Успее ли да прегази бързо (за седмица-две) Източна и Южна Украйна, Русия ще продължи и срещу Западна. Дали ще смогне да я превземе, и колко бързо ще е, вече е под въпрос. Зависи например от адекватността на украинската армия и западните инструктори в нея, а това е голямо неизвестно.

Ако Русия успее да превземе сравнително бързо и Западна Украйна, натискът от Китай да продължи срещу Източна Европа ще е още по-силен от сегашния. Путин вероятно няма особено желание да го прави, завземането дори само на Източна и Южна Украйна ще е покрило целите му и нуждите на Русия и занапред, а да нападне НАТО е много сериозен риск. Може да се опита да мотае нещата на този етап, да се прави на задавен в Украйна, но надали номерът ще мине пред китайците за дълго. Те търсят да нападнат Тайван, а това със сигурност ще предизвика намесата там на САЩ. А стигне ли се дотам, ще има потенциал дори за варианта с пълна трета световна с ядрено ангажиране. И с разгръщане на войната из целия тихоокеански театър и цяла Европа. (Оттук и реакцията на шведите. Вероятно не са единствената европейска страна, която го прави, просто при тях е по-публично и се разбира.)

Как сме засегнати конкретно българите?

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

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

И това е само началото. Русия няма да може да се противопостави на натиска на Китай да започне война с НАТО, за да ангажира войските му в Европа, далеч от Тайван. В такива ситуации кой плод късат най-напред? Който виси най-ниско към берача. А кой в Европа виси най-ниско към Русия?

И как тя ще задържи под контрол България, след като я превземе? Китайският натиск няма да спре – армията пак ще ѝ трябва, за срещу Западна Европа…

Колко е шансът да се стигне до най-черните варианти? Много ми се иска да е малък, но може и да не е. Затова и пиша този запис – предупреденият е въоръжен. Ако Русия нападне Украйна реално, е важно ситуацията в Тайван да се държи под око. Намеси ли се Китай там, няма да е чудно на България да ѝ остава до руска атака не повече от седмица-две след допрегазването на Украйна. И да е в опасност не само Черноморието, а цяла България.

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

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

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

Ще стане ли? Не зная. Колко е вероятността? Надявам се да не е много. Но ако Русия прегази цяла Украйна, и Китай нападне Тайван… чувствайте се предупредени.

Пък ако всичко това се окажат просто параноични страхове, аз ще съм най-щастлив.

Deep dive into NitroTPM and UEFI Secure Boot support in Amazon EC2

Post Syndicated from Neelay Thaker original https://aws.amazon.com/blogs/compute/deep-dive-into-nitrotpm-and-uefi-secure-boot-support-in-amazon-ec2/

Contributed by Samartha Chandrashekar, Principal Product Manager Amazon EC2

At re:Invent 2021, we announced NitroTPM, a Trusted Platform Module (TPM) 2.0 and Unified Extensible Firmware Interface (UEFI) Secure Boot support in Amazon EC2. In this blog post, we’ll share additional details on how these capabilities can help further raise the security bar of EC2 deployments.

A TPM is a security device to gather and attest system state, store and generate cryptographic data, and prove platform identity. Although TPMs are traditionally discrete chips or firmware modules, their adaptation on AWS as NitroTPM preserves their security properties without affecting the agility and scalability of EC2. NitroTPM makes it possible to use TPM-dependent applications and Operating System (OS) capabilities in EC2 instances. It conforms to the TPM 2.0 specification, which makes it easy to migrate existing on-premises workloads that use TPM functionalities to EC2.

Unified Extensible Firmware Interface (UEFI) Secure Boot is a feature of UEFI that builds on EC2’s long-standing secure boot process and provides additional defense-in-depth that helps you secure software from threats that persist across reboots. It ensures that EC2 instances run authentic software by verifying the digital signature of all boot components, and halts the boot process if signature verification fails. When used with UEFI Secure Boot, NitroTPM can verify the integrity of software that boots and runs in the EC2 instance. It can measure instance properties and components as evidence that unaltered software in the correct order was used during boot. Features such as “Measured Boot” in Windows, Linux Unified Key Setup (LUKS) and dm-verity in popular Linux distributions can use NitroTPM to further secure OS launches from malware with administrative that attempt to persist across reboots.

NitroTPM derives its root-of-trust from the Nitro Security Chip and performs the same functions as a physical/discrete TPM. Similar to discrete TPMs, an immutable private and public Endorsement Key (EK) is set up inside the NitroTPM by AWS during instance creation. NitroTPM can serve as a “root-of-trust” to verify the provenance of software in the instance (e.g., NitroTPM’s EKCert as the basis for SSL certificates). Sensitive information protected by NitroTPM is made available only if the OS has booted correctly (i.e., boot measurements match expected values). If the system is tampered, keys are not released since the TPM state is different, thereby ensuring protection from malware attempting to hijack the boot process. NitroTPM can protect volume encryption keys used by full-disk encryption utilities (such as dm-crypt and BitLocker) or private keys for certificates.

NitroTPM can be used for attestation, a process to demonstrate that an EC2 instance meets pre-defined criteria, thereby allowing you to gain confidence in its integrity. It can be used to authenticate an instance requesting access to a resource (such as a service or a database) to be contingent on its health state (e.g., patching level, presence of mandated agents, etc.). For example, a private key can be “sealed” to a list of measurements of specific programs allowed to “unseal”. This makes it suited for use cases such as digital rights management to gate LDAP login, and database access on attestation. Access to AWS Key Management Service (KMS) keys to encrypt/decrypt data accessed by the instance can be made to require affirmative attestation of instance health. Anti-malware software (e.g., Windows Defender) can initiate remediation actions if attestation fails.

NitroTPM uses Platform Configuration Registers (PCR) to store system measurements. These do not change until the next boot of the instance. PCR measurements are computed during the boot process before malware can modify system state or tamper with the measuring process. These values are compared with pre-calculated known-good values, and secrets protected by NitroTPM are released only if the sequences match. PCRs are recalculated after each reboot, which ensures protection against malware aiming to hijack the boot process or persist across reboots. For example, if malware overwrites part of the kernel, measurements change, and disk decryption keys sealed to NitroTPM are not unsealed. Trust decisions can also be made based on additional criteria such as boot integrity, patching level, etc.

The workflow below shows how UEFI Secure Boot and NitroTPM work to ensure system integrity during OS startup.

workflow

To get started, you’ll need to register an Amazon Machine Image (AMI) of an Operating System that supports TPM 2.0 and UEFI Secure Boot using the register-image primitive via the CLI, API, or console. Alternatively, you can use pre-configured AMIs from AWS for both Windows and Linux to launch EC2 instances with TPM and Secure Boot. The screenshot below shows a Windows Server 2019 instance on EC2 launched with NitroTPM using its inbox TPM 2.0 drivers to recognize a TPM device.

NitroTPM and UEFI Secure Boot enables you to further raise the bar in running their workloads in a secure and trustworthy manner. We’re excited for you to try out NitroTPM when it becomes publicly available in 2022. Contact [email protected] for additional information.

Stolen Bitcoins Returned

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2021/12/stolen-bitcoins-returned.html

The US has returned $154 million in bitcoins stolen by a Sony employee.

However, on December 1, following an investigation in collaboration with Japanese law enforcement authorities, the FBI seized the 3879.16242937 BTC in Ishii’s wallet after obtaining the private key, which made it possible to transfer all the bitcoins to the FBI’s bitcoin wallet.

More on NSO Group and Cytrox: Two Cyberweapons Arms Manufacturers

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2021/12/more-on-nso-group-and-cytrox-two-cyberweapons-arms-manufacturers.html

Citizen Lab published another report on the spyware used against two Egyptian nationals. One was hacked by NSO Group’s Pegasus spyware. The other was hacked both by Pegasus and by the spyware from another cyberweapons arms manufacturer: Cytrox.

We haven’t heard a lot about Cytrox and its Predator spyware. According to Citzen Lab:

We conducted Internet scanning for Predator spyware servers and found likely Predator customers in Armenia, Egypt, Greece, Indonesia, Madagascar, Oman, Saudi Arabia, and Serbia.

Cytrox was reported to be part of Intellexa, the so-called “Star Alliance of spyware,” which was formed to compete with NSO Group, and which describes itself as “EU-based and regulated, with six sites and R&D labs throughout Europe.”

In related news, Google’s Project Zero has published a detailed analysis of NSO Group’s zero-click iMessage exploit: FORCED ENTRY.

Based on our research and findings, we assess this to be one of the most technically sophisticated exploits we’ve ever seen, further demonstrating that the capabilities NSO provides rival those previously thought to be accessible to only a handful of nation states.

By the way, this vulnerability was patched on 13 Sep 2021 in iOS 14.8.

Friday Squid Blogging: UK Recognizes Squid as Sentient Beings

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2021/12/friday-squid-blogging-uk-recognizes-squid-as-sentient-beings.html

This seems big:

The UK government has officially included decapod crustaceans–including crabs, lobsters, and crayfish–and cephalopod mollusks–including octopuses, squid, and cuttlefish–in its Animal Welfare (Sentience) Bill. This means they are now recognized as “sentient beings” in the UK.

As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.

Read my blog posting guidelines here.

Deliverability Sessions: Managing Large Volume Spikes in Email

Post Syndicated from Matt Strzelecki original https://aws.amazon.com/blogs/messaging-and-targeting/deliverability-sessions-managing-large-volume-spikes-in-email/

Introduction:
In an ideal world of email deliverability, email is sent on a regular cadence to a normalized lists of subscribers and recipient email addresses with no major changes in pattern. Typically the volume, list members and content are relatively the same and mailbox providers (such as Gmail) begin to expect that schedule and those volumes. Often times however, marketers are tasked with sending out campaigns (both marketing and transactional) with little time to prepare and even less time to ramp up to a normalized schedule. This can create not only a short term deliverability problem but potentially a long term deliverability problem as your sender reputation may suffer as a result of big changes to volume and cadence. This blog provides some recommendations and points to consider that will give your messages a better chance at inbox placement and thus engagement.

What Internet Service Providers (ISP)/Mailbox Providers (MP) Expect:
As email senders, we are responsible to understand and adhere to the recipient domains we are attempting to send messages. For example, if you are sending a good portion of your emails to Gmail or Yahoo you should understand what each mailbox provider expects in terms of warming up, sending throughput, and general deliverability advice. Examples of these resources can be found here for Gmail and Yahoo. The important thing here is that while general email practices are similar, each mailbox provider may have specific requirements or recommendations for delivering to their users. The mailbox providers top priorities are to #1 deliver wanted messages to their users and #2 block unwanted messages from getting to their users. So one of the keys to developing a good approach even with spikes in sending is to understand your destination ISPs/mailboxes and make sure you’re following the recommended best practices from those ISPs/MPs.

Ultimately you need to build trust with the ISPs/MPs in order to successfully deliver to them. A big part of it is understanding what they expect but the following key areas will also provide valuable recommendations for approaching an email program with variant timing and volumes. These topics include: List hygiene, bounce/complaint management, list segmentation/stacking & scheduling, and IP/Domain environment.

List Hygiene and Management:
The next area of focus we’ll review is your list and how you manage your list. It is important to understand that building a list is hard and takes a lot of time and effort but it is important to build your list(s) organically. This means that you only send to folks who have explicitly signed up for whatever it is you’re planning on sending them. The goal here is to honor your user’s preferences and at times limit the volume of messages if they are unresponsive.

When a recipient becomes unresponsive over a longer period of time (say over 1 year) a few things are happening if you continue to send those addresses email. The first thing that happens is that your user engagement goes down as you are not getting opens for any of those messages sent. This can be problematic especially as mailbox providers shift to more machine learning and A.I. driven filtering decisions, like Gmail. The second thing that often happens is if they are ignoring your messages purposefully and you keep sending, at some point they may select all the messages and flag them all as spam inflating your spam feedback numbers. The third thing that happens is that ISPs/MPs start to see lower overall user engagement which then reduces your sender reputation score with them and if your spam rate spikes as well, you’ll be certain to have deliverability issues.

The best way to manage your list is to be as targeted as possible in terms of your brands, offerings, and what the user initially signed up to receive (or implicitly confirmed through a purchase or transaction). Understand that if a user is not engaging with your message it is best to stop sending that specific series and look at putting them into a win-back style campaign in which you make one to a few more attempts to connect with the recipient and confirm their preferences and opt-in status to those mailing lists.

In large volume sending days, you still need to honor previous unsubscribes and spam complaints by removing them from your active mailing lists and not sending to those addresses that have explicitly opted-out. Additionally, large spikes in bounced email addresses (invalid addresses) will also negatively impact your sender reputation so be sure to keep your suppression list(s) and bounce management current.

More information on strategies for list management are available in this SES Blog post:
https://aws.amazon.com/blogs/messaging-and-targeting/strategies-for-list-management-with-amazon-pinpoint-and-amazon-simple-email-service/

IP/Domain Reputation:
Building and maintaining IP and domain reputation is extremely important when it comes to consistent deliverability and also having good enough sender reputation to have a spike in traffic without immediately running into deliverability issues. The best way to maintain good sender reputation (both IP and domain) is getting high user engagement (Unique Open Rate) and low complaints. High user engagement means users are interacting positively with your messages at a high rate, primarily identified by Opens but can also be supported by clicks as well. The rate can vary based on industry but if you’re getting around a 20% unique open rate, you have high user engagement and are doing well with your list. But rates can vary depending on industry, frequency of sends, types of messages and content. Complaints can hurt deliverability quickly because it is instant feedback to ISPs/MPs and if the complaint rate is high enough it is a major trigger for the ISP/MP to react negatively which typically results in putting messages directly into the spam folder, throttling messages (deferring) and/or blocking the message outright.

List Segmenting and Scheduling:
When it comes to a large volume spike in messaging for your email program list segmenting and scheduling is extremely important. Typically you want to avoid a large spike in volume but at times it is mandatory to send out. To do so you need to split out your segments by likely best performance. You want to send to the subscribers that will most likely engage with the message positively – for instance your new signups, recently engaged in a message and long term engagement (multiple opens within the past 30 days for example). This does two things. First it allows the most likely to positively engage with the message the opportunity to get the message to their inbox. The second thing that will happen is that as you get better initial engagement on your first few segments, your sender reputation will continue to improve and the next segments will have a much better chance at also hitting the inbox as a result of good performance from the first segments.

When you need to send a large volume spike, utilize as much of your scheduling flexibility as you have available. If you have 2 days to send the massive spike, use the full two days and spread the segments out. This helps you reduce the size of your message blasts to an ISP/MP. In addition, you can monitor performance of your segments which will start to give you a better idea of where in your list the ROI might not be worth the risk. For example, once you get towards the end of your list it may not be worth sending to people who have never opened a message in the past year and the risk of a complaint, bounce or unsubscribe may outweigh that benefit of a potential open/click.

Authentication:
There are two authentication mechanisms for email which are SPF and DKIM. SPF (Sender Policy Framework) is a simple text record within the DNS of the sending domain that lists the IP addresses that messages should always come from and a policy indicating what to do with messages that are not from those resources. These options can be rejecting a message, accepting all messages or accepting messages but placing them in the spam folder. Additionally DKIM (DomainKeys Identified Mail) is an encrypted signature within the message header to validate the message came from the purported source. Most mailbox providers require both authentication mechanisms to exists to pass the message on to their users.

In additional to these two authentication mechanisms is another reporting mechanism called DMARC (domain-based message authentication, reporting and conformance). DMARC utilizes SPF and DKIM protocols to indicate to recipient mail servers that the messages are protected by SPF and DKIM and how to handle the messages based on the alignment of these two protocols. In addition to creating a delivery policy, DMARC provides the ability for the recipient to send back reports to the sender indicating a pass or fail of the DMARC evaluation. This is a good mechanism for brands to see if their brand is being spoofed by bad actors and/or if they have authentication issues for various sources of their messages.

Authentication is not only suggested but it is required. Passing SPF and DKIM are critical for message delivery. DMARC allows senders to additionally impose policies based on these two heavily used email authentication protocols. DMARC also provides insight into other sources who may be purporting to your brand.

More information on these protocols can be found here:
SPF: https://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-authentication-spf.html
DKIM: https://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-authentication-dkim.html
DMARC: https://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-authentication-dmarc.html

Final Thoughts:
Even though you will sometimes be forced to go off schedule (or possibly a non-normalized schedule is the norm) you must still try to align with ISP/MP best practices when possible. The goal is to build and maintain trust with not only the ISPs and Mailbox Providers but more importantly with your recipients. Your recipients are your key to email deliverability success – send them what they want and honor their opt-outs or preference center updates and you will be on the right track for good email deliverability.

More Log4j News

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2021/12/more-log4j-news.html

Log4j is being exploited by all sorts of attackers, all over the Internet:

At that point it was reported that there were over 100 attempts to exploit the vulnerability every minute. “Since we started to implement our protection we prevented over 1,272,000 attempts to allocate the vulnerability, over 46% of those attempts were made by known malicious groups,” said cybersecurity company Check Point.

And according to Check Point, attackers have now attempted to exploit the flaw on over 40% of global networks.

And a second vulnerability was found, in the patch for the first vulnerability. This is likely not to be the last.

Green information technology and classroom discussions

Post Syndicated from Gemma Coleman original https://www.raspberrypi.org/blog/green-information-technology-climate-change-data-centre-e-waste-hello-world/

The global IT industry generates as much CO2 as the aviation industry. In Hello World issue 17, we learn about the hidden impact of our IT use and the changes we can make from Beverly Clarke, national community manager for Computing at School and author of Computer Science Teacher: Insight Into the Computing Classroom.

With the onset of the pandemic, the world seemed to shut down. Flights were grounded, fewer people were commuting, and companies and individuals increased their use of technology for work and communication. On the surface, this seemed like a positive time for the environment. However, I soon found myself wondering about the impact that this increased use of technology would have on our planet, in particular the increases in energy consumption and e-waste. This is a major social, moral, and ethical issue that is hiding in plain sight — green IT is big news.

This is a major social, moral, and ethical issue that is hiding in plain sight — green IT is big news.

Energy and data centres

Thinking that online is always better for the planet is not always as straightforward as it seems. If we choose to meet via conference call rather than travelling to a meeting, there are hidden environmental impacts to consider. If there are 50 people on a call from across the globe, all of the data generated is being routed around the world through data centres, and a lot of energy is being used. If all of those people are also using video, that is even more energy than audio only.

Stacks of server hardware behind metal fencing in a data centre.
Data centres consume a lot of energy — and how is that energy generated?

Not only is the amount of energy being used a concern, but we must also ask ourselves how these data centres are being powered. Is the energy they are using coming from a renewable source? If not, we may be replacing one environmental problem with another.

What about other areas of our lives, such as taking photos or filming videos? These two activities have probably increased as we have been separated from family and friends. They use energy, especially when the image or video is then shared with others around the world and consequently routed through data centres. A large amount of energy is being used, and more is used the further the image travels.

Not only is the amount of energy being used a concern, but we must also ask ourselves how these data centres are being powered.

Similarly, consider social media and the number of posts individuals and companies make on a daily basis. All of these are travelling through data centres and using energy, yet for the most part this is not visible to the user.

E-waste

E-waste is another green IT issue, and one that will only get worse as we rely on electronic devices more. As well as the potential eyesore of mountains of e-waste, there is also the impact upon the planet of mining the precious metals used in these electronics, such as gold, copper, aluminium, and steel.

A hand holding two smartphones.
In their marketing, device manufacturers and mobile network carriers make us see the phones we currently own in a negative light so that we feel the need to upgrade to the newest model.

The processes used to mine these metals lead to pollution, and we should also consider that some of the precious metals used in our devices could run out, as there is not an endless supply in the Earth’s surface.

It is also problematic that a lot of e-waste is sent to developing countries with limited recycling plants […].

It is also problematic that a lot of e-waste is sent to developing countries with limited recycling plants, and so much of the e-waste ends up in landfill. This can lead to toxic substances being leaked into the Earth’s surface.

First steps towards action

With my reflective hat on, I started to think about discussions we as teachers could have with pupils around this topic, and came up with the following:

  • Help learners to talk about the cloud and where it is located. We can remind them that the cloud is a physical entity. Show them images of data centres to help make this real, and allow them to appreciate where the data we generate every day goes.
  • Ask learners how many photos and videos they have on their devices, and where they think those items are stored. This can be extended to a year group or whole-school exercise so they can really appreciate the sheer amount of data being used and sent across the cloud, and how data centres fit with that energy consumption. I did this activity and found that I had 7163 photos and 304 videos on my phone — that’s using a lot of energy!
A classroom of students in North America.
Helping young people gain an understanding of the impact of our use of electronic devices is an important action you can take.
  • Ask learners to research any local data centres and find out how many data centres there are in the world. You could then develop this into a discussion, including language related to data centres such as sensors, storage devices, cabling, and infrastructure. This helps learners to connect the theory to real-world examples.
  • Ask learners to reflect upon how many devices they use that are connected to the Internet of Things.
  • Consider for ourselves and ask parents, family, and friends how our online usage has changed since before the pandemic.
  • Consider what happens to electronic devices when they are thrown away and become e-waste. Where does it all go? What is the effect of e-waste on communities and countries?

Tips for greener IT

UK-based educators can watch a recent episode of TV programme Dispatches that investigates the carbon footprint of the IT industry. You can add the following tips from the programme to your discussions:

  • Turn off electronic devices when not in use
  • Use audio only when on online calls
  • Dispose of your old devices responsibly
  • Look at company websites and see what their commitment is to green IT, and consider whether we should support companies whose commitment to the planet is poor
  • Use WiFi instead of 3G/4G/5G, as it uses less energy

These lists are not exhaustive, but provide a good starting point for discussions with learners. We should all play our small part in ensuring that we #RestoreOurEarth — this year’s Earth Day theme — and having an awareness and understanding of the impact of our use of electronic devices is part of the way forward.

Some resources on green IT — do you have others?

What about you? In the comments below, share your thoughts, tips, and resources on green IT and how we can bring awareness of it to our learners and young people at home.

The post Green information technology and classroom discussions appeared first on Raspberry Pi.

Unify log aggregation and analytics across compute platforms

Post Syndicated from Hari Ohm Prasath original https://aws.amazon.com/blogs/big-data/unify-log-aggregation-and-analytics-across-compute-platforms/

Our customers want to make sure their users have the best experience running their application on AWS. To make this happen, you need to monitor and fix software problems as quickly as possible. Doing this gets challenging with the growing volume of data needing to be quickly detected, analyzed, and stored. In this post, we walk you through an automated process to aggregate and monitor logging-application data in near-real time, so you can remediate application issues faster.

This post shows how to unify and centralize logs across different computing platforms. With this solution, you can unify logs from Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Kinesis Data Firehose, and AWS Lambda using agents, log routers, and extensions. We use Amazon OpenSearch Service (successor to Amazon Elasticsearch Service) with OpenSearch Dashboards to visualize and analyze the logs, collected across different computing platforms to get application insights. You can deploy the solution using the AWS Cloud Development Kit (AWS CDK) scripts provided as part of the solution.

Customer benefits

A unified aggregated log system provides the following benefits:

  • A single point of access to all the logs across different computing platforms
  • Help defining and standardizing the transformations of logs before they get delivered to downstream systems like Amazon Simple Storage Service (Amazon S3), Amazon OpenSearch Service, Amazon Redshift, and other services
  • The ability to use Amazon OpenSearch Service to quickly index, and OpenSearch Dashboards to search and visualize logs from its routers, applications, and other devices

Solution overview

In this post, we use the following services to demonstrate log aggregation across different compute platforms:

  • Amazon EC2 – A web service that provides secure, resizable compute capacity in the cloud. It’s designed to make web-scale cloud computing easier for developers.
  • Amazon ECS – A web service that makes it easy to run, scale, and manage Docker containers on AWS, designed to make the Docker experience easier for developers.
  • Amazon EKS – A web service that makes it easy to run, scale, and manage Docker containers on AWS.
  • Kinesis Data Firehose – A fully managed service that makes it easy to stream data to Amazon S3, Amazon Redshift, or Amazon OpenSearch Service.
  • Lambda – A compute service that lets you run code without provisioning or managing servers. It’s designed to make web-scale cloud computing easier for developers.
  • Amazon OpenSearch Service – A fully managed service that makes it easy for you to perform interactive log analytics, real-time application monitoring, website search, and more.

The following diagram shows the architecture of our solution.

The architecture uses various log aggregation tools such as log agents, log routers, and Lambda extensions to collect logs from multiple compute platforms and deliver them to Kinesis Data Firehose. Kinesis Data Firehose streams the logs to Amazon OpenSearch Service. Log records that fail to get persisted in Amazon OpenSearch service will get written to AWS S3. To scale this architecture, each of these compute platforms streams the logs to a different Firehose delivery stream, added as a separate index, and rotated every 24 hours.

The following sections demonstrate how the solution is implemented on each of these computing platforms.

Amazon EC2

The Kinesis agent collects and streams logs from the applications running on EC2 instances to Kinesis Data Firehose. The agent is a standalone Java software application that offers an easy way to collect and send data to Kinesis Data Firehose. The agent continuously monitors files and sends logs to the Firehose delivery stream.

BDB-1742-Ec2

The AWS CDK script provided as part of this solution deploys a simple PHP application that generates logs under the /etc/httpd/logs directory on the EC2 instance. The Kinesis agent is configured via /etc/aws-kinesis/agent.json to collect data from access_logs and error_logs, and stream them periodically to Kinesis Data Firehose (ec2-logs-delivery-stream).

Because Amazon OpenSearch Service expects data in JSON format, you can add a call to a Lambda function to transform the log data to JSON format within Kinesis Data Firehose before streaming to Amazon OpenSearch Service. The following is a sample input for the data transformer:

46.99.153.40 - - [29/Jul/2021:15:32:33 +0000] "GET / HTTP/1.1" 200 173 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36"

The following is our output:

{
    "logs" : "46.99.153.40 - - [29/Jul/2021:15:32:33 +0000] \"GET / HTTP/1.1\" 200 173 \"-\" \"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36\"",
}

We can enhance the Lambda function to extract the timestamp, HTTP, and browser information from the log data, and store them as separate attributes in the JSON document.

Amazon ECS

In the case of Amazon ECS, we use FireLens to send logs directly to Kinesis Data Firehose. FireLens is a container log router for Amazon ECS and AWS Fargate that gives you the extensibility to use the breadth of services at AWS or partner solutions for log analytics and storage.

BDB-1742-ECS

The architecture hosts FireLens as a sidecar, which collects logs from the main container running an httpd application and sends them to Kinesis Data Firehose and streams to Amazon OpenSearch Service. The AWS CDK script provided as part of this solution deploys a httpd container hosted behind an Application Load Balancer. The httpd logs are pushed to Kinesis Data Firehose (ecs-logs-delivery-stream) through the FireLens log router.

Amazon EKS

With the recent announcement of Fluent Bit support for Amazon EKS, you no longer need to run a sidecar to route container logs from Amazon EKS pods running on Fargate. With the new built-in logging support, you can select a destination of your choice to send the records to. Amazon EKS on Fargate uses a version of Fluent Bit for AWS, an upstream conformant distribution of Fluent Bit managed by AWS.

BDB-1742-EKS

The AWS CDK script provided as part of this solution deploys an NGINX container hosted behind an internal Application Load Balancer. The NGINX container logs are pushed to Kinesis Data Firehose (eks-logs-delivery-stream) through the Fluent Bit plugin.

Lambda

For Lambda functions, you can send logs directly to Kinesis Data Firehose using the Lambda extension. You can deny the records being written to Amazon CloudWatch.

BDB-1742-Lambda

After deployment, the workflow is as follows:

  1. On startup, the extension subscribes to receive logs for the platform and function events. A local HTTP server is started inside the external extension, which receives the logs.
  2. The extension buffers the log events in a synchronized queue and writes them to Kinesis Data Firehose via PUT records.
  3. The logs are sent to downstream systems.
  4. The logs are sent to Amazon OpenSearch Service.

The Firehose delivery stream name gets specified as an environment variable (AWS_KINESIS_STREAM_NAME).

For this solution, because we’re only focusing on collecting the run logs of the Lambda function, the data transformer of the Kinesis Data Firehose delivery stream filters out the records of type function ("type":"function") before sending it to Amazon OpenSearch Service.

The following is a sample input for the data transformer:

[
   {
      "time":"2021-07-29T19:54:08.949Z",
      "type":"platform.start",
      "record":{
         "requestId":"024ae572-72c7-44e0-90f5-3f002a1df3f2",
         "version":"$LATEST"
      }
   },
   {
      "time":"2021-07-29T19:54:09.094Z",
      "type":"platform.logsSubscription",
      "record":{
         "name":"kinesisfirehose-logs-extension-demo",
         "state":"Subscribed",
         "types":[
            "platform",
            "function"
         ]
      }
   },
   {
      "time":"2021-07-29T19:54:09.096Z",
      "type":"function",
      "record":"2021-07-29T19:54:09.094Z\tundefined\tINFO\tLoading function\n"
   },
   {
      "time":"2021-07-29T19:54:09.096Z",
      "type":"platform.extension",
      "record":{
         "name":"kinesisfirehose-logs-extension-demo",
         "state":"Ready",
         "events":[
            "INVOKE",
            "SHUTDOWN"
         ]
      }
   },
   {
      "time":"2021-07-29T19:54:09.097Z",
      "type":"function",
      "record":"2021-07-29T19:54:09.097Z\t024ae572-72c7-44e0-90f5-3f002a1df3f2\tINFO\tvalue1 = value1\n"
   },   
   {
      "time":"2021-07-29T19:54:09.098Z",
      "type":"platform.runtimeDone",
      "record":{
         "requestId":"024ae572-72c7-44e0-90f5-3f002a1df3f2",
         "status":"success"
      }
   }
]

Prerequisites

To implement this solution, you need the following prerequisites:

Build the code

Check out the AWS CDK code by running the following command:

mkdir unified-logs && cd unified-logs
git clone https://github.com/aws-samples/unified-log-aggregation-and-analytics .

Build the lambda extension by running the following command:

cd lib/computes/lambda/extensions
chmod +x extension.sh
./extension.sh
cd ../../../../

Make sure to replace default AWS region specified under the value of firehose.endpoint attribute inside lib/computes/ec2/ec2-startup.sh.

Build the code by running the following command:

yarn install && npm run build

Deploy the code

If you’re running AWS CDK for the first time, run the following command to bootstrap the AWS CDK environment (provide your AWS account ID and AWS Region):

cdk bootstrap \
    --cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess \
    aws://<AWS Account Id>/<AWS_REGION>

You only need to bootstrap the AWS CDK one time (skip this step if you have already done this).

Run the following command to deploy the code:

cdk deploy --requires-approval

You get the following output:

 ✅  CdkUnifiedLogStack

Outputs:
CdkUnifiedLogStack.ec2ipaddress = xx.xx.xx.xx
CdkUnifiedLogStack.ecsloadbalancerurl = CdkUn-ecsse-PY4D8DVQLK5H-xxxxx.us-east-1.elb.amazonaws.com
CdkUnifiedLogStack.ecsserviceLoadBalancerDNS570CB744 = CdkUn-ecsse-PY4D8DVQLK5H-xxxx.us-east-1.elb.amazonaws.com
CdkUnifiedLogStack.ecsserviceServiceURL88A7B1EE = http://CdkUn-ecsse-PY4D8DVQLK5H-xxxx.us-east-1.elb.amazonaws.com
CdkUnifiedLogStack.eksclusterClusterNameCE21A0DB = ekscluster92983EFB-d29892f99efc4419bc08534a3d253160
CdkUnifiedLogStack.eksclusterConfigCommand515C0544 = aws eks update-kubeconfig --name ekscluster92983EFB-d29892f99efc4419bc08534a3d253160 --region us-east-1 --role-arn arn:aws:iam::xxx:role/CdkUnifiedLogStack-clustermasterroleCD184EDB-12U2TZHS28DW4
CdkUnifiedLogStack.eksclusterGetTokenCommand3C33A2A5 = aws eks get-token --cluster-name ekscluster92983EFB-d29892f99efc4419bc08534a3d253160 --region us-east-1 --role-arn arn:aws:iam::xxx:role/CdkUnifiedLogStack-clustermasterroleCD184EDB-12U2TZHS28DW4
CdkUnifiedLogStack.elasticdomainarn = arn:aws:es:us-east-1:xxx:domain/cdkunif-elasti-rkiuv6bc52rp
CdkUnifiedLogStack.s3bucketname = cdkunifiedlogstack-logsfailederrcapturebucket0bcc-xxxxx
CdkUnifiedLogStack.samplelambdafunction = CdkUnifiedLogStack-LambdatransformerfunctionFA3659-c8u392491FrW

Stack ARN:
arn:aws:cloudformation:us-east-1:xxxx:stack/CdkUnifiedLogStack/6d53ef40-efd2-11eb-9a9d-1230a5204572

AWS CDK takes care of building the required infrastructure, deploying the sample application, and collecting logs from different sources to Amazon OpenSearch Service.

The following is some of the key information about the stack:

  • ec2ipaddress – The public IP address of the EC2 instance, deployed with the sample PHP application
  • ecsloadbalancerurl – The URL of the Amazon ECS Load Balancer, deployed with the httpd application
  • eksclusterClusterNameCE21A0DB – The Amazon EKS cluster name, deployed with the NGINX application
  • samplelambdafunction – The sample Lambda function using the Lambda extension to send logs to Kinesis Data Firehose
  • opensearch-domain-arn – The ARN of the Amazon OpenSearch Service domain

Generate logs

To visualize the logs, you first need to generate some sample logs.

  1. To generate Lambda logs, invoke the function using the following AWS CLI command (run it a few times):
aws lambda invoke \
--function-name "<<samplelambdafunction>>" \
--payload '{"payload": "hello"}' /tmp/invoke-result \
--cli-binary-format raw-in-base64-out \
--log-type Tail

Make sure to replace samplelambdafunction with the actual Lambda function name. The file path needs to be updated based on the underlying operating system.

The function should return "StatusCode": 200, with the following output:

{
    "StatusCode": 200,
    "LogResult": "<<Encoded>>",
    "ExecutedVersion": "$LATEST"
}
  1. Run the following command a couple of times to generate Amazon EC2 logs:
curl http://ec2ipaddress:80

Make sure to replace ec2ipaddress with the public IP address of the EC2 instance.

  1. Run the following command a couple of times to generate Amazon ECS logs:
curl http://ecsloadbalancerurl:80

Make sure to replace ecsloadbalancerurl with the public ARN of the AWS Application Load Balancer.

We deployed the NGINX application with an internal load balancer, so the load balancer hits the health checkpoint of the application, which is sufficient to generate the Amazon EKS access logs.

Visualize the logs

To visualize the logs, complete the following steps:

  1. On the Amazon OpenSearch Service console, choose the hyperlink provided for the OpenSearch Dashboard 7URL.
  2. Configure access to the OpenSearch Dashboard.
  3. Under OpenSearch Dashboard, on the Discover menu, start creating a new index pattern for each compute log.

We can see separate indexes for each compute log partitioned by date, as in the following screenshot.

BDB-1742-create-index

The following screenshot shows the process to create index patterns for Amazon EC2 logs.

BDB-1742-ec2

After you create the index pattern, we can start analyzing the logs using the Discover menu under OpenSearch Dashboard in the navigation pane. This tool provides a single searchable and unified interface for all the records with various compute platforms. We can switch between different logs using the Change index pattern submenu.

BDB-1742-unified

Clean up

Run the following command from the root directory to delete the stack:

cdk destroy

Conclusion

In this post, we showed how to unify and centralize logs across different compute platforms using Kinesis Data Firehose and Amazon OpenSearch Service. This approach allows you to analyze logs quickly and the root cause of failures, using a single platform rather than different platforms for different services.

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

Resources

For more information, see the following resources:


About the author

HariHari Ohm Prasath is a Senior Modernization Architect at AWS, helping customers with their modernization journey to become cloud native. Hari loves to code and actively contributes to the open source initiatives. You can find him in Medium, Github & Twitter @hariohmprasath.

balluBallu Singh is a Principal Solutions Architect at AWS. He lives in the San Francisco Bay area and helps customers architect and optimize applications on AWS. In his spare time, he enjoys reading and spending time with his family.

Upcoming Speaking Engagements

Post Syndicated from Schneier.com Webmaster original https://www.schneier.com/blog/archives/2021/12/upcoming-speaking-engagements-15.html

This is a current list of where and when I am scheduled to speak:

  • I’m speaking at the RSA Conference 2022 in San Francisco on February 8, 2022.
  • I’m speaking at IT-S Now 2022 in Vienna on June 2, 2022.
  • I’m speaking at the 14th International Conference on Cyber Conflict, CyCon 2022, in Tallinn, Estonia on June 3, 2022.

The list is maintained on this page.

On the Log4j Vulnerability

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2021/12/on-the-log4j-vulnerability.html

It’s serious:

The range of impacts is so broad because of the nature of the vulnerability itself. Developers use logging frameworks to keep track of what happens in a given application. To exploit Log4Shell, an attacker only needs to get the system to log a strategically crafted string of code. From there they can load arbitrary code on the targeted server and install malware or launch other attacks. Notably, hackers can introduce the snippet in seemingly benign ways, like by sending the string in an email or setting it as an account username.

Threat advisory from Cisco. Cloudflare found it in the wild before it was disclosed. CISA is very concerned, saying that hundreds of millions of devices are likely affected.