Автоматизация проверки зашифрованной подписи
Один из основных моментов обеспечения безопасности вашей системы — ознакомление с устанавливаемым программным обеспечением. Как правило, для внимательного изучения исходного кода всего устанавливаемого программного обеспечения не хватает времени, знаний или ресурсов. Однако проверка того, что компилируемые и устанавливаемые программы — это именно то, что подразумевал их автор, может занять много времени, которое расходуется на предотвращение широкомасштабного распространения «троянских коней». Ряд главнейших программных продуктов (tcpdump, LibPCap, Sendmail и OpenSSH) имеет версии, хотя и редко встречающиеся, содержащие «троянов». Поскольку это одно из популярных направлений атак, проверка их наличия в программном обеспечении является критически важной. Почему это является проблемой? К несчастью, проверка программы перед установкой требует лишь небольших усилий. То ли из-за лени, то ли по невежеству многие системные администраторы упускают этот критический этап. Это является классическим примером «ложной» лени, которая впоследствии может привести к необходимости выполнять значительно больший объем работ. Решить эту проблему очень сложно, поскольку это требует совместной работы программистов и распространителей. Кроме того, лень мешает и здесь: длительное время программные продукты вообще не имели подписи, позволяющей проверить загруженный программный код. Зачастую подписи доступны вместе с исходным кодом, но для проверки последнего необходимо отыскать на сайте открытый ключ, используемый для создания подписи. После нахождения открытого ключа его необходимо загрузить, проверить подлинность, добавить его в «связку ключей» и затем проверить подпись программного кода. Вот как выглядит проверка подписи web-сервера Apache версии 1.3.28 с помощью GnuPG (http://www.gnupg.org):
# gрg -import КЕS
# gрg -verify apachej.. 3.28. tar. gz.asc apachel.3.28.tar.gz
gpg: Signature made Wed Jul 16 13:42:54 2008 FDT using D3 key ID 08C975E5
gpg: Good signature from "Jim Jagielski <jim@zend.com>"
gpg: aka "Jim Jagielski <jim@apache.org>"
gpg: aka "Jim Jagielski <jhT@jaguNET.com>"
gpg: WRNN3 This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Fingerprint: 8B39 757B 1D8A 994DF243 3ED5 8ВЗA 601F 08C9 75E5
Как можно заметить, процедура проверки очень проста, но в спешке этот шаг обычно упускается. Вот где полезен рассматриваемый трюк. Используется лишь небольшой сценарий и то, что известно как сервер ключей, а это уменьшает число шагов проверки.
Сервер ключей — это часть инфраструктуры криптографии с открытыми ключами, позволяющая извлекать ключи от третьей стороны, пользующейся доверием. Отличной функцией GnuPG является возможность обращения к серверам ключей за идентификаторами ключей, а также загрузки результатов в локальную «связку ключей». Чтобы разобраться, какой идентификатор ключа запрашивать, мы полагаемся на тот факт, что сообщение об ошибке, генерируемое GnuPG, при попытке проверить подписи сообщит нам, какой идентификатор ключа невозможно найти локально.
В предыдущем примере, если ключ, который нужен GnuPG, перед выполнением проверки подписи не был импортирован, появится подобное сообщение:
gpg: Signature made Wri Jul 16 13:42:54 2008 FDT using D3 key ID 08037555 gpg: Can't check signature: public key not found
Представленный далее сценарий извлекает пользу из этого сообщения: #!/bin/sh
VENDOR_KEYRING=vendors.gpg KEYSERVER=search.keyserver.net
KEYID="Ox4gpg —verify $1 $2 2>&1 I grep 'key ID1 I awk '{print $ N F)1"" gpg --no-default-keyring --keyring $VENDOR_KEYRING —recv-key
—keyserver $KEYSERVER $KEYID gpg —keyring $VENDOR_KEYRING —verify $1 $2
Первая строка сценария указывает «связку ключей», в которой должен храниться результат, полученный с сервера ключей. Можно использовать файл pubring.gpg (который для GnuGP является «связкой» по умолчанию), но использование отдельного файла облегчит управление открытыми ключами. Вторая строка сценария указывает, к какому серверу ключей произойдет обращение (сценарий использует search.keyserver.net; еще одним подходящим сервером является pgp.mit.edu). Третья строка пытается (в данном случае — неудачно) проверить подпись, не проконсультировавшись с сервером ключей. Далее GnuPG использует идентификатор ключа, указанный в сообщении об ошибке, добавляет спереди an Ох для того, чтобы в следующей строке обратиться к серверу ключей. И наконец, GnuPG пытается проверить подпись и указывает «связку ключей», в которой должен храниться ключ. Этот сценарий сокращает процесс проверки, избавляя от необходимости поиска и импорта открытого ключа, использованного для генерации подписи. Возвращаясь к примеру проверки исходного кода Apache 1.3.28, можно заметить, что удобнее проверять достоверность пакета следующим образом:
# check-sig apachej..3.28.tar.gz.asc apachej.. 3.28.tar. gz
gpg: requesting key 0ЕС975Б5 from HHP keyserver search.keyserver.net
gpg: key 08С975Б5: public key imported gpg: Total number processed: 1 gpg: imported: 1
gpg: Warning: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
gpg: Signature made Wad Jul 16 1 3:42:54 2003 FDT using D8 key ID 08C975E5
gpg: Good signature from "Jim Jagielski <jim@zend.com>"
gpg: aka "Jim Jagielski <jim@apache.org>"
gpg: aka "Jim Jagielski <jim@jaguNET.com>"
gpg: checking the trustdb
gpg: no ultimately trusted keys found
gpg: WARNING This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Fingerprint: 8B39 757B 1D8A 994D F243 3ED5 8B3A 601F 08C9 75E5
С помощью этого маленького и простого сценария сокращается как количество выполняемых шагов, так и необходимое для их выполнения время. Использование сценариев должно помочь вам быть ленивым в хорошем смысле: выполнять больше работы, но с меньшими усилиями.