Facebook Twitter
Linkedin LJ
Git Instagram
IPv6
9 posts tagged

security

Simple fail2ban log file parcer

I have written simple fail2ban log file parcer in Golang that finds banned IPs, makes a struct with date, time and IP and a map with IP as a key and count as a value. I am thinking of nmapping the values I’ve got and making a report out of them.

package main

import (
    "bufio"
    "fmt"
    "regexp"
    "os"
)


type record struct {
  day string
  time string
  ip string
}

type ip struct {
    ip string
    count int
}

// Checking most calls for errors.
// This helper will streamline our error checks below.
func check(e error) {
    if e != nil {
        panic(e)
    }
}

//reading file to array of lines

func readLines(path string) ([]string, error) {
  file, err := os.Open(path)
  check(err)
  defer file.Close()



  var lines []string
  scanner := bufio.NewScanner(file)
  for scanner.Scan() {
    lines = append(lines, scanner.Text())
  }
  return lines, scanner.Err()
}


func main() {

lines, err := readLines("./fail2ban.log")

  var log_records []record

if err != nil {
    fmt.Println("readLines: %s", err)
  }

//date
  dr, _ := regexp.Compile("[0-9]{4}-[0-9]{2}-[0-9]{2}")
//time
  tr, _ := regexp.Compile("[0-9]{2}:[0-9]{2}\\:[0-9]{2},[0-9]{3}")
//IPv4 address
  ir, _ := regexp.Compile("(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])$")
//"Ban"
br, _ := regexp.Compile("Ban")
ip_map := make(map[string]int)

var j int
j = 0

for i, line := range lines {
  if (br.MatchString(line) == true){
    var tmp record
    log_records = append (log_records, tmp)
    log_records[j].day = dr.FindString(line)
    log_records[j].time = tr.FindString(line)
    log_records[j].ip = ir.FindString(line)
//count unique IPs
    ip_map[log_records[j].ip]++
    fmt.Println("Log line:     ",i)
    fmt.Println("Date:         ",log_records[j].day)
    fmt.Println("Time:         ",log_records[j].time)
    fmt.Println("IP address:   ",log_records[j].ip)
    fmt.Println("Count:        ",ip_map[log_records[j].ip])
    fmt.Println("")
    j++
}


}

//pring map of IPs
fmt.Println(ip_map)

}
Apr 18   golang   IT   linux   security

Перевод Designing an Authentication System: a Dialogue in Four Scenes (часть 2)

Предположим я скопировал аутентификатор и билет пока они пересекали сеть. Мне придётся изменить сетевой адрес моей рабочей станции и моё пользовательское имя. И всё это я должен проделать за пару минут. Это довольно высокие требования. На самом деле я не думаю, что это возможно. Если только ... . . .

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

Этот пакет, как я помню, имеет две копии сессионного ключа: один для тебя и один для сервиса. Тот, который предназначен для сервиса скрыт внутри билета и я не смогу получить его, но как насчёт другого, который кто угодно может использовать для создания аутентификаторов?

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

Афина:
Это то, о чём я думала всю ночь, но когда я проследила весь процесс получения билетов я обнаружила, что невозможно похитить аутентификаторы таким образом.

Ты садишься за своё рабочее место и используешь программу kinit чтобы получить твой TGT. Kinit запрашивает твоё имя и после того, как ты введёшь его kinit отправляет его Харону.

Харон использует твоё имя, чтобы найти твой пароль в своей базе данных, затем продолжает создание TGT для тебя. Как часть этого процесса, он создаёт сессионный ключ, которым ты будешь обменивать с сервисом предоставления билетов (TGS). Затем Харон помещает копию этого ключа в TGT, а твою копию добавляет в пакет, содержащий билет и представляющий ответ Харона. Перед тем, как послать этот пакет, Харон зашифровывает его целиком твоим паролем.

Харон посылает этот пакет через сеть. Кто угодно может его скопировать, в то время пока он перемещается мимо, но никто не сможет ничего с ним сделать потому, что пакет зашифрован твоим паролем. В частности никто не сможет похитить сессионный ключ для TGS.

Kinit Получает этот пакет и запрашивает у тебя пароль, который ты должен ввести. Если ты вводишь правильный пароль, он сможет расшифровать пакет и предоставить тебе ключ сессии.

Теперь, когда ты предоставил kinit возможность закончить свою работу, ты можешь пожелать получить свою почту. Ты запускаешь почтового клиента. Эта программа пытается найти билет для почтового сервиса и не находит его (ведь ты ещё на пытался получить почту). Почтовый клиент должен использовать TGT, чтобы запросить у TGS билет для почтового сервиса.

Клиент создаёт аутентфикатор для обмена с TGS и шифрует его своей копией сессионного ключа для TGS. Затем клиент посылает Харону этот аутентификатор, TGT, твоё имя, адрес твоего компьютера и имя почтового сервиса.

TGS получает всё это и начинает выполнять проверки удостоверения личности отправителя. Если все они удачны, TGS в конце концёв получает ключ сессии, общий для него и тебя и создаёт твой билет почтового сервиса, и новый сессионный ключ, с помощью которого ты будешь обмениваться с почтовым сервисом.

TGS теперь приготавливает пакет с билетом готовый к отправке на твоё рабочее место. Пакет включает билет и твою копию сессионного ключа для почтового сервиса. Но перед тем как послать пакет, он шифрует его копией СВОЕГО сессионного ключа. Дело сделано. Пакет отправляется по своему пути.

Итак теперь мы имеем пакет с билетом почтового сервиса, спешащий по сети. Предположим некое сетевое чудовище копирует его в это время. Ему не повезёт потому, что пакет зашифрован сессионным ключом TGS; а ты и TGS два единственных существа, которые знают этот ключ. Из-за этого окажется невозможным расшифровать пакет с почтовым билетом, и он не сможет получить ПОЧТОВЫЙ КЛЮЧ СЕССИИ. Без этого ключа невозможно использовать любой из почтовых билетов которые ты возможно будешь потом посылать по сети.

Итак я думаю, что мы в безопасности. А что думаешь ты?

