Checkpoint mobile для linux

Checkpoint mobile для linux

Linux setup Check Point Mobile Access VPN

This is a step-by-step tutorial to setup your Linux machine with all the required dependencies to work with Check Point Mobile Access VPN. This tutorial also includes some troubleshooting.

In the past year I had to setup my Ubuntu 18.04 laptop twice. Both times were very exhausting and took long hours until it was ready to use due to so many different errors hard to find the solution on Google. So no need to mention this tutorial (at the current state) is only useful if you’re working with a clean and recently installed Ubuntu LTS distro.

First make sure your operating system is up-to-date with:

Now you need some basic tooling for installing and building independent package vendors:

If your system has no Java version installed, make sure you install the version 8 (or higher). You can do that quickly with SDKMAN!, but first be sure you’re on your home directory with:

And then for installing SDKMAN!:

List the available Java versions and try to find the OpenJDK version 8 or higher (in my case it was 8.0.232-open ) and then install it:

For the Check Point Mobile Access required packages, you’ll need to install xterm and some SSL packages with the following commands:

If you’re running a 64 bit operating system, you’ll need to install some 32 bit compatible libraries:

Downloading the Shell Scripts

There are two shell script files you’ll need to download to setup Check Point Mobile Access VPN on your machine:

Both of them you can get on your company’s Mobile Access VPN page.

2. Click on «Settings» button

3. Click on «Download Installation for Linux» for both SSL Network Extender and Check Point Mobile Access Portal Agent

Running the Shell Scripts

The scripts you’ve just downloaded are just regular files. So we need to change their permissions to make them executable with the following commands:

The first script we’re going to run is the snx_install.sh , which should not give any errors when installing it.

Here comes the tricky part: running the other shell script. The script will ask you for your password because it’s going to run some things as sudo . Everything should be going fine until it gets to the last step: when it tries to run /usr/bin/cshell/launcher . That’s where it gets stuck. This executable file does not work properly with sudo .

When you notice it is stuck at the message above, open Ubuntu’s system monitor and try to find a process called launcher with 0% CPU usage and Sleeping status. Once you find it, kill it.

Do not ever type CTRL+C on the terminal or try to end its process or launcher ‘s. You must kill the launcher process. Otherwise, the script will do a clean-up and erase everything it has made that will allow you to make Check Point Mobile Access VPN work.

If you’ve done everything right, there should be an executable file called launcher at /usr/bin/cshell/ . If so, run it and it should have been displayed some logs as follows:

It means it has successfully been installed, and you should be fine trying to connect to the VPN now, but it doesn’t mean we don’t have more work to do.

If you end up with an error when you’re trying to run /usr/bin/cshell/launcher about a named pipe file called cshell.fifo inside the /tmp folder, just delete it with:

You need to disable one of your system’s startup applications. You should be able to see one of them called cshell with a marked checkbox. All it does is running the launcher executable file in /usr/bin/cshell/ . You must uncheck it because every time you let it run automatically it’s going to be run as sudo , which means it’s going to get stuck.

Now we’re going to do a little trick to make it start automatically without sudo : run it inside the .bashrc file, so every time you open up a terminal it’s going to run with your user normal permissions. Actually, we only want to run it once when you log in, right? So why don’t we simply run it inside .profile ? Because everything in .profile run as sudo , so the launcher is going to get stuck.

So here is the tricky part: let’s create a simple log file to check whether launcher should run every time you open up a terminal window. Add the following lines to the .profile file to remove the log file every time you log in.

On the .bashrc file add the following lines to check whether it should run the launcher file every time you open up a terminal window:

Restart your computer, log into your user account and check if the log file we created is on your home directory by opening a terminal and typing:

Then show its contents by using cat and it should be displayed as the following:

Now you should be all set. Open your company’s Check Point Mobile Access page and you should be able to connect everytime you log into your computer. Just remember to open up a terminal window first 🙂

About

Linux setup to work with Check Point Mobile Access VPN.

Источник

Клиент Checkpoint VPN Linux

Есть ли клиент Linux для Checkpoint VPN? Предпочтительно для Ubuntu?

6 ответов

Я слышал хорошие вещи о Shrew, но я только видел, что он используется в Windows.

Я использую SNX (через контрольную точку), и он работает отлично. Его можно загрузить из здесь .

