Re: systemd

[Oleksandr Gavenko]

On 2015-11-22, Artem Chuprina wrote:

>  OG>  * 1 TCP соединение, вместо нескольких. Избегаем задержет на TCP 
> рукопожатие,
>  OG>не знаю, может есть также плюс и для SSL/TLS. Итого страничики через
>  OG>мобильное GPRS будут заметно быстрее открываться.
>
> По сравнению с чем он дает преимущество?  С HTTP/1.1, в котором это
> ввели, и который все давно уже умеют?

Таки да:

https://tools.ietf.org/html/rfc7230

Хотя

  6.  Connection Management

   HTTP messaging is independent of the underlying transport- or
   session-layer connection protocol(s).

все же:

   HTTP implementations are expected to engage in connection management,
   which includes maintaining the state of current connections,
   establishing a new connection or reusing an existing connection,
   processing messages received on a connection, detecting connection
   failures, and closing each connection.  Most clients maintain
   multiple connections in parallel, including more than one connection
   per server endpoint.  Most servers are designed to maintain thousands
   of concurrent connections, while controlling request queues to enable
   fair use and detect denial-of-service attacks.

Это если говорить о количестве соединений к одному серверу.

А то я забыл точный текст книги по поводу ограничения на 2 соединения к 1
хосту, и со стандартом не сверялся, в книге так:

  http://http2-explained.haxx.se/content/en/part3.html#34-sharding

  Initially the HTTP 1.1 specification stated that a client was allowed to use
  maximum of two TCP connections for each host. So, in order to not violate the
  spec clever sites simply invented new host names and – voilá - you could get
  more connections to your site and decreased page load times.

  Over time, that limitation was removed and today clients easily use 6-8
  connections per host name but they still have a limit so sites continue to use
  this technique to bump the number of connections.

  Recent stats from httparchive.org show that the top 300K URLs in the world
  need on average 40(!) TCP connections to display the site, and the trend says
  this is still increasing slowly over time.



Если же речь о HTTP pipelining - то я об этом ничего не знаю, кроме того что
никто из массовых WEB клиентов не использует эту возможность.



Попробовал открыть сайт с высокоскоростным соединением, Firefox Web Developer
показал:

  5'400 ms на connection
  40 ms на waiting

последующие страницы имели:

  0 ms на connection

На GPRS соединении у меня connection занимало 5-20 сек и каждое живое TCP
соединение делало связь очень напряжной, вплоть до того что браузер
отказывался загружать ресурсы по таймауту (это когда рядом открыты вкладки с
Ajax долбилками, которые так любят встраивать в комерческие сайты).

В общем влияние числа соединений на качество/скорость WEB есть, особенно для
мобильной связи (сейчас в сети - подавляющее большинство клиентов - мобильны).

Я не нахожу сравнения экспертов - как HTTP 2 на практике решает проблемы.

К сожалению на https://www.ietf.org не смог найти информацию о рабочем
комитете по HTTP 2 и их целях.

Есть теория что WebSocket лучше ложатся в HTTP 2:

  
http://stackoverflow.com/questions/28582935/does-http-2-make-websockets-obsolete
  https://bloggeek.me/websockets-http2/

Эта штука нужна социалкам, общалкам.

-- 
Best regards!

Re: Как работает локальный DNS кеш?

[Oleksandr Gavenko]

On 2015-11-23, Eugene Berdnikov wrote:

>> которые считывает GLib. Как я понял GLib также умеет общаться с DNS серверами
>> (так как это делает dig, есть ощущение что nslookup использует
>> getaddrinfo(3)).
>
>  В "ltrace nslookup localhost |& fgrep addr" ничего не ловится,
>  значит, getaddrinfo(3) там не используется. Было бы странно для
>  писателей bind9 использовать такие вызовы, ибо их модули
>  извлекают из пакетов гораздо больше информации, которую через
>  API для getaddrinfo получить никак невозможно. С другой стороны,
>  от gethostbyname/getaddrinfo невозможно оторвать просмотр hosts
>  и прочей описанной в nsswitch.conf хни, а dig/nslookup делают
>  исключительно обращения к dns, и ничего более. Поэтому nslookup
>  просто не может работать через getaddrinfo(3).
>
Ясно, я забыл что nslookup из проекта BIND.

>> У меня только сомнения по поводу наличия кода в GLibc работающего с DNS
>> серверами на подобии как это делает dig.
>
>  В чём подобие-то? В glibc есть лишь резолвер, а dig имеет гораздо более
>  широкий функционал.