Еврепид: Возможно.
Афина: Возможно?! Это всё что ты можешь сказать?!
Еврепид: (смеясь) Не расстраивайся. Тебе следует знать мою точку зрения. Я понимаю, что это нечестно с моей стороны --- ты не спала половину ночи.
Афина: фффф!
Еврепид: Ну хорошо, пусть будет три четверти ночи. Действительно система начинает казаться вполне приемлимой. Сессионные ключи решают задачу на которой я сам думал этой же ночью: проблему взаимного удостоверения подлинности.
Пауза.
Могу я поговорить минуту?
Афина: (Несколько настороженно) Пожалуй.
Еврепид:
Ты так добра. (Еврепид откашливаясь) В последнюю ночь пока видения сессионных ключей и аутентификаторов бродили в твоём уме, я пытался найти другие проблемы в системе, я нашёл одну, которая казалась мне очень серьёзной. Я проиллюстрирую её следующим примером.

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

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

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

Я рассмотрел задачу с противоположной точки зрения. Без сессионных ключей Харон может защитить свои сервисы от фальшивых пользователей, но он не может защитить своих пользователей от фальшивых сервисов. Системе нужен способ для клиентских программ удостовериться в подлинности сервиса перед посылкой ему информации. Система должна позволять взаимную аутентификацию.

Но ключ сессии решает и эту задачу, если твоя клиентская программа написана правильно. Возвращаясь к примеру с сервисом печати: я хочу такую программу печати, которая удостоверятся, что сервис для которого она отправляет задание является законным.

И вот что такая программа делает. Я ввожу её имя с параметрами печати включающими имя файла для печати -- моё резюме. Предположим, что я уже имею билет и ключ сессии. Клиентская программа использует сессионный ключ, чтобы создать аутентификатор, затем посылает аутентфикатор и билет “желаемому” серверу печати. Клиент ЕЩЁ НЕ ПОСЫЛАЕТ резюме; он ожидает ответа сервиса.

Реальный сервис получает билет и аутентификатор, расшифровывает билет и извлекает сессионный ключ, а затем использует его, чтобы расшифровать аутентификатор. Когда всё сделано, сервис выполняет все обычные проверки для удостоверения в личности клиента.

Предположим проверка подтвердила мою личность. Теперь сервис подготавливает ответный пакет, так чтобы доказать свою подлинность клиентской программе. Он использует сессионный ключ, чтобы зашифровать ответный пакет, и посылает его ожидающему клиенту.

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

Предпололжим, что мой босс перенастроил систему, так, что сервис выглядит так как будто он тот который мне нужен. Моя программа посылает аутентификатор и билет “сервису печати” и ожидает ответ. Фальшивый сервис печати не может сгенерировать правильный ответ, потому, что он не смог расшифровать билет и получить сессионный ключ. Моя программа не будет посылать задание если не получить правильного ответа. Очевидно, клиент в конце концёв прервёт ожидание и выйдет. Задание не будет выполнено, но хотя бы резюме не попадёт на стол моего врага.

Ты знаешь, я думаю у нас есть крепкий фундамент на котором мы сможем построить Систему Аутентификации Харон.

Афина: Возможно. Но в любом случае, мне не нравится имя “Харон”.
Еврепид: Да ну! Давно ли?
Афина: Оно мне никогда не нравилось из-за своей бессмысленности. Я разговаривала с моим дядюшкой Гадесом об этом день назад, и он мне предложил другое имя --- кличку его трехголового сторожевого пса.
Еврепид: О! Ты имеешь в виду “Цербер”?
Афина: Прикуси свой язык! “Цербер”... как же!
Еврепид: Эээ... Разве его зовут не так?
Афина: Так. Только если бы ты был римлянином! А я греческая богиня, он греческий сторожевой пёс и его имя -- Керберос. Керберос с первой буквой “К”.
Еврепид: Хорошо, хорошо не разбрасывай громы и молнии. Я принимаю твоё имя. Действительно оно приятно звучит. Прощай Харон и здравствуй Керберос.
Послесловие

Эта пьеса был написан в 1988 году, чтобы помочь читателям понять основные причины по которым протокол Керберос 4 был реализован именно так. И в течении многих лет это удавалось.

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

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

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

Второе большое отличие протокола то, что билет больше не шифруется пользовательским паролем когда он посылается от сервиса Керберос для kinit во время первоначального обмена билетами. Билет уже и так зашифрован секретным ключом TGS; более того в дальнейшем, когда он используется для получения других билетов, он посылается через сеть в незашифрованном виде. Значит нет причины по которой билет должен быть зашифрован ещё раз Hence, there is no reason why the ticket should be encrypted again пользовательским паролем. (Остаток ответа сервера Керберос пользователю, включая например пользовательскую копию сессионного ключа по прежнему, конечно, зашифрован пользовательским паролем. )

Похожие изменения были сделаны и в протоколе TGS; билеты возвращённые TGS также больше не шифруются ключом сервиса, так как билеты приложений уже зашифрованы их ключами. Так например пакет, который в Керберос V4 мог бы выглядеть так:

ОТВЕТ_KDC = {БИЛЕТ, клиент, сервис, K_сессии}K_пользователя
где “{X}K_Y” означает “X зашифрован ключом K_Y”, а
БИЛЕТ = {клиент, сервис, время_получения, время жизни,
K_сессии}K_сервиса
В пятой версии Керберос ОТВЕТ_KDC выглядит так:
ОТВЕТ_KDC = БИЛЕТ, {клиент, сервиса, K_сессии}K_пользователя
Конечно, в пятой версии появилось ещё много изменений. Пользователи теперь могут безопасно передавать их билеты на другие машины, так что они могут использоваться с другого сетевого адреса; в добавок пользователи могут также делегировать часть своих прав сервису, так, что он может играть роль посредника с поведением аналогичным пользовательскому. Кроме того можно заменить DES другим более надёжным алгоритмом шифрования, таким как triple-DES. Читатели которым интересны остальные отличия между четвёртой и пятой версиями протокола могут прочитать о них в The Evolution of the Kerberos Authentication System, написанной Cliff Neumann и Theodore Ts’o.

Я надеюсь вы получили удовольствие от этого небольшого введения в протокол Керберос. Желаю вам дальнейших открытий!

Теодор Тсо, февраль 1997.

