Эта статья навеяна выполнением работ для одного из наших крупных клиентов ООО «ЕвроСтудио».
Известно, что в CentOS 7 было много нововведений. Одно из них — firewalld, демон-надстройка над iptables, добавляющая определенные удобства в работе с брандмауэром. Можно долго спорить на тему удобно/неудобно, и о том, что надстройка эта по умолчанию ставится только в разработках RedHat и совместимых с ними CentOS, но она есть, установлена, а значит почему бы ее не использовать?
Итак, IPset. Это именованные списки IP-адресов и подсетей, которые можно использовать в правилах iptables для уменьшения количества этих правил. Чем меньше правил — тем быстрее они анализируются, тем производительнее сеть на данном сервере. Поддержка IPset появилась в firewalld начиная с версии 0.4.0.
Смотрим версию firewalld firewall-cmd -v 0.3.9
Видим, что версия ниже, чем 0.4.0, значит ее надо обновить yum install firewall
Снова проверяем версию firewall firewall-cmd -V 0.4.4.4
Если версия правильная, (>= 0.4.0, как у нас) можно работать с IPset. Например добавим список адресов firewall-cmd --permanent --new-ipset=IP-whitelist --type=hash:ip
Если в списке должны быть и адреса, и подсети, то список следует добавлять так firewall-cmd --permanent --new-ipset=IP-whitelist --type=hash:net
Мы добавили именованный список IP-whitelist. Опция «—permanent» добавляет конфигурационный файл этого списка, без нее после перезагрузки списка у нас не будет. А еще она сохраняет правила, списки и адреса в различные конфигурационные файлы .xml в директории /etc/firewalld, чтобы они автоматически применялись при перезагрузке сервера. Если нужно просто протестировать список или правило, опцию «—permanent» добавлять не нужно, правило или список в этом случае сохранится только до ближайшей перезагрузки.
Теперь будем добавлять в список адресов собственно адреса firewall-cmd --ipset=IP-whitelist --add-entry=192.168.1.4 --permanent firewall-cmd --ipset=IP-whitelist --add-entry=192.168.1.6 --permanent firewall-cmd --ipset=IP-whitelist --add-entry=192.168.1.8 --permanent
И подсети firewall-cmd --ipset=IP-whitelist --add-entry=192.168.2.0/24 --permanent firewall-cmd --ipset=IP-whitelist --add-entry=192.168.1.100/28 --permanent
Посмотрим, какие у нас есть списки адресов/сетей Показать существующие списки адресов firewall-cmd --get-ipsets IP-whitelist
Показать сам список firewall-cmd --ipset=IP-whitelist --get-entries 192.168.1.4 192.168.1.6 192.168.1.8 192.168.2.0/24 192.168.1.100/28
Список у нас есть, можем теперь добавить правила, работающие с этими списками. Допустим, нам надо, чтобы сервис ssh был доступен только для белого списка адресов IP-whitelist, а порты 80 и 443 были закрыты для адресов в списке IP-blacklist
Добавим правило, разрешающее сервис ssh для белого списка «IP-whitelist» firewall-cmd --permanent --zone=public --add-rich-rule='rule source ipset="IP-whitelist" service name="ssh" accept'
Если есть правило, разрешающее сервис ssh для всех, удалим его firewall-cmd --permanent --zone=public --remove-service=ssh
Убедились, что ваш адрес есть в белом списке, иначе доступ к серверу будет закрыт! firewall-cmd --ipset=IP-whitelist --get-entries
И запретим доступ с этих адресов для портов 80 и 443 используя опцию service firewall-cmd --add-rich-rule='rule source ipset=IP-blacklist service name="http" drop' --permanent firewall-cmd --add-rich-rule='rule source ipset=IP-blacklist service name="https" drop' --permanent
Или опцию port firewall-cmd --add-rich-rule='rule source ipset=IP-blacklist port protocol="tcp" port="80" drop' --permanent firewall-cmd --add-rich-rule='rule source ipset=IP-blacklist port protocol="tcp" port="80" drop' --permanent
Правила добавлены, блокировка включена, к ssh имеют доступ только разрешенные хосты. Теперь во время работы сервера мы можем добавлять и убирать адреса в эти списки Добавление адреса в списки firewall-cmd --ipset=IP-blacklist --add-entry=192.168.1.20 --permanent firewall-cmd --ipset=IP-blacklist --add-entry=192.168.1.70 --permanent firewall-cmd --ipset=IP-whitelist --add-entry=192.168.1.80 --permanent firewall-cmd --reload
COUNTRIES=('ru' 'kz')
ipset flush countries
for i in "${COUNTRIES[@]}"; do
echo "Ban IP of country ${i}"
for IP in $(wget -O - https://www.ipdeny.com/ipblocks/data/countries/${i}.zone)
do
#ipset add allowcountries $IP,22
firewall-cmd --ipset=IP-whitelistnet --add-entry=$IP --permanent
done
done
Accessing Exchange Server 2019 /OWA and /ECP throws the errors: “Status code: 500” and “Could not load file or assembly ‘Microsoft.Exchange.Common, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies.”
Problem
You’ve noticed that after patching Exchange Server 2019 servers (for this example, the patch for HAFNIUM was applied), access to /OWA and /ECP now displays the following errors:
OWA
🙁
Something went wrong
Your request couldn’t be completed. HTTP Status code: 500.
Could not load file or assembly ‘Microsoft.Exchange.Common, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.Exchange.Common, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Assembly Load Trace: The following information can be helpful to determine why the assembly ‘Microsoft.Exchange.Common, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ could not be loaded.
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
Stack Trace:
[FileNotFoundException: Could not load file or assembly ‘Microsoft.Exchange.Common, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.]
[ConfigurationErrorsException: Could not load file or assembly ‘Microsoft.Exchange.Common, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.]
[HttpException (0x80004005): Could not load file or assembly ‘Microsoft.Exchange.Common, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.]
You’ve noticed that reviewing the BinSearchFolders application settings for ecp folder in the Exchange Back End website shows that the Value is configured with %ExchangeInstallDir%:
Changing this to the path without using the variable appears to fix the ECP page but not OWA:
Solution
One of the possible solutions to correct the issue is to use the UpdateCas.ps1 script located in the \Microsoft\Exchange Server\V15\Bin folder to rebuild the /OWA and /ECP directory:
Proceed to test the /owa and /ecp directories once the PowerShell completes.