Я использовал это руководство , чтобы установить snx на моем клиенте, проверить его и проверьте, установлены ли у вас все необходимые пакеты.

Кроме того, вы можете создать файл .snxrc в /home/user/ и укажите там IP-адрес и имя пользователя, например:

Затем просто запустите snx , вам будет предложено ввести ваш пароль и все.

Существующий клиент является древним, и на данный момент AFAIK нет планов писать более новый. Есть частные VPN-клиенты Linux, которые должны работать с контрольной точкой — особенно проверьте vpnc и енот.

Я успешно подключился к Checkpoint (NGX R75) с помощью Shrew Soft, подробнее здесь: https://serverfault.com/a /386021/73387

Я предполагаю, что вы ищете клиента IPSEC, но если вы ищете SSL VPN, мне повезло с клиентом Checkpoint SNX в Ubuntu.

Я тоже искал его И я нашел VPN-клиент контрольной точки на форумах пользователей Checkpoint, я свяжу его с вами завтра.

OK Вот ссылка на документацию в RedHat:

НО, VPN-клиент Linux, похоже, устарел и больше не поддерживается, как и мой собственный опыт, лучше использовать OpenSwan VPN для подключения через VPN-шлюз Checkpoint VPN под Linux.

Источник

Checkpoint mobile для linux

После нескольких лет экспериментов мне таки удалось их соединить. Вообще-то Checkpoint использует IPSec, но, как водится, с некоторыми расширениями, делающими его несовместимыми с другими реализациями.

Родной клиент под линукс у Checkpoint’а когда-то был, но последняя версия была под RedHat 5 (не путать с RHEL5!). RH5 — это примерно 1997-98 год. С тех пор Checkpoint на линукс забил, а желающим рекомендует использовать SSL Network Extender, работающий через Java-плагин в браузере. Точнее, в моём случае не работающий, поскольку гейт по HTTPS вообще не отвечает.

Но добрые люди из компании Shrew Soft написали универсальный клиент, который умеет разговаривать на многих диалектах IPSec, включая CheckPoint’овский. Готового пакета под линукс у них самих нет, но из исходников собралось влёт. В некоторых дистрибутивах, типа убунты, говорят, есть уже готовое.

Остались сущие мелочи: настроить. В родной инструкции сказано, что клиенту нужен сертификат, который предлагается экспортировать из сервера. Но у меня нет доступа к серверу. Виндовый клиент этот сертификат скачивает при первом соединении с сервером и сохраняет у себя (способ небезопасный, но уж какой есть). Вот только сохраняет он его таким хитровывернутым способом…

Итак,
1) в Program Files\CheckPoint\SecuRemote\database\ находим файлик userc.C, в котором лежит конфигурация клиента. Файлик, к счастью, текстовый. Находим в нём параметр :cert, представляющий собой длинную строку из шестнадцатиричных цифр. И сохраняем эту строку в другой файлик, скажем, cert.hex
2) Конвертируем в бинарный вид: xxd -p -r cert.hex > cert.bin
3) Переставляем байты в обратном порядке… cat cert.bin | perl -0777e ‘print scalar reverse <>‘ > cert.der
4) Полученный файл представляет собой серверный сертификат в формате DER. Конвертируем в PEM: openssl x509 -inform DER -in cert.der -outform PEM -out cert.pem

Это Страшное Колдунство найдено тут.

Так, с сертификатом разобрались. Переходим к настройке параметров соединения..

Запускаем qikea, тыкаем в кнопочку Add. В полученном диалоге вбиваем следующие настройки:

General:
указываем IP-адрес гейта, порт 500.
Auto configuration: ike config pullю
Local Host Address method: Use a virtual adapter and assigned address и Obtain automatically.
MTU оставляем 1380.

Client:
NAT traversal: disable. Несмотря на это, оно успешно работает из-за NAT’а. Вероятно, эта настройка относится к собственно IPSec’овому NAT-T, а здесь он инкапсулируется в UDP, и NAT проходит на этом уровне. И в инструкции всё равно написано, что Shrew не поддерживает CheckPoint’овский NAT-T.
IKE fragmentation: enable, Max packet size: 540.
Остальные три галки (Enable Dead Peer Detection, Enable ISAKMP Failure Notifications, Enable Client Login Banner) оставляем как есть, то есть, включёнными.