Я не знал в том что glibc содержит частичную реализацию
протокола (как Вы сказали резолвер):

  https://www.ietf.org/rfc/rfc1035.txt

Было удивительно что glibc не просто прослойка к ядру, но также выполняет
прикладные сервисы как разрешение имен.

Я наивно полагал что этим занимается ядро или сторонняя служба...

-- 
Best regards!

Re: Как работает локальный DNS кеш?

[Oleksandr Gavenko]

On 2015-11-22, Artem Chuprina wrote:

> resolvconf у меня живет весьма неплохо, но я не пользуюсь connman/nm.
> Пользуюсь wicd, и про него знаю, что он сам эту информацию не трогает,
> ею занимается dhclient (или кто там у тебя работает с DHCP) в связке с
> resolvconf.
>
> И кэшем работает dnsmasq.  На домашнем сервере - bind9, и ему приходится
> вручную добавлять скрипт, звездочка в документации неспроста.  А с
> dnsmasq работает из коробки.

В общем прояснилось, еще почитал:

  GETADDRINFO(3)
  `info libc "Name Service Switch"'
  http://www.tldp.org/LDP/nag2/x-087-2-resolv.library.html

Итого getaddrinfo(3), gethostbyname(3) встроены в GLib.

Есть ряд файлов настроек:

  /etc/host.conf
  /etc/hosts
  /etc/resolv.conf
  /etc/nsswitch.conf

которые считывает GLib. Как я понял GLib также умеет общаться с DNS серверами
(так как это делает dig, есть ощущение что nslookup использует
getaddrinfo(3)).

Кеширование DNS запросов может быть сделано либо в GLib, либо в приложении,
либо прописыванием localhost в /etc/resolv.conf и поднятием локального DNS
сервера кеша.

dhclient по успешному выполнению вызывает тригеры, пример доступной информации
в дригере в файле:

  /etc/dhcp/dhclient-enter-hooks.d/debug

for prefix in '' 'cur_' 'new_' 'old_'; do
for basevar in reason interface medium alias_ip_address \
   ...
   domain_name domain_search domain_name_servers \
   ...
   dhcp6_domain_search dhcp6_name_servers ; do
var="${prefix}${basevar}"
eval "content=\$$var"
echo "$var='${content}'" >> /tmp/dhclient-script.debug

resolvconf поставляет свой хук /etc/dhcp/dhclient-enter-hooks.d/resolvconf и
затем сообщает кеширующему DNS серверу о новых настройках.

У меня только сомнения по поводу наличия кода в GLibc работающего с DNS
серверами на подобии как это делает dig.

-- 
Best regards!

Re: Как работает локальный DNS кеш?

[Eugene Berdnikov]

On Mon, Nov 23, 2015 at 08:13:12PM +0200, Oleksandr Gavenko wrote:
> В общем прояснилось, еще почитал:
> 
>   GETADDRINFO(3)
>   `info libc "Name Service Switch"'
>   http://www.tldp.org/LDP/nag2/x-087-2-resolv.library.html
> 
> Итого getaddrinfo(3), gethostbyname(3) встроены в GLib.

 Не в Glib, а в glibc. Под "glib" обычно понимают прикладную библиотеку
 Гнома, а glibc есть базовая библиотека всего линуксового рантайма,
 включающая интерфейсы к вызовам ядра.

> которые считывает GLib. Как я понял GLib также умеет общаться с DNS серверами
> (так как это делает dig, есть ощущение что nslookup использует
> getaddrinfo(3)).

 В "ltrace nslookup localhost |& fgrep addr" ничего не ловится,
 значит, getaddrinfo(3) там не используется. Было бы странно для
 писателей bind9 использовать такие вызовы, ибо их модули
 извлекают из пакетов гораздо больше информации, которую через
 API для getaddrinfo получить никак невозможно. С другой стороны,
 от gethostbyname/getaddrinfo невозможно оторвать просмотр hosts
 и прочей описанной в nsswitch.conf хни, а dig/nslookup делают
 исключительно обращения к dns, и ничего более. Поэтому nslookup
 просто не может работать через getaddrinfo(3).

> У меня только сомнения по поводу наличия кода в GLibc работающего с DNS
> серверами на подобии как это делает dig.

 В чём подобие-то? В glibc есть лишь резолвер, а dig имеет гораздо более
 широкий функционал.
