Для меня вопрос адекватности безопасников и безопасности на этом сайте был окончательно прояснён, когда они раздавили свой сертификат, который нужно было добавить в корневые сертификаты в системе, по HTTP. С тех пор, как видно, изменилось не много.
Я не эксперт, могу ошибаться, но где-то в интернетах читал, что часть наследия соляриса взяли непосредственно в систему (как минимум что-то по работе с памятью, потому на 32 битной фряхе ZFS возможен, а под линуксом нет). Что не поместилось оформили в модуль.
Почти. Там имеет место целый слой абстракции, делающий среду работы данного модуля слегка притянутой к Solaris. В результате на единицу массы там слишком много абстракций, а это чревато боком. К чести ZFS следует признать, что даже в этих условиях она работает отлично. Но нужно иметь в виду жадный до оперативы ARC, и выкручивать его максимумы так, чтобы оставалось приложениям и ещё немного для манёвров со стороны ОС.
В Linux нет, в FreeBSD прекрасно живёт на 2. Проблема с Linux — ZFS любит память ( в том смысле как любит её база данных), и дерётся за неё с системой, при этом не достаточно оперативно её освобождая. А интеграция этой ФС с Linux через такую-то матерь только добавляет эпичности сюжету. Когда ZFS вписана в систему, всё становится несколько проще.
Шикарно. А если к всему этому добавить возврат статистики по пингам обратно на центральный сервер для статистики и мониторинга и добавить обработку не 200-х кодов переключением на второй по доступности хост, либо вообще реализовать подгрузку картинок через JavaScript на стороне клиента, разбрасывая нагрузку по запросам пропорционально пингам и при этом отправляя при переходах статистику по отличным от 200 кодам обратно в центр, решение будет совсем замечательным.
И вопрос: а почему не использовали полный редирект на точку присутствия у соответствующего провайдера и не стали раздавать статику с него, при этом проксируя динамику в центр. Ведь на связность в точках присутствия больше влияния чем на связность клиента и сервера? Да добавляется лишний элемент, который ещё нужно мониторить, но с центра кэшированием можно снять часть нагрузки…
Полностью согласен. Учить народ условному рефлексу на зелёный замочек, а потом массово пропихивать всеобщее шифрование интернета было не дальновидно.
А вообще надо народ не устойчивым стойкам на разные цвета и изображения учить, а собраться всем экспертам гуртом и выработать наконец инструмент, который однозначно классифицирует ресурс как безопасный и инфраструктуру к нему. Пока мы видим только вялое внедрение странных вещей в основном в инициативном порядке.
Ещё раз поясню, что пока живо противоборство вас достанет везде, в любой точке этой планеты прямо или опосредовано. Алькаида, устроившая переполох в благополучных штатах, тоже продукт этого противостояния, жуть того хаоса, что творился в Европе в прошлом году и возможно творится сейчас — отголоски продуктов того противостояния. Нет на земле больше безопасных мест кроме Антарктиды, но это по-моему временное недоразумение. А если долго рассказывать про ужасы кровавой гэбни и умалчивать о других злодействах, легко складывается ощущение, что гэбня — самое кровавое, что есть на этой планете. А это уже серьёзное заблуждение, которое в перспективе даёт шанс другой кровавой негэбне стать ещё кровавее, ибо балансирующую её кровавую гэбню закопают, и сдерживающий фактор пропадёт.
Отсюда вообще возникает предложение, от нефиг делать данные темы не трогать, а если трогать, то начислять всем сёстрам поровну. Вам не кажется, что это не лишено логики?
Я лишь намекнул, что во время холодной войны погибло чуть больше чем 66 человек, так на порядок, а то и на тройку. И гибли люди с обоих сторон. А тех кто к этим сторонам не принадлежал вообще считать не принято. Поэтому крайне странно когда выскакивает такой материал на тему «Гля чо кровавая гебня сотворила!» без материала о кровавых соколах по другую сторону. Не справедливо…
А людей жалко, и тех кто погиб, и тех кто по каким то причинам работал без должной процедуры взаимодействия с опасными материалами. И всё это безотносительно того, имела место утечка или естественное заражение. Это не важно. Люди гибнут по воле безумия, которое ещё даже не пытались истребить. Но активно пытаются приуменьшить заслуги своего и преувеличить у оппонентов. И это ещё один уровень безумия, стоящий слишком далеко в очереди на уничтожение, нежели того заслуживает.
Сессионные ключи действуют ограниченное время, ими можно раскрыть обмен данными, однако, чтобы сгенерировтаь сессионный ключ, и войти в систему нужны логины пароли и личные ключи. Передача на хранение последних вроде как пока не предписывается. Проникнув в систему хранения трафика можно получить сведения, которые передавались, и то если сведения будут лежать зашифрованными а рядом лежать ключи (что логично) то Вам ещё предстоит трафик расшифровать. Нормально спроектированная система не должна позволить получить к себе доступ даже имея на руках всё это, но не имея личного ключа.
А если Вам кто-то не нравится, можно ему устроить налоговую проверку с изъятием оргтехники, если ничего не найдётся, то всё равно контора будет надолго парализована. А если человек совсем не нравится, ему на голову можно уронить кирпич. Не стоит усложнять простые вещи. Это всё создаётся не для этого. Ничем хрошом оно не светит, но и подобных раскладов тоже не стоит опасаться. Человек загнанный в угол имеет свойство не подчиняться заповедям о «не убей», «не укради» и причинять тем гораздо больше проблем чем обычно.
Мне вот тоже интересно кому это реально нужно. Хранить трафик можно просто сбрасывая на диск в pcap формате. Вот только это гора бесполезных данных. А для достойного разбора всего этого нужен неслабый выч. ресурс. И это без учёта необходимости раскрытия зашифрованного трафика. Даже имея ключи на вычисления связанные с расшифровкой нужно ещё больше ресурса. И DPI не совсем панацея, я знаю примеры, когда сервисы вытаскивали даже за аппаратные фаерволы, поскольку они не справлялись…
А если смотреть на трафик, то кажется что хранение большей его части — глупость. Оно либо не актуально уже через 5 минут, либо дублирует что-то.
В общем кому нужно продать немного оборудования, продаст и успокоится.
Вы когда-нибудь пробовали читать журналы squid или подобного ПО развернутого на сеть из дюжины машин. Это блин тонна однообразной хрени. Ажиотаж снимается уже через 30 минут пролистрывания. Человек с нормальной психикой не лезет туда пока сильно не припрёт, а если припрёт гоняет грепом, скриптами или системой анализа. Даже если на squid развернута хреновина для анализа логов, мало кто лезет в середину топа по скачкам, если пользователь не представляет особого интереса. И это squid, где большая часть информации имеет какое-то значение. А теперь представьте петабайты обмена, дикая часть из которых порождается автоматическими системами и службами поддержания работоспособности сети. Начнём с того что, что просто «погрепать» эту бигдату задача не совсем тривиальная, а попытка сделать из этого массива данных информационный массив вызовут улыбку у каждого DBA, они то знают, что удобные индексы на массив зачастую по объёму превышают сам массив. А на эту гору хрени очень сложно навесить эффективное индексирование, слишком много различных объектов с различными типами.
И это я упускаю тот момент, что если к web-приложению можно получить доступ имея дамп трафика, то это уже проблема, которую нужно решать на уровне web-приложения.
Кроме того, можно будет перестать воевать друг с другом, а строить центры долгосрочного хранения в складчину, чтобы не хранить один и тот же трафик дважды. Буфер храним у себя, а остальное сливаем в центр с пометками. Если магистрал льёт тоже, сохраняется одна копия.
Ещё можно не хранить объекты контент-провайдеров, а ставить метки, мол юзер закачал вот этот файл, его можно взять у Вконтакта. А вконтакт, когда будет чиститься просто сольёт копию файла в центр.
Решая задачу по минимизации затрат в этом аду, вполне может выйти, что в отрасли будет больше порядка, так как придётся трафик лучше классифицировать и метить, чтобы обработать каждый класс более подходящими дешёвыми а не более универсальными дорогими средствами.
А вот если работать по проблеме в лоб, то да, кап вложения себя не оправдают, от слова совсем…
Вот у меня лично по коду есть два очень тревожащих меня вопроса знатокам:
1. Не вызывает ли дополнительного утомления кодера исходный текст в смешанной раскладке, причём при их смешении прямо в имени переменных (в константах и комментариях они мешаются часто и в других языках)?
2. Не слышно, 1С не планирует внести в платформу более человеческий метод работы с SOAP, т.к. это судя по всему основной протокол ГосAPI? Вот честно, у меня кровь из глаз хлынула на куске по формированию запроса через банальное конструирование XML на низком уровне…
x86 — есть матрёшка, где в самом сердце сидит процессор для калькулятора. Где-то на хабре была статья о командах в этой архитектуре, в элементах которых прослеживается все взлёты и падения, удачные и неудачные решения, заблуждения и находки. Поэтому набор этих команд крайне разнообразен, их структура воспринимается сложно, а местами требования обратной совместимости не дают что-то сделать по-человечески. И теперь всё вот это безумие мы имеем на НОВОМ процессоре, заточенном под СПЕЦИАЛЬНЫЕ задачи. Когда такая ситуация имела место ранее, были сделаны ещё 2 типа процессоров: математический и видео (я уже не говорю что современная миниЭВМ, то бишь сервер, имеет по спец процессору на каждую вторую и каждую первую ключевую подсистему), и никто не делал мат. процессор способным запускать код основного, он великолепно справляется со своими задачами, и с развитием физического уровня был благополучно встроен в центральный. То же с графикой. А вот процессор массового параллельного специализированного счёта мы делаем x86, дабы запустить на нём vim и пару тестов. Вопрос: нафиг?.. Оно должно принять массив чисел в области памяти, код (желательно специализированный, дабы не заниматься предсказанием пожеланий программиста на уровне микросхемы, ибо на уровне компилятора это сделать проще, по крайней мере в запущенных случаях можно спросить) и как можно быстрее этот код прогнать по массиву. Остального от данного процессора ожидать глупо и бессмысленно, ибо для этого есть вполне хороший центральный процессор.
На мой взгляд, пытаться засунуть в данный камень x86 во всём её ужасном многообразии также дико как запускать Microsoft Office, или Conter-Strike на IBM Watson. Технически задача решаема, вот только вопрос остаётся в силе: нафиг?
Вот интересно, зачем спец процессоры делать обычными x86. ИМХО x86 и так уже растянута на всё что только можно и непонятно, как оно ещё не лопнуло от всего этого. Странное решение.
Вот так, потихоньку без суеты наши собственные законодатели научат нас наконец пользоваться системой WHOIS и заняться её развитием. Вот только почему сеть не может в этом месте организоваться самостоятельно не до конца понятно.
ОС сама по себе бесполезна. она формирует базу программной платформы. Разработка ОС для того, чтобы положить её в реестр — идиотское занятие. Когда придёт время для разработки прикладной системы, решающей конкретные задача, про эту ось вспомнят, но толку не будет, потому как разработчики нужны, а у разработчиков скил. Чтобы данная работа была нужна и эффективна — нужно говорить не о ОС а о единой платформе, в которую войдут все те линуксы и иные системы на, из которых у нас делаются российские ОС разного назначения. Но мы слышим только про ОС, задачи работ по данной теме даются туманные, работа по уже распиареным темам идёт как-то не ясно, успехов пока не видно. Потому народ и говорит про распилы, в такой мутной воде люди дела проворачивают, а не по пишут.
Потому что не ясно зачем писать свою ОС, когда не летит Ubuntu для мобилок, провалилась WebOS… И вообще, программа решает проблемы стоящие перед человеком. Не важно что за программа, ОС относится к ПО. Но у нас не обозначена решаемая проблема, нет своей платформы, нет задач кроме защиты от вражеского NSA. А под соусом УраПатриотизма обычно пилят деньги, причём везде, мы здесь не исключение. И да, из шумной компанией по российскую ОС пока ничего не вышло, хотя деньги какие-то освоены…
И вопрос: а почему не использовали полный редирект на точку присутствия у соответствующего провайдера и не стали раздавать статику с него, при этом проксируя динамику в центр. Ведь на связность в точках присутствия больше влияния чем на связность клиента и сервера? Да добавляется лишний элемент, который ещё нужно мониторить, но с центра кэшированием можно снять часть нагрузки…
А вообще надо народ не устойчивым стойкам на разные цвета и изображения учить, а собраться всем экспертам гуртом и выработать наконец инструмент, который однозначно классифицирует ресурс как безопасный и инфраструктуру к нему. Пока мы видим только вялое внедрение странных вещей в основном в инициативном порядке.
Отсюда вообще возникает предложение, от нефиг делать данные темы не трогать, а если трогать, то начислять всем сёстрам поровну. Вам не кажется, что это не лишено логики?
А людей жалко, и тех кто погиб, и тех кто по каким то причинам работал без должной процедуры взаимодействия с опасными материалами. И всё это безотносительно того, имела место утечка или естественное заражение. Это не важно. Люди гибнут по воле безумия, которое ещё даже не пытались истребить. Но активно пытаются приуменьшить заслуги своего и преувеличить у оппонентов. И это ещё один уровень безумия, стоящий слишком далеко в очереди на уничтожение, нежели того заслуживает.
А если Вам кто-то не нравится, можно ему устроить налоговую проверку с изъятием оргтехники, если ничего не найдётся, то всё равно контора будет надолго парализована. А если человек совсем не нравится, ему на голову можно уронить кирпич. Не стоит усложнять простые вещи. Это всё создаётся не для этого. Ничем хрошом оно не светит, но и подобных раскладов тоже не стоит опасаться. Человек загнанный в угол имеет свойство не подчиняться заповедям о «не убей», «не укради» и причинять тем гораздо больше проблем чем обычно.
А если смотреть на трафик, то кажется что хранение большей его части — глупость. Оно либо не актуально уже через 5 минут, либо дублирует что-то.
В общем кому нужно продать немного оборудования, продаст и успокоится.
И это я упускаю тот момент, что если к web-приложению можно получить доступ имея дамп трафика, то это уже проблема, которую нужно решать на уровне web-приложения.
Кроме того, можно будет перестать воевать друг с другом, а строить центры долгосрочного хранения в складчину, чтобы не хранить один и тот же трафик дважды. Буфер храним у себя, а остальное сливаем в центр с пометками. Если магистрал льёт тоже, сохраняется одна копия.
Ещё можно не хранить объекты контент-провайдеров, а ставить метки, мол юзер закачал вот этот файл, его можно взять у Вконтакта. А вконтакт, когда будет чиститься просто сольёт копию файла в центр.
Решая задачу по минимизации затрат в этом аду, вполне может выйти, что в отрасли будет больше порядка, так как придётся трафик лучше классифицировать и метить, чтобы обработать каждый класс более подходящими дешёвыми а не более универсальными дорогими средствами.
А вот если работать по проблеме в лоб, то да, кап вложения себя не оправдают, от слова совсем…
1. Не вызывает ли дополнительного утомления кодера исходный текст в смешанной раскладке, причём при их смешении прямо в имени переменных (в константах и комментариях они мешаются часто и в других языках)?
2. Не слышно, 1С не планирует внести в платформу более человеческий метод работы с SOAP, т.к. это судя по всему основной протокол ГосAPI? Вот честно, у меня кровь из глаз хлынула на куске по формированию запроса через банальное конструирование XML на низком уровне…
На мой взгляд, пытаться засунуть в данный камень x86 во всём её ужасном многообразии также дико как запускать Microsoft Office, или Conter-Strike на IBM Watson. Технически задача решаема, вот только вопрос остаётся в силе: нафиг?
Ну это так, мысли вслух…