Разрешается использование, копирование, модификация и распространение этого документа для любых целей и без оплаты, при условии что сохранения авторства и указания его в каждой копии, а также присутствия данных об авторстве и этого разрешения в сопровождающих документах. Запрещается использоваться имя M.I.T. в рекламе или других публикациях связанных с распространением без предварительного разрешения. M.I.T. не несёт ответственности за использование этого документа в любых целях. Документ поставляется “как есть” без всяких явных или неявных гарантий.

Для комментариев/предложений пишите: tytso@mit.edu

Apr 6   IT   kerberos   security

Перевод Designing an Authentication System: a Dialogue in Four Scenes

Надо сохронить, так как этот полезный текст остался только в Веб Архиве.

Copyright 1988, 1997 Массачусетский технологический институт. Все права защищены.

Билл Брант (Bill Bryant), февраль 1988.

Отредактировал и подготовил HTML вариант -- Теодор Тсо (Theodore Ts’o), Февраль, 1997. Также добавлено приложение описывающие изменения 5-й версии протокола Kerberos.

От переводчика

Перевод некоторых терминов требует отдельного пояснения:

Аутентификация (Authentication). Подтверждение того, что некая личность является именно той, за которую себя выдаёт. Очень часто аутентификацию путают или смешивают с авторизацией --- определением того имеет ли право определённый пользователь выполнять те или иные операции. Аутентификация всегда предшествует авторизации, так как последняя не имеет никакого смысла без предшествующей проверки подлинности пользователя. Чтобы избежать этой путаницы я, по возможности, старался избегать употребления этого слова и заменял его сочетаниями “удостоверение личности”, “подтверждение личности” и другими.

Система разделения времени (Timesharing system). Мощный компьютер с большим количеством подключённых пользовательских терминалов --- недорогих приборов, состоящих из клавиатуры, монитора и устройства связи с компьютером. Такие системы были единственными представителям компьютерного мира до появления персональных компьютеров.

Рабочая станция (Workstation). Общее название для компьютеров предназначенных для работы только одного человека, но несовместимых с IBM PC. Как правило на таких компьютерах установлена одна из версий ОС UNIX. Есть большой соблазн перевести этот термин просто, как “персональный компьютер”, но из уважения к старому доброму слову “workstation” я всё таки оставил непривычное для уха русскоязычного пользователя словосочетание “рабочая станция”, время от времени заменяя его там, где это не мешает пониманию, словами “рабочее место”.

Сервер (Server) и сервис (service). Слово “сервер” имеет в компьютерной литературе два смысла. С одной стороны это некий компьютер, который предоставляет свои ресурсы (процессор, память, другие устройства) другим компьютерам сети, а с другой часто сервером называют программу, которая выполняется на этом сервере. Так, часто можно услышать “веб-сервер”, “почтовый сервер” и тому подобные выражения. Очевидно, что на одном сервере может выполняться несколько программ, каждая из которых предоставляет какую-то определённую услугу. Например на одном единственном компьютере могут быть (и часто так оно и есть) запущены одновременно и почтовый сервер и веб-сервер и сервер передачи файлов ftp. Поэтому чтобы чётко понимать, когда речь идёт о компьютере, я употребляю слово “сервер”, а когда о запущенной на нём программе --- “сервис” (service, услуга). Надеюсь, что несколько корявое предложение “обратиться к почтовому сервису” не вызовет нареканий со стороны придирчивых читателей.
Сергей Долин (dsa@glug.org)

Предисловие

Эта небольшая пьеса представляет вымышленную историю и причины разработки системы аутентификации в открытых сетях, названную “Харон”. По мере развития, её главные герои -- Афина и Еврепид постепенно раскрывают проблемы безопасности возникающие в открытом сетевом окружении. Каждая проблема должна тем или иным способом решаться с помощью Харона, и поэтому проект также изменяется в течении всего действия пьесы. Афина и Еврепид не прекращают свою работу до завершения пьесы.

Когда они заканчивают проектирование, Афина изменяет её имя на “Kerberos,” --- имя, довольно случайно, выбранное для системы аутентификации, разработанной и реализованной в МИТ. Система “Kerberos”, описанная в пьесе чрезвычано напоминает систему Kerberos: An Authentication Service for Open Network Systems представленную на USENIX зимой 1988, в Далласе, штат Техас.

Содержание

Действующие лица
Действие I
Действие II
Действие III
Действие IV

Действующие лица

Афина -- начинающий и перспективный системный программист.
Еврепид -- опытный разработчик, который постоянно во всём видит только плохое.

Действие I

Небольшой кабинет без окон. Афина и Еврепид работают за соседними терминалами.