-- 
 Eugene Berdnikov

Re: вопрос по .xsession-errors

[Oleksandr Gavenko]

On 2015-11-23, Melleus wrote:

> 1. имеем файл ~/.xsession-errors
>
> 2. в него кто-то раз в несколько секунд с завидным постоянством пишет
> следующее:
>
> sh: 1: iwconfig: not found
>
> Обнаружил случайно, решил заглянуть, почему такой большой размер у
> файла. А там - это.
>
> Вопрос - как разобраться, что происходит? 

  $ sudo apt-get install auditd

  $ sudo auditctl -w ~/.xsession-errors -p w

Ждать и затем анализировать /var/log/audit/audit.log, или:

  $ sudo ausearch -f ~/.xsession-errors

В конце:

  $ sudo auditctl -W ~/.xsession-errors
  $ sudo service auditd stop
  $ sudo update-rc.d auditd disable

Я попробовал:

  $ sudo auditctl -w /tmp -p w

При старте xterm в логе есть строчка:

  type=SYSCALL msg=audit(1448308853.684:34): arch=c03e syscall=87
  success=yes exit=0 a0=24218a0 a1=7ffe55d12880 a2=7ffe55d12880
  a3=7ffe55d12640 items=2 ppid=3522 pid=12342 auid=4294967295 uid=1000
  gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000
  tty=(none) ses=4294967295 comm="xterm" exe="/usr/bin/xterm" key=(null)

Тут у нас pid, ppid, uid, gid, а также:

  comm="xterm" exe="/usr/bin/xterm"

что очень удобно для быстро исчезающих скриптов.

> Извиняюсь за шум, методом исключения выяснил, что это awesome
> виноват.

Я полагаю таким способом Вы бы прямо получили ответ без "метода исключения".

Чесно говоря до Вашего поста я о auditctl ничего не знал, но недавно отлаживал
CLASSPATH в Tomcat и там оказалось классным:

  $ inotifywait -m -r /tmp

Но inotify не рассказывает какие pid задействованы. inotify можно узнать какие
файлы трогают, но этого не достаточно в Вашем случае.

Для себя поискал как решается задача, что б знать на будущее, auditd -
дополнительно говорит кто трогает.

Там еще есть какие то штуки:

  https://en.wikipedia.org/wiki/File_Alteration_Monitor

-- 
Best regards!

Re: создание репозитория (вопрос по файлу Contents-amd64.gz)

[Victor Wagner]

On Mon, 23 Nov 2015 12:53:36 +0300
Andrew Kirsanov  wrote:

> У меня есть репозиторий на двух дисках (ОС Астра линукс - debian
> based).
> 
> Хочу соединить их в один репозиторий, чтобы разместить в сети.

1. По-моему, проще оставить это двумя разными репозиториями и прописать
в sources.list на тех машинах, которые будут этими репозиториями
пользоваться, две строчки.

Тогда можно раздавать репозитории прямо с примонтирвоанных образов
дистрибутивных дисков

> 
> Делаю так.
> Собрал два пула с разных дисков в одно место.
> Файлы в папке dists генерю самостоятельно командой apt-ftparchive.

2. Можно взять какой-нибудь другой инструмент, генерирующий Packages и
Contents, но умеющий pool-based репозитории, например reprepro.

> Но на выходе у меня получается список без относительны

[DONE] wml://security/2015/dsa-3401.wml

[Lev Lamberov]

Cheers!
Lev Lamberov
--- english/security/2015/dsa-3401.wml	2015-11-23 10:57:41.0 +0500
+++ russian/security/2015/dsa-3401.wml	2015-11-23 14:35:12.336338636 +0500
@@ -1,20 +1,22 @@
-security update
+#use wml::debian::translation-check translation="1.1" maintainer="Lev Lamberov"
+обновление безопасности
 
-It was discovered that rebinding a receiver of a direct method handle
-may allow a protected method to be accessed.
+Было обнаружено, что повторное связывание получателя обработчика прямого метода
+может привести к открытию доступа к защищённому методу.
 
-For the oldstable distribution (wheezy), this problem has been fixed
-in version 7u91-2.6.3-1~deb7u1.
+В предыдущем стабильном выпуске (wheezy) эта проблема была исправлена
+в версии 7u91-2.6.3-1~deb7u1.
 
