Пульс

По подсчетам исследователей безопасности сейчас на сайте содержится порядка 10 тысяч таких ключей.

Разработчики GitHub, являющиеся по совместительству пользователями Amazon Web Services (AWS), получили рекомендацию проверить обнародованный ими на своих страницах код и удалить оттуда секретные ключи доступа для учетной записи AWS, которые могли случайно туда попасть.

«При получении доступа к AWS программным путем проверка подлинности пользователя и приложений происходит с помощью ключа доступа. Этот ключ состоит из access key ID (что-то вроде AKIAIOSFODNN7EXAMPLE), а также секретного ключа доступа (что-то вроде wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY), — инструктируют в Amazon. — Любой, кто знает ключ доступа, способен получить тот же уровень доступа к AWS-ресурсам пользователя, что и владелец этого ключа».

В компании также отметили, что случаи, когда клиенты компании случайно публикуют свои ключи корневого доступа к репозиториям вовсе не редки, в связи с чем их стоит либо удалить, либо вовсе не создавать, если в этом нет необходимости.

Это также подтвердил исследователь безопасности Тай Миллер (Ty Miller), глава компании Threat Intelligence, специализирующейся на проведении тестов на проникновение.

По его словам, найти эти ключи довольно просто и сделать это позволяет имеющийся на GitHub функционал поиска. Так, в настоящий момент на сайте доступные порядка 10 тысяч таких ключей.

Подробнее: www.securitylab.ru/news/450802.php

Увидел я такое объявление о фрилансе.


И мне стало интересно, как поживает Матюшко Михаил, который всегда врет, но не признает того, что наврал.

Кто забыл, вспоминаем прошлое лето, когда был брутфорс ворпрессов. И ддос атаки. Ближе к осени я понял, что никаких атак не было, скорее всего это был тупо брутфорс безлимитных мусорных блогов, которые сотнями там висели.
От сотрудничества с allhosting он похоже отказался.

Кстати, кто помнит, в новостях на сайте была новость о ддосах атаках. Сейчас я зашел на сайт — новости конечно же нету. История не сохранилась. Человек все так и продолжает считать, что все идиоты :))) Таких редко встретишь.

Ну так вот, мне как наблюдателю всегда интересно вспоминать прошлое.
Быстренько я прошелся глянул как дела. Раз, два, три. Ничего нового. Этот топик он видимо не читал. А я уже замечал, пару хостеров, которые стали так делать. А вообще, идеального метода DNS так и не существует! Может быть ispsystem сделает подключение cloudflare в своих панелях и будет заебись. Тариф за 200 баксов не разу не подводил меня.

Итак, смотрим дальше.
Возьмем с конца — там hetnzer банальный и сервера не работают. Просто домены похоже брошены, остались висеть на старых мертвых dns.

195.154.64.49
195-154-64-49.rev.poneytelecom.eu

176.31.185.66
66.ip-176-31-185.eu
OVH

Но все это не работает.

5.9.138.93
serv37.coopertino.ru
Hetzner так и остался, выжил

5.39.221.252
serv39.coopertino.ru
inetnum: 5.39.221.247 — 5.39.221.255
netname: Coopertino-NET
descr: Coopertino Ltd.
descr: abuse@coopertino.ru
country: NL
hostkey.com

144.76.74.166
vip11.coopertino.ru
Hetzner

178.33.88.224
Имя хоста: serv41.coopertino.ru
inetnum: 178.33.88.224 — 178.33.88.227
netname: COOPERTINO-RU
country: FR
OVH.com

Собственно все подомены ведут на одно и тоже. Либо это dns хостинг, по правильному уже. А чтобы не заставлять людей менять адреса, все старые поддомены направлены на OVH. Либо всего 1-2 сервера и тупо через аккаунты реселлера, чтобы ссылки в панели были 12 44 66.

Прошло 9 месяцев. Хостинг оклемался похоже. Скоро начнет снова тратить на рекламу.

С умением написать программную часть для автоматизации.
Естественно не бесплатно.
mail@alice2k.org



Пример тот же наш prostovpn stat.prostovpn.org/register

ru-tld.ru/dns/

Надеюсь после 2015 так будет у всех

cloud.google.com/partners/program-guide
cloud.google.com/partners/



Может кому-ниб пригодится.

Если у вас VPS / VDS или выделенный сервер, вам стоит проверить его на наличие уязвимости командой:

ntpdc -c monlist адрес_сервера

Если команда выдает список клиентов (а не «timed out, nothing received»), значит система уязвима.

Для устранение проблемы можно воспользоваться одним из способов:
1. Обновить сервис ntpd до версии 4.2.7p26.

Без обновления можно:
2. Отключить функцию monlist в ntp.conf, добавив строчку disable monitor
3. Отключить любые запросы статуса сервера в restrict default:

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

www.hts.ru/ru/events/news/?id=145

tehnodom.com/auction/ (кто забыл, раз, два)

Был ark.intel.com/ru/products/65697/Intel-Core-i3-3217U-Processor-3M-Cache-1_80-GHz
Стал ark.intel.com/ru/products/75107/Intel-Core-i3-4010U-Processor-3M-Cache-1_70-GHz

Мне не особо понятно лучше или хуже. Но некоторые параметры отличаются в описании.

cloudant.com/ibm-to-acquire-cloudant/#.UwtYNPl_u3o
www-03.ibm.com/press/us/en/pressrelease/43238.wss

У меня в команде есть чел, который игровые сервера делает.
Так вот, он не подстраховывается как я. Не делает извратские методы с dns или чтобы все сайты весили менее 100мб и были мобильны. Он не мыслит, как я, который с опытом изучения хостинга увидел весь этот гемор, похуистов, нубасов и лишний раз не отвлекает тех поддержку.


Сколько мы уже, год, пользуемся Техндомом. И мои полу-пустые сервера как работали, так и работают. Вообще с ними ничего не случается, так как я всегда держу очень большой пустой запас.
А он постоянно выжимает из серверов максимум. Есть менталитет людей таких, которые считают что если заплатили, то нужно использовать на полную. ))
Так вот, за год КВМ практически не запрашивался кроме игровых серверов, которые он админит.

И вот, недавно он открыл для себя смарт дисков и начал изучать. И нашел какие-то ошибки.
Попросил замену. И ему — заменили без каких-либо претензий.

После этого он решил, что в апреле еще купит 5 серверов в Технодоме. Хотя под игры мы там с осени не покупали.

Так что, вот 2 факта

• Отношение ДЦ сыграло в пользу психологии человека клиента
• Технодом меняет hdd без вопросов. Я всегда обращался в ДЦ только когда диски сгорали. Поэтому не знаю, как реагируют другие дата центры на подобные запросы по смарту. И поэтому подобная новость достойна топика. Что-то новое для статистики в пути изучения.

Получил такие вот уведомления.

И действительно


Не везет им с dns, если все затянется, опять начнется как в марте 2012

А конкретно советы(раз,два), что нужно покупать 2 или лучше 4 домена.
И обязательно каждый домен — у отдельного доменного регистратора.
ns.domain.ru
ns.domain.com
ns.domain.net
ns.domain.org

Надеюсь в будущем делать dns минимум на 2х доменах станет нормой.