Post Syndicated from original https://lwn.net/Articles/888524/
The first
alpha release of Asahi Linux, a distribution for Apple M1 silicon, has
been released.
Keep in mind that this is still a very early, alpha
release. It is intended for developers and power users; if you decide to
install it, we hope you will be able to help us out by filing detailed bug
reports and helping debug issues. That said, we welcome everyone to give it
a try – just expect things to be a bit rough.
Post Syndicated from original https://lwn.net/Articles/888519/
The
5.16.16,
5.15.30,
5.10.107, and
5.4.186
stable kernel updates have been released; each contains another set of
important fixes.
Post Syndicated from Lucas Pardue original https://blog.cloudflare.com/a-primer-on-proxies/
Traffic proxying, the act of encapsulating one flow of data inside another, is a valuable privacy tool for establishing boundaries on the Internet. Encapsulation has an overhead, Cloudflare and our Internet peers strive to avoid turning it into a performance cost. MASQUE is the latest collaboration effort to design efficient proxy protocols based on IETF standards. We’re already running these at scale in production; see our recent blog post about Cloudflare’s role in iCloud Private Relay for an example.
In this blog post series, we’ll dive into proxy protocols.
To begin, let’s start with a simple question: what is proxying? In this case, we are focused on forward proxying — a client establishes an end-to-end tunnel to a target server via a proxy server. This contrasts with the Cloudflare CDN, which operates as a reverse proxy that terminates client connections and then takes responsibility for actions such as caching, security including WAF, load balancing, etc. With forward proxying, the details about the tunnel, such as how it is established and used, whether or not it provides confidentiality via authenticated encryption, and so on, vary by proxy protocol. Before going into specifics, let’s start with one of the most common tunnels used on the Internet: TCP.
The TCP transport protocol is a rich topic. For the purposes of this post, we will focus on one aspect: TCP provides a readable and writable, reliable, and ordered byte stream. Some protocols like HTTP and TLS require a reliable transport underneath them and TCP’s single byte stream is an ideal fit. The application layer reads or writes to this byte stream, but the details about how TCP sends this data “on the wire” are typically abstracted away.
Large application objects are written into a stream, then they are split into many small packets and they are sent in order to the network. At the receiver, packets are read from the network and combined back into an identical stream. Networks are not perfect and packets can be lost or reordered. TCP is clever at dealing with this and not worrying the application with details. It just works. A way to visualize this is to imagine a magic paper shredder that can both shred documents and convert shredded papers back to whole documents. Then imagine you and your friend bought a pair of these and decided that it would be fun to send each other shreds.
The one problem with TCP is that when a lost packet is detected at a receiver, the sender needs to retransmit it. This takes time to happen and can mean that the byte stream reconstruction gets delayed. This is known as TCP head-of-line blocking. Applications regularly use TCP via a socket API that abstracts away protocol details; they often can’t tell if there are delays because the other end is slow at sending or if the network is slowing things down via packet loss.
Proxying TCP is immensely useful for many applications, including, though certainly not limited to HTTPS, SSH, and RDP. In fact, Oblivious DoH, which is a proxy protocol for DNS messages, could very well be implemented using a TCP proxy, though there are reasons why this may not be desirable. Today, there are a number of different options for proxying TCP end-to-end, including:
While SOCKS and PEPs are viable options for some use cases, when choosing which proxy protocol to build future systems upon, it made most sense to choose a reusable and general-purpose protocol that provides well-defined and standard abstractions. As such, the IETF chose to focus on using HTTP as a substrate via the CONNECT method.
The concept of using HTTP as a substrate for proxying is not new. Indeed, HTTP/1.1 and HTTP/2 have supported proxying TCP-based protocols for a long time. In the following sections of this post, we’ll explain in detail how CONNECT works across different versions of HTTP, including HTTP/1.1, HTTP/2, and the recently standardized HTTP/3.
In HTTP/1.1, the CONNECT method can be used to establish an end-to-end TCP tunnel to a target server via a proxy server. This is commonly applied to use cases where there is a benefit of protecting the traffic between the client and the proxy, or where the proxy can provide access control at network boundaries. For example, a Web browser can be configured to issue all of its HTTP requests via an HTTP proxy.
A client sends a CONNECT request to the proxy server, which requests that it opens a TCP connection to the target server and desired port. It looks something like this:
CONNECT target.example.com:80 HTTP/1.1
Host: target.example.com
If the proxy succeeds in opening a TCP connection to the target, it responds with a 2xx range status code. If there is some kind of problem, an error status in the 5xx range can be returned. Once a tunnel is established there are two independent TCP connections; one on either side of the proxy. If a flow needs to stop, you can simply terminate them.
HTTP CONNECT proxies forward data between the client and the target server. The TCP packets themselves are not tunneled, only the data on the logical byte stream. Although the proxy is supposed to forward data and not process it, if the data is plaintext there would be nothing to stop it. In practice, CONNECT is often used to create an end-to-end TLS connection where only the client and target server have access to the protected content; the proxy sees only TLS records and can’t read their content because it doesn’t have access to the keys.
Finally, it’s worth noting that after a successful CONNECT request, the HTTP connection (and the TCP connection underpinning it) has been converted into a tunnel. There is no more possibility of issuing other HTTP messages, to the proxy itself, on the connection.
HTTP/2 adds logical streams above the TCP layer in order to support concurrent requests and responses on a single connection. Streams are also reliable and ordered byte streams, operating on top of TCP. Returning to our magic shredder analogy: imagine you wanted to send a book. Shredding each page one after another and rebuilding the book one page at a time is slow, but handling multiple pages at the same time might be faster. HTTP/2 streams allow us to do that. But, as we all know, trying to put too much into a shredder can sometimes cause it to jam.
In HTTP/2, each request and response is sent on a different stream. To support this, HTTP/2 defines frames that contain the stream identifier that they are associated with. Requests and responses are composed of HEADERS and DATA frames which contain HTTP header fields and HTTP content, respectively. Frames can be large. When they are sent on the wire they might span multiple TLS records or TCP segments. Side note: the HTTP WG has been working on a new revision of the document that defines HTTP semantics that are common to all HTTP versions. The terms message, header fields, and content all come from this description.
HTTP/2 concurrency allows applications to read and write multiple objects at different rates, which can improve HTTP application performance, such as web browsing. HTTP/1.1 traditionally dealt with this concurrency by opening multiple TCP connections in parallel and striping requests across these connections. In contrast, HTTP/2 multiplexes frames belonging to different streams onto the single byte stream provided by one TCP connection. Reusing a single connection has benefits, but it still leaves HTTP/2 at risk of TCP head-of-line blocking. For more details, refer to Perf Planet blog.
HTTP/2 also supports the CONNECT method. In contrast to HTTP/1.1, CONNECT requests do not take over an entire HTTP/2 connection. Instead, they convert a single stream into an end-to-end tunnel. It looks something like this:
:method = CONNECT
:authority = target.example.com:443If the proxy succeeds in opening a TCP connection, it responds with a 2xx (Successful) status code. After this, the client sends DATA frames to the proxy, and the content of these frames are put into TCP packets sent to the target. In the return direction, the proxy reads from the TCP byte stream and populates DATA frames. If a tunnel needs to stop, you can simply terminate the stream; there is no need to terminate the HTTP/2 connection.
By using HTTP/2, a client can create multiple CONNECT tunnels in a single connection. This can help reduce resource usage (saving the global count of TCP connections) and allows related tunnels to be logically grouped together, ensuring that they “share fate” when either client or proxy need to gracefully close. On the proxy-to-server side there are still multiple independent TCP connections.
One challenge of multiplexing tunnels on concurrent streams is how to effectively prioritize them. We’ve talked in the past about prioritization for web pages, but the story is a bit different for CONNECT. We’ve been thinking about this and captured considerations in the new Extensible Priorities draft.
QUIC is a new secure and multiplexed transport protocol from the IETF. QUIC version 1 was published as RFC 9000 in May 2021 and, the next day, we enabled it for all Cloudflare customers.
QUIC is composed of several foundational features. You can think of these like individual puzzle pieces that interlink to form a transport service. This service needs one more piece, an application mapping, to bring it all together.
Similar to HTTP/2, QUIC version 1 provides reliable and ordered streams. But QUIC streams live at the transport layer and they are the only type of QUIC primitive that can carry application data. QUIC has no opinion on how streams get used. Applications that wish to use QUIC must define that themselves.
QUIC streams can be long (up to 2^62 – 1 bytes). Stream data is sent on the wire in the form of STREAM frames. All QUIC frames must fit completely inside a QUIC packet. QUIC packets must fit entirely in a UDP datagram; fragmentation is prohibited. These requirements mean that a long stream is serialized to a series of QUIC packets sized roughly to the path MTU (Maximum Transmission Unit). STREAM frames provide reliability via QUIC loss detection and recovery. Frames are acknowledged by the receiver and if the sender detects a loss (via missing acknowledgments), QUIC will retransmit the lost data. In contrast, TCP retransmits packets. This difference is an important feature of QUIC, letting implementations decide how to repacketize and reschedule lost data.
When multiplexing streams, different packets can contain STREAM frames belonging to different stream identifiers. This creates independence between streams and helps avoid the head-of-line blocking caused by packet loss that we see in TCP. If a UDP packet containing data for one stream is lost, other streams can continue to make progress without being blocked by retransmission of the lost stream.
To use our magic shredder analogy one more time: we’re sending a book again, but this time we parallelise our task by using independent shredders. We need to logically associate them together so that the receiver knows the pages and shreds are all for the same book, but otherwise they can progress with less chance of jamming.
HTTP/3 is an example of an application mapping that describes how streams are used to exchange: HTTP settings, QPACK state, and request and response messages. HTTP/3 still defines its own frames like HEADERS and DATA, but it is overall simpler than HTTP/2 because QUIC deals with the hard stuff. Since HTTP/3 just sees a logical byte stream, its frames can be arbitrarily sized. The QUIC layer handles segmenting HTTP/3 frames over STREAM frames for sending in packets. HTTP/3 also supports the CONNECT method. It functions identically to CONNECT in HTTP/2, each request stream converting to an end-to-end tunnel.
We’ve talked about HTTP/1.1, HTTP/2 and HTTP/3. The diagram below is a convenient way to summarize how HTTP requests and responses get serialized for transmission over a secure transport. The main difference is that with TLS, protected records are split across several TCP segments. While with QUIC there is no record layer, each packet has its own protection.
HTTP CONNECT is a simple and elegant protocol that has a tremendous number of application use cases, especially for privacy-enhancing technology. In particular, applications can use it to proxy DNS-over-HTTPS similar to what’s been done for Oblivious DoH, or more generic HTTPS traffic (based on HTTP/1.1 or HTTP/2), and many more.
However, what about non-TCP traffic? Recall that HTTP/3 is an application mapping for QUIC, and therefore runs over UDP as well. What if we wanted to proxy QUIC? What if we wanted to proxy entire IP datagrams, similar to VPN technologies like IPsec or WireGuard? This is where MASQUE comes in. In the next post, we’ll discuss how the MASQUE Working Group is standardizing technologies to enable proxying for datagram-based protocols like UDP and IP.
Post Syndicated from Talks at Google original https://www.youtube.com/watch?v=L2cHRUNwtMM
Post Syndicated from Зорница Христова original https://toest.bg/editorial-14-19-march-2022/
Събуждам се, включвам компютъра, проверявам станало ли е чудо. Това е ритуалът ми от последните дни.
Смея се, разбира се, на себе си. Но вижте: комунистическите режими в Източния блок се срутиха като плочки домино, в Югославия имаше война, после два самолета се забиха в кулите на Световния търговски център, после съобщаваха за други терористични актове, после пандемията, после войната в Украйна… Всички тези неща се случиха извън моята страна (или започнаха другаде). И се отразиха върху нея – жестоко. Една част от тях можеше да бъдат предвидени. Предвидихме ли ги? Имаме ли идея накъде ще се развива настоящата криза?
Много вероятно е например Путин да инвестира сериозен ресурс, за да смени режимите в Източна Европа – да речем, чрез комбинация от информационна война и вложения в удобни за него партии. Анализът на Емилия Милчева „Сезонът на путлеристите“ отчита ръста на подкрепата за „Възраждане“ („най-кресливата, патетична и с прокремълски уклон група в българския парламент“), но не само. Бъдещият проект на бившия военен министър Стефан Янев ще използва същите настроения, казва тя. И шансовете му не са малки. Междувременно президентът не иска самолети на НАТО, въпреки че, по собствените му думи, армията ни няма ресурс да ни защитава. Значи и той чака „чудо“. Дали?
Едно може да се предвиди: политиката на „снишаването“ неизменно води до политика на „потушаване на пожари“ – тоест несръчно, кризисно справяне с неща, за които е трябвало да се подготвим. Това е повече от очевидно при посрещането на украинските бежанци. Тази седмица темата е разгърната в три последователни текста, така че става безпощадно ясно за какво иде реч.
Първо, новата подкаст поредица на Николета Атанасова „Украйна не е загубена“ дава възможност да чуете с ушите си как точно звучи бежанският опит, дава глас на реалните хора зад „броя на потърсилите убежище у нас“. Препоръчвам да започнете оттам.
След като сте чули самите хора, прочетете статията на Светла Енчева, описваща процеса на интегра… чакайте, какъв процес на интеграция? Към момента, в който е публикувана статията, пунктовете за регистрация на бежанците не работят с пълен капацитет, съответно те не могат да получат статут на временна закрила – с всичко следващо от него.
Светла продължава нататък и се опитва да си представи как би изглеждала възможната интеграция в нашето общество с цялата тромавост на административния апарат, с езиковата бариера и т.н. Как може човек да се оправи в системата на здравеопазването например? Ами в образователната система? Та тя не може да интегрира дори българчета с друг майчин език, напомня авторката. Леко се размечтавам за стандартна практика от добре разработени курсове по български за двуезични учители, но нищо такова няма да стане, разбира се, въпросът ще се реши „по чудо“.
Ако съществува антоним на думата „чудо“, то вероятно е нещо, което спъва и нормалните рационални решения на проблемите. Не забързва действието, а го забавя до обезсмисляне. Според статията на Венелина Попова такава структура е Държавната агенция за бежанците.
Към въпросите, зададени на председателката на ДАБ при изслушването в парламента, Венелина добавя още доста – свързани както с ефективността на Агенцията, така и със съмненията за вътрешна корупция. Става ясно, че са отпуснати 100 допълнителни щатни бройки за справяне с кризата, но ДАБ не само не предприема нищо специално (например да сформира мобилни екипи за най-натоварените места), но и отказва да регистрира бежанци. Тези, които били влезли легално в страната и имали право на 90-дневен престой, не били неин проблем. И така нататък.
Толкова по настоящата (уж неочаквана) криза. А какво може да предстои? Статията на арх. Анета Василева за настъплението на Китай в архитектурната геополитика на Африка показва възможна посока за радикална промяна на света. Китай може да се окаже по-близо, отколкото мислим – като най-големия инвеститор на подценявания, но богат на ресурси африкански континент. Така както в момента обмисля да изкупи акциите на руски енергийни фирми. И така както позицията на Пекин би могла да наклони везните във войната между Русия и Украйна.
С други думи, твърде вероятно е оттук нататък икономическата тежест на Китай да нараства и да се усеща все по-близо до нас. В същото време само преди седмица чух от млада китаистка с икономически профил, че няма смисъл да работи по специалността си.
Не по-малко важно от предвиждането на бъдещето е да осмислим какво все пак ни се е случвало в миналото. Особено ако то се явява бяло петно, нещо, което удобно се пропуска. Точно такъв е случаят с войната, която се водеше през 90-те в непосредствено съседство до нас – и точно затова за рубриката „На второ четене“ Стефан Иванов посяга към книга именно по тази тема. „Югославия, моя любов“ на Горан Войнович е роман, който разделя историята на късчета и ги събира по друг начин. И макар обърнат назад, гледа и напред към онова, което предстои – „как може войната да свърши и човешкото същество не само да оцелее, но и да продължи живота си“.
Междувременно едно малко локално чудо все пак се случи. Арестът на бившия премиер Бойко Борисов предизвика повече ентусиазъм от настъпването на Нова година. Eмилия Милчева обаче нарича тази акция по-скоро изпитание – и за Европрокуратурата, и за управляващите у нас. Дали ще доведе до усещане, че борбата с корупцията все пак е възможна, или напротив, ще смъкне още повече авторитета на правителството – зависи от това как ще се развие. Да видим.
А след сутрешната проверка, ако чудото пак е забравило да настъпи, най-добре да действаме. Все нещо ни е по силите.
Post Syndicated from Стефан Иванов original https://toest.bg/na-vtoro-chetene-yugoslaviya-moya-strana-goran-vojnovic/
превод от словенски Лилия Мързликар, изд. ICU, 2019
Когато се събудихме на 24 февруари и се оказа, че още преди изгрев-слънце Русия е започнала война с Украйна, някои от спонтанните, шокирани коментари, които чух и четох, бяха, че това е първото подобно събитие от Втората световна война насам. Моята първа мисъл беше, че клането в Сребреница е от още по-скоро, а градчето е на няма и 500 километра от София.
Затова и потърсих книга за войната в Босна и Херцеговина. Защото за което не може да се говори, понякога още повече трябва да се говори. Да се пишат романи за него, но и да се четат. Да се помни, за да може да се избегне, ако е възможно, катастрофалното и порочно безкрайно повторение.
Днес за Босна и Херцеговина все още има реален риск от разпад. Литературата (да не се бърка с пропагандата) желае да предотврати такива разпади. Тя сънува и мечтае за едни и същи неща, откакто я има – прехвърляне на буквалните и брутални конфликти в полето на символното и словесното. Част от литературата дори си мислеше, че го е постигнала и че е дошъл краят на реалната война, краят на национализма и фанатизма, настъпил е конкретен вечен мир, в който като планетарно общество трябва да се справим с климатичната криза.
Когато разбрах, че словенският писател Горан Войнович е издал „Югославия, моя страна“ на 33-годишна възраст, се учудих как е могъл да напише толкова цялостен, детайлен, майсторски, мъдър, дълбок и панорамен роман. При това и с чувство за хумор. В разговор с Антония Апостолова той казва, че книгата „като че ли отваря най-много личната ми рана“. И е наистина така. Трудно ми беше да повярвам, че това не е автобиография и изповед, стигаща до дъното на всичко, което може да се разкаже. Като читател още чакам поне сходен такъв български роман. Дано го дочакам.
Войнович отново ми връща вярата, че има голяма ценност и смисъл от такова рисковано писане, което всячески се опитва да не премълчава нищо. Нито красотата на детството, нито националните предразсъдъци, нито родовите травми, нито безизходицата, която идва и не си отива, каквото и да направиш, нито сякаш неизчерпаемата способност на хората на Балканите да се обиждат от всичко и после да си отмъщават. Войнович не ги превръща в стилизирани, безобидни и сантиментални лостове за трогване и сълзи. Те имат своята тежест и сила. Не са в кавички.
Писателят не спекулира и не си играе с дистанцирани или иронични предположения и фантасмагории. Не. В същото интервю по-горе той казва:
… една от способностите на литературата е да разглоби официалната история на отделни части и след това от тях да сглоби една по-различна история. Литературата всъщност си играе свободно със спомените и понякога извиква и онези, вече забравените, а по този начин, естествено, разкрива истинската природа на спомените, както и на историите.
Той се пита и усилено се опитва да отговори откъде идват тези пръчки, които все се забиват в колелата на личния и общия живот. Защо те увреждат съдбите на поколение след поколение жители на Балканите и не само тук. И възможни ли са прошка и помирение. Войнович препотвърждава старата и уж очевидна истина, че въображението и свободата, които дава романът като жанр за изразяване на множество разкази, ценности и разбирания, трудно могат да бъдат постигнати с друг тип писане. Истински литературен подвиг е да обемеш сложността на случилото се през 90-те в бивша Югославия и да го предадеш по такъв директен и открит начин. Книгата буквално се чете на един дъх.
За син, който мисли, че баща му е покойник, а всъщност се оказва, че не е – и синът тръгва да го търси. За баща, който е спрял да бъде баща, за да бъде само военен, а после и военен престъпник и беглец от закона и съвестта си. За майка, която е спряла да бъде майка на сина си, така както и нейните майка и баща са се отказали да ѝ бъдат родители. За Югославия, Сърбия, Хърватия, Македония, Черна гора, Босна и Херцеговина. За изгубената невинност, която от един момент нататък няма как да си наденеш даже като маска.
Става въпрос и за дузина човеци, живеещи в малък апартамент по време на война и как „спокойният сън представляваше единствената привилегия, която можеха да предоставят на децата си“:
Вероятно само затова не спираха да ходят на пръсти, сърбаха в мълчание едно след друго джезве турско кафе, четяха вестници и си кимаха или поклащаха глава […] всичко това без думи, без да изпуснат един-единствен звук. Бяха си създали свой собствен и тих свят, в който за няколко часа всички телефони, транзистори, чайници, тенджери под налягане, домофони, машинки за бръснене, сешоари, телевизори, мелнички за кафе, кухненски роботи и перални млъкваха. Всяка сутрин тези хора се отказваха отново и отново от тях, само и само да не събудят случайно Йована, Мишо или Владан, които бяха толкова сладки, докато спят, както обичаше да прошепва Сава, надничайки в спалнята.
В крайна сметка в тъмното и болезнено сърце на романа е историята за това как се става „човек, който подпалва села и хвърля мъртъвците в купища един върху друг“:
Това беше омагьосан кръг и за миг през ума ми мина мисълта, че може би и самият аз съм част от тази проклета история и някога някой може да захвърли и моя труп върху купчина други трупове, в която след това ще се взира онзи, който ще остане след мен. В тази премълчана история жертвите ставаха палачи, а палачите ставаха жертви и всички в тази история убиваха или бяха убити.
Как да се изплъзнеш от порочния кръг? Как да вземеш съдбата си в ръце? Как да избереш да не повтаряш същата грешка? Как може войната да свърши и човешкото същество не само да оцелее, но и да продължи живота си?
Книгата на Войнович поставя и тези въпроси, но читателят, с действията си във всекидневието, ще даде собствените си отговори.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2022/03/friday-squid-blogging-the-costs-of-unregulated-squid-fishing.html
Greenpeace has published a report, “Squids in the Spotlight,” on the extent and externalities of global squid fishing.
News article.
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.
Post Syndicated from Garrett Galow original https://blog.cloudflare.com/domain-scoped-roles-early-access/
Today, Cloudflare is making it easier for enterprise account owners to manage their team’s access to Cloudflare by allowing user access to be scoped to sets of domains. Ensuring users have exactly the access they need and no more is critical, and Domain Scoped Roles provide a significant step forward. Additionally, with the introduction of Domain Groups, account owners can grant users access to domains by group instead of individually. Domains can be added or removed from these groups to automatically update the access of those who have access to the group. This reduces toil in managing user access.
One of the most common uses we have seen for Domain Scoped Roles is to limit access to production domains to a small set of team members, while still allowing development and pre-production domains to be open to the rest of the team. That way, someone can’t make changes to a production domain unless they are given access.
If you are an enterprise customer please talk with your CSM to get you and your team enrolled. Note that you must have Super Administrator privileges to be able to modify account memberships.
Once the beta has been enabled for you, here is how to start using it:
In addition to manually creating inclusion or exclusion lists per user, account owners can also create Domain Groups to allow granting one or more users to a group of domains. Domain Groups can be created from the member invite flow or directly from Account Configurations -> Lists. When creating a domain group, the user selects the domains to include and, from that point on, the group can be used when inviting a user to the account.
Domain Scoped Roles is possible because of a new permission system called Bach. Bach provides a policy based system for defining authorization to Cloudflare’s control plane. Authorization defines what someone can do in a system. Bach has been powering API Tokens, but going forward all authorization will use Bach. This gives customers the ability to define more granular permissions and resource scoping. Resources can be any object a user interacts with whether that be accounts, zones, worker environments, or DNS records to name a few.. Whereas before Cloudflare’s RBAC system relied on assigning a set of roles in which each role defined broad permissions that applied to an entire account, Bach’s policies allow for deeper permission grants that can be scoped to sets of resources.
Let’s take a look at the legacy system and how it compares to what Bach supports. Typically, user’s permissions are defined by the ‘roles’ that they are assigned to. These included: ‘Super Administrator’, ‘Administrator’, ‘Cloudflare for Teams’, and ‘Cloudflare Workers Admin’ to name a few. In the legacy system, each of these maps to an explicit set of simple permissions like ‘workers:read’, ‘workers:edit’ or ‘zones:edit’. When requests get made either via the Cloudflare API or the Cloudflare dashboard, Cloudflare’s API Gateway would check to see if, for the endpoint requested, an actor had the correct permissions to perform the action. In order to change a zone setting, the actor would need to have the ‘zone:edit’ permission – which could be granted from one of many roles. Below is what a user with only ‘DNS’ permissions is granted in the legacy system:
| Permission | Edit | Read |
|---|---|---|
| dns_records | ✔ | ✔ |
| legal | ✔ | |
| account | ✔ | |
| subscription | ✔ | |
| zone | ✔ | |
| zone_settings | ✔ |
While straightforward, this had many drawbacks. First, this meant the inability to define limits on the resources the permissions applied to, whether that be a set of resources or attributes of resources. Second, permissions for a given ‘resource’ were simply read or edit, where edit included creating and deleting. These don’t fully capture the needs that may exist – for example, limiting deletions while allowing edits.
With Bach we have an expanded capability to define granular permissions for authorization. An example policy defining the aforementioned ‘DNS’ member’s access would look like this:
(slightly modified for readability)
#Legacy DNS Role - applies to all zones
policies:
- id: 186f95f3bda1443c986aeb78b05eb60b
permission_groups:
- id: 49ce85367bae433b9f0717ed4fea5c74
name: DNS
meta:
description: Can edit DNS records.
editable: 'false'
label: dns_admin
scopes: com.cloudflare.api.account
permissions:
- key: com.cloudflare.registrar.domain.read
- key: com.cloudflare.registrar.domain.list
- key: com.cloudflare.registrar.contact.read
- key: com.cloudflare.registrar.contact.list
- key: com.cloudflare.api.account.secondary-dns.update
- key: com.cloudflare.api.account.secondary-dns.read
- key: com.cloudflare.api.account.secondary-dns.delete
- key: com.cloudflare.api.account.secondary-dns.create
- key: com.cloudflare.api.account.zone.secondary-dns.update
- key: com.cloudflare.api.account.zone.secondary-dns.read
- key: com.cloudflare.api.account.zone.secondary-dns.delete
- key: com.cloudflare.api.account.zone.secondary-dns.create
- key: com.cloudflare.api.account.notification.*
- key: com.cloudflare.api.account.custom-ns.update
- key: com.cloudflare.api.account.custom-ns.list
- key: com.cloudflare.api.account.custom-ns.*
- key: com.cloudflare.edge.spectrum.app.list
- key: com.cloudflare.edge.spectrum.app.read
- key: com.cloudflare.api.account.zone.custom-page.read
- key: com.cloudflare.api.account.zone.custom-page.list
- key: com.cloudflare.api.account.zone.setting.read
- key: com.cloudflare.api.account.zone.setting.list
- key: com.cloudflare.api.account.zone.dnssec.update
- key: com.cloudflare.api.account.zone.dnssec.read
- key: com.cloudflare.api.account.dns-firewall.cluster.delete
- key: com.cloudflare.api.account.dns-firewall.cluster.update
- key: com.cloudflare.api.account.dns-firewall.cluster.read
- key: com.cloudflare.api.account.dns-firewall.cluster.create
- key: com.cloudflare.api.account.dns-firewall.cluster.list
- key: com.cloudflare.api.account.zone.dns-record.delete
- key: com.cloudflare.api.account.zone.dns-record.update
- key: com.cloudflare.api.account.zone.dns-record.read
- key: com.cloudflare.api.account.zone.dns-record.create
- key: com.cloudflare.api.account.zone.dns-record.list
- key: com.cloudflare.api.account.zone.page-rule.read
- key: com.cloudflare.api.account.zone.page-rule.list
- key: com.cloudflare.api.account.zone.railgun-connection.read
- key: com.cloudflare.api.account.zone.railgun-connection.list
- key: com.cloudflare.api.account.zone.subscription.read
- key: com.cloudflare.api.account.zone.aml.read
- key: com.cloudflare.api.account.zone.read
- key: com.cloudflare.api.account.zone.list
- key: com.cloudflare.api.account.audit-log.read
- key: com.cloudflare.api.account.custom-page.read
- key: com.cloudflare.api.account.custom-page.list
- key: com.cloudflare.api.account.railgun.read
- key: com.cloudflare.api.account.railgun.list
- key: com.cloudflare.api.account.dpa.read
- key: com.cloudflare.api.account.subscription.read
- key: com.cloudflare.api.account.subscription.list
- key: com.cloudflare.api.account.read
- key: com.cloudflare.api.account.list
resource_groups:
- id: 2fe938e0a5824128bdc8c42f9339b127
name: com.cloudflare.api.account.a67e14daa5f8dceeb91fe5449ba496eb
meta:
editable: 'false'
scope:
key: com.cloudflare.api.account.a67e14daa5f8dceeb91fe5449ba496eb
objects:
- key: "*"
access: allow
You can see a greater granularity in the permissions that are defined. In both cases, the user can perform the same actions, but the granularity means we are more explicit about what can be done. Here for DNS records (under com.cloudflare.api.account.zone.dns-record) there are explicit create, read, update, delete and list permissions. In the resource group section, we can see that the scope section defines an account. Any objects like domains in that account will match to the “*” value under ‘objects’. This means that these permissions apply throughout the entire account. Now, let’s modify this user’s permissions to be scoped to a single domain and see how the policy changes.
(slightly modified for readability)
# Zone Scoped DNS role - scoped to 1 zone
policies:
- id: 80b25dd735b040708155c85d0ed8a508
permission_groups:
- id: 132c52e7e6654b999c183cfcbafd37d7
name: Zone DNS
meta:
description: Grants access to edit DNS settings for zones in an account.
editable: 'false'
label: zone_dns_admin
scopes: com.cloudflare.api.account.zone
permissions:
- key: com.cloudflare.api.account.zone.secondary-dns.*
- key: com.cloudflare.api.account.zone.dnssec.*
- key: com.cloudflare.api.account.zone.dns-record.*
- key: com.cloudflare.api.account.zone.analytics.dns-report.*
- key: com.cloudflare.api.account.zone.analytics.dns-bytime.*
- key: com.cloudflare.api.account.zone.setting.read
- key: com.cloudflare.api.account.zone.setting.list
- key: com.cloudflare.api.account.zone.rate-plan.read
- key: com.cloudflare.api.account.zone.subscription.read
- key: com.cloudflare.api.account.zone.read
- key: com.cloudflare.api.account.subscription.read
- key: com.cloudflare.api.account.subscription.list
- key: com.cloudflare.api.account.read
resource_groups:
- scope:
key: com.cloudflare.api.account.a67e14daa5f8dceeb91fe5449ba496eb
objects:
- key: com.cloudflare.api.account.zone.b1fbb152bbde3bd28919a7f4bdca841f
access: allow
Once we scope the user’s permissions to only include one explicit zone, we see two main differences. First, there is a large reduction in permissions. This is because we do not grant the user access to read or list many account level resources that the legacy account scoped roles grant. The only account level permissions granted are account.read, subscriptions.read, and subscriptions.list. These permissions are necessary for a user to be able to use the dashboard. When viewing the account in the dashboard the only account level product that will be shown is domains. Other products like Cloudflare Workers, Zero Trust, etc will be hidden.
Second, in the resource groups scope section, we see an explicit mention of a zone (line X: com.cloudflare.api.account.zone.b1fbb152bbde3bd28919a7f4bdca841f). This means that the zone permissions outlined in the policy only apply to that specific zone. Any attempt to access other features of that zone or to modify DNS for any other zones will be rejected by Cloudflare.
If you are an enterprise customer and interested in getting started with Domain Scoped Roles, please contact your CSM to get enabled for the Early Access period. This announcement represents a significant milestone in our migration to Bach, an authorization system built for Coudflare’s scale. This will allow us to expand these same capabilities to more products in the future and to create an authorization system that puts customers more in control of their team’s access across all of Cloudflare’s services. Stay tuned as we are just getting started!
Post Syndicated from Molly Cinnamon original https://blog.cloudflare.com/securing-cloudflare-using-cloudflare/
When a new security threat arises — a publicly exploited vulnerability (like log4j) or the shift from corporate-controlled environments to remote work or a potential threat actor — it is the Security team’s job to respond to protect Cloudflare’s network, customers, and employees. And as security threats evolve, so should our defense system. Cloudflare is committed to bolstering our security posture with best-in-class solutions — which is why we often turn to our own products as any other Cloudflare customer would.
We’ve written about using Cloudflare Access to replace our VPN, Purpose Justification to create granular access controls, and Magic + Gateway to prevent lateral movement from in-house. We experience the same security needs, wants, and concerns as security teams at enterprises worldwide, so we rely on the same solutions as the Fortune 500 companies that trust Cloudflare for improved security, performance, and speed. Using our own products is embedded in our team’s culture.
We’ve built the muscle to think Cloudflare-first when we encounter a security threat. In fact, many security problems we encounter have a Cloudflare solution.
Our Detection & Response team has regained visibility into security threats by connecting corporate devices to Gateway through our Cloudflare WARP application. These Zero Trust products shield users and devices from security threats like malware, phishing, shadow IT and more, as well as enable our Security team to instantly block threats and prevent sensitive data from leaving our organization — with no performance impact for our employees, no matter their location.
Our Identity and Access Management team uses Access to create policies that minimize data access, ensuring that our employees only have access to what they need. Flexibility and instantaneous application of policies allow for ease of scalability as our internal tooling and teams evolve. With Purpose Justification Capture, employees must also justify their use case for visiting domains with particularly sensitive data — which not only solves an internal need for Cloudflare, but helps our customers meet data policy requirements (like GDPR).
Our Product Security Engineering team uses Cloudflare’s development platform Workers to seamlessly deploy a code review assist framework to flag secrets, vulnerability dependencies, and binary security flags. The flexibility of Workers enables the Security team to evolve the tool depending on security concerns and scale it to the hundreds of PRs the company generates per week.
These are just some of the ways the Security team has used Cloudflare’s products to block malicious domains, streamline access management, provide visibility into threats, and harden our overall security posture. To give a sense of how we think about these challenges technically, we will dive into the implementation of a use of Cloudflare to secure Cloudflare.
Two-factor authentication is one of the most important security controls that can be implemented. Not all second factors provide the same level of security though. Time-based One-time password (TOTP) apps like Google Authenticator are a strong second factor, but are vulnerable to phishing via man-in-the-middle attacks. A successful phishing attack on an employee with privileged access is a terrifying thought, and it is a risk we wanted to completely eliminate.
FIDO2 was developed to provide simple UX and complete protection against phishing attacks. We decided to fully embrace FIDO2 supported security keys in all contexts, but FIDO2 support is not yet ubiquitous and there are many challenging compatibility issues. Cloudflare Access allowed us to enforce that FIDO2 was the only second factor that can be used when reaching systems protected by Cloudflare Access.
In order to manage our Cloudflare Access policies we check each one into source control as terraform code. Group based access control is enforced for our applications.
resource "cloudflare_access_policy" "prod_cloudflare_users" {
application_id = cloudflare_access_application.prod_sandbox_access_application.id
zone_id = cloudflare_zone.prod_sandbox.id
name = "Allow "
decision = "allow"
include {
email_domain = ["cloudflare.com"]
okta {
# Require membership in Sandbox group
name = ["ACL-ACCESS-sandbox"]
identity_provider_id = cloudflare_access_identity_provider.okta_prod.id
}
}
# Require a security key
require {
auth_method = "swk"
}
}
The require section enforces that Cloudflare employees are using their FIDO2 supported security keys to access all of our internal and external applications that are protected by Access. More deeply described in RFC8176, auth_method is enforcing specific values are returned during the login flow from our OIDC provider within the amr field. The enforced swk is “Proof of possession of a software-secured key” which corresponds to logins using a security key.
The ability to enforce the use of security keys when accessing internal sites caused a massive improvement in our security posture. Prior to implementing this change, for many of our internal services we allowed both soft tokens like TOTP with Google Authenticator, along with WebAuthn because of a small number of systems that still didn’t support FIDO2. You’ll see that our use of soft tokens dropped to near zero after enforcing this change.
Not only does the Security team deploy Cloudflare’s products, but we test them first too. We work directly with Product to “dog food” our own products first. It’s our mission to help build a better Internet — and that means testing our products and collecting valuable feedback from our internal teams before every launch. As the number one consumer of Cloudflare’s products, the Security team is not only helping keep the company safer, but also contributing to build better products for our customers.
To learn more about examples and technical implementation of our use of Cloudflare products at Cloudflare, please check out this recent Cloudflare TV segment on Securing Cloudflare with Cloudflare.
And for more information on the products mentioned in this document, reach out to our Sales team to find out how we can help you secure your business, teams, and users.
Post Syndicated from Molly Cinnamon original https://blog.cloudflare.com/using-cloudflare-one-to-secure-iot-devices/
There is probably an insecure device with an exploitable vulnerability sitting in your house. And your office. And probably even your child’s school. Cameras, printers, speakers, access control readers, thermostats, even heart monitors… all of these devices are, or can be, Internet of Things (IoT) devices. These IoT devices are seamlessly integrated into our modern lives to improve efficiency and control of our environments — yet they are notoriously insecure. This is due to the constrained nature of device hardware and their limited computational capacity, which often lead to minimize access controls, hard-coded passwords, and an inability to patch remotely.
The reality of this threat can play out dramatically. Take, for example, the 2016 Mirai botnet attack, in which hackers exploited millions of IoT devices to become a large-scale botnet network capable of launching DDoS attacks that took down major portions of the Internet, including Twitter, the Guardian, and CNN. These types of attacks are hardly an infrequent occurrence. Cloudflare experienced this reality firsthand in March 2021, when one of our potential vendors for physical security cameras, Verkada, was compromised. The incident allowed a hacker to access Verkada’s internal support tools to manage the cameras remotely, enabling them to attempt to move laterally to other devices in the network. Thankfully, our use of a Zero Trust model at Cloudflare prevented the hackers from moving laterally; the incident affected the cameras and nothing else.
But even if we’re unaffected, we view security incidents as a challenge to take our security products one step further. So we asked ourselves: can we use our own products to secure IoT devices themselves — even on the same network as production systems – thus ensuring any compromise of these notoriously insecure devices is isolated? Using Cloudflare One, the answer is yes.
As aforementioned, Cloudflare was not impacted by an IoT compromise because we use a Zero Trust model. If the environmental considerations are suitable, such as in Cloudflare’s corporate offices, the enterprise network can be ring-fenced with a Zero Trust model. Lateral movement is prevented because hitting any other part of the network requires authentication for access. Given that the IoT device itself is not isolated, careful attention must be paid to put all other network points of entry behind zero trust access.
However, not all environments can be so diligently controlled. Take, for example, data centers. The presence of other vendors, complexity of old production networks, and prevalence of machine-to-machine connections means we can’t provide the same zero trust guarantees upon installing an IoT device (such as an access reader or a camera) as we can in our corporate offices. As the complexity of the environment grows, successfully deploying a Zero Trust model to prevent successful lateral movement from IoT devices only becomes more difficult.
Many enterprises deploy their IoT devices on a completely separate network from production, utilizing an out-of-band network or VLAN. While VLANs create isolation at Layer 2, they require access lists at their upstream routed interface to restrict Layer 3 traffic. And many network administrators want additional configurations for more stringent guarantees, such as access lists for both ingress and egress traffic and logging for both successful and denied connections. The management of these access lists can quickly grow in complexity: each new network is another landscape to protect, patch, and detect.
If not properly configured, the security guarantees of VLANs can be easily undermined. Take a network with two separate VLANs; if the access lists are not consistently applied to the two respective switches, a hacked device from one VLAN could easily pivot to a device under the other VLAN. A network administrator could use private VLANs on a per switch basis but, again, this adds additional complexity.
Consistent configurations and architectural choices, from the access list rules to the type of gear used at each site, are required to successfully deploy VLANs to prevent lateral movement. As the number of sites increases and an environment’s footprint expands, this only becomes more challenging.
We use our own products to isolate devices without deploying on a separate network. This provides security guarantees without requiring additional hardware. It’s a severless, infrastructure-less solution to isolating a network.
How is this done? The hardware device (for our proof of concept, a Verkada camera) is connected to a Power over Ethernet switch, which is configured to tunnel its traffic via Anycast GRE to the Cloudflare Global network. There, we can configure rules from the Cloudflare dash to write egress rules, ensuring that outbound traffic only goes where it is supposed to. Thus, lateral movement is prevented.
This architecture allows a network administrator to control traffic from Layer 3 and up from a single dashboard by applying policies to ingress and egress traffic instantly. This architecture provides a simple set-it-and-forget-it solution that can adapt to a changing environment: protection is vendor agnostic, uses common standards, and log collection is automatic. Compared to other methods of lateral movement protection, Cloudflare provides superior ease, adaptability, and security guarantees necessary to securely manage any environment with IoT devices.
| Zero Trust | VLAN | Cloudflare One | |
|---|---|---|---|
| Prevents lateral movement with proper configuration | ✅ | ✅ | ✅ |
| Hardware not required | ✅ | ❌ | ✅ |
| Automatic logging | ✅ | ❌ | ✅ |
| Isolation of IoT Device itself | ❌ | ✅ | ✅ |
| Single point of configuration | ❌ | ❌ | ✅ |
| Complexity does not increase with number of devices | ❌ | ❌ | ✅ |
| Device agnostic | ❌ | ❌ | ✅ |
| Speed and performance benefits from CF’s network | ❌ | ❌ | ✅ |
In Q4 2021, we hired a trusted pen test partner, to test this setup by replicating a rogue device attempting to pivot to production networks from behind the Cloudflare One architecture. They were unable to move laterally — as in, this architecture works.
Given that this architecture has been tested, we will begin to formalize the rollout of Cloudflare One internally at our data center sites as part of a Physical Security initiative to keep our most trusted assets secure.
For more information on using Cloudflare One at your enterprise, please reach out to our Sales team.
Post Syndicated from Tanushree Sharma original https://blog.cloudflare.com/vision-for-observability/
Whether you’re a software engineer deploying a new feature, network engineer updating routes, or a security engineer configuring a new firewall rule: You need visibility to know if your system is behaving as intended — and if it’s not, to know how to fix it.
Cloudflare is committed to helping our customers get visibility into the services they have protected behind Cloudflare. Being a single pane of glass for all network activity has always been one of Cloudflare’s goals. Today, we’re outlining the future vision for Cloudflare observability.
Observability means gaining visibility into the internal state of a system. It’s used to give users the tools to figure out what’s happening, where it’s happening, and why.
At Cloudflare, we believe that observability has three core components: monitoring, analytics, and forensics. Monitoring measures the health of a system – it tells you when something is going wrong. Analytics give you the tools to visualize data to identify patterns and insights. Forensics helps you answer very specific questions about an event.
Observability becomes particularly important in the context of security to validate that any mitigating actions performed by our security products, such as Firewall or Bot Management, are not false positives. Was that request correctly classified as malicious? And if it wasn’t, which detection system classified it as such?
Cloudflare, additionally, has products to improve performance of applications and corporate networks and allow developers to write lightning fast code that runs on our global network. We want to be able to provide our customers with insights into every request, packet, and fetch that goes through Cloudflare’s network.
Analytics are fantastic for summarizing data, but how do you know when to look at them? No one wants to sit on the dashboard clicking refresh over and over again just in case something looks off. That’s where notifications come in.
When we talk about something “looking off” on an analytics page, what we really mean is that there’s a significant change in your traffic or network which is reflected by spikes or drops in our analytics. Availability and performance directly affect end users, and our goal is to monitor and notify our customers as soon as we see things going wrong.
Today, we have many different types of notifications from Origin Error Rates, Security Events, and Advanced Security Events to Usage Based Billing and Health Checks. We’re continuously adding more notification types to have them correspond with our awesome analytics. As our analytics get more customizable, our notifications will as well.
There’s tons of different algorithms that can be used to detect spikes, including using burn rates and z-scores. We’re continuing to iterate on the algorithms that we use for detections to offer more variations, make them smarter, and make sure that our notifications are both accurate and not too noisy.
So, you’ve received an alert from Cloudflare. What comes next?
Analytics can be used to get a birds eye view of traffic or focus on specific types of events by adding filters and time ranges. After you receive an alert, we want to show you exactly what’s been triggered through graphs, high level metrics, and top Ns on the Cloudflare dashboard.
Whether you’re a developer, security analyst, or network engineer, the Cloudflare dashboard should be the spot for you to see everything you need. We want to make the dashboard more customizable to serve the diverse use cases of our customers. Analyze data by specifying a timeframe and filter through dropdowns on the dashboard, or build your own metrics and graphs that work alongside the raw logs to give you a clear picture of what’s happening.
Focusing on security, we believe analytics are the best tool to build confidence before deploying security policies. Moving forward, we plan to layer all of our security related detection signals on top of HTTP analytics so you can use the dashboard to answer questions such as: if I were to block all requests that the WAF identifies as an XSS attack, what would I block?
Customers using our enterprise Bot Management may already be familiar with this experience, and as we improve it and build upon it further, all of our other security products will follow.
Analytics are a powerful tool to see high level patterns and identify anomalies that indicate that something unusual is happening. We’re working on new dashboards, customizations, and features that widen the use cases for our customers. Stay tuned!
Logs are used when you want to examine specific details about an event. They consist of a timestamp and fields that describe the event and are used to get visibility on a granular level when you need a play-by-play.
In each of our datasets, an event measures something different. For example, in HTTP request logs, an event is when an end user requests content from or sends content to a server. For Firewall logs, an event occurs when the Firewall takes an action on an HTTP request. There can be multiple Firewall events for each HTTP request.
Today, our customers access logs using Logpull, Logpush, or Instant Logs. Logpull and Logpush are great for customers that want to send their logs to third parties (like our Analytics Partners) to store, analyze, and correlate with other data sources. With Instant Logs, our customers can monitor and troubleshoot their traffic in real-time straight from the dashboard or CLI. We’re planning on building out more capabilities to dig into logs on Cloudflare. We’re hard at work on building log storage on R2 – but what’s next?
We’ve heard from customers that the activity log on the Firewall analytics dashboard is incredibly useful. We want to continue to bring the power of logs to the dashboard by adding the same functionality across our products. For customers that will store their logs on Cloudflare R2, this means that we can minimize the use of sampled data.
If you’re looking for something very specific, querying logs is also important, which is where forensics comes in. The goal is to let you investigate from high level analytics all the way down to individual logs lines that make them up. Given a unique identifier, such as the ray ID, you should be able to look up a single request, and then correlate it with all other related activity. Find out the client IP of that ray ID and from there, use cases are plentiful: what other requests from this IP are malicious? What paths did the client follow?
Logs are really useful, but they don’t capture the context around a request. Traces show the end-to-end life cycle of a request from when a user requests a resource to each of the systems that are involved in its delivery. They’re another way of applying forensics to help you find something very specific.
These are used to differentiate each part of the application to identify where errors or bottlenecks are occurring. Let’s say that you have a Worker that performs a fetch event to your origin and a third party API. Analytics can show you average execution times and error rates for your Worker, but it doesn’t give you visibility into each of these operations.
Using wrangler dev and console.log statements are really helpful ways to test and debug your code. They bring some of the visibility that’s needed, but it can be tedious to instrument your code like this.
As a developer, you should have the tools to understand what’s going on in your applications so you can deliver the best experience to your end users. We can help you answer questions like: Where is my Worker execution failing? Which operation is causing a spike in latency in my application?
Notifications, analytics, logs, and tracing each have their distinct use cases, but together, these are powerful tools to provide analysts and developers visibility. Looking forward, we’re excited to bring more and more of these capabilities on the Cloudflare dashboard.
We would love to hear from you as we build these features out. If you’re interested in sharing use cases and helping shape our roadmap, contact your account team!
Post Syndicated from digiblurDIY original https://www.youtube.com/watch?v=4Jl_gZoXntY
Post Syndicated from original https://lwn.net/Articles/888453/
Over on the Software Freedom
Conservancy blog, Bradley M. Kuhn considers
the question of the interaction between copyleft and the “ethical source” effort that seeks to
use copyleft-like licensing to bring about additional changes, beyond just
software freedom; the Hippocratic
License is an example of such a license. In his view, copyleft and
ethical software are not really compatible, even though many in
free-software world (including Kuhn) are highly sympathetic to the goals,
especially in light of the recent invasion of Ukraine by Russia.
I suspect activists will continue to disagree about whether we have a moral
imperative to change FOSS licenses themselves to contractually forbid Putin
to copy, modify, redistribute and reinstall the FOSS he already has (or
surreptitiously downloaded by circumventing sanctions). However, these
horrendous events in Ukraine offer real world examples to consider the
viability of expanding copyleft term expansion beyond software, and
consider how it might work. My analysis is that such changes would only
give us the false sense of having “done something”. Ultimately enforcement
of such licensing changes would either be impossible or pointless. The very
entities (such as the varied international courts and treaty organizations)
that could enforce such terms will also have plenty of other war crimes and
sanctions violations to bring against Putin and his cronies anyway. The
penalties for the actions of war that Putin took will be much stronger than
Putin’s contractual breach or copyright infringement claim that could be
brought under a modified copyleft license and/or the Hippocratic License.
Post Syndicated from James Perry original https://aws.amazon.com/blogs/security/ransomware-mitigation-using-amazon-workdocs-to-protect-end-user-data/
Amazon Web Services (AWS) has published whitepapers, blog articles, and videos with prescriptive guidance to assist you in developing an enterprise strategy to mitigate risks associated with ransomware and other destructive events. We also announced a strategic partnership with CrowdStrike and Presidio where together we developed a Ransomware Risk Mitigation Kit, and a Quick-Start engagement to assist with deployment, to provide you with tools to deal with security events before and after they occur.
Developing a ransomware mitigation strategy often uses a risk-based approach, where priority is given to protecting mission-critical applications and data. Managing identified risks associated with individual end users is often deemed a lower priority. However, in many organizations, such as research universities, the work performed by individual researchers is the organizational mission.
End users are increasingly mobile. They’re working remotely, on the go, and frequently moving from one project to the next. They’re also collaborating across borders, time zones, and organizations. You need options for your employees to work securely from any location.
This post covers how you can help prevent, back up, and recover your critical end-user data from ransomware by using Amazon WorkDocs.
Amazon WorkDocs is a fully managed, secure content creation, storage, and collaboration service. With Amazon WorkDocs, you can create, edit, and share content, and because content is stored centrally on AWS, access it from anywhere, on any device. Amazon WorkDocs makes it easier to collaborate with others, and lets you share content, provide rich feedback, and collaboratively edit documents.
You can access Amazon WorkDocs on the web, or install apps for Windows, MacOS, Android, and iOS devices. In addition, the Amazon WorkDocs Companion lets you open and edit a file from the web client in a single step. When you edit a file, Companion saves your changes to Amazon WorkDocs as a new file version. Amazon WorkDocs Drive enables you to open and work with Amazon WorkDocs files on your computer’s desktop. And the Amazon WorkDocs SDK includes APIs that allow you to build new applications or create integrations with existing Amazon WorkDocs solutions and applications.
As illustrated in Figure 1, these features combine to enable end-user and team file storage, team content and collaboration workflows, secure and auditable content sharing, cloud-based file sharing, and mobile workforce enablement, with support for automation and extensibility.
Figure 1: Common use cases enabled by Amazon WorkDocs
Amazon WorkDocs is built with security in mind. Amazon WorkDocs files are stored using the highly durable AWS storage infrastructure, and are encrypted both while in transit and at rest. The service supports the use of multi-factor authentication (MFA), IP filtering of allow lists, and the ability to specify which AWS Region will be used to meet data residency requirements. Your organization can set security policies that prevent your employees from sharing documents externally. Third-party auditors assess the security and compliance of Amazon WorkDocs as part of multiple AWS compliance programs, including SOC, PCI DSS, FedRAMP, HIPAA, ISO 9001, ISO 27001, ISO 27017, and ISO 27018.
Amazon WorkDocs uses a directory to store and manage organization information for your users and their documents. You can choose from three supported options: Simple Active Directory (Simple AD), Active Directory (AD) Connector, or AWS Managed Microsoft AD.
You can use Simple AD as a standalone directory in the cloud to support Windows workloads that need basic AD features and compatible AWS applications, or to support Linux workloads that need LDAP service. However, Simple AD does not support MFA. For more information, see Simple Active Directory.
AD Connector is a proxy service that provides an easy way to connect compatible AWS applications, such as Amazon WorkDocs, to your existing on-premises Microsoft Active Directory. With AD Connector, you can simply add one service account to your Active Directory. AD Connector also eliminates the need for directory synchronization, as well as the cost and complexity of hosting a federation infrastructure.
AWS Managed Microsoft AD is powered by Microsoft Windows Server Active Directory (AD), managed by AWS in the AWS Cloud. It enables you to migrate a broad range of Active Directory–aware applications to the AWS Cloud. AWS Managed Microsoft AD works with Microsoft SharePoint, Microsoft SQL Server Always-On Availability Groups, and many .NET applications. It also supports AWS managed applications and services, including Amazon WorkDocs.
You can attach a supported directory to a WorkDocs site during provisioning. When you do, an Amazon WorkDocs feature called Auto activation adds the users in the directory to the site as managed users, meaning they don’t need separate credentials to log in to your site. You can also create user groups, enable MFA, and configure single sign-on (SSO) for your Amazon WorkDocs site.
Amazon WorkDocs also includes built-in security features that enable you to selectively prevent file downloads and changes, revert files to a previous version, and recover deleted files, all of which can mitigate impact and support recovery from a ransomware event.
You can keep track of prior versions in Amazon WorkDocs with unlimited versioning. A new version of a file is created every time you save it. With Amazon WorkDocs, all feedback is associated with a specific file version, so you can refer back to comments in earlier iterations. Previous versions can be retrieved, as shown in Figure 2, when you access Amazon WorkDocs with a web browser.
Figure 2: File versioning in Amazon WorkDocs via web browser
Using the file versioning feature can help enable the restoration of an unlocked file that has been altered by ransomware to a previous version.
When files or folders are deleted, they are stored in an end-user managed recycle bin, as shown in Figure 3, where they can be recovered by the end user if needed.
Figure 3: End-user file recovery from recycle bin in Amazon WorkDocs via web browser
After a period of 30 days, the files and folders will be retained for an additional 60 days in an Amazon WorkDocs site administrator-managed recovery bin before being permanently deleted. 60 days is the default retention period, but site administrators can adjust this period to any value from 0 to 365 days. Files will be retained for the specified period and permanently deleted when the retention period limit is reached.
In addition, customers can sync files from Amazon WorkDocs to Amazon S3 for additional resiliency.
Using the file recovery features can provide the ability to restore individual files and folders that were deleted—by ransomware or even just by accident. Note that as of today, file recovery works on a per file or folder basis.
Amazon WorkDocs lets you control who can access, comment on, and download or print your files. And, because the Amazon WorkDocs web client performs remote file rendering via HTML (see supported file types), users gain protection they would not otherwise be afforded when viewing potentially infected files locally. This, combined with the ability to prevent a file from being downloaded as illustrated in Figure 4, can help to mitigate the risk of malware spreading.
You can also lock files while making changes, and enable settings that prevent edits from being overwritten by other contributors, eliminating the need to coordinate changes. You can also disable feedback when you’ve completed a file. When you lock a file, as illustrated in Figure 4, a new version of that file cannot be uploaded until you unlock the file. If someone else needs access to the file, they can request that you unlock it, and you’ll be notified of the request.
Figure 4: End-user file lock settings in Amazon WorkDocs via web browser
Using the file locking feature can prevent ransomware from making unauthorized changes (such as encrypting) to a locked file.
In this blog post, I showed how AWS customers can help prevent, back up, and recover critical end-user data from ransomware incidents by using the file versioning, recovery, and control features of Amazon WorkDocs.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
Want more AWS Security news? Follow us on Twitter.
Post Syndicated from Ling Wu original https://blog.cloudflare.com/our-commitment-to-customer-security/
Cloudflare has been hooked on securing customers globally since its inception. Our services protect customer traffic and data as well as our own, and we are continuously improving and expanding those services to respond to the changing threat landscape of the Internet. Proving that commitment is a multi-faceted venture, the Security Team focuses on people, proof, and transparency to ensure every touchpoint with our products and company feels dependable.
The breadth of knowledge of the Security Team is wide and bleeding edge. Working as a security team at a security company means being highly technical, diverse, willing to test any and all products on ourselves, and sharing our knowledge with our local and global communities through industry groups and presenting at conferences worldwide. Connecting with our customers and counterparts through meetups and conferences lets us share problems, learn about upcoming industry trends, and share feedback to make improvements to the customer experience. In addition to running a formally documented, risk-based security program for Cloudflare, team members drive continuous improvement efforts across our Product and Infrastructure teams by reviewing and advising on changes, identifying and treating vulnerabilities, controlling authorization and access to systems and data, encrypting data in transit and at rest, and by detecting and responding to threats and incidents.
Security claims are all well and good, but how can a customer be sure we are doing what we say we do? We do it by undergoing several audits a year, proving that our security practices meet industry standards. To date, Cloudflare has regularly assessed and maintained compliance with PCI DSS (as a merchant and a service provider), SOC 2 Type II, ISO 27001 and ISO 27701 standards. No matter where our customers are in the world, they will likely need to rely on at least one of these standards to protect their customers’ information. We honor the responsibility of being the backbone of that trust.
As Cloudflare’s customer base continues to grow into more regulated industries with complex and rigorous requirements, we’ve decided to assess our global network against three additional standards this year:
Our commitment to security for our customers and business means we have to be super transparent. When a security incident is being contained, we have in our response plan to not only bring in our legal, compliance and communications teams to determine notification strategy, but we also start outlining a detailed overview of how we are responding, even if we are still in the process of remediating.
We know firsthand how frustrating it can be when your critical vendors stay silent during a security incident and provide nothing more than a one sentence legal response which fails to reveal how they were impacted by the security vulnerability or incident. Here at Cloudflare, it is in our DNA to be transparent. You can see it with the blogs (Verkada Incident, Log4j) we write and how quickly we show our customers how we’ve responded and what we’re doing to fix the issue.
One of the most frequent questions we get from our customers regarding incidents is if our third-parties were impacted. Supply chain vulnerabilities, like Solarwinds and Log4j, have driven us to create efficiencies, such as automated inquiries, to all of our critical vendors at once. During the Containment phase of our security incident response process, our third-party risk team is quickly able to identify the impacted vendors and prioritize our production and security vendors. Our tooling allows us to trigger inquiries to third parties immediately, and our team is integrated into the incident response process to ensure effective communication. Any information that we receive from our vendors, we share with our Security Compliance forums to ensure that other companies who are also inquiring with their vendors don’t have to duplicate their work.
These recurring audits and assessments are not simple website badges. Our Security team doesn’t produce evidence only to pass audits; our process includes identifying risks, forming controls and processes to address those risks, continuous operation of those processes, evaluation of the effectiveness of (in the form of internal and external audits and tests) those processes, and making improvements to the ISMS based on those evaluations. Some things on our process that set us apart include the following:
The final step is communicating the resulting picture of our security posture to our customers. Our security certifications and assessment results are available to our customers via download from their Cloudflare Dashboards, or by request to their account team. For the latest information about our certifications and reports, please visit our Trust Hub.
Post Syndicated from Alan David Foster original https://blog.rapid7.com/2022/03/18/metasploit-weekly-wrap-up-153/
Our very own Shelby Pace has added a new module for the CVE-2022-21999 SpoolFool privilege escalation vulnerability. This escalation vulnerability can be leveraged to achieve code execution as SYSTEM. This new module has successfully been tested on Windows 10 (10.0 Build 19044) and Windows Server 2019 v1809 (Build 17763.1577).
Jake Baines has contributed a new module for CVE-2021-4191, which queries the GitLab GraphQL API to acquire the list of GitLab users without authentication. There’s some news coverage from earlier this month here. The module works on all GitLab versions from 13.0 up to 14.8.2, 14.7.4, and 14.6.5.
Spencer McIntyre has added a new payload type that allows existing modules to be adapted for new scenarios. For example, modern exploits often deliver OS command payloads while Metasploit users would prefer to have more fully-featured native payloads (like Meterpreter delivered) and these scenarios are often special cases handled by the module author. Metasploit’s new payload adapters allow payloads from one architecture to be converted to another for seamless compatibility with a wider variety of exploit modules. The first entry for this new type is an adapter that converts Python payloads to OS command payloads, allowing any exploit capable of executing a Unix Command payload to deliver a Python Metepreter in memory. For additional ease of use, the correct Python binary is automatically determined.
http.sys when parsing Accept-Encoding headers, to cause a BSoD and denial of service on vulnerable IIS servers.cmd/unix/reverse_bash is chosen over cmd/unix/reverse_netcat by default unless RequiredCmd is set such that the module cannot execute Bash payloads.scanner/smb/smb_version module when the target server has SMB1 disabled.normalize_host method so that when it attempts and fails to resolve a hostname to an IP address, it will return nil instead of raising an exception. Previously this exception would result in modules like auxiliary/gather/enum_dns crashing instead of saving the information it had managed to gather on the target so far.payload/windows/x64/encrypted_shell_reverse_tcp without having a database configuredAs always, you can update to the latest Metasploit Framework with msfupdate
and you can get more details on the changes since the last blog post from
GitHub:
If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest.
To install fresh without using git, you can use the open-source-only Nightly Installers or the
binary installers (which also include the commercial edition).
Post Syndicated from Vimala Pydi original https://aws.amazon.com/blogs/architecture/migrating-petabytes-of-data-from-on-premises-file-systems-to-amazon-fsx-for-lustre/
Many organizations use the Lustre filesystem for Linux-based applications that require petabytes of data and high-performance storage. Lustre file systems are used in machine learning (ML), high performance computing (HPC), big data, and financial analytics. Many such high-performance workloads are being migrated to Amazon Web Services (AWS) to take advantage of the scalability, elasticity, and agility that AWS offers. Amazon FSx for Lustre is a fully managed service that provides cost-effective, high-performance, and scalable storage for Lustre file systems on AWS.
AWS DataSync is an AWS managed service for copying data to and from Amazon FSx for Lustre. It provides high-speed transfer through its use of compression and parallel transfer mechanism and integrates with Amazon CloudWatch for observability.
This blog will show you how to migrate petabytes of data files from on-premises to Amazon FSx for Lustre using AWS DataSync. It will provide an overview of Amazon CloudWatch metrics and logs to help you monitor your data transfer using AWS DataSync and metrics from Amazon FSx for Lustre.
The high-level architecture diagram in Figure 1 depicts file storage data migration from on-premises data center to Amazon FSx for Lustre using AWS DataSync.
Following are the steps for the migration:
Figure 1. Architecture diagram for transferring files on-premises to Amazon FSx for Lustre using AWS DataSync
To start the migration, create a Lustre file system in Amazon FSx service and follow the step-by-step guidance provided in Getting started with Amazon FSx for Lustre.
For this blog, a target of ‘Persistent 2’ deployment type FSx for Lustre is selected with a storage capacity of 1.2 TB (Figure 2.)
Figure 2. FSx for Lustre target file system
Follow steps in the article: Getting started with AWS DataSync to get started with the AWS DataSync service. Configure the source system to migrate the file system data using the following steps:
Figure 3. Create AWS DataSync agent
A DataSync task consists of a pair of locations between which data is transferred. The source location defines the storage system that you want to read from. The destination location defines the storage service that you want to write data to. Here the source location is an on-premises Lustre system and the destination location is the Amazon FSx for Lustre service (Figure 4.)
Figure 4. Configure source and destination location for AWS DataSync task
A task is a set of two locations (source and destination) and a set of options that you use to control the behavior of the task. Create a task with the source and destination locations and choose Start from the Actions menu (Figure 5.)
Figure 5. Start task
Wait for the task status to change to Running (Figure 6.)
Figure 6. Task status
To check the details of the task completion, select the task and click on the History tab (Figure 7.) The status should show Success once the task successfully completes the migration.
Figure 7. Task history
Amazon CloudWatch is the AWS native observability service. It collects and processes raw data from AWS services such as Amazon FSx for Lustre and AWS DataSync into readable, near real-time metrics. It provides metrics that you can use to get more visibility into the data transfer. For a full list of CloudWatch metrics for AWS DataSync and Amazon FSx for Lustre, read Monitoring AWS DataSync and Monitoring Amazon FSx for Lustre.
Amazon FSx for Lustre can also provide various metrics, for example, the number of read or write operations using DataReadOperations and DataWriteOperations. To find the total storage available you can check the metric FreeDataStorageCapacity (Figure 8.)
Figure 8. CloudWatch metrics for Amazon FSx for Lustre
AWS DataSync metrics such as FilesTransferred, gives the actual number of files or metadata that transferred over the network. BytesTransferred provides the total number of bytes that transferred over the network when the agent reads from the source location to the destination location.
A robust monitoring system can be built by setting up an automated notification process for any errors or issues in the data transfer task. Integrate Amazon CloudWatch in combination with the Amazon Simple Notification Service (SNS). Figure 9 depicts the AWS DataSync logs in Amazon CloudWatch.
Figure 9. AWS DataSync logs in Amazon CloudWatch
You can also gather insights from the logs of the data transfer metrics using CloudWatch Logs Insights. CloudWatch Log Insights enables you to quickly search and query your log data (Figure 10.) You can set a filter metric for error codes and alert the appropriate team.
Figure 10. Amazon CloudWatch Logs Insights for querying logs
If you are no longer using the resources discussed in this blog, remove the unneeded AWS resources to avoid incurring charges. After finishing the file transfer, clean up resources by deleting the Amazon FSx file system and AWS DataSync objects (DataSync agent, task, source location, and destination location.)
In this post, we demonstrated how we can accelerate migration of Lustre files from on-premises into Amazon FSx for Lustre using AWS DataSync. As a fully managed service, AWS DataSync securely and seamlessly connects to your Amazon FSx for Lustre file system. This makes it possible for you to move millions of files and petabytes of data without the need for deploying or managing infrastructure in the cloud. We walked through different observability metrics with Amazon CloudWatch integration to provide performance metrics, logging, and events. This can further help to speed up critical hybrid cloud storage workflows in industries that must move active files into AWS quickly. This capability is available in Regions where AWS DataSync and Amazon FSx for Lustre are available. For further details on using this cost-effective service, see Amazon FSx for Lustre pricing and AWS DataSync pricing.
For further reading:
Post Syndicated from LGR original https://www.youtube.com/watch?v=NIFEXCGTPhg
Post Syndicated from original https://lwn.net/Articles/888413/
Jason Donenfeld has published a lengthy look at the changes to the Linux random-number generator (RNG) for Linux 5.17 and the upcoming 5.18 kernel. It covers his efforts “to modernize both the code and the cryptography used” and also peers into the future for changes that may be coming.
random.c was introduced back in 1.3.30, steadily grew features, and was a pretty impressive driver for its time, but after some decades of tweaks, the general organization of the file, as well as some coding style aspects were showing some age. The documentation comments were also out of date in several places. That’s only natural for a driver this old, no matter how innovative it was. So a significant amount of work has gone into general code readability and maintainability, as well as updating the documentation. I consider these types of very unsexy improvements to be as important if not more than the various fancy modern cryptographic improvements. My hope is that this will encourage more people to read the code, find bugs, and help improve it. And it should make the task of academics studying and modeling the code a little bit easier.
Post Syndicated from original https://lwn.net/Articles/887974/
The kernel community has a number of excuses for the relative paucity of
regression-test coverage in the project, some of which hold more water than
others. One of the more convincing reasons is that a great deal of kernel
code is hardware-specific, and nobody can ever hope to put together a
testing system with even a small fraction of all the hardware that the
kernel supports. A new driver-testing framework called roadtest,
posted by Vincent Whitchurch, may make that excuse harder to sustain,
though, at least for certain kinds of hardware.