-For the stable distribution (jessie), this problem has been fixed in
-version 7u91-2.6.3-1~deb8u1.
+В стабильном выпуске (jessie) эта проблема была исправлена в
+версии 7u91-2.6.3-1~deb8u1.
 
-For the unstable distribution (sid), this problem has been fixed in
-version 7u91-2.6.3-1.
+В нестабильном выпуске (sid) эта проблема была исправлена в
+версии 7u91-2.6.3-1.
 
-We recommend that you upgrade your openjdk-7 packages.
+Рекомендуется обновить пакеты openjdk-7.
 
 
 # do not modify the following line
 #include "$(ENGLISHDIR)/security/2015/dsa-3401.data"
 # $Id: dsa-3401.wml,v 1.1 2015/11/23 05:57:41 kaare Exp $
+

вопрос по .xsession-errors

[Melleus]

Прошу подсказки в такой ситуации:

1. имеем файл ~/.xsession-errors

2. в него кто-то раз в несколько секунд с завидным постоянством пишет
следующее:

sh: 1: iwconfig: not found

3. с сетью (и вообще с системой в целом) видимых проблем нет, все
работает.

Обнаружил случайно, решил заглянуть, почему такой большой размер у
файла. А там - это.

Вопрос - как разобраться, что происходит? 

Спасибо заранее.

ЗЫ. Комп используется как декстоп (писательство, я не настоящий
айтишник). Сижу на стабильной ветке, десктопом awesome заведует, сетью -
network manager.

Re: вопрос по .xsession-errors

[Melleus]

Извиняюсь за шум, методом исключения выяснил, что это awesome
виноват.

Re: вопрос по .xsession-errors

[Eugene Berdnikov]

On Mon, Nov 23, 2015 at 02:18:26PM +0200, Melleus wrote:
> Прошу подсказки в такой ситуации:
> 
> 1. имеем файл ~/.xsession-errors
> 
> 2. в него кто-то раз в несколько секунд с завидным постоянством пишет
> следующее:
> 
> sh: 1: iwconfig: not found
> 
> 3. с сетью (и вообще с системой в целом) видимых проблем нет, все
> работает.
> 
> Обнаружил случайно, решил заглянуть, почему такой большой размер у
> файла. А там - это.
> 
> Вопрос - как разобраться, что происходит? 

 Проще всего сделать исполняемый файлик iwconfig с командочкой вроде
 ps auxfww | mail -s iwconfig root
 Можете подставить свой e-mail по вкусу. Есть и другие решения.
-- 
 Eugene Berdnikov

создание репозитория (вопрос по файлу Contents-amd64.gz)

[Andrew Kirsanov]

У меня есть репозиторий на двух дисках (ОС Астра линукс - debian based).

Хочу соединить их в один репозиторий, чтобы разместить в сети.

Делаю так.
Собрал два пула с разных дисков в одно место.
Файлы в папке dists генерю самостоятельно командой apt-ftparchive.

Но на выходе у меня получается список без относительных путей.

Например:

В оригинальном файле Contents-amd64.gz
*etc/ald/ald.confnon-free/admin/ald-client*
У меня получается просто имя
etc/ald/ald.conf ald-client

Как сделать аналогичный список?

А может я вообще не так все делаю?

-- 
Andrew Kirsanov

Re: вопрос по .xsession-errors

[Melleus]

Eugene Berdnikov  writes:

> On Mon, Nov 23, 2015 at 02:18:26PM +0200, Melleus wrote:
>> Прошу подсказки в такой ситуации:
>> 
>> 1. имеем файл ~/.xsession-errors
>> 
>> 2. в него кто-то раз в несколько секунд с завидным постоянством пишет
>> следующее:
>> 
>> sh: 1: iwconfig: not found
>> 
>> 3. с сетью (и вообще с системой в целом) видимых проблем нет, все
>> работает.
>> 
>> Обнаружил случайно, решил заглянуть, почему такой большой размер у
>> файла. А там - это.
>> 
>> Вопрос - как разобраться, что происходит? 
>
>  Проще всего сделать исполняемый файлик iwconfig с командочкой вроде
>  ps auxfww | mail -s iwconfig root
>  Можете подставить свой e-mail по вкусу. Есть и другие решения.

Все гениальное - просто. И тот, кто дернет за ниточку, спалит себя сам
:) Спасибо за идею!

Re: вопрос по .xsession-errors

[Melleus]

Oleksandr Gavenko  writes:

