Статья про атаки на Линукс, а в качестве примера приводится атака на веб-сервер с дальнейшим запуском нагрузки (не увдивлюсь, если процесс веб-сервера работал под рутом, тогда тут ловить впринципе уже нечего). А интересно почитать именно про атаки на саму операционку.
Месяц назад интренет бурлил по поводу того, что IBM продал Palo Alto свой облачный SIEM QRoC и IBM Consulting заточился на продажу решения Palo Alto. А теперь вот еще и новость про "любовь" с микрософт, совсем эффективный менеджмент заедает голубого гиганта.
25 лет назад, когда СУБД были вообще центром всего в книгах и статьях относительно обеспечения целостности транзакций был очень важный раздел про то, что такое блокировки, типы блокировок и какие алгоритмы, а значит и стоимость по ресурсам используются для обеспечения этих блокировок. Без этой основы не возникнет инженерного понимания и может возникнуть соблазн перейти исключительно на serializable.
Я уже дано этим не знаимаюсь, но в памяти всплывают особенности: table level, page level, row level блокировок и алгоритмов их автоматической эскалации. Где зранится информация о блокировках: в памяти, на диске. Типы блокировок: intent, exclusive, shared. Выделение пулов памяти для хранение информации о блокировках (сейчас может все автоматом, но во времена Sybase ASE 11,12 или древнего оракла это надо было знать и мониторить). И это только начало, мастхэв юного писателя логики на СУБД.
"Go гораздо проще в использовании, чем Rust. Почему Rust проигрывает в гонке " В оригинале: "Go is much easier to use than Rust. Why losing Rust in performance race? " может надо перевести как: "Go гораздо проще в использовании, чем Rust. Почему он Rust-у проигрывает в гонке?"
Скажите, а правила пишутся именно ручками текстом с этими всеми тэгами, или есть некий конструктор? (хотя как например в qradar).
Можно ли писать правила которые учитывают последовательность событий, в том числе и сработку других SIEM правил. events sequence, event after another sequences, event in some event scope и т.п.
Можно ли обогощать событие внешними данными?
Как устроен процесс отладки правил? Есть ли профайлер по которому можно оценить "тяжесть" правила.
насколько я знаю, то этот вопрос исследовался, когда было открыто расширение вселенной. В результате оказалось, что нет такого центра, вселенная расширяется из каждой точки пространства.
Если мы живем в пространсве черной дыры, то тогда бы расширение пространства нашей дыры-вселенной было бы не равномерным, т.к. черные дыры растут только тогда, когда захватывают массу. А наша ЧД вроде как питается хорошо, без задержек :) Как объяснить это в предложенной модели?
А по управлению памятью ничего не поменялось? гугл пиксель, запущен только браузер. Идет входящий звонок, отвечаю. Возвращаюсь обратно в браузер - страница перегружается. И не важно сколько гигабайт оперативки, все равно опыт от использования ка кот очень навороченной тамагочи. Это не ОС для работы.
Я нашел недавно скан переводов трудов Ибн Сины на русский язык. В СССР хватало заниматься и таким. Начал читать. Так вот, там несколько разделов: физика, логика.. и т.п. Начал читать раздел по формальной логике, а там очень крутой алгоритмический труд, он и сегодня выглядит круто.
А еще Ибн Сина был крутым суфием. Гений эпохи свей и общей истории.
Вначале думал, что очередная пустая статья, но вот эта фраза резюме, хоть и не дает ответа. но является по-настоящему правильным диагнозом.
"Но как в реальности обеспечить правильное функционирование бюрократической машины под постоянным давлением человеческого эгоизма вопрос вовсе не праздный. За прошедшие 7 000 лет цивилизации мы так и не нашли ответа на этот вопрос. "
Non-repeatable Read это когда вы читаете одну и туже строку два раза подряд, но из-за конкурирующей транзакции, которая меняет значение в этой строке, второе чтение может вернуть значения в строке, отличные от первого чтения.
Phantom Read - это когда вы читаете набор из нескольких строк опять таки два раза, но из-за конкурирующей транзакции, которая может удалить или изменить одну из строк так, что она уже не попадает под условия выборки, то после второго чтения результирующий набор будет отличаться от первого.
В обеих случаях читаются только закомичченные данные, но влияние на результат отличается.
"Non-repeatable reads are when your transaction reads committed UPDATES from another transaction. The same row now has different values than it did when your transaction began.
Phantom reads are similar but when reading from committed INSERTS and/or DELETES from another transaction. There are new rows or rows that have disappeared since you began the transaction."
Вспоминая старые времена, когда передний край ИТ крутился вокруг СУБД и тонкостей реализации в них поддержки уровней изоляции, то хорошо бы в статье написать про обратную сторону медали - какими решениями и технологиями СУБД обеспечивает это все: Вспоминается варианты наложения блокировок: table level lock, page level lock, row level lock и их эскалация. Как они хранятся (в памяти, на диске)
Типы блокировок: shared (READ|UPDATE), Intent, Exclusive и животворящий deadlock
И в конце рассказать, почему в итоге гонку технологий выиграла snapshot isolation и все промышленные субд которые не поддерживали ее так или иначе проиграли (DB2, informix, sybase ase).
Помню, какие были жаркие споры в начале 200х на sql.ru по поводу клссмических блокировчников и версионников и их работы на ресурсах серверов того времени. Ностальгия.
Скорее эта реорганизация в первую очередь посыл акционерам/фондовому рынку, что мол мы меняемся, что-бы эффективно быть эффективными и все такое прочее и цена акций не падала.
Статья про атаки на Линукс, а в качестве примера приводится атака на веб-сервер с дальнейшим запуском нагрузки (не увдивлюсь, если процесс веб-сервера работал под рутом, тогда тут ловить впринципе уже нечего). А интересно почитать именно про атаки на саму операционку.
Месяц назад интренет бурлил по поводу того, что IBM продал Palo Alto свой облачный SIEM QRoC и IBM Consulting заточился на продажу решения Palo Alto. А теперь вот еще и новость про "любовь" с микрософт, совсем эффективный менеджмент заедает голубого гиганта.
а для меня это до сих пор ОС вышедшая "недавно" )))
25 лет назад, когда СУБД были вообще центром всего в книгах и статьях относительно обеспечения целостности транзакций был очень важный раздел про то, что такое блокировки, типы блокировок и какие алгоритмы, а значит и стоимость по ресурсам используются для обеспечения этих блокировок. Без этой основы не возникнет инженерного понимания и может возникнуть соблазн перейти исключительно на serializable.
Я уже дано этим не знаимаюсь, но в памяти всплывают особенности: table level, page level, row level блокировок и алгоритмов их автоматической эскалации. Где зранится информация о блокировках: в памяти, на диске. Типы блокировок: intent, exclusive, shared. Выделение пулов памяти для хранение информации о блокировках (сейчас может все автоматом, но во времена Sybase ASE 11,12 или древнего оракла это надо было знать и мониторить). И это только начало, мастхэв юного писателя логики на СУБД.
"Go гораздо проще в использовании, чем Rust. Почему Rust проигрывает в гонке "
В оригинале:
"Go is much easier to use than Rust. Why losing Rust in performance race? "
может надо перевести как:
"Go гораздо проще в использовании, чем Rust. Почему он Rust-у проигрывает в гонке?"
Так людям вкус кофе нравится и аромат, в некторых случаях это еще и ритуал, возможность сделать перерыв.. А микродозингом эту проблему не решить.
Скажите, а правила пишутся именно ручками текстом с этими всеми тэгами, или есть некий конструктор? (хотя как например в qradar).
Можно ли писать правила которые учитывают последовательность событий, в том числе и сработку других SIEM правил. events sequence, event after another sequences, event in some event scope и т.п.
Можно ли обогощать событие внешними данными?
Как устроен процесс отладки правил? Есть ли профайлер по которому можно оценить "тяжесть" правила.
насколько я знаю, то этот вопрос исследовался, когда было открыто расширение вселенной. В результате оказалось, что нет такого центра, вселенная расширяется из каждой точки пространства.
Если мы живем в пространсве черной дыры, то тогда бы расширение пространства нашей дыры-вселенной было бы не равномерным, т.к. черные дыры растут только тогда, когда захватывают массу. А наша ЧД вроде как питается хорошо, без задержек :)
Как объяснить это в предложенной модели?
А по управлению памятью ничего не поменялось?
гугл пиксель, запущен только браузер. Идет входящий звонок, отвечаю. Возвращаюсь обратно в браузер - страница перегружается. И не важно сколько гигабайт оперативки, все равно опыт от использования ка кот очень навороченной тамагочи. Это не ОС для работы.
Я нашел недавно скан переводов трудов Ибн Сины на русский язык. В СССР хватало заниматься и таким. Начал читать. Так вот, там несколько разделов: физика, логика.. и т.п. Начал читать раздел по формальной логике, а там очень крутой алгоритмический труд, он и сегодня выглядит круто.
А еще Ибн Сина был крутым суфием. Гений эпохи свей и общей истории.
Вначале думал, что очередная пустая статья, но вот эта фраза резюме, хоть и не дает ответа. но является по-настоящему правильным диагнозом.
"Но как в реальности обеспечить правильное функционирование бюрократической машины под постоянным давлением человеческого эгоизма вопрос вовсе не праздный. За прошедшие 7 000 лет цивилизации мы так и не нашли ответа на этот вопрос. "
рыночная экономика, свободная конкуренция ...
Интересно, но идея пульсирующих вселенных - база космологии восточных (индуистских) религий.
Non-repeatable Read это когда вы читаете одну и туже строку два раза подряд, но из-за конкурирующей транзакции, которая меняет значение в этой строке, второе чтение может вернуть значения в строке, отличные от первого чтения.
Phantom Read - это когда вы читаете набор из нескольких строк опять таки два раза, но из-за конкурирующей транзакции, которая может удалить или изменить одну из строк так, что она уже не попадает под условия выборки, то после второго чтения результирующий набор будет отличаться от первого.
В обеих случаях читаются только закомичченные данные, но влияние на результат отличается.
Вот тут детально: https://stackoverflow.com/questions/11043712/non-repeatable-read-vs-phantom-read
"Non-repeatable reads are when your transaction reads committed UPDATES from another transaction. The same row now has different values than it did when your transaction began.
Phantom reads are similar but when reading from committed INSERTS and/or DELETES from another transaction. There are new rows or rows that have disappeared since you began the transaction."
Вспоминая старые времена, когда передний край ИТ крутился вокруг СУБД и тонкостей реализации в них поддержки уровней изоляции, то хорошо бы в статье написать про обратную сторону медали - какими решениями и технологиями СУБД обеспечивает это все: Вспоминается варианты наложения блокировок: table level lock, page level lock, row level lock и их эскалация. Как они хранятся (в памяти, на диске)
Типы блокировок: shared (READ|UPDATE), Intent, Exclusive и животворящий deadlock
И в конце рассказать, почему в итоге гонку технологий выиграла snapshot isolation и все промышленные субд которые не поддерживали ее так или иначе проиграли (DB2, informix, sybase ase).
Помню, какие были жаркие споры в начале 200х на sql.ru по поводу клссмических блокировчников и версионников и их работы на ресурсах серверов того времени. Ностальгия.
в список из простого но эффективного: локальным фаерволом закрыть повершеллу и многим системным утилитам доступ наружу.
Скорее эта реорганизация в первую очередь посыл акционерам/фондовому рынку, что мол мы меняемся, что-бы эффективно быть эффективными и все такое прочее и цена акций не падала.
и не ради общего а блага, а ради исключительно личной выгоды..