Как сделать свой пул для Биткоин в 2019 году — Биткоин Блог / и всё о Биткоине

Главная страница » Вопросы »

Выгодно ли открывать свой пул для майнинга ?

Или это просто благое дело и я не буду иметь никакого процента от майнеров?

А также сервер должен быть таким же как и железо майнеров (по характеристикам)?

И если можно поделитесь информацией по установке и настройке своего пулла.

Вопрос задан более трёх лет назад
14827 просмотров

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

Кстати на каком железе вы собрались поднимать пул?

@ARezvanov Точнее то на что пулов почти нету, а лучше на свежую монетку
так как конкуренции мало или вообще нету

Если пул получет какойто процент то всерамно что то буду иметь и смогу обменять на биток, правда если будет биржа или обменик какойто )

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

А на остальных валютах там настолько небольшие суммы крутятся, что смысла делать что-то нет.

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

При текущей сложности заработать можно только имея асик сделанный по последнему техпроцессу. Меньше чем с террахешем туда лезть не стоит, с такой скоростью ты будешь зарабатывать примерно четыре бакса в день.

Я не совсем понимаю что такое блейд м610. Возможно вы говорите про обычный блейд сервер с ксеоном на борту?

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

Сегодня веб-сайты работающие с криптовалютами являются очень «вкусной» мишенью для хакеров. И вроде бы их безопасность должна быть на высоком уровне, но нет. это далеко не всегда так. Посмотрите хотя бы на BlockChain Graveiard, где видно как крупнейшие сервисы банкротятся и закрываются в результате хакерских атак. Меня это воодушевило и я решил провести собственное исследование безопасности одного из таких веб-приложений. В этой статье я расскажу что из этого получилось и сколько мне заплатили. Интересно? Добро пожаловать под кат.

Читайте также: Сколько Биткоинов стоит тесла

Итак, я посетил ViaBTC Pool — один из крупнейших пулов для совместного майнинга. Выбор был случайным и базировался на диаграмме ниже.

Диаграмма построена на основе рыночной доли самых популярных биткоин-пулов для майнинга по состоянию на 23.09.2017

Я зарегистрировал аккаунт, привязал телефон и подключил двухфакторную аутентификацию через Google Authenticator. Также была включена опция “Authenticate When Sign In ViaBTC” (2fa при входе).

Вот так безопасно выглядел аккаунт потенциальной жертвы:

1. Сайт не защищен от CSRF атак.

CSRF (англ. Сross Site Request Forgery — «Межсайтовая подделка запроса», также известен как XSRF) — вид атак на посетителей веб-сайтов, использующий недостатки протокола HTTP. Если жертва заходит на сайт, созданный злоумышленником, от её лица тайно отправляется запрос на другой сервер (например, на сервер платёжной системы), осуществляющий некую вредоносную операцию (например, перевод денег на счёт злоумышленника). Для осуществления данной атаки жертва должна быть аутентифицирована на том сервере, на который отправляется запрос, и этот запрос не должен требовать какого-либо подтверждения со стороны пользователя, которое не может быть проигнорировано или подделано атакующим скриптом.

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

Работает это так:

Пользователь веб-приложения переходит на сайт злоумышленника.
Жертва ничего не подозревает, однако в этот момент на сайт pool.viabtc.com был отправлен запрос на смену email адреса.

Злой хакер тут же получает письмо на свою почту для подтверждения операции.

После перехода по ссылке в письме злоумышленник видит:

Великолепно! Почта успешно привязалась и атакующий автоматически залоггинился в аккаунте жертвы. Но влажные фантазии нашего воображаемого хакера о несметных криптобогатствах прервёт тот самый редирект «ту хоум». Да, это окно втрого шага аутентификации (2fa при входе, помните?):

2. Обход двухфакторной аутентификации при входе

Далее была обнаружена критическая уязвимость в реализации двухфакторной аутентификации. Некоторые функции веб-приложения требовали подтверждение вторым фактором аутентификации только во фронтенде. Если отправить запрос непосредственно на бэкенд, то он будет успешно выполнен без надлежащей аутентификации.