Афина: Да, что ты будешь делать! Эта наша система разделения времени совсем перестала шевелиться. Из-за того, что с ней сейчас работают все, кто только имеет к ней доступ я совсем не могу заниматься своим делом.
Еврепид: Ничем не могу помочь. Я только делаю свою работу.
Афина: А знаешь, что нужно сделать? Нам следует дать каждому собственную рабочую станцию, так, что бы не нужно было заботиться о разделении компьютерных тактов. А для соединения этих рабочих станций мы будем использовать сеть, так, чтобы люди могли общаться друг с другом.
Еврепид: Чудесно. Так, что всё, что нам нужно – пара тысяч рабочих станций?
Афина: Ну... около того.
Еврепид: Ты когда нибудь видела размер обычного жёсткого диска рабочей станции? Где ты найдешь столько места, чтобы разместить все программное обеспечение, которое ты имеешь на нашей системе с разделением времени?
Афина: Я уже придумала. Это очень просто. Мы можем хранить копии программ на нескольких машинах-серверах. В момент начала работы на рабочей станции она получит доступ к программам выполнив подключение к одному из серверов. Это позволит многим машинам использовать единственную копию программного обеспечения, и также решит проблему обновления программного обеспечения. Тебе не прийдётся устанавливать копию новой версии на каждую машиной. Достаточно просто изменить програмное обеспечение на сервере.
Еврепид: Не плохо. А что ты собираешься делать с личными файлами? В системах с разделяемым временем я могу получить доступ к моим файлам с любого терминала, который подключен к системе. Смогу ли я подойти к любой рабочей станции и автоматически получить свои файлы? Или мне прийдётся подобно пользователям ПК хранить свои файлы на дискете? Хочется надеться, что нет.
Афина: Мне кажется, ничто не мешает использовать какой нибудь компьютер в качестве хранилища для файлов. Да. Ты можешь воспользоваться любой рабочей станцией и получить свои файлы.
Еврепид: А как насчёт печати? Каждая машина должна иметь свой принтер? Признайся, чьи деньги ты решила растранжирить? А что будет с электронной почтой? Как ты собираешься доставлять почту к каждой из этих машин?
Афина: Ээээ... Ну, очевидно, нам не прийдётся давать каждому собственный принтер, мы могли бы иметь несколько машиных предназначенных для обслуживания печати. Ты посылаешь задание на этот сервер печати, и он его выполняет. Примерно также можно поступить и с почтой. Достаточно одной машины выделенной для пересылки почты. Если ты захочешь свою почту, ты просто подключаешься к почтовому серверу и от туда её забираешь.
Еврепид: Да, Тина, твоя система с персональными рабочими станциям выглядит неплохо. Знаешь, что я собираюсь сделать, как только получу подобную? Первым делом я узнаю твоё имя для входа в систему и сделаю, так, что моя машина думала, что я --- это ты. Затем я подключусь к почтовому серверу и прочитаю твою почту. Потом я подключусь к твоему файловому серверу и удалю твои файлы, и ...
Афина: Ты это сделаешь?
Еврепид: Без сомнения! Как все эти сетевые серверы смогут убедиться, что я -- это не ты?
Афина: Хех.. Я не знаю. Кажется, мне надо ещё подумать.
Еврепид: Да, похоже на то. Сообщи мне, когда что нибудь придумаешь.

Действие II

Кабинет Еврепида на утро следующего дня. Еврепид сидит за своим столом и читает почту. В дверь стучится Афина.

Афина: Ну, я сообразила как обезопасить открытое сетевое окружение так, чтобы такие бессовестные парни, как ты не могли использовать услуги сетевых серверов от имени других людей.
Еврепид: Ну и как? Присаживайся.
Афина садится.
Афина: Перед тем, как я начну, можно первым делом оговорить одно правило для нашего обсуждения?
Еврепид: Что за правило?
Афина: Будем полагать, что, когда я произношу нечто вроде “я хочу мою электронную почту и поэтому связываюсь с почтовым сервисом и прошу его переслать почту на мой компьютер” то на самом деле я не устанавливаю непосредственно контакт с сервисом. Для этого я пользуюсь программой для подключения к почтовому сервису и получения своей почты, Эта программа явяется КЛИЕНТОМ программы почтового сервиса.

Просто мне не хочется повторять “клиент делает то-то и то-то” каждый раз, когда я описываю обмен сообщениями между пользователем и сервисом. Я могу в этом случае просто сказать “я делаю то-то и то-то”, помня, конечно что все эти вещи за меня делает клиентская программа. Устраивает ли это тебя?

Еврепид: Будь уверен. Не вижу проблемы.
Афина: Хорошо. Если так, я начну с описания проблемы, которую я собираюсь решить. В условиях открытого сетевого окружения машины, которые пердоставляют услуги должны иметь возможность проверить что, люди которые запрашивают у них услуги являются именно теми за кого они себя выдают. Если я связываюсь с почтовым сервисом и прошу у него свою почту, программа должна иметь возможность проверить, что я являюсь именно Афиной, правильно?
Еврепид: Да.
Афина: Ты бы мог решить проблему самым простым способом, потребовав, чтобы почтовый сервис запрашивал пароль перед тем, как я смогу им пользоваться. Я докажу, что я тот, кем являюсь введя свой пароль.
Еврепид: Это, коненчно же, неуклюжое решение. В системе, подобной этой, каждый сервис должен знать твой пароль. Если в сети тысяча сервисов, то каждому сервису прийдётся знать тысячу паролей. Если ты пожелаешь изменить свой пароль, ты будешь вынужден установить контакт со всеми сервисами и уведомить их об этом изменении. Мне представляется, что твоя система не столь тупа.
Афина: Да моя система не такая дурацкая. Она работает примерно так: Не только люди имеют пароли, сервисы имеют пароли тоже. Каждый пользователь знает свой пароль и каждая сервисная программа знает свой пароль. И кроме того существует сервис аутентификации, который знает ВСЕ пароли -- каждый пользовательский пароль, и пароль каждого сервиса. Сервер аутентификации хранит все пароли в единственной, централизованной базе данных.
Еврепид: Ты придумал имя для этого сервиса аутентификации?
Афина: Я об этом ещё не думал. А у тебя есть какие-то идеи?
Еврепид: Как звали того парня который преправлял души умерших через Стикс?
Афина: Харон?
Еврепид: А! Я про него. От отказывался первозить через реку если ты не сможешь подтвердить свою личность.
Афина: Ты можешь далеко зайти, переписывая по новой греческую мифологию. Харона совсем не интереовала твоя личность. Ему было достаточно убедиться, что ты мёртв.
Еврепид: У тебя есть имя получше?
Пауза.
Афина: Нет, в самом деле.
Еврепид: Ну тогда давай назовём систему аутентификации “Харон”
Афина:
Ну ладно. Хотя мне кажется, что следует заняться описанием самой системы, да?

Предположим, что ты хочешь использовать почтовый сервис. В моей системе ты не сможешь использовать сервис если только... эээ... Харон сообщит ему, что ты именно тот, кем себя объявляешь. И ты не получишь разрешения использовать сервис пока не аутентифицируешь себя у Харона. В свою очередь, когда ты запрашиваешь аутентификацию у Харона, ты толжен сообщить ему имя сервиса, для которого просишь разрешения. Если ты хочешь разговаривать с почтовым сервисом, ты прежде должен договориться с Хароном.

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

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

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

Поэтому, вместо того, чтобы давать тебе пароль, Харон даёт тебе БИЛЕТ сервиса. Этот билет включает твоё пользовательское имени, которое ЗАШИФРОВАНО ИСПОЛЬЗУЯ ПАРОЛЬ ПОЧТОВОГО СЕРВИСА.

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