> On 2015-11-23, Oleksandr Gavenko wrote:
>
> Это не поможет топикстартеру, но интересно было разобраться, а то смешно,
> когда то на работе в цикле грепали ps:
>
>   while true;
> ps -e | grep COND
> sleep 1
>   done

Спасибо. Это целая пушка для моего воробья. Сначала исключением угадал с
первого раза. А потом еще и закладку сделал. Закладка сработала и
указала на awesome. А анализ конфига привел к библиотеке obvious, автор
которой и дергал неосторожно iwconfig (пока поставил на него линк в
~/bin в качестве костыля). В общем-то изменения формата конфигурационных
файлов с каждой версией awesome как-бы намекают на некоторую сырость
продукта. И, вместе с этим, лучшей альтернативы пока не вижу. И не
очень-то хочу, чтобы в стабильную ветку приползло обновление. Когда все
уже настроено под себя...

Re: proftpd + inetd + ssl/tls и другие вопросы.

[Tim Sattarov]

On 23/11/15 07:30 PM, Oleksandr Gavenko wrote:


   bash# lftp ftp://user@vps
   Password:
   lftp user@vps:~> ls
   ls: Fatal error: Certificate verification: Not trusted
   lftp user@vps:~> exit

тут бы я посмотрел на ftp:ssl-* значения
curl попробовать с -k

и смотреть как работает SSL соединение с помощью openssl

openssl s_client -connect vps:990

Re: proftpd + inetd + ssl/tls и другие вопросы.

[Tim Sattarov]

On 23/11/15 07:30 PM, Oleksandr Gavenko wrote:

Выяснил что plain ftp передает пароль в открытом виде в момент авторизации.

Есть https://ru.wikipedia.org/wiki/FTPS в разных версиях / режимах работы.

Не могу вьехать что делать что бы proftpd + inetd работал безопасно.



а SFTP или Rsync over SSH не нравится ?

Re: proftpd + inetd + ssl/tls и другие вопросы.

[Tim Sattarov]

On 23/11/15 07:30 PM, Oleksandr Gavenko wrote:


   bash# lftp ftp://user@vps
   Password:
   lftp user@vps:~> ls
   ls: Fatal error: Certificate verification: Not trusted
   lftp user@vps:~> exit

тут бы я посмотрел на ftp:ssl-* значения
curl попробовать с -k

и смотреть как работает SSL соединение с помощью openssl

openssl s_client -connect vps:990

Re: proftpd + inetd + ssl/tls и другие вопросы.

[Artem Chuprina]

Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Tue, 24 Nov 2015 
02:30:58 +0200:

 OG> Выяснил что plain ftp передает пароль в открытом виде в момент авторизации.

 OG> Есть https://ru.wikipedia.org/wiki/FTPS в разных версиях / режимах работы.

 OG> Не могу вьехать что делать что бы proftpd + inetd работал безопасно.

 OG> В общем на сервере выполнил:

 OG>   $ sudo proftpd-gencert

 OG> /etc/proftpd/proftpd.conf::

 OG>   Include /etc/proftpd/tls.conf

 OG> /etc/proftpd/tls.conf::

 OG>   TLSEngine   on
 OG>   TLSLog  /var/log/proftpd/tls.log
 OG>   TLSProtocol SSLv23

По нынешним временам SSL v2 и v3 считается за "шифрование отсутствует".
В смысле, дыры и их эксплойты в этих версиях протокола известны.

 OG>   TLSRSACertificateFile   /etc/ssl/certs/proftpd.crt
 OG>   TLSRSACertificateKeyFile/etc/ssl/private/proftpd.key
 OG>   TLSOptions  NoCertRequest EnableDiags
 OG>   TLSVerifyClient off
 OG>   TLSRequired on

 OG> Пробую:

 OG>   bash# lftp ftp://user@vps
 OG>   Password:
 OG>   lftp user@vps:~> ls
 OG>   ls: Fatal error: Certificate verification: Not trusted
 OG>   lftp user@vps:~> exit

 OG>   bash# lftp -e 'set ssl:verify-certificate no' ftp://user@vps
 OG>   Password:
 OG>   lftp user@vps:~> ls
 OG>   drwxr-xr-x   5 user user 4096 Nov 22 18:04 devel
 OG>   drwxr-xr-x   2 user user 4096 Oct 10 16:14 tmp

 OG> Обычная команда `ftp` из `/usr/bin/netkit-ftp` не поддерживает SSL:

 OG>   bash# ftp -n vps
 OG>   Connected to vps.
 OG>   220 ProFTPD 1.3.5 Server (Debian) [149.202.132.30]
 ftp>> ls
 OG>   550 SSL/TLS required on the control channel
 OG>   ftp: bind: Address already in use
 ftp>> user user
 OG>   ^C
 OG>   421 Service not available, remote server has closed connection
 ftp>> exit

 OG> `curl` тоже работает::

 OG>   $ curl --ftp-ssl -k --netrc ftp://user@vps/.bashrc

 OG> Нужно ли в inetd.conf использовать ftps или ftp:

 OG>   ftpstream  tcp nowait  root /usr/sbin/tcpd /usr/sbin/proftpd 
  
 OG>   ftpsstream  tcp nowait  root /usr/sbin/tcpd /usr/sbin/proftpd

 OG> У меня на ftps ошибки:

 OG>   bash# curl --ftp-ssl -k --netrc ftps://user@vps/.bashrc
 OG>   curl: (35) gnutls_handshake() failed: An unexpected TLS packet was 