Таким образом, атакующий способен отключить двухфакторную аутентификацию при входе, несмотря на то, что он не прошёл ту самую двухфакторную аутентификацию, что, несомненно, является очень удобной фичей.

Атакующий использует запрос ниже для отключения 2fa при авторизации.

Злоумышленник переходит на главную страничку, но теперь аутентификация не запрашивается.

Что ещё можно было сделать отправляя запрос непосредственно на сервер? Давайте вспомним первую уязвимость, где браузер жертвы сам отправил запрос на смену email’a. Если пользователю необходимо изменить email, то фронтед запросит подтверждение через второй фактор аутентификации. Но если отправлять запрос напрямую, то подтверждение не требуется! Из за такого недостатка безопасности атакующий и смог изменить email используя CSRF.

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

3. Полный обход двухфакторной аутентификации

Веб-приложение разрешает использовать два метода подтверждения операций: SMS код или код из Google Authenticator. Но я обнаружил ещё один метод – email код.

Как? Я обратил внимание на процесс подтверждения операции через SMS. Он состоит из запроса на отправку кода и запроса на подтверждение используя полученный код. Выглядит это так:

«В этом запросе было бы неплохо изменить “sms” на “email”», – подумал я.

А здесь логично “sms_code” на “email_code”.

Ну что сказать, ловкость рук и никакого мошенничества!

Да, у атакующего нет доступа к SMSкам жертвы. И да, у него нет доступа к аккаунту Google Authenticator жертвы. Но у него есть доступ к email’у (он был привязан к аккаунту благодаря CSRF).

Итак, финальные шаги:

Злоумышленник отправляет запрос на получение кода подтверждения для операции перепривязки аккаунта Google Authenticator.

Получает код на email.

Подтверждает операцию используя email код.

Изменяет второй фактор аутентификации на свой.

Вот таким нехитрым образом злоумышленник завладел аккаунтом обычного пользователя веб-приложения.

Цепочка уязвимостей позволяет полностью украсть аккаунт, что, конечно же, критично. Тем не менее уязвимости исправить не сложно:

Внедрить CSRF-токены.
Выполнять проверки на стороне сервера.
Отключить подтверждение через email.

Но если смотреть глубже, эти уязвимости просто симптомы по которым можно диагностировать:

Разработчики не имеют базовых знаний в области безопасности веб-приложений. Как минимум знание заезженного OWASP TOP TEN исключили бы появление столь банальной уязвимости как CSRF.
Разработчики считают, что фронтенд является единственным источником данных для бэкенда веб-приложения и слишком доверяют данным от него. Но это не так: мы можем отправлять прямые запросы на сторону сервера.
Отсутствует строгая политика относительно функционала веб-приложения. Разработчики допустили существование предположительно дебаг функции в продакшн версии веб-приложения.

Главное это не просто исправить те несколько уязвимостей, что я обнаружил. Важно смотреть в корень проблемы. Техническая команда должна сделать выводы и постоянно улучшать их знания в области безопасности. Да, возможно эта мысль банальна и очевидна. Но мы каждый месяц наблюдаем громкие заголовки о взломе очередной криптобиржи. Забавно то, что это вроде бы как новые технологии с огромными рисками, миллионы денег, которые могут безвозвратно покинуть ваш кошелёк, но всё те же разработчики, которые не знают что такое CSRF. Я всё.

Хардкорная конфа по С++. Мы приглашаем только профи.

Взлом Биткоин адресов. 500 Биткоинов взломаны в «мозговом кошельке» с паролем «bitcoin is awesome» Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e

подробнее.

Всем кто хочет заработать Биткоины без вложений — рекомендую сайт http://bitcoin-zarabotat.ru

10 шахтеров в настоящее время, но я планирую получить более скоро. Я хочу, чтобы создать свой собственный пул для добычи Bitcoins.

Читайте далее: