You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Мы (команда Destructive Voice из УрФУ) несколько лет стабильно использовали ферму из этого репозитория, но столкнулись с рядом ограничений:
Ферму тяжело использовать на RuCTFE (компьютер с трудом выдерживает одновременный запуск 400 процессов даже в случае простых эксплоитов).
start_posting.py и все start_sploit.py должны работать на одной машине. Если один эксплоит выжрет всю память (это легко сделать с 400 процессами), зависает вся машина и останавливаются все остальные эксплоиты. Если запустить несколько start_posting.py на разных компьютерах, потеряется контроль за квотами.
Сложно добавить отображение нормальной статистики, так как интерфейс только консольный и в файлах не сохраняется, из какого эксплоита и от какой команды пришёл флаг.
По той же причине нельзя так просто добавить квотирование флагов по командам и таскам, чтобы защититься от спама флагами (когда какая-то команда загружает тысячи ложных флагов в чужой таск, а в проверяющей системе есть ограничение на количество сданных флагов).
Мелкие неприятности: при использовании start_sploit.py нужно не забывать вручную делать chmod +x и добавлять shebang (иначе печатаются непонятные сообщения об ошибках). Мои сокомандники, которые раньше не пользовались start_sploit.py, долго не понимали, что ферма хочет от них.
Неочевидные баги: мы часто пишем эксплоиты, которые проходятся по списку пользователей/записей в сервисе, получая флаги от самых новых к самым старым. В этом случае мы рассчитываем, что ферма будет прибивать эксплоит по таймауту и регулярно перезапускать (таким образом, все флаги будут получены).
В определённый момент мы поняли, что при использовании этой фермы флаги в такой конфигурации теряются. А именно, если stdout эксплоита на Python привязан к пайпу до фермы, стандартно используется более агрессивная, чем в случае терминала, буферизация (stdout не flush'ится даже после вывода \n). Когда ферма убивает эксплоит по таймауту, содержимое буфера теряется и в ферму не приходит.
Баг очень хитрый, потому что легко подумать, что "плохо хакается, потому что многие уже защитились" (хотя на деле это не так).
Мы хотели исправить всё перечисленное (и добавить новых фич, таких, как веб-интерфейс для просмотра потока с флагами), но поняли, что проще будет переписать всё с нуля. Новая ферма хорошо показала себя на последних RuCTFE и RuCTF.
На днях мы выложили её в open source. Надеюсь, кому-то это окажется полезным :)
The text was updated successfully, but these errors were encountered:
Мы (команда Destructive Voice из УрФУ) несколько лет стабильно использовали ферму из этого репозитория, но столкнулись с рядом ограничений:
Ферму тяжело использовать на RuCTFE (компьютер с трудом выдерживает одновременный запуск 400 процессов даже в случае простых эксплоитов).
start_posting.py
и всеstart_sploit.py
должны работать на одной машине. Если один эксплоит выжрет всю память (это легко сделать с 400 процессами), зависает вся машина и останавливаются все остальные эксплоиты. Если запустить несколькоstart_posting.py
на разных компьютерах, потеряется контроль за квотами.Сложно добавить отображение нормальной статистики, так как интерфейс только консольный и в файлах не сохраняется, из какого эксплоита и от какой команды пришёл флаг.
По той же причине нельзя так просто добавить квотирование флагов по командам и таскам, чтобы защититься от спама флагами (когда какая-то команда загружает тысячи ложных флагов в чужой таск, а в проверяющей системе есть ограничение на количество сданных флагов).
Мелкие неприятности: при использовании
start_sploit.py
нужно не забывать вручную делатьchmod +x
и добавлять shebang (иначе печатаются непонятные сообщения об ошибках). Мои сокомандники, которые раньше не пользовалисьstart_sploit.py
, долго не понимали, что ферма хочет от них.Неочевидные баги: мы часто пишем эксплоиты, которые проходятся по списку пользователей/записей в сервисе, получая флаги от самых новых к самым старым. В этом случае мы рассчитываем, что ферма будет прибивать эксплоит по таймауту и регулярно перезапускать (таким образом, все флаги будут получены).
В определённый момент мы поняли, что при использовании этой фермы флаги в такой конфигурации теряются. А именно, если stdout эксплоита на Python привязан к пайпу до фермы, стандартно используется более агрессивная, чем в случае терминала, буферизация (stdout не flush'ится даже после вывода \n). Когда ферма убивает эксплоит по таймауту, содержимое буфера теряется и в ферму не приходит.
Баг очень хитрый, потому что легко подумать, что "плохо хакается, потому что многие уже защитились" (хотя на деле это не так).
Мы хотели исправить всё перечисленное (и добавить новых фич, таких, как веб-интерфейс для просмотра потока с флагами), но поняли, что проще будет переписать всё с нуля. Новая ферма хорошо показала себя на последних RuCTFE и RuCTF.
На днях мы выложили её в open source. Надеюсь, кому-то это окажется полезным :)
The text was updated successfully, but these errors were encountered: