Мы (команда 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. Надеюсь, кому-то это окажется полезным :)
Мы (команда 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. Надеюсь, кому-то это окажется полезным :)