received.

 OG>   bash# lftp ftps://user@vps
 OG>   lftp user@vps:~> ls
 OG>   ls: Fatal error: gnutls_handshake: An unexpected TLS packet was received.

 OG> Такое ощущение что для ftps:// используется другой протокол, чем на ftp:// 
с
 OG> включенным SSL.

Да.  ftps начинается с SSL/TLS handshake, и уже только после того, как
защищенное соединение установилось, начинается диалог по протоколу FTP.
В случае с ftp сначала начинается диалог по FTP, внутри него выдается
просьба поднять TLS, и после того, как он поднят, продолжается диалог по
FTP.

 OG> Как правильно запретить общение открытым текстом и настроить SSL/TLS в 
proftpd?

По идее, при настройке TLSRequired on разницы в безопасности быть не
должно - FTP не поддерживает вроде бы pipelining, на USER сервер выдаст
вон то, что он выдает команде ftp, и до пароля дело не дойдет.

 OG> Далее вопрос как в Debian сделать публичный ключ proftpd доверенным на
 OG> клиентах?

 OG> Я пробовал как:

 OG>   $ sudo mkdir /usr/share/ca-certificates/vps
 OG>   $ sudo scp user@vps:/etc/ssl/certs/proftpd.crt 
/usr/share/ca-certificates/vps/proftpd.crt
 OG>   $ sudo dpkg-reconfigure ca-certificates
 OG>   $ sudo update-ca-certificates --fresh

 OG> Но curl и lftp игнорируют Дебиановские соглашения о сертификатах. Или я
 OG> неверно готовлю. При том proftpd.crt виден в конце:

Второе.

Тут, вероятно, для начала нужен некоторый ликбез.

Клиенты доверяют сертификату сервера, если этот сертификат подписан
доверенным центром сертификации.  Вот то самое "ca" в ca-certificates.
Certification Authority.  У CA тоже есть сертификат, и подпись на
сертификате сервера проверяется об этот сертификат (там содержится
открытый ключ подписи).

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

Чтобы нормально работало, надо сделать честный сертификат CA,
распространить его по клиентам, в норме - установить в набор доверенных
корневых (это то, что ты пытался сделать с сертификатом сервера),
сделать честный серверный сертификат и подписать его ключом CA.

Или купить серверный сертификат у какого-нибудь известного CA, про
которого большинство клиентов знает из коробки.  Это минус необходимость
устанавливать свой сертификат CA на клиентов - довольно сложная операция
для юзера на винде (вероятно, разная для разных версий винды),
работоспособная не в каждом андроиде, и 

proftpd + inetd + ssl/tls и другие вопросы.

[Oleksandr Gavenko]

Выяснил что plain ftp передает пароль в открытом виде в момент авторизации.

Есть https://ru.wikipedia.org/wiki/FTPS в разных версиях / режимах работы.

Не могу вьехать что делать что бы proftpd + inetd работал безопасно.

В общем на сервере выполнил:

  $ sudo proftpd-gencert

/etc/proftpd/proftpd.conf::

  Include /etc/proftpd/tls.conf

/etc/proftpd/tls.conf::

  TLSEngine   on
  TLSLog  /var/log/proftpd/tls.log
  TLSProtocol SSLv23

  TLSRSACertificateFile   /etc/ssl/certs/proftpd.crt
  TLSRSACertificateKeyFile/etc/ssl/private/proftpd.key
  TLSOptions  NoCertRequest EnableDiags
  TLSVerifyClient off
  TLSRequired on