Сервис использует свой пароль, чтобы расшифровать билет и, если он будет расшифрован правильно, то сервис получит имя того пользователя, который Харон поместил в билет.

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

Что ты думаешь насчёт всего этого?

Еврепид: У меня осталось несколько вопросов.
Афина: Я так и думала. Ну-ну, давай.
Еврепид: Когда сервис расшифрует пароль, как он узнает, что сделал это правильно?
Афина: Я не знаю.
Еврепид: Вохможно, тебе следует включить в билет и имя сервиса? Тогда, после того, как билет будет расшифрован, отсутствие ошибок может быть проверено по тому оказалось ли внутри него это имя.
Афина:
По моему это неплохо. Итак билет выглядит примерно так:

(Она наспех черкает на клочке бумаги:)
БИЛЕТ – {имя пользователя:имя сервиса}
Еврепид: То есть билет включает только имя пользователя и сервиса?
Афина: ...зашифрованные паролем сервиса.
Еврепид: Я не думаю, что этой информации достаточно, чтобы сделать билет надёжным с точки зрения безопасности.
Афина: Что ты имеешь в виду?
Еврепид: Предположим, что ты запрашиваешь у Харона билет для почтового сервиса. Харон изготавливает такой билет и пишет на нём твоё имя “Тина”. Предположим, что я копирую твой билет в то время, как он перемещался мимо меня по пути через сеть от Харона до тебя. Предположим я зайду на свою незащищённую рабочую станцию, под твоим именем “Тина”. Программа почтового клиента на моей рабочей станции считает, что я это ты. От твоего имени она переправляет украденный билет почтовому сервису --- тот расшифровывает билет и видит, что он правильный, так как имя пользователя в билете совпадает с именем пользователя, который послал билет. Почтовый сервис даёт мне твою почту...
Афина: Ого! В этом нет ничего хорошего.
Еврепид:
Но мне кажется я знаю, как решить эту задачу. Или хотя бы найти частичное решение. Я думаю Харону следует включать несколько больше информации в билеты, которые он изготавливает: в добавок к имени пользователя, билет должен содержать СЕТЕВОЙ АДРЕС с которого пользователь запросил билет. Это даст тебе ещё один уровень безопасности.

Я проиллюстрирую. Предположим я украл твой билет теперь. Этот билет содержит твой сетевой адрес и этот адрес не совпадает с адресом моей машины. От твоего имени я отправляю похищенный билет почтовому сервису. Программа сервиса извлекает имя пользователя и сетевой адрес из билета и пытается сопоставить их с пользовательским именем и сетевым адресом того пользователя, который послала билет. Хотя имя и совпадает, но сетевой адрес – нет, и сервис отказывается принять билет, потому, что он, очевидно, был украден.

Афина: Браво! Браво! Хотела бы я додуматься до этого сама.
Еврепид: Ну для этого я здесь и работаю.
Афина:
Итак после пересмотра эскиз билета выглядит так:

Она делает набросок мелом на демонстрационной доске:

БИЛЕТ – {имя пользователя:сетевой адрес:имя сервиса}
Афина: Ну теперь я просто в восторге. Давай быстрей сделаем такую систему и посмотрим, как она работает!
Еврепид: Не так быстро. У меня есть ещё несколько замечаний по твоему предложению.
Афина: Хорошо. ( Афина наклоняется вперёд в своём кресле. ) Давай... Выбрасывай свои козыри.
Еврепид: Пока, что всё выглядит так, как будто мне придётся получать новый билет каждый раз когда я хочу получить доступ к сервису. Если у меня восьмичасовой рабочий день, я скорее всего захочу проверять свою почту более одного раза, и что же я буду запрашивать билет и вводить пароль каждый раз, когда я хочу это сделать? Если я прав, то мне твоя система не нравится.
Афина: Ээээ... Ну... я не вижу причин почему бы билеты не могут бытьь повторно использованы. Если ты получил билет для почтового сервиса, то логично ожидать, что ты будешь иметь возможность использовать их вновь и вновь. Например когда почтовая программа пользователя делает запрос сервису от твоего имени она может посылать копию твоего, ранее полученного, билета.
Еврепид: Это уже лучше. Но я всё ещё вижу проблемы. По-видимому, ты предполагаешь, что я должен общаться с Хароном каждый раз, когда я хочу использовать сервис для которого у меня нет билета. Я вошёл в систему и хочу получить доступ к своим файлам. Я отправляю запрос к Харону для правильного билета и это значит, что я должен ввести свой пароль. Затем я хочу прочитать свою почту. Ещё одно обращение к Харону --- и я должен вновь вводить свой пароль. Теперь предположим я хочу послать своё почтовое сообщение на печать. Опять запрос Харону и... Ну, ты представил себе как будет выглядеть работа?
Афина: Ууу... Да, представила.
Еврепид: И, если это для тебя недостаточно, рассмотри и такой случай: мне кажется, что когда ты представляешь себя Харону, ты посылаешь твой секретный пароль по сети открытым текстом. Умные люди вроде тебя могут легко отследить трафик в сети и украсть копии паролей всех пользователей. Если я получу пароль, я могу использовать любой сервис от твоего имени. Афина вздыхает.
Афина: Это серьёзные проблемы. Кажется мне нужно ещё раз вернуться на своё рабочее место.

Действие III

На следующее утро Афина встречает Еврепида в буфете и похлопывает его по плечу в то время, как он наливает чашку кофе.
Оба поворачиваются к кофеварке.

Афина: У меня появилась новая версия Харона, которая решает нашу задачу.
Еврепид: Действительно? Быстро ты.
Афина: Ты знаешь, эти размышления над на проблемами не давали мне покоя всю ночь.
Еврепид: Должно быть это была твоя совесть. Тебе не кажется, что нам лучше продолжить беседу в кабинете?
Афина: Почему бы и нет?
Оба идут в рабочий кабинет.
Афина: Я вновь начну с условий задачи, но теперь я переиначу их так, чтобы они превратились в требования предъявляемые к системе.
Афина откашливается.
Афина: Первое требование: пользователи должны вводить свои пароли только однажды, в начале работы на рабочей станции. Это требование подразумевает, что тебе нет необходимости вводить пароль каждый раз, когда ты нуждаешься в новом билете для доступа к сервису. Второе требование: пароли не следует посылать по сети в открытом незашифрованном виде.
Еврепид: Всё так.
Афина:
Я начну с первого требования --- тебе придётся вводить пароль только один раз. Я удовлетворила это требование изобретением нового сервиса. Он называется “сервис предоставления билетов” (ticket-granting service,TGS), сервис, который предоставляет Хароновские билеты пользователям которые уже однажды аутентифицировались (доказали, что являются теми за кого себя выдают) у Харона. Этот сервис можно использовать имея билет только для него.

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

