Manage a Publisher
After deploying your publisher, use the following sections to make modifications to your Publishers.
After assigning private apps to specific Publishers, you can change one or more Publishers simultaneously. The Private Apps page enables you to change private apps assignments in bulk. For example:
Change one or more publishers for private apps.
Quickly migrate existing private apps to a new publisher.
Disconnect private apps before deleting a publisher.
To change publishers for private apps:
Go to Settings > Security Cloud Platform > App Definition > Private Apps.
Select one or more private app check boxes and click Change Publishers.
The selected private apps are shown in the Bulk Change Publisher dialog box. Click in the Publisher text field and select one or more publisher in the dropdown list, and then click Save.
In addition to changing publishers for private apps, this page enables you to delete one or more private apps. Select one or more private app check boxes, and click Delete, and then click Delete again to confirm. If the private app being deleted is specified in a policy, a message box informs you of this factor and you'll need to remove it from the policy in order to delete the private app.
This topic describes how to upgrade one or more Publishers. Using at least a pair of Publishers for each private app is recommended so they can provide high-availability access. Before upgrading all Publishers, upgrade a test Publisher first, and then proceed to the other Publishers.
To use these instructions, identify the Publishers that you want to upgrade.
Upgrading Publishers
SSH into the Publisher you want to upgrade.
On the Publisher option menu, select Upgrade, and then select 1 to initiate the upgrade. The upgrade should take around a minute.
In the Netskope UI, go to Settings > Security Cloud Platform > Publishers. Locate the Publisher you just upgraded on the Publishers page to confirm it has a Connected status.
Repeat these steps for every Publisher you are using to access private apps.
Changing Publishers during an Upgrade
If the upgraded publisher has not re-established access, re-assign the app(s) to a different Publisher.
To change Publisher assignments in the Netskope UI, go to Settings > Security Cloud Platform > App Definition > Private Apps. Select the checkboxes for the apps assigned to the Publisher and click Change Publisher.
Click in the Publishers text field, and then select a different Publisher from the list. When finished, click Save.
Locate the Publisher you just assigned on the Publishers page to confirm it has a Connected status. If not, contact Netskope Support to stop the upgrade process and ask for assistance.
This topic explains how to enable SNMP on a Publisher and edit the firewall to allow external monitoring.
Connect to a Publisher using SSH and login.
On the menu, select
5and exit to the CLI.Install SNMP and snmp-utils.
sudo yum install net-snmp net-snmp-utils
Configure the SNMP daemon to start after a device restart.
sudo systemctl enable snmpd
Check the snmpd service to make sure it is running.
systemctl status snmpd.service
Install your favorite file editing utility, in this nano.
sudo yum install nano
Edit the snmpd.conf file to change community strings and increase security.
sudo nano /etc/snmp/snmpd.conf
Restart the snmpd service.
sudo systemctl restart snmpd.service
Check the snmpd service to make sure it is running.
systemctl status snmpd.service
Verify the firewall service.
sudo firewall-cmd --state running
Determine what the default zone is.
firewall-cmd --get-default-zone public
Determine what zones are active. Please note that if the publisher has not connected to an application yet the docker interface will not be present.
firewall-cmd --get-active-zones docker interfaces: docker0 public interfaces: ens32 virbr0
Add the SNMP service to the public firewall zone.
sudo firewall-cmd --zone=public --add-service=snmp success
Confirm that the SNMP service has been added to the public firewall zone.
sudo firewall-cmd --list-all public (active) target: default icmp-block-inversion: no interfaces: ens32 virbr0 sources: services: dhcpv6-client snmp ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv4" destination address="191.1.1.1/32" port port="784" protocol="tcp" accept rule family="ipv4" destination address="191.1.1.1/32" port port="785" protocol="udp" accept
sudo firewall-cmd --zone=public --list-all public (active) target: default icmp-block-inversion: no interfaces: ens32 virbr0 sources: services: dhcpv6-client snmp ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv4" destination address="191.1.1.1/32" port port="784" protocol="tcp" accept rule family="ipv4" destination address="191.1.1.1/32" port port="785" protocol="udp" accept
Test access to SNMP. If it works, then add permanent.
Add the SNMP service to the firewall permanently.
sudo firewall-cmd --zone=public --permanent --add-service=snmp success
Verify that the SNMP service has been added to the firewall permanently.
sudo firewall-cmd --zone=public --permanent --list-services dhcpv6-client snmp ssh
Netskope provides prebuilt Publishers for VMWare (OVA format), Hyper-V (VHDX), and AWS (AMI). Additionally, you can also deploy a publisher on top of CentOS machine for other environments, such as GCP. The deployment methods and use of Docker images may raise some concerns about hardening and security. This document provides info that can be used by customers under NDA to better understand how a Publisher is deployed and maintained.
Base OS
CentOS
The version depends on the exact platform that the publisher is being deployed on.
AWS AMI – 7.6.1810
VMWare OVA – 7.7.1908
Hyper-V – 7.7.1908
All other platforms are dependent on what version of CentOS the provider supports.
Docker Engine
Client and Server: 19.03.5
Docker Container OS
Ubuntu 14.04
Netskope takes a number of hardening steps for the images we provide including:
Disabling root login to base OS and container OS
Removing root password
Removing unneeded Linux firmware and packages
Running the latest security updates prior to capturing the image
Disabling support for CTL – ALT- DEL to prevent accidental or malicious system restarts.
The Publisher only requires communication over the following ports and protocols:
Inbound
SSH Access
Port 22 for management
Outbound
DNS
Port 53
The publisher must have access to DNS to resolve:
http://ns-{TENANTID}.{POPNAME}.npa.goskope.com
TENANTID would be the typical ID, such as 1234, etc.
POPNAME represents the Home PoP Name, which can include:
us-sv5
us-sjc1
nl-am2
de-fr4
For example: ns-1234.us-sjc1.npa.goskope.com
Customer application names
HTTPS
Port 443
Outbound connectivity required for tunneling and updates
Other ports
The Publisher requires connectivity to/from the applications the customer defines on the ports necessary for their applications.
Netskope Private Access leverages RSA 2048 for all encrypted communications including Client, Publisher, and inner tunnel.
TLS certificates used in Netskope Private Access include limited information which does include any internal customer or service information. The certificates include a randomized identifier per client and Publisher, the Netskope tenant name, and the expiration date.
Netskope Private Access leverages an internal Public Key Infrastructure (PKI) that is managed and owned by Netskope. Certificates used in communication are signed and issued by either a tenant specific intermediate certificate authority or Netskope’s root certificate authority.
You can perform additional hardening steps such as:
Hardening SSH to use keys rather than passwords
AWS AMI uses keys by default. Publishers deployed on other platforms must be manually configured to use keys
Using the native CentOS firewall or network firewalls to limit access to and from the Publisher.
Netskope provides updates to the Publisher that include:
Base OS (CentOS) security updates
Publisher (security, functionality, and enhancements).
Netskope recommends that customers keep Publisher updates current.
SELinux & FirewallD
The NPA Publisher is configured with SELinux enforcing mode, and firewalld enabled and running. During Publisher installation, the following firewalld configurations are made in order to enable the NPA Publisher to process data packets appropriately.
# Configure firewalld with an NPA specific zone that opens ports 784 and 785 firewall-cmd --reload firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" destination address="191.1.1.1/32" port protocol="tcp" port="784" accept' firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" destination address="191.1.1.1/32" port protocol="udp" port="785" accept' firewall-cmd --reload # Restart firewalld & the NPA publisher after this configuration sudo systemctl restart firewalld sudo pkill npa_publisher
Note
As indicated above, this configuration is applied automatically in all current NPA Publisher releases and is included here for reference/legacy Publishers.
Tunneling Info
NPA includes a number of measures that would prevent a Netskope employee or anyone else from intercepting private application traffic:
Certificate Pinning on both the Client and the Publisher
Multiple levels of tunneling:
Client to Gateway
Gateway to Stitcher
Publisher to Stitcher
Inner tunnel between the Client and Publisher.
Additional measures to secure the certificates for all encryption
Outer tunnel certificates are stored securely in systems with limited access and Netskope employees are restricted to only performing maintenance. Monitoring and auditing of these systems is enabled with processes in place to protect these systems.
The inner tunnel certificates are stored on the publisher themselves in memory so only the customer has access.