Пробую:

  bash# lftp ftp://user@vps
  Password:
  lftp user@vps:~> ls
  ls: Fatal error: Certificate verification: Not trusted
  lftp user@vps:~> exit

  bash# lftp -e 'set ssl:verify-certificate no' ftp://user@vps
  Password:
  lftp user@vps:~> ls
  drwxr-xr-x   5 user user 4096 Nov 22 18:04 devel
  drwxr-xr-x   2 user user 4096 Oct 10 16:14 tmp

Обычная команда `ftp` из `/usr/bin/netkit-ftp` не поддерживает SSL:

  bash# ftp -n vps
  Connected to vps.
  220 ProFTPD 1.3.5 Server (Debian) [149.202.132.30]
  ftp> ls
  550 SSL/TLS required on the control channel
  ftp: bind: Address already in use
  ftp> user user
  ^C
  421 Service not available, remote server has closed connection
  ftp> exit

`curl` тоже работает::

  $ curl --ftp-ssl -k --netrc ftp://user@vps/.bashrc

Нужно ли в inetd.conf использовать ftps или ftp:

  ftpstream  tcp nowait  root /usr/sbin/tcpd /usr/sbin/proftpd  
 
  ftpsstream  tcp nowait  root /usr/sbin/tcpd /usr/sbin/proftpd

У меня на ftps ошибки:

  bash# curl --ftp-ssl -k --netrc ftps://user@vps/.bashrc
  curl: (35) gnutls_handshake() failed: An unexpected TLS packet was received.

  bash# lftp ftps://user@vps
  lftp user@vps:~> ls
  ls: Fatal error: gnutls_handshake: An unexpected TLS packet was received.

Такое ощущение что для ftps:// используется другой протокол, чем на ftp:// с
включенным SSL.

Как правильно запретить общение открытым текстом и настроить SSL/TLS в proftpd?

Далее вопрос как в Debian сделать публичный ключ proftpd доверенным на
клиентах?

Я пробовал как:

  $ sudo mkdir /usr/share/ca-certificates/vps
  $ sudo scp user@vps:/etc/ssl/certs/proftpd.crt 
/usr/share/ca-certificates/vps/proftpd.crt
  $ sudo dpkg-reconfigure ca-certificates
  $ sudo update-ca-certificates --fresh

Но curl и lftp игнорируют Дебиановские соглашения о сертификатах. Или я
неверно готовлю. При том proftpd.crt виден в конце:

  /etc/ssl/certs/ca-certificates.crt

Также если кормить напрямую:

  bash# curl -v --ftp-ssl --cacert /usr/share/ca-certificates/vps/proftpd.crt 