Система аутентификации сейчас работает следующим образом: ты включаешь свою рабочую станцию и используешь программу названную kinit, чтобы установить контакт с сервисом Харона. Затем удостоверяешь свою личность и kinit получает билет, позволяющий получать другие билеты (ticket-granting ticket --- TGT).

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

Еврепид: Должен ли я получать новый TGT каждый раз, когда мне нужен новый сетевой сервис?
Афина: Нет. Вспомни, что в прошлый раз мы сошлись на том, что билеты могут использоваться повторно. Получив однажды TGT тебк не нужно делать это ещё раз. Ты используешь один и тот же TGT, чтобы получать другие нужные тебе билеты.
Еврепид: Ладно, это всё имеет смысл. И с того момента, как ты можешь использовать билеты повторно, однажды полученный с помощью TGT билет для какого-то определённого сервиса, позволяет тебе больше не запрашивать билет для этого же сервиса.
Афина: Элегантно? Не правда ли?
Еврепид: Да. Я бы не отказался от подобной штуки. Сразу, после того, как только тебе станет не нужно посылать твой пароль отрытым текстом по сети, для получения TGT.
Афина:
Как я и говорила, я решила и эту проблему тоже. Дело в том, что когда я говорю --- “запросить у Харона TGT”, мои слова звучат так как будто-бы ты должен посылать свой пароль открытым текстом по сети сервису Харона. Но это совершенно не обязательно.

Вот, что происходит на самом деле. Когда ты используешь программу kinit чтобы получить TGT, то она не отправляет твой пароль сервису Харона, а посылает только твоё имя.

Еврепид: Хорошо.
Афина:
Харон использует имя пользователя, чтобы найти его пароль в своей базе данных, а затем подготавливает пакет данных, который включает и TGT. Перед тем, как послать этот пакет тебе, Харон использует твой пароль, чтобы зашифровать содержимое пакета.

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

Как это для твоего изощрённого ума?

Еврепид: Я не знаю... Теперь моя очередь задуматься. Честно говоря, я думаю, что система, которую ты только что описала будет работать более, чем хорошо. Твоя система требует от меня аутентифицироваться только однажды. После этого Харон может отправлять мне билеты для разных сервисов. без вмешательства с моей стороны. Безупречно. Безупречно в этом отношении. Но есть что-то в проекте, что беспокоит меня. И это “что-то” связано с тем фактом, что билеты могут повторно использоваться. Я осознаю, что они должны быть такими, но по своей природе, это свойство таит опасность.
Афина: Что ты имеешь в виду?
Еврепид:
Посмотри с такой точки зрения. Предположим ты используешь компьютер, к которому имеют доступ другие пользователи. Во время своей работы ты получил билет почтового сервиса, сервиса печати и билет для файлового сервиса. Предположим ты неосторожно оставила эти билеты на компьютере после того, как покинула своё рабочее место.

А теперь предположим я сяду за этот же компьютер и найду эти билеты. Я стремлюсь причинять неприятности, так, что я заставлю машину считать, что я -- это ты. Так как билет был получен от твоего имени, я могу использовать почтовую программу для доступа к твоей почте, могу читать и удалять твои файлы, могу отправить на печать такие задания, что тебе будет очень трудно заплатить по счету. И всё только потому, что твои билеты случайно остались лежать доступными кому угодно.

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

Афина:
Но это легко исправить. Мы просто напишем программу, которая будет разрушать билеты после каждого окончания работы. Ты не сможешь использовать билеты, которые были разрушены.

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

У меня есть программа, которая отслеживает весь траффик в сети и копирует билеты в то время, пока они передаются по сети. Предположим я выбрал жертвой тебя. Я жду когда ты начнешь работу на своей машине, запускаю свою программу и копирую все твои билеты.

Я дожидаюсь пока ты покинешь своё рабочее место и выключисшь компьютер. Затем изменяю сетевой адрес так, чтобы он совпадал с адресом твоей машины, за которой ты работал, когда получал скопированные мной билеты. Затем я заставляю мою машину поверить, что я -- это ты. У меня есть твои билеты, твое пользовательское имя и правильный сетевой адрес. Я могу вновь посылать эти билеты и использовать сетевые сервисы под твоим именем.

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

Афина: Я поняла что ты хочешь сказать! Билеты не могут быть действующими бесконечно, потому, что тогда они представляют огромный риск для безопасности. Мы должны ограничить время в течении, которого билета может использоваться, например дать каждому билету срок, после которого он устаревает.
Еврепид: Именно. Я думаю, что каждый билет нуждается в двух дополнительных информационных полях: времени жизни, которое указывает период в течении, которого билет остаётся действующим и время в которое Харон его выслал. Поэтому билет будет выглядеть примерно так:
Еврепид подходит к демонстрационной доске и чертит такой рисунок:

БИЛЕТ {имя пользователя:адрес:имя сервиса:время жизни:время получения}
Еврепид: Теперь, когда сервис расшифровывает билет, он сравнивает пользовательское имя и адрес в билете с пользовательским именем и сетевым адресом того, кто послал билет, затем проверяет не устарел ли этот билет используя информацию о времени получения и времени действия.
Афина: Всё правильно. И какое же время жизни должен иметь типичный билет для сервиса?
Еврепид: Я не знаю. Возможно длина типичного рабочего дня. Скажем, восемь часов.
Афина: Тогда, если я нахожусь на рабочем месте более, чем восемь часов, все билеты устареют. Включая TGT. Поэтому мне прийдётся удостоверять свою личность у Харона каждые восемь часов.
Еврепид: Но это же не безпричинно, не так ли?
Афина: Понимаю, что нет. Итак мы договрились -- билеты устаревают через восемь часов. Теперь у меня есть вопрос для тебя. Предположим я скопировал ТВОИ билеты из сети --
Еврепид: ( с весёлой ухмылкой ) Ах, Тина! Ты ведь не стала бы делать этого, не так ли?
Афина:
Это только в качестве аргумента. Я скопировала твои билеты. Теперь я жду когда ты выйдешь из системы. Ну, например, тебе назначен визит к врачу, и поэтому ты закончил свой сеанс после пары часов работы. Ты тёртый калач и уничтожил копии билетов перед отключением.

