CIPHER вопрос к опытным

3 views
Skip to first unread message

friackazoid

unread,
Jul 6, 2009, 8:42:54 AM7/6/09
to RuCTF 2009
А я правильно понимаю чьл согласно 7 8 правилу из FAQ нельзя
пользоваться никаким фаерволом даже iptables ни на уязвимом образе ни
на шлюзе?

ilya zelenchuk

unread,
Jul 7, 2009, 2:42:33 AM7/7/09
to ru...@googlegroups.com
Привет!

Да, похоже на то, что нельзя. Тут ещё есть ограничение, что нельзя
фильтровать запросы на уровне приложения.


--
С уважением,
Илья Зеленчук

Trickster

unread,
Jul 7, 2009, 1:21:01 PM7/7/09
to RuCTF 2009
Привет всем!

На сколько я понял, речь идет только о блокировке запросов везде,
кроме внутренностей самого сервиса. Порты же прокинуть по прежнему
можно? ;)

Anthony Sapozhnikov

unread,
Jul 7, 2009, 1:59:49 PM7/7/09
to ru...@googlegroups.com
Привет!
Попробую перефразировать ответ из фака, что б было понятнее (:
http://cipher-ctf.org/FAQ.php
Can we do Layer 7 filtering (watching for buffer overflows for example) and then using the L7 NetFilter plugin to filter related attacks? Or do we have to do this without any sort of filtering on the server.
In contrast to former CTF events, we do not allow L7-Filtering any more.
In fact, any kind of filtering that is not done in the applications themselves is considered against the rules. :

Нельзя применять какую-либо фильтрацию, кроме той, что реализована в самом приложении.
Пример: отменяются всякие mod_security и прочие sql-detectors(такой был предложен хакердомом в том году)
Если вы перепишите саму прогу, то это только в плюс вам.

вопрос номер два, задан не был, но наверняка вы думали об этом ;)
Можно ли применять разный софт предотвращающий переполнения буфера и т.п.?
нельзя. судя так же входят и прочие приблуды в духе SELinux и AppArmor
Can the kernel be recompiled with the openwall or grsec security patches in place... patching that would limit/prevent buffer overflows?
Recompiling the kernel is allowed. BUT: patches that would limit/prevent buffer overflows are not allowed.
дух данного ctf кроется в следующем приложении:
Remember that the exercise is about application layer security and not about creating an OS that works around insecure applications.


Конечно если кто-нибудь будет использовать подобные вещи и грамотно их реализует, то никто и не узнает об этом, всё остается на совести участника, как, например и количество человек в команде.

2009/7/7 Trickster <CyMpak...@gmail.com>



--
С уважением, Антон Сапожников.
mailto: Anton.Sa...@gmail.com

friackazoid

unread,
Jul 7, 2009, 2:30:56 PM7/7/09
to RuCTF 2009
Блин это не правильно...
Хороши админ должен расчитавать на плохих програмистов и админить сеть
так чтоб никто не пробралсо... Работоспособность то не нарушается.

Trickster

unread,
Jul 7, 2009, 2:39:01 PM7/7/09
to RuCTF 2009
Все таки не совсем понятно. В FAQ четко сказано, что нельзя
фильтровать трафик до уязвимого образа ни на каком из уровней OSI. Тут
логика организаторов понятно, где-то даже была фраза про то, что
соревнования по безопасности уровня приложений. А вот относится ли к
такой фильтрации изменение топологии сети с пробросом портов и прочими
вкусностями, а также защита других машин, имхо, еще не факт.

friackazoid

unread,
Jul 7, 2009, 2:52:31 PM7/7/09
to RuCTF 2009
Думаю к нату это не относится. Потому что лично у нас чтоы просто
организовать игровое поле пришлось покумекать и с натом и
топологией... да так что рассказывать стыдно. К тому же впринципе
проверить все это достаточно сложно и если советь твоя чиста то и
юзать можно без осоого шуму.

Nickolai Zhuravlev

unread,
Jul 7, 2009, 3:00:31 PM7/7/09
to ru...@googlegroups.com
2009/7/8 friackazoid <friac...@gmail.com>:

> Думаю к нату это не относится.

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

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

> К тому же впринципе
> проверить все это достаточно сложно и если советь твоя чиста то и
> юзать можно без осоого шуму.

http://cipher-ctf.org/CaptureTheFlag.php:
"""
The image will contain some mean for the gamemaster to log on and
check if the team is adhering to the rules. It is not allowed to
de-activate this account.
"""


--
Николай Журавлёв

friackazoid

unread,
Jul 7, 2009, 3:15:36 PM7/7/09
to RuCTF 2009
Так я не про безопасную инфраструктуру говорю, я про рабочую говорю. У
нас например без плясок с бубнами вокруг iptables вообще никак впн не
организуешь этож не значит что нам теперь играть нельзя.

Nickolai Zhuravlev

unread,
Jul 7, 2009, 3:29:43 PM7/7/09
to ru...@googlegroups.com
2009/7/8 friackazoid <friac...@gmail.com>:

> Так я не про безопасную инфраструктуру говорю, я про рабочую говорю. У
> нас например без плясок с бубнами вокруг iptables вообще никак впн не
> организуешь этож не значит что нам теперь играть нельзя.

Думаю, что Trickster спрашивал не про такую ситуацию :-)

(изначально я понял, что реплика про natы была в ответ на его письмо,
хотя сейчас смотрю, что может быть это и не так)


--
Николай Журавлёв

Anthony Sapozhnikov

unread,
Jul 7, 2009, 3:35:17 PM7/7/09
to ru...@googlegroups.com
По идеи.
единственные сложности которые могут возникнуть - это установка соединения с vpn сервером, тут конечно никаких ограничений нет.
В правилах ведь речь идет о том, что происходит после деинкапсуляции трафика из vpn.

2009/7/8 friackazoid <friac...@gmail.com>

Так я не про безопасную инфраструктуру говорю, я про рабочую говорю. У
нас например без плясок с бубнами вокруг iptables вообще никак впн не
организуешь этож не значит что нам теперь играть нельзя.

Reply all
Reply to author
Forward
0 new messages