Дмитрий Филимонов

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

Но можно усугубить: если вы используйте conntrack в FORWARD вместе с правилом

iptables -I FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

то потенциально возможен случай, когда соединение установится до загрузки iptables, а позже, когда iptables загрузит правила, соединение пойдет по этому правилу. Но ведь это редкость, когда кто-то использует conntrack в FORWARD, да еще и с пропуском всех установленных/связанных соединений. Обычно такое актуально для INPUT у серверов, но уж точно никак для FORWARD.

Так вот, если у вас все правильно, вы не используйте conntrack с этой конструкцией для FORWARD, по умолчанию политика для FORWARD является DROP, и вы там строго контролируете, что куда в какие стороны по сетям, то нет повода для паники. Все равно все неправомерные соединения дропнутся после инициализации iptables, а время до загрузки iptables вряд ли критично, хотя лучше грузить его пораньше, конечно. Причем это некритично для systemd, например, ибо он параллельный и асинхронный (или для многих других init-систем).

Других случаев я не придумал.

В качестве вывода: опуская паранойю и ESTABLISHED/RELATED ACCEPT в FORWARD, атака нереальна.

На данный момент есть открытый пулреквест даже. Можете попробовать оттуда поставить Bower-Ignore-Dependencies.

Как принятно на русских ресурсах не отвечать на вопрос, а давай советы :) Но в этот раз совет важный и даже юзабельный.

Хранить файл в БД - плохо. Может показаться, что это удобно (например, только бэкап БД спасет всех).

Но на самом деле:

• Растет размер БД. Что делать, если он станет запредельным из-за сохраненных там файлов?
  
• Возрастает нагрузка на диски/оперативную память сервера БД.
  
• Офигенно растут логи, а это дополнительная нагрузка на диск.
  
• Замедлится передача данных от MySQL, т.к. там, во-первых, может быть сеть со своей пропускной способностью, а во-вторых, MySQL будет передавать большой файл маленькими частями (снова оверхед на I/O диска и сети).
  
• То, что можно отдать обычным nginx'ом как статику, отдается через костыли.
  

Хранить блобы можно, конечно, но рано или поздно сделаете БД узким местом. Если и хранить блобы, то очень-очень маленькие, но и даже это спорно и зависит от задачи.

Поэтому отказывайтесь от идеи.

Просто в этих пдфках содержаться персональные данные пользователей и нельзя чтобы они имели прямые ссылки(доступ к ним открывается только после авторизации)

Причем здесь БД? Храните файл в том месте, которое не сервится наружу. А доступ до файла регулируйте при запросе. То есть у вас есть какой-то url для файла, там содержится его id, например. Вы проводите авторизацию: если можно забрать файл, спрашиваете у БД ссылку, где он находится на диске (а это место наружу не видно), и отдаете файл подобным образом, как делаете сейчас. НО, если ожидаются крупные файлы, читать файл нужно по частям, иначе можете закончить оперативу. В фреймворках обычно есть для этого инструменты, кстати.

Конечно, люди разные, но я не могу. Лучше это время тратить на личные проекты (опенсорс) и на развитие (новые языки, улучшать фундаментальные знания), либо еще на какое-то хобби (у меня это музыка, например). В долгосрочной перспективе это принесет больше пользы, а качество жизни будет выше. Работать на двух работах, совмещать работу/учебу - все это либо для очень-очень организованных людей (феноменально организованных, которые могут жить четко по плану каждый день), либо для тех, кто особо-то и не вникает (а это напрямую влияет на качество скилла). Кроме того, как не пытался, предел продуктивной работы в сутки - это порядка 6 часов. Все остальное не только не приносит удовольствия, так еще и по качеству получается хуже. Лучше делать одну задачу, "быть медленнее", но делать ее реально круто.

Если к API нужно ходить с фронтенда, то можно на вашем nginx запроксировать запросы на сторонний ресурс. В ряде случаев понадобится настройка чего-нибудь (nginx/php) на удаленной стороне (если, например, нужно передавать хидеры специализированные, например http-x-real-ip). Ситуация вполне штатная, обычная. Если нужно ходить с бэкенда, то так и напрямую ходите (curl или что там у вас). Ситуация тоже обычная.

