В тази статия ще разгледаме процеса на организиране и конфигуриране на прост интернет шлюз, базиран на CentOS 7.x. Този шлюз ще позволи на потребителите от локалната мрежа да имат достъп до Интернет, както и достъп до сървъри или компютри във вътрешната мрежа отвън. За да организираме маршрутизиране и пренасочване на пакети, ще използваме NAT технологията, базирана на защитната стена на iptables. Ние също така обмисляме как да поддържаме и анализираме регистрационните файлове на връзките към интернет шлюза, когато външни потребители имат достъп до локалната мрежа.
Съдържание:
- Диаграма на локалната мрежа с шлюз за достъп до Интернет, NAT
- Конфигуриране на Source NAT: LAN достъп
- Конфигурирайте Destination NAT и пренасочване към порта: достъп от Интернет до локалната мрежа
- Анализиране на дневниците за мрежова връзка на NAT в Linux
Диаграма на локалната мрежа с шлюз за достъп до Интернет, NAT
NAT (Превод на мрежови адреси) - превод на IP адреси, това е механизъм, който ви позволява да замените изходния и дестинационния адрес в IP заглавката на пакетите, когато преминават през рутера, т.е. между различни мрежи.
Ние ще конфигурираме NAT между вътрешната мрежа с адресиране 10.2.0.0/24 и външната интернет мрежа от два вида:
- източник NAT - това е заместване на изходния IP адрес, в нашия случай, за организиране на достъп до Интернет чрез един публичен IP адрес на няколко клиенти.
- дестинация NAT - подмяна на IP адреси на местоназначение, в нашия случай, за да се осигури достъп от външна интернет мрежа чрез публичен IP адрес до сървърите на вътрешната мрежа.
Дефинираме мрежовите елементи (фигура 1), между които ще бъде организиран NAT:
- GW-сървър - шлюз на сървър, т.е. нашият CentOS Linux сървър, който осигурява достъп извън вътрешната мрежа. Той има два интерфейса, първият eth1 (10.2.0.1) във вътрешната мрежа, вторият eth0 (84.201.168.122) с публичен IP адрес и достъп до Интернет;
- уеб-server01 - Уеб сървър на вътрешната мрежа, IP адрес 10.2.0.11;
- ми-server01 - личен сървър на вътрешната мрежа, IP адрес 10.2.0.12.
Конфигуриране на Source NAT: LAN достъп
С изходния NAT за външни мрежови сървъри заявките на нашите клиенти от вътрешната мрежа ще изглеждат така, сякаш шлюзният сървър комуникира директно с тях - GW-server01.
В последната статия „Основна конфигурация на защитната стена на Linux с помощта на iptables“ разгледахме основите на използването на iptables. Този път ще работим в iptables не само с таблицата филтър, но и с маса NAT. За разлика от таблиците за филтриране на трафика филтър, Нат таблицата съдържа следните вериги:
- PREROUTING - В тази верига входящите IP пакети се обработват, преди те да бъдат разделени на тези, предназначени за самия сървър или за предаване на друг, т.е. преди да вземете решение за избора на маршрут за IP пакета;
- OUTPUT - Веригата е предназначена за обработка на IP пакети, които се генерират локално от приложението на сървъра. Локално генерираните IP пакети не преминават през PREROUTING веригата;
- POSTROUTING - всички изходящи IP пакети се обработват в тази верига, след като се вземе решение за маршрута на IP пакета.
Действията, изпълнявани за IP пакетите в тази таблица, също са различни:
- маскарад и SNAT- замества изходния IP адрес за изходящи пакети. Разликата между тези действия е, че SNAT дава възможност да се зададе конкретен IP адрес за нов източник, а в случай на MASQUERADE това се случва динамично;
- DNAT - замества IP местоназначения за входящи пакети.
Фигура 2 показва стъпките за обработка на IP пакет от вътрешната мрежа на шлюза gw-server01 с SNAT на iptables. IP адресът и портът на местоназначение остават непроменени..
Фигура 2
- IP пакетът пристигна на вътрешния интерфейс eth1 на gw-server01 сървъра. Тъй като целевият IP не принадлежи на gw-server01, IP пакетът преминава към обработка от веригата FORWARD.
- След преминаване на веригата FORWARD, за IP пакета се определя изходящият мрежов интерфейс, от който той трябва да бъде изпратен, това се маркира в жълто
- В края IP пакетът преминава през веригата POSTROUTING, в която изходният IP адрес се променя на IP адреса на външния интерфейс eth0 на сървъра gw-server01
Нека да настроим. Първо трябва да зададете параметъра на ядрото, което ви позволява да прехвърляте пакети между сървърните интерфейси. За да направите това във файл /etc/sysctl.conf добавете променлива:
net.ipv4.ip_forward = 1
За да приложите промените, изпълнете командата
sysctl -p /etc/sysctl.conf
тук sysctl е команда, която ви позволява да управлявате параметрите на ядрото, ключа -р означава, че трябва да прочетете параметрите от файла.
Създайте правило в iptables, което позволява прехвърлянето на пакети между вътрешния (eth1) и външния (eth0) интерфейс:
iptables -A FORWARD -i eth1 -o eth0 -j ПРИЕМАНЕ
и нека да прехвърляме пакети между интерфейси, свързани с вече установени връзки.
iptables -A FORWARD -m състояние - състояние СВЪРЗАНО, УСТАНОВЕНО -j ПРИЕМАНЕ
Има смисъл да се създадат предишните две правила, само ако политиката DROP е зададена по подразбиране за веригата FORWARD:
iptables -P НАПРЕД ЗАПУСКАНЕ
SNAT Активиране:
iptables -t nat -A POSTROUTING -s 10.2.0.0/24 -o eth1 -j SNAT - to-source 84.201.168.122
- -до-източник трябва да бъде адресът в интерфейса, от който се планира да се издават IP пакети към външната мрежа;
- -s 10.2.0.0/24 уточнено е, че вътрешната мрежа е 10.2.0.0/24, но това е незадължителен параметър, ако не го посочите, няма да има ограничения за източника на взаимодействие.
Нека видим получената конфигурация за таблицата филтър и вериги НАПРЕД (изходът е подрязан):
iptables -L -n -v
и конфигурация за таблицата NAT и вериги POSTROUTING (изходът е подрязан):
iptables -t nat -L -n -v
За да проверим дали нашия уеб сървър във вътрешната мрежа е получил достъп до Интернет, ще се опитаме да се свържем чрез telnet до адрес 1.1.1.1 (Cloudflare DNS) порт 80:
telnet 1.1.1.1 80
Екипни резултати Свързан 1.1.1.1, показва, че връзката е била успешна.
Конфигурирайте Destination NAT и пренасочване към порта: достъп от Интернет до локалната мрежа
Сега помислете за обратната ситуация. Искаме клиентите отвън да имат достъп до нашия сайт във вътрешната мрежа. И също така трябва да отидем до вашия личен сървър (или работна станция) от Интернет. Разликата между този случай е не само в посоката на взаимодействие, но и във факта, че трябва да пренасочвате заявки към отделни портове, 80 (TCP) и 3389 (TCP), като същевременно замествате целевия сървър и евентуално пристанището на местоназначение. Тази техника се нарича пренасочване на порт (пренасочване на порт).
Пренасочването на порт в Windows може да бъде организирано с помощта на командатаnetsh интерфейс portproxy.Първо, активирайте пакетно предаване от външния интерфейс (eth0) към вътрешния (eth1) интерфейс:
iptables -A FORWARD -i eth0 -o eth1 -j ПРИЕМАНЕ
Това правило позволява IP пакетите да се прехвърлят между интерфейсите, независимо от източника. Но е възможно да се забрани връзка чрез NAT за отделни IP адреси или подмрежи като отделно правило:
iptables-I FORWARD 1 -o eth1 -s 167.71.67.136 -j DROP
Сега пренасочете всички връзки към порт 80 на външния мрежов интерфейс (eth0) към IP адреса на уеб сървъра във вътрешната мрежа уеб-server01:
iptables -t nat -A ПРЕДОСТАВЯНЕ -p tcp --dport 80 -i eth0 -j DNAT - до дестинация 192.168.0.11
-до-дестинация - трябва да бъде IP адресът, на който трябва да бъде заменен целевият IP адрес.
За да проверите, опитайте да се свържете от интернет чрез telnet към публичния IP адрес на сървъра на gw-server на порт 80:
телнет 84.201.168.122 80
Резултатът ще бъде отговорът на web-server01 на уеб сървъра от нашата вътрешна мрежа:
HTTP / 1.1 400 Bad Server сървър: nginx / 1.14.2 Дата: сряда, 31 юли 2019 10:21:21 GMT Тип на съдържанието: текст / html Дължина на съдържанието: 173 Връзка: затвори
По същия начин можете да конфигурирате достъп от интернет до работната си станция чрез RDP. Тъй като ограничен брой хора ще се нуждаят от RDP достъп, ще бъде по-безопасно да използвате нестандартен порт, например 13389, когато се свързвате, и да го пренасочите към порт 3389 на сървъра на вътрешната мрежа (или да промените номера на RDP порта на компютър с Windows). Промененият дестинационен порт се обозначава с двоеточие след IP адреса:
iptables -t nat -A ПРЕДОСТАВЯНЕ -p tcp --dport 13389 -i eth0 -j DNAT - до дестинация 192.168.0.12 ∗ 389
За да проверите, опитайте да се свържете от интернет чрез telnet (или командлера PowerShell Test-NetConnection) към публичния IP адрес на сървъра GW-сървър на порт 13389:
телнет 84.201.168.122 13389
В отговор получаваме празен екран и курсор, това показва, че връзката работи.
Анализиране на дневниците за мрежова връзка на NAT в Linux
Един от моментите за повишаване на нивото на сигурност след конфигуриране на пренасочване на пристанища към нашия личен сървър от външна мрежа ще бъде сглобяването и анализа на външните дневници за връзка. Всъщност освен нас, нападател може да се опита да използва този достъп.
Първо, активирайте записа в лог файла /Var/ log / съобщения всички опити да се свържем с нестандартния RDP порт, който използваме:
iptables -I INPUT 1 -p tcp --dport 13389 -m състояние --state НОВО -j LOG --log-префикс "НОВА RDP SESSION"
Свържете се с нашия личен сървър, така че в дневника да се появи журнал. Сега филтрираме всички записи в лог файла, от които се нуждаем:
cat / var / log / messages | grep "НОВА ПРЕДПРИЯТИЯ"
ядро: НОВО RDP SESSION IN = OUT = eth1 SRC = 167.71.67.79 DST = 84.201.168.122 LEN = 60 TOS = 0x00 PREC = 0x00 TTL = 64 ID = 16270 DF PROTO = TCP SPT = 60836 DPT = 13389 WINDOW = 29200 RES = 0x00 SYN URGP = 0
Четенето на такъв дневник не е много удобно, особено всеки ден. Следователно следващата стъпка е автоматизирането на анализа на регистрационните файлове, за да получават редовно отчети въз основа на нашия филтър. За целта използвайте помощната програма Logwatch, инсталирайте го чрез стандартния мениджър пакет на yum:
yum инсталирайте logwatch
Първо, опитайте да генерирате отчет ръчно:
/ usr / sbin / logwatch - разпродажба на ниски - iptables за услуги - оранжево днес
тук,
- -обслужване - задава конкретна услуга, съобщения, от които трябва да анализирате, в нашия случай, само от iptables;
- -диапазон - посочва периода на вземане на извадки от данни, днес - всички събития за днес;
- -детайл - ниво на подробности за отчета (високо, средно, ниско).
По подразбиране logwatch ще покаже отчета на екрана, получаваме нещо подобно:
--------------------- iptables firewall Начало ------------------------ Изброени от източниците на хостове: Влезли 2 пакета на интерфейс eth1 От 167.71.45.65 - 2 пакета до tcp (13389) ---------------------- iptables firewall End -------------------------
Докладът работи, остава да го стартирате по график, веднъж на ден и да го изпращаме на имейла си, за това актуализираме командата и я записваме в /etc/cron.daily/00logwatch файла:
/ usr / sbin / logwatch - изходна поща --mailto [email protected] --продажба на ниски - iptables за услуги - оранжево вчера
Тук бяха добавени опциите:
-продукция - указва начина на извеждане на отчета, поща - изпращане на поща;
-за mailto - електронен адрес на получателя на отчета.
Когато препращате RDP вътре в локалната мрежа, вие също трябва да можете да анализирате дневниците на RDP връзки директно в Windows.
