Анатолий

Защита изображений от хотлитка

location ~ .(gif|png|jpeg|jpg|svg)$ {
     valid_referers none blocked ~.google. ~.bing. ~.yahoo. ~.yandex. yourdomain.com;
     if ($invalid_referer) {
        return   403;
    }
}

Вариантов много, но если будет совсем грустно, то можно воспользоваться CDN.

1. При включенном в nginx:
add_header X-XSS-Protection "1; mode=block;";
в консоли хрома, при запуске phpmyadmin получаю:

Error parsing header X-XSS-Protection: 1; mode=block, 1; mode=block;: expected semicolon at character position 13. The default protections will be applied.

Как видно защита применилась дважды, т.е. эта защита phpMyAdmin уже встроена, проверяем (домен заменил на фейковый):
а) Сайт mysite.com

HTTP/2 200
server: nginx
date: Thu, 07 Feb 2019 15:36:15 GMT
content-type: text/html; charset=UTF-8
vary: Accept-Encoding
link: <https://mysite.com/wp-json/>; rel="https://api.w.org/"
expires: Thu, 01 Jan 1970 00:00:01 GMT
cache-control: no-cache
strict-transport-security: max-age=63072000
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
x-xss-protection: 1; mode=block;

б) mysite.com/phpmyadmin/index.php

HTTP/2 200
server: nginx
date: Thu, 07 Feb 2019 15:38:07 GMT
content-type: text/html; charset=utf-8
vary: Accept-Encoding
set-cookie: pma_lang=en; expires=Sat, 09-Mar-2019 15:38:07 GMT; Max-Age=2592000; path=/phpmyadmin/; secure; HttpOnly
set-cookie: phpMyAdmin=bt28h1km40qsqau05np1a2qt6k; path=/phpmyadmin/; secure; HttpOnly
x-ob_mode: 1
x-frame-options: DENY
referrer-policy: no-referrer
content-security-policy: default-src 'self' ;script-src 'self' 'unsafe-inline' 'unsafe-eval' ;style-src 'self' 'unsafe-inline' ;img-src 'self' data:  *.tile.openstreetmap.org;object-src 'none';
x-content-security-policy: default-src 'self' ;options inline-script eval-script;referrer no-referrer;img-src 'self' data:  *.tile.openstreetmap.org;object-src 'none';
x-webkit-csp: default-src 'self' ;script-src 'self'  'unsafe-inline' 'unsafe-eval';referrer no-referrer;style-src 'self' 'unsafe-inline' ;img-src 'self' data:  *.tile.openstreetmap.org;object-src 'none';
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
x-permitted-cross-domain-policies: none
x-robots-tag: noindex, nofollow
expires: Thu, 01 Jan 1970 00:00:01 GMT
cache-control: no-cache
pragma: no-cache
last-modified: Thu, 07 Feb 2019 15:38:07 +0000
vary: Accept-Encoding
strict-transport-security: max-age=63072000
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
x-xss-protection: 1; mode=block;

видим, что строка x-xss-protection: 1; mode=block используется дважды, поэтому и ошибка
Решение: phpmyadmin/libraries/classes/Header.php удаляем строки 599-601.


2) После того как изменил настройки phpmyadmin:

location ^~ /phpmyadmin {
        alias /var/www/phpmyadmin/;
        location ~ \.php$ {
                fastcgi_pass backend7;
                fastcgi_index index.php;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $request_filename;
                fastcgi_ignore_client_abort off;
        }

        location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
                access_log off;
                log_not_found off;
                expires 1M;
        }
}

phpMyAdmin нормально загружается, не смотря на то, что настройки уровнем выше не изменились, но теперь ему без разницы на js, все работает

apt update
apt upgrade
reboot

и вроде снова заработало, в конфигах ничего не менял, причина ошибки не ясна, и возможно завтра появится, вопрос пока закрываю

Решил углубится в тему, вот результаты:

Директива open_file_cache применяется для кеширования информации о статических файлах: js, css, jpeg, html,..
Если файл не существует, или не прав на чтение, то эта информация также может хранится в кеше.
По умолчанию: open_file_cache off;

Пример с описанием:

# Информация о 1000 файлов, может хранится в кеше. Если не было активности к файлу в течение 5 мин, то информация о нем удаляется из кеша
open_file_cache max=1000 inactive=5m;  

# Активностью считается обращение к файлу хотя бы 2 раза. В кеш они также попадают, если было хотя бы 2 обращения к файлу
open_file_cache_min_uses 2;             

# Вся информация о файлах в кеше обновляться раз в 1 минуту
open_file_cache_valid 1m;               

# Сохранять ли информацию об ошибках, например, если файла, к которому вы обратились - нет, то это будет тоже в кеше, информация тоже обновится через 1 мин
open_file_cache_errors on;

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

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

При работе с файловой системой NFS, рекомендуется не включать open_file_cache, так как информация о файлах может не обновляться даже после open_file_cache_valid.

Написал, а то может кому интересно будет или я забуду :)

Вопрос можно закрыть не знаю на сколько он решен, но сейчас вроде все работает.
Что сделано:
1. разбил css файл на 3 части - работала только 1 часть, при подключении остальных переставало.
2. разбил на 6 частей, чтобы понять, где же собака порылась, но почему-то все заработало.
3. собрал опять все в один файл, сейчас все работает.

Ничего из кода не менял и не удалял. Я в шоке, что это за магия.

Удалил все сертификаты, удалил все настройки certbot-auto и certbot.
Установил certbot заного, теперь все работает нормально, на русские буквы не жалуется, и что интересно ничего теперь дописывать не нужно и никакие служебные папки не создаются. В общим, все как раньше, только теперь запускаю certbot и все.
Спасибо chupasaurus, что подсказал, что certbot-auto это лишь скрипт обновления certbot, т.е. его я больше ставить не буду, для обновления вполне достаточно:
apt update
apt upgrade

пока тему прикрываю, вопросов как бы сейчас нет, но не знаю появится ли эта проблема еще или нет
странно конечно это все

Уже почти сдался, и оппачки нашел решение https://stackoverflow.com/questions/28490391/how-t...

Решение выглядит так:
location /bb {
alias /var/www/mysite;
location ~ ^/bb/(.+\.php)$ {
fastcgi_pass backend;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $request_filename;
include fastcgi_params;
}
}