Но я похитила твои билеты и они действуют ещё на протяжении шести часов. Это даст мне достаточное количство времени для грабежа твоих файлов и печати тысячи копий чего угодно под твоим именем.

Как видишь, отметка о времени жизни работает хорошо в том случае когда похититель билета решает использовать билет после того он устарел. Если же использовать билет до того, как это произойдёт...

Еврепид: Ну,... Конечно, ты права.
Афина: Мне кажется, что у нас большие проблемы. (Вздыхает.)
Пауза.
Еврепид: Похоже на то, что у тебя опять будет бессоная ночь. Хочешь ещё кофе?
Афина: Почему бы нет.
Действие IV

Следующее утро в кабинете Еврепида. Афина стучится в дверь.

Еврепид: У тебя круги под глазами.
Афина: Ну, понимаешь. Опять не спала всю ночь.
Еврепид: Решила ли ты проблему повторного использования билетов?
Афина: Я думаю, да.
Еврепид: Ну, присаживайся.
Она садится.
Афина: Как обычно, я чувствую, что должна вновь сформулировать проблему. Билеты могут повторно использоваться в течении определённого времени, скажем восемь часов. Если кто нибудь украдёт твои билеты и и решит использовать их перед тем, как они устареют мы не можем сделать ничего, что бы остановить злоумышленника.
Еврепид: Да. Проблема в этом.
Афина: Мы можем её решить, если разработаем систему с билетами, которые не могут быть использованы повторно.
Еврепид: Но ведь тогда тебе прийдётся получить новый билет каждый раз когда ты захочешь использвать сетевой сервис.
Афина:
Правильно. Это неуклюжое решение. (Пауза.) Э... Я могу продолжать? Да? (Она ненадолго задумалась.)

Итак, я собираюсь вновь сформулировать проблему, в этот раз в форме набора условий. Сетевой сервис должен иметь возможность удостовериться, что личность, использующая билет, та же самая, для которой это билет был создан.

Я прослежу весь процесс аутентификации вновь и постараюсь найти правильный способ проиллюстрировать мое решение этой проблемы.

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

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

Наша система аутентификации в настоящий момент основывается на следующих проверках:

Может ли сервис расшифровать пароль?
Истекло ли время жизни?
Совпадает ли имя и сетевой адрес рабочей станции указанной в билете с именем и сетевым адресом того человека, который послал билет?
Что гарантируют эти проверки? Первая проверка подтверждает, что билет был получен именно от Харона. Если билет не может быть расшифрован, он не был получен от Харона, который зашифровал бы билет паролем сервиса, так как Харон и сервис -- единственные, кто знают пароль сервиса. Если билет расшифровывается удачно, сервис точно знает, что он получен от Харона. Эта проверка защищает от возможности подделать билет.

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

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

Если имя и адрес всё таки совпадают, что доказывает эта проверка? Ничего. Прохвост может украсть билеты из сети, изменить свой адрес и имя пользователя, и использовать ресурсы других пользователей. Как я сказала вчера, билеты могут повторно использоваться пока не устареют. Они могут это делать потому, что сервис не может определить, что пользователь пославший билет действительно законный его владелец.

Сервис не может определить это потому, что сам он не обменивается никаким секретным паролем непосредственно с пользователем. Посмотрим на это с другой стороны. Если я стою на страже в Эльсиноре, ну, ты помнишь та крепость в Гамлете, и ожидаю, что ты сменишь меня, я не должен позволять тебе занять своё место, если только ты не предоставишь правильный пароль. Это как раз тот момент, где мы обмениваемся паролем. При этом ничто не исключает возможности, что это пароль выдумал и сообщил каждому часовому, кто-то другой.

Поэтому я думала всю прошлую ночь, почему бы Харону не изготовить пароль для законного владельца билета, которым он может обменяться с сервисом? Харон даёт копию этого ключа сессии сервису, и копию пользователю. Когда сервис получает билет от пользователя, он может использовать ключ чтобы провереть подлинность личности пользователя.

Еврепид: Секунду. Как Харон собирается передать обоим сторонам ключ сессии?
Афина: Владелец билета получает ключ сессии, как часть ответа от Харона. Примерно так:
Она рисует следующую схему на доске:

ОТВЕТ ХАРОНА – [ключ сессии|билет]
Свою копию сессионного ключа сервис получает внутри билета; после того, как расшифрует его. Поэтому билет выглядит так:

БИЛЕТ – {ключ сессии:имя пользователя:адрес:имя сервиса:время жизни:время
получения}
Когда ты хочешь получить услуги от сервиса, клиентская программа начинает создавать то, что я решила называю АУТЕНТИФИКАТОР. Аутентификатор включает твоё имя и сетевой адрес твоей рабочей станции. Клиент шифрует эту информацию с помощью ключа сессии -- копии сессионного ключа, который он получил во то время, когда запросил билет.

АУТЕНТИФИКАТОР – {имя пользователя:адрес} зашифровванные с
помощью ключа сессии.
После создания аутентификатора, клиент посылает его и билет сервису. Однако сервис не может расшифровать аутентификатор, потому, что он не имеет сессинного ключа. Этот ключ находится внутри билета, поэтому сервис вначале расшифровывает его.

После расшифровки билета, сервис наконец получает следующую информацию:

Время жизни и время получения;
Имя владельца билета;
сетевой адрес владельца билета;
ключ сессии.
Сервис, так же как и раньше, проверяет, не истёк ли срок действия билета. И, если всё в порядке, вслед за этим получает ключ сессии, чтобы расшифровать аутентификатор. Если процесс дешифрования аутентификатора не вызывает проблем, сервис заканчивает работу проверкой, того, что имя и адрес, содержащиеся внутри билета совпадают с именем и адресом пользователя, которые содержатся внутри аутентификатора. Если всё совпадает, сервис определил, что отправитель билета является его законным владельцем.