Name resolution: оставляем по умолчанию:
Enable DNS, Obtain automatically. DNS suffix тоже Obtain automatically.
Учтите, что это приведёт к добавлению записей в /etc/resolv.conf при поднятии туннеля, если это нежелательно, можно выключить.

Authentication:
Authentication method: Hybrid RSA+XAuth.
Local Identity: User FQDN, UFQDN string оставляем пустой. В инструкции написано, что надо использовать FQDN, но у меня оно с такой настройкой не работает, только с UFQDN.
Remote Identity: Identification Type: any. В инструкции написано, что можно ещё IP address, я не пробовал.
Credentials: Server Certificate Authority File: вот тут надо указать файл с сертификатом, выковырянный на первом этапе. Сам файл больше уже не понадобится, он тут импортируется и целиком сохраняется в конфиге.

Phase1:
Exchange type: main. Agressive не работает.
DH Exchnage: group 2. Остальные варианты, включая auto, у меня не работают.
Cipher algorithm: AES, Key length: 256 bit. Auto не работает.
Hash algorithm: sha1. Auto не работает.
Key Life Time Limit: оставляем как есть: 86400 sec, data limit: 0 (в смысле, отключено).
Не забыть поставить галку Enable Check Point Compatible Vendor ID, без неё точно не заработает.

Phase2: всё про умолчанию:
Transfer algorithm: auto
HMAC Algorithm: auto
PFS Exchange: disabled
Compression algotithm: disabled
Key life time limit: 3600 sec, data limit: 0.

Policy:
Policy generation level: auto
Maintain persistent Security Associations: у меня выключено, в принципе, можно и включить, если кому надо.
Obtain Topology Automatically or Tunnel All: у меня выключено в связи с идиотской политикой, выдаваемой сервером. Он выдаёт маршрут в VPN для внешнего IP-адреса гейта. Причём в Windows этот идиотизм как-то работает, но в линуксе однозначно не будет. Поэтому все нужные маршруты далее вбить вручную. Тем более, что в инструкции написано, что автоматическое получение маршрутов из CheckPoint’а всё равно не работает.

Вот, собственно, и всё. Сохраняем, запускаем, вводим логин и пароль, и надеемся, что заработает..

Источник

Checkpoint mobile для linux

Check Point and Alkira
Better Together!

Protect Endpoints from
Ransomware and Phishing Attacks

Try out the new
CheckMates Labs!

Check Point Acquires Avanan
Learn Why Avanan and Check Point are Better Together

CheckMates Go:
The Things They’re Missing

Premier Event for Securing Users & Access
12th October

• CheckMates
• :
• Products
• :
• Harmony
• :
• Remote Access VPN
• :
• Endpoint Security VPN certificate-based authentica.

• Subscribe to RSS Feed
• Mark Topic as New
• Mark Topic as Read
• Float this Topic for Current User
• Bookmark
• Subscribe
• Mute
• Printer Friendly Page

• Mark as New
• Bookmark
• Subscribe
• Mute
• Subscribe to RSS Feed
• Permalink
• Print
• Email to a Friend
• Report Inappropriate Content

I’m working for a client who uses Check Point Endpoint Security VPN for their remote access solutions. I have a server address and password-protected certificate (p12) which I can use to authenticate and get VPN access. This works fine on Windows using Check Point’s client.

How can I use the same certificate to connect to this VPN using a Linux endpoint, preferably using a terminal client?

I realize Check Point doesn’t provide its own Linux client, but I would assume the protocols used aren’t home-brewed, meaning an existing Linux client could probably be used (e.g. Openswan).

I couldn’t find any guides or other form of documentation in Check Point’s knowledge base, and all forum posts related to VPN+Linux discuss username+password-based authentication, not certificate-based.

Источник

Виртуальные Check Point’ы: чек-лист по настройке

Многие клиенты, арендующие у нас облачные ресурсы, используют виртуальные Check Point’ы. С их помощью клиенты решают различные задачи: кто-то контролирует выход серверного сегмента в Интернет или же публикует свои сервисы за нашим оборудованием. Кому-то необходимо прогонять весь трафик через IPS blade, а кому-то хватает Check Point в роли VPN-шлюза для доступа к внутренним ресурсам в ЦОДе из филиалов. Есть и те, кому нужно защитить свою инфраструктуру в облаке для прохождения аттестации по ФЗ-152, но об этом я расскажу как-нибудь отдельно.