Но я так понимаю, что главный вопрос в том, не плохо ли тут использовать vpn? Здесь нужно знать, какой у вас vpn. Самый печальный vpn - это pptp, т.к. небезопасен и будет дольше реконнектиться в случае потери соединения (да и в сравнении, например, с openvpn он даже в конфигурировании неудобен). Уверен, что у вас не pptp, это просто к слову (никто в здравом уме не будет поднимать pptp между сервер-сервер). Грубо говоря, все остальное (openvpn, ipsec и т.п.) можно использовать: проверено временем, стабильно. Касательно оверхеда: в 99% некритично. Например, если это openvpn l3 по udp, то оверхед на каждый пакет по размеру будет ~70 байт (где-то 20 ip, 8 udp, порядка 40-50 на tls)... примерно. И хотя если посчитать этот размер относительно маленьких пакетов, может выйти больше самого пакета (смотря как считать еще), это ни о чем не говорит: при достаточном канале (а у вас, раз речь идет про сервера, должно быть все хорошо) это некритично. В плане времени сколько-то уйдет на шифрование, но опять же для api это некритично (и надо учитывать, что соединение-то постоянное, то есть временной оверхед, например, на tcp/http и тем более https выше, а оно повсеместно, никто не парится). Для собственного успокоения можете замерить ширину канала (nc), потыкать в api (hping).

Кстати, если везде линуха, не нужна защита, нет по пути страшных фаерволов, видимость на уровне l3 есть, то лучший вариант, как по мне, - это линуксовый ipip, либо gre: минимальный оверхед, крайне легко настраивается (описано в lartc), не нужно дополнительное ПО. Не знаю, насколько это популярно, но я бы использовал такой "vpn", если возможно/нужно.

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

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

Если есть тоннель, то это значит, либо L2, либо L3 канал уже есть, в обоих случаях имеется IP-адрес с двух сторон. Поэтому вы уже ходите в обе стороны. Дальнейшая настройка зависит от того, что хотите делать. В типичном случае: настроить фаерволл, чтобы он разрешал доступ до нужного ПО/порта, поднять это самое ПО. Поэтому не просто можно, а из коробки можно.

Список всех включенных модулей можно узнать с помощью apachectl.

apachectl -M

Напишите обертку вокруг этого.

Либо если используется mod_php, то есть функция apache_get_modules() в PHP.

Совсем дефолтовая задача, использовать json.loads().
https://docs.python.org/3/library/json.html

#!/usr/bin/env python

import json

path = 'example.json'

with open(path, 'r') as f:
    data = json.loads(f.read())
    for i in data['employees']['employee']:
        if i['id'] == '3':
            print(i['photo'])

Правила выглядит правильно... Но такое поведение очень похоже на rp_filter.

Попробуйте его отключить:

sysctl net.ipv4.conf.default.rp_filter=0
sysctl net.ipv4.conf.all.rp_filter=0

UPD
Немного погрузился в эту ситуацию, тут есть фича. Если убрать SNAT, но при этом сделать ping 8.8.8.8 -I eth1, то при включенном rp_filter оно работает. Дело в том, что в таблицах роутинга у вас исходящий адрес для 8.8.8.8 из другой сети/интерфейса (т.к. есть дефолтовый или иной подходящий для 8.8.8.8 маршрут), поэтому любая программа (сокет), будь то ping или браузер, выберет дефолтовый нужный исходящий адрес по таблицам роутинга (но не по меткам там). А когда iptables маркирует, и пакет попадает в другой шлюз/интерфейс согласно метке, срабатывает rp_filter, ведь адрес источника не принадлежит сети на исходящем интерфейсе. Поэтому, если задача направить конкретные адреса в конкретный шлюз, то лучше создать много правил ip rule и не маркировать трафик, избавиться от SNAT. Если так нельзя, то да, отключать rp_filter.

-A FORWARD -j REJECT

Вот этим правилом вы весь FORWARD-трафик режете. Вам нужно разрешить FORWARD для сети 192.168.0.0/16 в обе стороны.

Например, так:

-A FORWARD -s 192.168.0.0/16 -i ИНТЕРФЕЙС_В_192.168.0.0/16 -j ACCEPT
-A FORWARD -d 192.168.0.0/16 -o ИНТЕРФЕЙС_В_192.168.0.0/16 -j ACCEPT