Афина замолкает, прокашливается, отпивает немножко кофе.

Мне кажется сессионный ключ и аутентификатор хорошо справляется с проблемой повторного использования.

Еврепид: Возможно. Но я не понимаю... То есть, чтобы взломать систему я должен иметь правильный аутентификатор для сервиса?
Афина: Нет. Ты должен иметь аутентификатор И билет для сервиса. Аутентификатор не имеет смысла без билета, потому, что сервис не сможет расшифровать аутентификатор без того, чтобы вначале получить соответствующий ключ сессии, а его он не сможет получить без расшифровки билета.
Еврепид: Хорошо. Я это понял. Но не хочешь ли ты сказать, что когда клиентская программа общается с сервисом, она посылает одновременно с билетом, соответствующий аутентификатор?
Афина: Да. Именно это я пыталась сказать.
Еврепид: Если так происходит в действительности, то, что мешает мне похитить билет и аутентификатор одновременно? Я уверен, что смогу написать программу, которая легко справится с этой работой. Если я получу билет и его аутентификатор, нет сомнений в том, что смогу использовать их обои так долго, как долго не устареет билет. Мне нужно только изменить адрес рабочей станции и имя пользователя. Так?
Афина: ( Кусая свои губы) Так. Как безнадёжно.
Еврепид: Стоп, стоп, стоп! Это не такая уж большая проблема. Билеты могут повторно использоваться пока они не устареют, но это не значит, что такой же способностью должны обладать аутентификаторы. Предположим мы разработаем систему так, что аутентификаторы могут использоваться только однажды. Поможет ли это нам хоть чем нибудь?
Афина:
Ну, возможно. Давай посмотрим: клиентская программ создаёт аутентификатор, затем посылает его вместе с билетом сервису. Ты копируешь их в то время пока они проносятся мимо твоей рабочей станции на сервер. Но оригинальные билет аутентефикатор достигнут сервер до того, как ты сможешь послать свои копии. Если аутентификатор может быть использован, только один раз твоя копия больше не годится, и попытка повторно использовать билет окончится нечем.

Так, что это поможет. Поэтому всё, что мы должны придумать, так это способ сделать аутентификатор одноразовым.

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

Сервис получает билет и аутентификатор и начинает заниматься своими обычными делами. После расшифровки аутентификатора он проверяет его время жизни и отметку о времени получения. Если аутентфикатор ещё не устарел и всё остальное в порядке, сервис считает, что ты подтвердил свою личность.

Apr 6   IT   kerberos   security

DKIM=temperror

Recently I have checked my messages headers of the mail that comes from the andreybondarenko.com MX and found that Google shows that my DKIM signature is invalid:

Authentication-Results: mx.google.com; dkim=temperror (no key for
 signature) header.i=@andreybondarenko.com;

In the spam score section:

DKIM_SIGNED,T_DKIM_INVALID

However the header itself is present:

DKIM-Filter: OpenDKIM Filter v2.10.3 andreybondrenko.com CE25780BAC
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=andreybondarenko.com; s=default; t=1483634085;
        bh=w00tuUhwty0/5n/YHiopiY3PpnqKT5BLK9l6TkDNUUk=;
        h=Subject:From:Reply-To:To:Date:From;
        b=J5qB5RF9lrOho1wBpLyLi5a6CwIHZK1sugCr2wpwnPKwEg76RFv2/y8xaiwquqftX
         VhTJH9NLJXcPdu8k8/zN/sc8P1RksNR9EvDw6k2YNEKoeMsKMGgyMC4kAAhcT31IgX
         eqnIqWxhVTVdjRqrqzNPn0wuBbGJgO2bwmFcVsy8=

I have found that it’s quite common configuration error of the OpenDKIM, the selector you choose to store key can be chosen randomly, but the TXT record should match /etc/opendkim.conf. In my case:

##  Defines the name of the selector to be used when signing messages.
Selector   default

But the DNS record:

[user@andreybondarenko ~]$ dig TXT mail._domainkey.andreybondarenko.com

;; ANSWER SECTION:
mail._domainkey.andreybondarenko.com. 1800 IN TXT "v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCdGRWtWPPZVIg0fy7Pr0+rsBsoL6Imt1GBE/QRd3X5Izv1iAJFUsOtea
f9TI9EO/YFwoLLahzuoZM1oUU4ED3fHlItEnqXCKQhX8Zripi7gfIO+DRFEhGuQtG6OIuA6+c3ivao7DTPk/IFqY7MG5M3wMvAfV+
eIBf1VjmajSwe3wIDAQAB"

Changing ‘Selector’ to ‘mail’ and restating opendkim (it’s faster then change DNS):

Authentication-Results: mx.google.com; dkim=pass
 header.i=@andreybondarenko.com;

In the spam score section:

DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU
2017   dkim   linux   mail   security
2016   google   IT   security   web

Debugging Kerberos

If you need to debug Kerberos, check the time synchronization at the first place. In about 50% cases it is it.

  1. the ntpd (or chrony) should be presented in the process list
  2. they should really be configured correctly
  3. in case of the virtual host crony is preferable, with the ntpd time skew is possible

Really nice crony/ntpd comparative chart: https://chrony.tuxfamily.org/comparison.html , “Summary” section is complete.

2016   chrony   kerberos   linux   ntpd   security

Today I’ve learned...

My colleagues from the linux.org.ru board have found out one small flaw, so everyone including me stared to dance around PGP/GPG. So far I have found that among my systems:

  • Linux works as it should: two mouse clicks and you are ready. Covers 100% of my work mail, 75% of my personal mail.
  • Mac OS Sierra is not ready: GPG Suite has no support for the mail.app yet, just a workaround (yet). Hopefully we will see the solution in days.
  • iOS has only S/MIME out of the box, but GPG/PGP solution is ugly (due to restrictions).

And I don’t like install software that does not come with the operating system, for a reason :-)

2016   internet   ios   IT   linux   mac   mail   security