По долгу службы я занимаюсь поддержкой и администрированием Check Point’ов. Сегодня расскажу, что нужно учесть при разворачивании кластера из Check Point’ов в виртуальной среде. Затрону моменты уровня виртуализации, сети, настроек самого Check Point’а и мониторинга.
Не обещаю открыть Америку – многое есть в рекомендациях и best practices вендора. Но их же никто не читает), поэтому погнали.

Режим работы кластера

У нас Check Point’ы живут в кластерах. Самая частая инсталляция – кластер из двух нод в режиме active-standby. Если с active-нодой что-то случается, она становится неактивной, и в работу включается standby-нода. Переключение на «запасную» ноду обычно происходит из-за проблем в синхронизации между участниками кластера, состоянии интерфейсов, установленной политики безопасности, просто из-за сильной нагрузки на оборудование.

В кластере из двух нод мы не используем режим active-active.

При падении одной из нод выжившая нода может просто не выдержать двойной нагрузки, и тогда мы потеряем все. Если очень хочется active-active, то в кластере должно быть минимум 3 ноды.

Настройки сети и виртуализации

На сетевом оборудовании разрешено прохождение multicast-трафика между SYNC-интерфейсами членов кластера. В случае если прохождение multicast-трафика невозможно, то протокол синхронизации (CCP) используется broadcast. Ноды в кластере Check Point’а синрохнизируются между собой. Сообщения об изменениях передаются от ноды к ноде через multicast. У Check Point’а используется нестандартная реализация мультикаста (используется не multicast IP-адрес). Из-за этого некоторое оборудование, например, коммутатор Cisco Nexus, эти сообщения не понимает и поэтому блокирует их. В этом случае переключаемся на broadcast.

Описание проблемы с Cisco Nexus и ее решения на портале вендора.

На уровне виртуализации также разрешаем прохождение multicast-трафика. Если multicast запрещен для синхронизации кластера (CCP), то используем broadcast.

В консоли Check Point’а c помощью команды cphaprob -a if можно посмотреть настройки CPP и его режим работы (multicast или broadcast). Чтобы изменить режим работы, используем команду cphaconf set_ccp broadcast.

Ноды кластера должны находиться на разных ESXi-хостах. Тут все понятно: при падении физического хоста вторая нода продолжает работать. Этого можно достичь с помощью DRS anti-affinity rules.

Размеры виртуальной машины, на которой будет работать Check Point. Рекомендации вендора – 2 vCPU и 6 ГБ, но это для минимальной конфигурации, например, если у вас работает firewall с минимальной пропускной способностью. По нашему опыту внедрений, при использовании нескольких программных блейдов желательно использовать как минимум 4 vCPU, 8 GB RAM.
На ноду мы выделяем в среднем 150 ГБ диска. При развертывании виртуального Check Point диск разбивается на партиции, и мы можем регулировать, какое пространство выделить под System Swap, System Root, Logs, Backup and Upgrade.

При увеличении System Root партицию Backup and Upgrade также нужно увеличить, чтобы соблюсти пропорцию между ними. Если пропорция не соблюдается, то очередной бэкап может не уместиться диске.

Disk Provisioning – Thick Provision Lazy Zeroed.Check Point генерирует много событий и логов, каждую секунду появляется 1000 записей. Под них лучше сразу зарезервировать место. Для этого при создании виртуальной машины выделяем ей диск по технологии Thick Provisioning, т.е. есть резервируем место на физическом хранилище в момент создания диска.

Настроено 100% резервирование ресурсов для Check Point при миграции между ESXi-хостами. Рекомендуем зарезервировать 100 % ресурсов, чтобы виртуальная машина, на который развернут Check Point, не конкурировала за ресурсы с другими ВМ на хосте.

Прочее. У нас используется версия Check Point’а R77.30. Для нее рекомендуется использовать RedHat Enterprise Linux version 5 (64-bit) в качестве гостевой ОС на виртуальной машине. Из сетевых драйверов – VMXNET3 или Intel E1000.

Настройки Check Point’a

На шлюзах и сервере управления установлены последние обновления Check Point. Проверяем наличие обновлений через CPUSE.