--netrc ftp://user@vps/.bashrc
  *   Trying 149.202.132.30...
  * Connected to vps (149.202.132.30) port 21 (#0)
  < 220 ProFTPD 1.3.5 Server (Debian) [149.202.132.30]
  > AUTH SSL
  < 234 AUTH SSL successful
  * found 1 certificates in /usr/share/ca-certificates/vps/proftpd.crt
  * found 728 certificates in /etc/ssl/certs
  * ALPN, offering http/1.1
  * SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
  * server certificate verification failed. CAfile: 
/usr/share/ca-certificates/vps/proftpd.crt CRLfile: none
  * Closing connection 0
  curl: (60) server certificate verification failed. CAfile: 
/usr/share/ca-certificates/vps/proftpd.crt CRLfile: none
  More details here: http://curl.haxx.se/docs/sslcerts.html

  curl performs SSL certificate verification by default, using a "bundle"
   of Certificate Authority (CA) public keys (CA certs). If the default
   bundle file isn't adequate, you can specify an alternate file
   using the --cacert option.
  If this HTTPS server uses a certificate signed by a CA represented in
   the bundle, the certificate verification probably failed due to a
   problem with the certificate (it might be expired, or the name might
   not match the domain name in the URL).
  If you'd like to turn off curl's verification of the certificate, use
   the -k (or --insecure) option.

-- 
Best regards!

Re: Как работает локальный DNS кеш?

[Eugene Berdnikov]

On Mon, Nov 23, 2015 at 09:44:17PM +0200, Oleksandr Gavenko wrote:
> Было удивительно что glibc не просто прослойка к ядру, но также выполняет
> прикладные сервисы как разрешение имен.

 В libc традиционно есть масса функций, никак не завязанных на вызовы ядра.
 Например, обработка строк: sscanf, sprintf, strchr, strtok, index и т.д.

> Я наивно полагал что этим занимается ядро или сторонняя служба...

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

Re: вопрос по .xsession-errors

[Oleksandr Gavenko]

On 2015-11-23, Oleksandr Gavenko wrote:

> Я попробовал:
>
>   $ sudo auditctl -w /tmp -p w
>
> При старте xterm в логе есть строчка:
>
>   type=SYSCALL msg=audit(1448308853.684:34): arch=c03e syscall=87
>   success=yes exit=0 a0=24218a0 a1=7ffe55d12880 a2=7ffe55d12880
>   a3=7ffe55d12640 items=2 ppid=3522 pid=12342 auid=4294967295 uid=1000
>   gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000
>   tty=(none) ses=4294967295 comm="xterm" exe="/usr/bin/xterm" key=(null)
>
> Тут у нас pid, ppid, uid, gid, а также:
>
>   comm="xterm" exe="/usr/bin/xterm"
>
> что очень удобно для быстро исчезающих скриптов.

Я боялся что не будет имени исполняемого файла.

Есть lastcomm из пакета acct (который также запускает сервис):

  bash# lastcomm 
  lastcomm   user pts/3  0.00 secs Mon Nov 23 22:38
  sh user pts/8  0.00 secs Mon Nov 23 22:37
  awkuser pts/8  0.00 secs Mon Nov 23 22:37
  seduser pts/8  0.00 secs Mon Nov 23 22:37
  manuser pts/8  0.01 secs Mon Nov 23 22:37

Согласно ACCT(5):

   If the kernel is built with the process accounting option enabled
   (CONFIG_BSD_PROCESS_ACCT), then calling acct(2) starts process
   accounting, for example:

   acct("/var/log/pacct");

/var/log/pacct - бинарный файл, lastcomm помагает его читать.

Мне очень жаль что нет полного пути к команде и нет опций запуска и нет PWD.
Эта информация очень бы помогла в отладке.

Можно попробовать стартовать пользователькую сесию с

  $ cat ~/.xinitrc
  ...
  strace -e execve -o ~/strace.log -f LASTCOMMAND

Будет вылазить:

  bash# strace -e execve -f sh -c "/bin/echo ok"
  execve("/bin/sh", ["sh", "-c", "/bin/echo ok"], [/* 59 vars */]) = 0
  Process 14651 attached
  [pid 14651] execve("/bin/echo", ["/bin/echo", "ok"], [/* 59 vars */]) = 0
  ok
  [pid 14651] +++ exited with 0 +++
  --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=14651, si_uid=1000, 
si_status=0, si_utime=0, si_stime=0} ---
  +++ exited with 0 +++

Там пытаться воспроизвести проблемную ситуацию.

Текущий каталог мониторить по:

  $ strace -e chdir,execve -f xterm

Далее нашел:

  $ sudo forkstat

  23:06:33 exec  15004 /bin/bash -c  exec xterm -e bash -i
  23:06:33 exec  15004 xterm -e bash -i
  23:06:33 fork  15004 parent  xterm -e bash -i
  23:06:33 fork  15005 child   xterm -e bash -i
  23:06:33 exec  15005 bash -i
  23:06:33 fork  15005 parent  bash -i
  23:06:33 fork  15006 child   bash -i
  23:06:33 fork  15006 parent  bash -i
  23:06:33 fork  15007 child   bash -i
  23:06:33 exec  15007 dircolors -b /home/user/.dircolors
  23:06:33 exit  15007  00.001 dircolors -b /home/user/.dircolors
  23:06:33 exit  15006  00.001 bash -i
  23:06:33 fork  15005 parent  bash -i
  23:06:33 fork  15008 child   bash -i
  23:06:33 fork  15008 parent  bash -i
  23:06:33 fork  15009 child   bash -i
  23:06:33 exec  15009 ls /etc/bash_completion.d
  23:06:33 exit  15009  00.002 ls /etc/bash_completion.d
  ...

Это не поможет топикстартеру, но интересно было разобраться, а то смешно,
когда то на работе в цикле грепали ps:

  while true;
ps -e | grep COND
sleep 1
  done

-- 
Best regards!