С помощью Verifier проверяем, что пакет обновлений, который мы собираемся установить, не конфликтует с системой.

Verifier, конечно, штука хорошая, но есть нюансы. Некоторые обновления несовместимы с add-on, но этих конфликтов Verifier не покажет и позволит обновиться. В конце обновления у вас появится ошибка, и только из нее вы узнаете, что мешает обновлению. Например, такая ситуация возникла с пакетом обновлений MABDA_001 (Mobile Access Blade Deployment Agent), которая решает проблему с запуском Java Plugin в браузерах отличных от IE.

Настроено ежедневное автоматическое обновление сигнатур для IPS и других программных блейдов. Check Point выпускает сигнатуры, с помощью которых можно детектировать или блокировать новые уязвимости. Уязвимости автоматически присваивается уровень критичности. В соответствии с этим уровнем и выставленным фильтром система принимает решение о том, детектировать или блокировать сигнатуру. Тут важно не переусердствовать с фильтрами, периодически проверять и вносить корректировки, чтобы не блокировался легитимный трафик.

Профиль IPS, где выбираем действие по отношению к сигнатуре в соответствии с ее параметрами.

Настройки политики для данного профиля IPS в соответствии с параметрами сигнатур: уровень критичности, влияние на производительность и пр.

На оборудовании Check Point настроен протокол синхронизации времени NTP. По рекомендациям, Check Point следует использовать внешний NTP-сервер для синхронизации времени на оборудовании. Сделать это можно через веб-портал gaia.

Неточно выставленное время может привести к рассинхронизации кластера. Если время будет неправильным, то крайне неудобно искать интересующую нас запись в логах. Каждая запись в журналах событий маркируется так называемым timestamp.

Настроен Smart Event для оповещения о срабатываниях IPS, App Control, Anti-Bot и т. д. Это отдельный модуль со своей лицензией. Если он у вас есть, то с его помощью удобно визуализировать информацию о работе всех программных блейдов и устройств. Например, атаки, количество срабатываний IPS, уровень критичности угроз, какие запрещенные приложения используют пользователи и пр.

Это статистика за 30 дней по количеству сигнатур и степени их критичности.

Более подробная информация по детектированным сигнатурам на каждом программном блейде.

Мониторинг

Важно отслеживать как минимум следующие параметры:

• состояние кластера;
• доступность компонент Check Point’а;
• загрузку процессора;
• оставшееся место на диске;
• свободную память.

У Check Point’а есть отдельный программный блейд – Smart Monitoring (отдельная лицензия). В нем можно дополнительно следить за доступностью компонент Check Point’а, нагрузками на отдельные блейды, статусами лицензий.

График по нагрузке на Chek Point. Всплеск – это заказчик отправлял push-уведомления 800 тыс. клиентам.

График по нагрузке на блейд Firewall в той же ситуации.

Мониторинг можно настроить и через сторонние сервисы. У нас, например, также используется Nagios, где мы мониторим:

• сетевую доступность оборудования;
• доступность кластерного адреса;
• загрузку CPU по ядрам. При загрузке более 70% приходит оповещение на почту. Такая высокая загрузка может говорить о специфическом трафике (vpn, например). Если это часто повторяется, то, возможно, не хватает ресурсов и стоит расширить пул.
• свободную оперативную память. Если остается меньше 80%, то мы об этом узнаем.
• загрузка диска по определенным партициям, например var/log. Если она скоро забьется, то надо расширять.
• Split Brain (на уровне кластера). Отслеживаем состояние, когда обе ноды становятся активными и между ними пропадает синхронизация.
• High availability mode – отслеживаем, что кластер работает в режиме active-standby. Смотрим на состояния нод – active, standby, down.

Параметры мониторинга в Nagios.

Также стоит мониторить состояние физических серверов, на которых развернуты ESXi-хосты.

Резервное копирование

Сам вендор рекомендует делать снепшот сразу после инсталляции обновления (Hotfixies).

В зависимости от частоты изменений настраивается полный бэкап раз в неделю или месяц. В нашей практике мы делаем ежедневное инкрементное копирование файлов Check Point и полный бэкап раз в неделю.

На этом все. Это были самые базовые моменты, которые нужно учесть при развертывании виртуальных Check Point’ов. Но даже выполнение этого минимума поможет избежать проблем с их работой.

Источник