SOPHOS-XG Firewall Administrator PPT.pptx

SOPHOS-XG FIREWALL
ADMINISTRATOR

WHAT IS SOPHOS FIREWALL
- Sophos Firewall offers the enterprise-grade protection, performance,
visibility, and SD-WAN features that you need for today's most demanding
networks.
- It provides next-generation firewall protection that blocks unknown
threats and automatically responds to incidents by isolating compromised
systems
- Sophos Firewall's extensive suite of security features impressed us from
the start.
- Sophos also keeps track of your applications and apps, blocking harmful
ones and allowing the user to uninstall them.

MODULE 1: XG FIREWALL OVERVIEW
The Sophos XG Firewall will block even unknown threats with it's comprehensive
suite of advanced protection which includes a Web Application Firewall,
Sandboxing, Dual AV, IPS, ATP, Web and Application Control
The Sophos XG Firewall can be deployed in four ways:
1. As a hardware device - Sophos XG Devices come pre-loaded and ready to go.
2. As software - installed onto Intel compatible hardware.
3. As a virtual device - running on the most common hypervisors, including
VMware, Hyper-V, Xen and KVM.
4. XG Firewall can be deployed into the cloud on Azure

MODULE 1: XG FIREWALL OVERVIEW
The subscriptions are also offered in bundles:-
1. Enterprise Guard includes the Base Firewall, Network Protection, Web Protection, and
Enhanced Support.
2. Full Guard includes Enterprise Guard plus Email Protection and Webserver Protection.
3. Full Guard Plus includes Full Guard and add Sandstorm.
4. Both Enterprise Guard and Full Guard are for software, virtual and cloud deployments.
5. Enterprise Protect is Enterprise Guard plus hardware, and Total Protect is Full Guard plus
hardware.
6. Total Protect plus add Sandstorm to the Total Protect Bundle

MODULE 1: GETTING STARTED WITH XG FIREWALL

MODULE 1: GETTING STARTED WITH XG FIREWALL
- The Sophos XG Firewall is an object oriented system that allows
administrators to create reusable objects that can represent hosts, services,
networks, or even entire countries.
- By default, the devices’ IP address will be 172.16.16.16 and the Web Admin
on a Sophos XG firewall runs on port 4444.
- To connect to the Web Admin interface you would need to connect to
HTTPS://172.16.16.16:4444 on a brand new device.
- The XG Firewall supports a number of different interface types besides the
onboard physical interfaces. These include Bridge, VLAN, Alias, LAG, and
RED interfaces.

MODULE 1: XG FIREWALL INTERFACES
1. A bridge - interface allows for the merging of two or more interfaces into a
transparent layer 2 or layer 3 bridge to allow for seamless communication
between interfaces.
2. A VLAN - interface allows the administrator to create a virtual LAN
interface on one of the existing XG interfaces.
3. An Alias - allows the adding of additional IP addresses to an existing
interface.
4. A LAG - is a group of interfaces acting as one single connection which
can provide redundancy and increased speed between two devices.
5. A RED - interface is used to configure and connect RED hardware devices
back to the XG firewall.

MODULE 1: XG FIREWALL NETWORK PROTECTION

MODULE 1: XG FIREWALL ZONE BASED
- As we have already mentioned the XG Firewall is a zone-based, object
oriented firewall. This makes creating rules and policies on the XG
firewall both easy and flexible.
- Basic network rules can be created to control traffic between
different zones or between networks and hosts within the zones.
- Traffic that is allowed by a basic packet filter rule can then be
examined further by modules such as the IPS module or based on the
clients Security Heartbeat in order to determine if that traffic is going
to be allowed or blocked.
- The XG firewall comes with a number of predefined IPS security
policies which can be found in PROTECT > Intrusion Prevention > IPS
Policies. These policies cover most of the everyday scenarios that an
administrator would encounter on an average network.

MODULE 1: XG FIREWALL DEFAULT POLICY
- Custom IPS policies can be created by filtering the rule set on:
• Signature category (e.g., Browsers)
• Security level (e.g., Critical)
• Operating system
• Device type
- The Security Heartbeat provides intelligent communication between
endpoints that are managed in Sophos Central and the XG Firewall so
that they can coordinate their response to threats.
- The computer sends a small regular heartbeat to the XG Firewall to
identify itself and show that it is still active and protected.

MODULE 1: XG FIREWALL CONNECTIONS

MODULE 1: XG FIREWALL VPN
- Sophos XG Firewall supports three types of VPN:
• Site-to-site, also known as gateway-to-gateway, which is used to link
together networks such as a head office and branch office
• Remote access, also known as host-to-gateway, which is used to link
a single host to a network
• Host-to-host, which is used to link two hosts
- With threat free tunneling, all of the security features of the Sophos XG
Firewall can be applied to data passing through the VPN. This includes:
• All layer-8 firewall controls
• Anti-virus and anti-spam scanning
• Intrusion prevention
• Content filtering
• Bandwidth management

MODULE 1: XG FIREWALL AUTHENTICATION

• The XG Firewall has three types of user;
1. Standard users that authenticate with a username and password. They
can be authenticated locally by the XG Firewall or using an external
authentication server such as Active Directory.
2. Clientless users do not authenticate using a username and password,
but instead are identified purely by their IP address. Clientless users are
always authenticated locally by the XG Firewall. Typically you would
use clientless users to control network access for servers or devices
such as printers and VoIP phones.
3. The final type of user is a guest user. These are users that are given
temporary network access, usually to access the Internet. They
authenticate with a username and password that are generated by
the XG Firewall and are always authenticated locally.

The Sophos XG Firewall supports five main methods for authenticating
users, these are:
• Hotspot
• Clientless Users
• Single Sign-On (SSO)
• Authentication Agent
• Captive Portal
This is the order in which authentication is checked for users.

MODULE 1: XG FIREWALL WEB PROTECTION

MODULE 1: XG FIREWALL WEB PROTECTION
• Web Policies and Application Control filters are applied in user and network firewall rules.
• A Web Policy is made up of an ordered list of rules that apply to a set of users, have one
or more activities, an action, and optionally can be scheduled to only be active at
certain times.
• The activities can include dynamic categories (ActiveX, Applets, Cookies, HTTP Upload),
Categories (e.g., Weapons), URL Groups (a custom list of domain names to match), and
file types. In addition to these, you can apply keyword content filters.
• You can also group Categories, URL Groups and File Types into User Activities and select
these in the Web Policy rules.
• Application Control filters contain applications that are grouped with an allow or deny
action.
• The filter also has a default action for unmatched applications.
• The XG Firewall comes preloaded with over 2,700 applications, and for each you can
see additional details regarding the applications categorization and characteristics.

MODULE 1: XG FIREWALL EMAIL PROTECTION

MODULE 1: XG FIREWALL EMAIL PROTECTION
• Email Protection on the XG Firewall can be configured in MTA Mode, which makes the
XG Firewall a full mail transfer agent (MTA) rather than just a transparent proxy. This
means that it is possible to configure different email routing options for different
domains.
• In MTA mode, the XG Firewall can spool emails, storing them before delivery. This means
that if your mail server is offline, the emails will be queued on the XG Firewall for delivery.
• The XG Firewall is also able to perform additional validation checks on emails as it
receives them, rejecting emails from hosts that send invalid HELO arguments or that are
missing reverse DNS entries.
• When in MTA mode, the mail proxy is configured to scan mail both transparently and
when the XG Firewall is configured as an explicit mail proxy.

MODULE 1: XG FIREWALL WIRELESS PROTECTION

MODULE 1: XG FIREWALL WIRELESS PROTECTION
• Wireless network solutions for use in businesses need to be able to provide a fast,
reliable and uninterrupted signal for the entire office. In an office environment it is
important that wireless networks provide strong security options and are able to be
easily deployed and centrally managed.
• There are three main advantages to using the Sophos XG Firewall for wireless security:
1. It is easy to install and manage with centralized configuration
2. It is secure and reliable, allowing you to use all of the security features of the XG
Firewall for your wireless connections
3. It provides flexible access, with a continuous signal throughout the entire office, and
supports multiple SSIDs for separate corporate and guest networks
• Wireless networks managed by Sophos XG Firewall can provide either limited or full
access to both the Internet and resources on the internal company network, with all of
the same security as computers that are connecting from a physical network
connection.

MODULE 1: XG FIREWALL REMOTE ACCESS
- The Sophos XG Firewall allows users and administrators to access resources protected
behind the firewall through the use of secured VPN connections. With various options
available for both desktops and mobile devices, administrators can ensure that users
access sensitive information in the most secure way possible.
Available for remote access are such options as:
1. IPsec
2. SSL
3. L2TP over IPsec
4. PPTP
5. Clientless Access
6. CISCO VPN Client

MODULE 1: XG FIREWALL LOGGING &REPORT

MODULE 1: XG FIREWALL LOGGING &REPORT
• The Sophos XG Firewall has on-box reporting built-in, which provides administrators
with a comprehensive view of what is happening on their network.
• The on-box reporting feature comes preconfigured with dashboards and reports that
administrators can refine and drill down into in order to get the exact information
they are looking for; including reports specially configured to help with compliance
management.
• The Application Risk Meter in Sophos XG Firewall provides a risk assessment based on
an analysis of traffic flowing through the network. The risk meter is displayed at the
top of the Applications & Web report tab when the User App Risks & Usage report is
selected as an easy way to view an organization’s level of security and risk.
• To help administrators identify risks and threats, Sophos XG Firewall calculates a
metric called User Threat Quotient (UTQ).

MODULE 2: DEPLOYMENT OVERVIEW OF XG
FIREWALL

MODULE 2: DEPLOYMENT MODES OF THE XG
FIREWALL
• The XG firewall is a versatile device able to fill a number of different roles in a
network.
• When deploying an XG Firewall, whether in production, POC, or even just to gather
information, there are various modes that can be used on the XG firewall to
accomplish the desired outcome.
• The available deployment modes include:-
1. classic Gateway deployment
2. Bridge Mode deployment
3. Mixed Mode deployment
4. TAP or Discover Mode for collecting information

MODULE 2: DEPLOYMENT MODES OF THE XG
FIREWALL

GATEWAY MODE
- Gateway mode is used when you want to deploy a new appliance or replace an existing
appliance with a Sophos Firewall.
- Often deployed as an edge device when in gateway mode, it acts as a barrier between
the various networks connected to the firewall.
- The Sophos Firewall is used in gateway mode when it needs to manage routing between
multiple networks and zones as well as provide security for the various networks.
- This is the most used deployment mode for firewalls and allows for routing of information
from any zone connected to the Sophos Firewall

BRIDGE MODE
- The Sophos Firewall supports bridge mode that allows the transparent passing of traffic
between the various interfaces. By putting the firewall in bridge mode, we can place it in
the network without modifying the existing design.
- This can be extremely useful when adding a firewall to an existing environment to use as a
proof of concept, or even as a drop in solution, when not being deployed as an edge
device to replace an existing firewall.
- In full bridge mode all the interfaces on Sophos Firewall are bridged together to make a
single interface.
- Sophos Firewall supports multiple bridge pairs if you are using it in a mixed mode.
- While deployed as a transparent bridge, Sophos Firewall can still process multi-subnet
traffic, and can filter which subnets can be passed over the bridge.

BRIDGE MODE
Bridge Mode
✓ Transparent ARP
✓ Multi-subnet traffic processing
✓ Filter VLANs
✓ Mid-stream connection pickup
COUTIONS:-Does not support:
• Using Sophos Firewall as a VPN concentrator
• Multiple WAN links

BRIDGE INTERFACES
- By default, a bridge that is added to the Sophos Firewall is created as a layer 2 bridge, it routes traffic across the
bridge based on the MAC address on the packets passing through the device.
- Optionally, the bridge can be converted into a layer 3 bridge by selecting the shown checkbox, where it can then
route traffic based on IP address as well as MAC address. It will then route traffic between ports that are connected
to different networks.

MIXED MODE
- Mixed mode is a combination of bridge and gateway mode, where two or more
ports are added as a bridge and the other ports are left to work in a gateway
mode.
- Mixed mode also works with multiple bridge pairs or bridges that contain more than
just two interfaces. In mixed mode, the bridges can be either layer 2 or layer 3.
- When deployed as a full bridge, all the ports are included as part of the bridge.
There is also the option to create a bridge on the Sophos Firewall with fewer ports, or
even multiple bridges, each consisting of un-used ports on the device.

DISCOVER MODE
• Discover Mode (popularly known as Test Access Point (TAP) mode, port mirroring
or SPAN (Switched Port Analyzer)), is where an administrator can deploy the
device at a point in the network where it can monitor all network traffic without
the need to make any changes to the existing network schema.
• The device to which the Sophos XG Firewall is connected (normally a switch)
forwards a copy of every packet that passes through it to the Sophos XG Firewall
for monitoring.
• This allows Sophos XG Firewall to report on the traffic it sees to demonstrate its
capabilities.

DISCOVER MODE
• The Sophos XG Firewall passively monitors all the traffic across the network and uses
the gathered data to generate a Security Assessment Report (SAR).
• The SAR can be generated from the REPORTS section of the XG firewall. It is found
under the Show Report Settings in the upper right and then click the Report
Scheduling tab.
• Click the Add button and select to create a new Security Audit Report. Name the
report then it can be configured to be run daily or weekly and emailed to a
specific email address if desired.
• A sample SAR is provided with the additional reading materials

DISCOVER MODE
• To use the Sophos XG Firewall in
discover mode, you will need to
configure port mirroring on the switch.
Different switch vendors have different
methods of enabling port mirroring.
Please refer to the documentation for
your switch when configuring discover
mode.
• Then, connect a port on the Sophos XG
Firewall (not the management port,
PortA) to the mirrored port on the
switch.
• Finally, enable discover mode by
running the command shown here on
the console. Please note, you can only
use an interface that has not previously
been assigned an IP address

FIREWALL FRAMEWORK
• Firewall Framework Flow – Forwarding Only
• This scenario shows how the XG Firewall interacts with traffic that it is flowing through
the device, either inbound or outbound.
• Firewall subsystems offer a way to intercept and manipulate the packets at the
different positions in a network stack in order to implement the firewall functionality.
These subsystems are:
1. Prerouting
2. Forwarding
3. Postrouting

FIREWALL FRAMEWORK
PREROUTING
• Protocol anomaly checks are performed on incoming packets. If necessary, fragmented
packets are reassemble prior to these checks
• After anomaly check packets are processed through DOS & Spoof prevention modules. If
the traffic is for the local loopback interface or HA dedicated interface the packets will be
bypass the DoS & Spoof check
• In the next stage packets are submitted to the connection tracking module (Conntrack).
If packet doesn’t match an existing connection a new entry is created. If the packet
matches an existing connection the packet is associated with it. If the connection is
Related (e.g. FTP connection) then a child connection entry is added, which is then
associated with it’s parent connection entry
• The packet is associated with a user ID based on the source IP address
• The packet state is inspected , and packets with an invalid state are dropped
• For the first packet in a connection the link ID is set as per configured routes for multilink
management, then the packets is associates with its destination zone
•

FIREWALL FRAMEWORK
FORWARD
• Packets undergo application classification, and are associated with an application
where possible
• The packets pass through the packet filter based on the firewall rules
• If the packet is accepted it will be submitted to the IPS if it is applied to the matching
firewall rule, or it will go straight to POSTROUTING
POSTROUTING
• If the packet is the first in the connection, the masquerading and SNAT policies are
checked and applied to the packet. For existing connections the already matched
NATing policy is used
• The connection tracking module entries are updated
• If HA load balancing is enabled, the packet is sent to the load balancer • Finally,
Quality of Service is applied

DEVICE ACCESS
• The default settings in device access allow minimal services in the WAN zone while
allowing most services in the LAN zone.
• This configuration is based on the idea that the LAN zone is a trusted zone and the
WAN zone contains many dangerous devices.
• Best practice dictates that any services that are not needed should be disabled
for any zone in which they will not be used.
• Admin Services – Allow administrative access to the XG firewall
• Authentication Services – Allow clients to authenticate themselves against the XG
firewall
• Network Services – Allows clients to ping the firewall and use it as a DNS server
• Other Services – Includes various other services including wireless and VPN
services, access to the user portal, routing, proxy services, mail and SNMP

PUBLIC KEY AUTHENTICATION
• Select the services that the ACL will apply to
• Finally, select to allow or block the selected services from the selected networks
or hosts.
• The admin user can be authenticated using public key authentication for SSH
access. This provides a mechanism that can be used to provide access without
needing to share the admin password, and it can be used to provide access to
multiple users by uploading their public keys.
• The XG Firewall supports RSA, DSA and ECDSA keys of 1024, 2048 and 4096 bits in
length.
• Keys can be created using a tool such as PuTTY Key Generator on Windows, or
sshkeygen on Linux.
• Here you can see a key that has been generated using PuTTY.

INTERFACE &GATEWAYS
• The XG Firewall supports a
number of different interface
types that can be created.
These include:
1. Bridge
2. VLAN
3. Alias
4. LAG
5. RED
6. Also available are Physical
ports and WiFi interfaces.

FAIL-OPEN BYPASS
• The fail-open bypass ports enable
data to follow through the device
even if there is a hardware or
software fault or power outage.
• Relays create a physical
connection between two ports to
create a bypass pair, and these
can be used for Bridge Mode
inline deployments.
• This means that the XG Firewall
can be installed inline with any
existing firewall without
introducing additional risk.

LINK AGGREGATION
• Link aggregation is a devices’
ability to combine multiple
physical interfaces into one
single logical unit.
• There are two main advantages
of Link Aggregation. These are:
1. Increased Bandwidth – LAG
allows for an increased amount
of bandwidth from having
multiple physical ports working
in unison
2. Redundancy – With multiple
physical ports all connected
from the XG Firewall to another
device, if one fails the other
connected ports will continue
to function and pass traffic

LINK AGGREGATION MODE
When creating a LAG on the XG firewall, there
are two different modes that are supported.
These are 802.3ad (LACP) and Active-Backup.
802.3ad (LACP) mode has to be supported by all
devices that will participate in the
LAG, that is, the XG Firewall and whichever
device the ports that are members of the LAG
are connected to, such as a switch. LACP is
commonly supported by many vendors today
and allows for both increased bandwidth and
failover between the XG firewall and another
device.
Active-Backup mode was developed by Sophos
and does not require that the device on the
other end support any special protocol. In
Active-Backup, the XG Firewall manages the
links, keeping one link active and the other in an
inactive backup state.

GATEWAY MANAGER
• The Gateway Manager on the XG
Firewall allows the configuration of IPv4
and IPv6 gateways for use with firewall
rules and policy based routing.
• New gateways are added from
CONFIGURE > Routing > Gateways
• To configure a gateway, enter the IP
address and select which interface
should be used to reach it. You can also
create custom NAT policies for the
gateway.
• Gateways can be monitored using a
health check that will test whether the
gateway is up by pinging it at regular
intervals, and email notifications can be
enabled for when the gateway state
changes.

ROUTING
• While routing is often considered a basic function of a device such as the XG firewall,
there of numerous options for routing within the device. There are simple static routes
that only look at the destination address of the traffic. These are often used internally
to control traffic flow within a network.
• The XG firewall also offers policy based routing which allows the device to dig
deeper into the traffic and make more intelligent decisions based on factors other
than just the destination, such as the source address or services.
• Dynamic routing protocols are also supported to allow the XG firewall to
communicate with neighbors and populate it’s internal routing tables with minimal
administrator interaction.
• Unlike the kernel routing, the XG routing precedence can be modified on the
console using the system route_precedence command.

ROUTING POLICY
• By default, policy routing has
the highest priority; this can
be viewed on the console,
and changed if necessary
using the system
route_precedence
command.
• Note that traffic that is
generated by the XG
Firewall is not routed by
policy routes

ROUTING PROTOCOLS
RIP is most useful in small networks that need or want dynamic routing in order to build
their routing tables. RIP is a simple protocol that is not optimized for medium or large
environments and is often accused of generating a lot of traffic if many devices exist.

LAB ACTIVITIES
• Let use the sample network to configure

MODULE 3: FAST PATH
• In the connection table, a contract is established with any device that is going
to send and receive packets.
• This is done through the use of a three-way handshake and a deep inspection of
the packet.
• The Sophos XG Firewall will learn about the traffic based on parameters like the
user-id, application-id, firewall rule id, and other connection related information.
• In Fast Path technology, since the appliance already knows the state of a
connection, the next time traffic of a similar pattern is observed, it will not have
to traverse through all of the firewall rules.
• The appliance will be able to map the firewall rule to the traffic that it recorded
earlier, thus saving processing time and increasing the throughput of the firewall.

MODULE 3: NETWORK PROTECTION
• This is a high level overview of packet flow through the XG firewall related to Fast Path
technology:
• A packet enters the XG Firewall from any zone. This can be from a WAN, LAN, DMZ,
WiFI, VPN, or any custom created zone as well.
• The incoming packet is first through the DOS and spoof prevention modules. If any
anomalies are detected, the packet is dropped. If the packets are clean, they are
then passed on to the connection tracking module.
• Connection tracking will now examine the packet. If a connection exists for the
packet, it is matched to that connection. If this is a new connection, an entry is
created in the connection tracking table.

MODULE 3: STRICT POLICY
• Strict policy is a set of protection policies that are on by default on the XG
Firewall.
• Strict policy is used to check for common attacks that are easily detected and
prevented.
• When strict policy is applied, the device drops specific traffic and attacks such as
the Winnuke attack, Land attack, Zero IP Protocol, and various other IP based
attacks against the firewall.
• If false positives are detected and strict policy is suspected to be blocking
legitimate information then it can be disabled. To turn the strict policy on or off, in
the console
• use the command: set advanced-firewall strict-policy (on/off)
• Please note that individual components of strict policy cannot be enabled or
disabled. The command disables all policies included in the strict policy module.

MODULE 3: INTRUSION PREVENTION
• Intrusion prevention focuses on examining
traffic passing through the firewall for
malicious content and blocking that traffic.
Intrusion prevention also includes DoS
protection to protect the firewall against
denial of service attacks intended not to
steal information but deny services to users
or clients.
• The IPS module is often to blame for high
resource utilization on the XG firewall. This is
often because it has not been fine tuned
to work closely with the policies that the
firewall is allowing.
• DoS protection can also be customized to
help prevent false positive events from
denying valid connections.

MODULE 3: FINE TUNING IPS POLICY
• One of the easiest ways to fine tune IPS
policies it to make sure that they are inline
with the existing firewall policies.
• For example, if there is a firewall policy
that only allows web traffic (HTTP, HTTPS,
DNS, etc.) through and it has applied to it
the default LAN to WAN IPS policy, then
the IPS engine is performing a lot of extra
work for each packet that passes though
the firewall.
• This is because the default policies are
designed to scan for all common types of
traffic including web, mail, FTP, database,
ERP, and a number of other traffic types.

• To get started, first create a new IPS
policy. This is done from PROTECT >
Intrusion Prevention > IPS Policies.
• Add a name to identify the policy. The
name is limited to fifteen characters
including spaces.
• The description should be used to better
identify the purpose of the policy and
there is the option to clone an existing
policy to bring in all of the existing rules.
When this information is filled in, click the
save button and it will take you back to
the main screen.
• From there, edit the policy to begin
adding or editing the rules.

• The IPS policy editor enables quick and easy
selection of desired IPS patterns, which helps
you create the most efficient IPS policies and
keep them current. Only needed IPS signatures
should be active, to save CPU and Memory use
and reducing the IPS performance impact
• There are three types of IPS policy rule that can
be created:
•You can search for and select specific signatures
to include
•You can filter the signatures using pre-defined
criteria 3. You can filter signatures using text-based
smart filters
• We will take a look at each of these in more
detail.

MODULE 3: PACKET STREAM
• Packet streaming allows the XG Firewall to buffer the packets within a TCP stream
and reassemble them in order to examine the stream to detect and prevent more
complex attacks.
• This is done by buffering the entire Stream of packets inside of a TCP session. Next,
the XG Firewall will re-assemble the TCP segments in to a correct stream based on
the sequence numbers.
• It can then check for overlapping packets and duplicate segments and verify their
checksums.
• During this process, the firewall will scan every packet with the IPS engine to identify
any malicious or duplicate payloads that may be hiding within the stream.

MODULE 3: NAT POLICY
• A local NAT policy is used when you want the appliance to go forward with a
different IP, rather than its masqueraded IP.
• Local NAT is used when traffic originating from the appliance (such as webcat
updates, AV definition updates, or IPS updates) need to reach the Internet.
• If the device has multiple WAN links terminated on it and the requirement is to
reach the Internet using specific IP address for all Device generated traffic,
Local NAT can be used to define which IP will be used for traffic that originates
from the XG Firewall.

MODULE 3: TRAFFIC SHAPING POLICIES

MODULE 3: ORDERING FIREWALL RULES

LAB ACTIVITIES
1. Configure local NAT policy
2. Create and account on DoS protection
policy

MODULE 4: WEB SERVER PROTECTION

• Sophos Web Server Protection hardens your web servers using Reverse Proxy
technology to protect them from modern attacks and data loss. With it, you can
securely offer applications like Outlook Web Access (OWA) and guard against
techniques like SQL Injection and Cross Site Scripting (XSS), and prevent hackers from
using these types of attacks to gain access to sensitive information like credit card
data, personal information, and social security numbers.
• Sophos Web Server Protection aids you in compliance efforts where a web
application firewall is required, such as PCI-DSS.
• The XG Firewall will monitor and manage the connections to and from your web or
Outlook Web Access servers. Using this technology, Sophos can scan all of the
transactions occurring in real-time while giving you layered security options for how
the Internet interacts with your servers, both over normal HTTP and encrypted HTTPS.

• Web Server Protection on Sophos XG Firewall uses an Apache virtual server running
on the device to filter web requests to web servers.
• This provides significantly more protection than using a simple DNAT rule to publish a
web server. One virtual server instance is created for every web service to be
protected, and the virtual server loads security modules, defined by the Protection
Policy, to filter the traffic.
• Sophos XG Firewall can also act as an authentication proxy for web apps. This
greatly increases security because attackers cannot even reach the login form on
the web server until they have authenticated with Sophos XG Firewall.

MODULE 4: PROTECTION FEATURES
• Sophos’ Web Server Protection uses antivirus to scan both uploads and
downloads with scanning engines. This means that your servers are protected
from malicious code being uploaded, and on the other side users are protected if
your servers have been compromised and infected.
• Antivirus scanning can be configured to use Sophos, Avira or both scanning
engines.
• Sophos XG Firewall can scan files as they are being uploaded to the web server,
downloaded from the web server or both. This allows you to protect the web
server, but also prevents the spread of malware if it is compromised.
• Block unscannable content, such as files that are encrypted or corrupt.
• You can limit the size of file that Sophos XG Firewall will scan. You may choose to
do this if the web service handles large non-executable data files.

• Sophos’ protection is kept simple allowing the administrator to select which protection
methods they want to enable without having to deal with pages of complex patterns and
configuration screens.
• Categories of rules can be enabled and disabled, depending on the type of web server
being protected.
1. Protocol Violations
Enforces adherence to the RFC standard specification of the HTTP protocol. Violating these
standards usually indicates malicious intent.
2. Protocol Anomalies
Searches for common usage patterns. Lack of such patterns often indicates malicious requests.
These patterns include, among other things, HTTP headers like 'Host' and 'User-Agent’.
3. Request Limits
Enforces reasonable limits on the amount and ranges of request arguments. Overloading
request arguments is a typical attack method.

Bad Robots
Checks for usage patterns characteristic of bots and crawlers. By denying them access, possible
vulnerabilities on your web servers are less likely to be discovered.
Generic Attacks
Searches for attempted command executions common to most attacks. After having breached
a web server, an attacker usually tries to execute commands on the server such as expanding
privileges or manipulating data stores. By searching for these postbreach execution attempts,
attacks can be detected that might otherwise have gone unnoticed, for example because
they targeted a vulnerable service by the means of legitimate access.
SQL Injection Attacks
Checks for embedded SQL commands and escape characters in request arguments. Most
attacks on web servers target input fields that can be used to direct embedded SQL commands
to the database.

XSS Attacks
Checks for embedded script tags and code in request arguments. Typical cross-site scripting
attacks aim at injecting script code into input fields on a target web server, often in a legitimate
way.
Tight Security
Performs tight security checks on requests, like checking for prohibited path traversal attempts.
Trojans
Checks for usage patterns characteristic of Trojans, thus searching for requests indicating Trojan
activity. It does not, however, prevent the installation of such Trojans as this is covered by the
antivirus scanners.
Outbound
Prevents web servers from leaking information to the client. This includes, among other things,
error messages sent by servers which attackers can use to gather sensitive information or detect
specific vulnerabilities.

• Cookie signing prevents cookies from
being manipulated.
• When the web server sets a cookie, a
second cookie is added to the first one,
containing a hash built of the primary
cookie's name, its value and a secret,
where the secret is only known by the
Sophos XG Firewall.
• If a request cannot provide a correct
cookie pair, there has been some sort of
manipulation and the cookie will be
dropped.

• Static URL Hardening protects against
URL rewriting by signing all of the URLs in
the page that is served.
• If a URL is requested that is not signed,
then access is denied.
• This only works with static URLs. URLs that
are dynamically generated in the client,
for example by JavaScript, will not be
signed
• Static URL hardening affects all files with
a HTTP content type of text/* or *xml*,
where * is a wildcard.
• Make sure that other file types, e.g.
binary files, have the correct HTTP
content type, otherwise they may get
corrupted by the URL hardening feature.
• Entry URLs are the unsigned URLs that
can be requested

• Form Hardening protects against web form
rewriting. It saves the original structure of a
web form and signs it.
• Therefore, if the structure of a form has
changed, when it is submitted Sophos XG
Firewall rejects the request.
• The XG Firewall also inspects and validates
the information submitted by visitors via
forms on your web sites.
• This stops malicious users from passing
invalid data which can damage or exploit
your server as it is processed.

• Blocking clients with a bad reputation uses remote lookups; these can be skipped,
and cached GEOIP-based classification can be used instead, which is faster.

- Sophos XG Firewall can act as an
authentication proxy, adding another
layer of protection between potential
attackers and web services.
- Uses can be present with either a login
form or basic authentication.
-Sophos XG Firewall will authenticate the
user, and if their credentials are correct,
will pass their requests through the web
server.
-Sophos XG Firewall can optionally pass
the user’s credentials through to the web
server to log them into the web service.
- This can only be done where the web
service supports basic authentication.

MODULE 4: WEB SERVER CONFIGURATION
• The first step is to configure the real web servers that you want to protect. To do this you
need to create a web server on the XG Firewall in Protect > Web Server > Web Servers.
• The host can be either an IP address or FQDN Host object. FQDN Host is
recommended here because hosts listed with their IP address transmit empty host
headers, which leads to problems with some browsers.
• Each web server can be created for either HTTP or HTTPS.
• Set which port the service is running on.
• Enable Keep alive to keep the connection between Sophos XG Firewall and the real
server open, instead of opening a new connection for every single request. In rare
cases where the real web server does not support keep alive properly, this feature can
provoke reading errors or timeouts, and should be disabled for the affected web server.
• Timeout period for the Keep alive option. Values between 1 and 65535 seconds are
allowed. The default is 300 seconds.

MODULE 4: WEB SERVER CONFIGURATION

MODULE 4: CONFIGURATION - POLICIES

MODULE 4: CONFIGURATION - POLICIES
• Enabling ‘Pass Outlook Anywhere’ allows RPC over HTTP traffic to traverse the
Web Server Protection module. RPC over HTTP is used heavily by Microsoft
applications such as Exchange, so is required to allow external Microsoft Outlook
clients to access Microsoft Exchange Servers protected by Sophos XG Firewall.
• Web App Protection Policies can be configured in two modes:
1. Monitor: requests are monitored and logged
2. Reject: requests are rejected
• Rigid Filtering tightens the security of the selected rules, and ensures that RFC
standards are being followed. Enabling this option may lead to legitimate
applications being blocked if they are not conforming correctly to the RFCs.

MODULE 4: CONFIGURATION – BUSINESS RULE

MODULE 4: CONFIGURATION – BUSINESS RULE
• Web Server Protection is selected by choosing it in the ‘Application Template’
dropdown.
• The hosted server is the Apache virtual server that will be running on Sophos XG
Firewall.
• Hosted Address – which interface the virtual server will listen on.
• If ‘HTTPS’ is enabled, the virtual server will accept HTTPS connections. By default it
will accept HTTP connections.
• If ‘Redirect HTTP’ is enabled, the virtual server will accept HTTP connections and
redirect the client to HTTPS.
• You can change the port that the virtual server listens for connections on. By
default it will use 80 for HTTP and 443 for HTTPS.

MODULE 4: PATH – SPECIFIC ROUTING

• In the Protected Application Server(s) you can enable path-specific routing to
define the path to which a web server’s requests are forwarded.
• For each hosted web server, one default site path route is created automatically
with a path of /.
• The device automatically applies the site path routes in the most reasonable way:
starting with the strictest, i.e., longest paths, and ending with the default path route,
which is only used if no other more specific site path route matches the incoming
request.
• The order of the site path route list is not relevant. If no route matches an incoming
request (in case the default route was deleted), the request will be denied.

• Define the path.
• Select one or more web servers to
serve requests to the path. Where
more than one web server is
selected Sophos XG Firewall will
load balance across them.
• You can select an Authentication
Policy to apply to requests made to
this path. This will be covered later in
the module.
• Restrict access to the path based
on the IP address or network the
request is coming from. The block list
takes precedence over the allow list

• There may be an instance when the
security applied to a web server
causes the application running on that
server to not function as expected.
• When this occurs, we can add
exceptions to bypass certain checks
that are causing the issues.
• Exceptions can be applied to a path
on the web server, a source IP address
or network, or a combination of the
two.
• For each exception, the checks or
threat categories to skip can be
selected.

• The exception can be used to
skip any of the common threats
categories:
1. Protocol Violations
2. Protocol Anomalies
3. Request Limits
4. HTTP Policy
5. Bad Robots
6. Generic Attacks
7. SQL Injection Attacks
8. XSS Attacks
9. Tight Security
10. Trojans
11. Outbound

MODULE 4: LOG – URL HARDENING

MODULE 4: LOG – URL HARDENING
• The Web Server Protection logs can be viewed in the WebAdmin
using the Log Viewer, or on the console.
• The log file is /log/reverseproxy.log. You can use the tail if command
to follow new entries that are added to the file.
• Here is what you would expect to see in the logs if access if being blocked
due to URL hardening.
• Verify that all of the required paths are allowed within URL hardening
configuration.
• Paths are case sensitive, so you need to add all forms that will be accessed.
• When the form hardening detects a problem you will see errors like these in
the reverseproxy.log. The important information here is the fact that it is
triggering form hardening and the URL involved.

MODULE 4: LOG – THREAT FILTER RULES

MODULE 4: LOG – THREAT FILTER RULES
In the first two you can see the rule ID that is being triggered, and so can add these
to the skip list in the Protection Policy.
• To resolve issues caused by the form hardening HTML-parser changing the initial
web request you need to use the "Never change HTML during Static URL
Hardening or Form Hardening" option, which can be enabled in the exceptions.
• To be able to use this option you will need to create a new exception for form
hardening that applies to the URL identified in the reverseproxy.log.
• Here we can see the log entries where rules for the common threat filter have
been triggered by an application.

MODULE 4: AUTHENTICATION
There are three main steps to setting up reverse authentication on Web
Server Protection. These are:
1. Optionally customize and upload an HTML form template to display to
users who are logging in
A. This can be made up of a single HTML template and multiple CSS and
image files
2. Configure the Authentication Policy, which can include the uploaded
form template
A. Here you choose between presenting a basic authentication prompt
or form-based login
B. Choose the users and groups that are allowed to login
3. Select the Authentication Policy

MODULE 4: WEB SERVER AUTHENTICATION

MODULE 4: WEB SERVER AUTHENTICATION
• You can optionally add a prefix or suffix to the username when it is passed through.
This can be used to reformat usernames into UPN (user principle name) style
username@domain or Windows domain style domainusername as required by the
web application.
• In ‘User Session’ section you can configure the timeout and lifetime settings that
Sophos XG Firewall should use.
• As we previously mentioned, Web Server Authentication can either be applied to a
whole Business Application Rule.

MODULE 4: AUTHENTICATION POLICIES

MODULE 5: SITE-TO-SITE VPN
• There are two modes of operation for IPsec: transport mode and tunnel mode.
• Sophos XG Firewall uses transport mode for remote access and host-to-host VPNs, and in
this mode only the payload of the message is encrypted. Tunnel mode is used for site-to-
site VPNs, and in this mode the payload, the header, and the routing information are all
encrypted.
• It is very common to use SSL VPNs for remote access, as they use the standard HTTPS
• port and usually work from almost anywhere. Sophos XG Firewall comes with an SSL VPN
client for Windows, but configuration packages can also be downloaded for other
platforms.
• Sophos is one of the few vendors that implements SSL VPNs for site-to-site, but it provides a
simple and effective way to configure secure access between sites.

MODULE 5: SITE-TO-SITE VPN
• The point to point IPsec VPN connection is one of the most commonly used point to point
connections today.
• Most vendors provide the ability to configure IPsec point to point connections and are
compatible with most other vendors.
• One thing to take note of, however, is that while most vendors have the same or similar
options for their IPsec configurations, those options may go by different names.
• We are going to look at the use and configuration of an IPsec VPN on the XG firewall.

MODULE 5: IPSEC VPN POLICY
Key Negotiation Tries specifies the maximum number of key negotiation tries allowed.
Set to 0 for unlimited number of tries.
The Authentication Mode is used for exchanging authentication information.
1. Main Mode consists of 6 messages. The phase 1 parameters are exchanged in
multiple rounds with encrypted authentication making it more secure
2. Aggressive mode consists of 3 messages. With Aggressive Mode, the tunnel can
be established faster than using Main Mode, as fewer messages are exchanged
during authentication, and no cryptographic algorithm is used to encrypt the
authentication information. Use Aggressive Mode when the remote peer has
dynamic IP Addresses
Enable to pass data in compressed format to increase throughput

MODULE 5: KEY EXCHANGE
Phase 1 – Internet Key Exchange (IKE)
Select the encryption algorithms that can be negotiated for phase 1. Supported algorithms are:
• 3DES – Triple DES is a symmetric strong encryption algorithm that is compliant with the OpenPGP
standard. It is the application of DES standard where three keys are used in succession to provide
additional security
• AES – Advanced Encryption Standard offers the highest standard of security. The effective key
lengths that can be used with AES are 128, 192 and 256 Bits. This security system supports a number
of encryption algorithms
• Serpent – Serpent is a 128-bit block cipher i.e. data is encrypted and decrypted in 128-bit chunks,
and a variable key length of 128, 192, or 256 bits. The Serpent algorithm uses 32 rounds, or iterations
of the main algorithm. Serpent is faster than DES and more secure than Triple DES
• BlowFish – BlowFish is a symmetric encryption algorithm which uses the same secret key to both
encrypt and decrypt messages. It is also a block cipher which divides a message into fixed length
blocks during encryption and decryption. It has a 64-bit block size and a key length of anywhere
from 32 bits to 448 bits and uses 16 rounds of main algorithm
• TwoFish – TwoFish is a symmetric key block cipher with a block size of 128 bits and key sizes up to 256
bits

MODULE 5: KEY EXCHANGE
Phase 2 – IPsec (Internet Security Association and Key Management Protocol / ISAKMP)
Select the encryption algorithms that can be negotiated for phase 2.
Select the authentication algorithms that can be negotiated for phase 2.
Up to three combinations of encryption and authentication algorithms can be selected. The remote
peer must support at least one of the combinations for the VPN to be successfully established.
PFS Group (DH Group) specifies the Diffie-Hellman group which controls the key length used for
encryption. The default is to use the same as phase 1.
Specify the Key Life in seconds. Key Life is the amount of time that will be allowed to pass before the
key expires. The default is 3600 seconds (1 hour).

MODULE 5: CERTIFICATE AUTHENTICATION
There are three certificates required:
1. The ‘Default’ CA certificate from the London Head Office, as we will use this to
sign the other certificates
2. A certificate for the London Head Office XG, this will be configured as the local
certificate on the Head Office side of the VPN
3. A certificate for the New York Branch Office XG, this will be configured as the
remote certificate on the Head Office side of the VPN
All three certificates need to be downloaded from the London Head Office XG
Firewall, and uploaded on the New York Branch Office XG Firewall.
For the CA certificate, on the certificate needs to be uploaded so it can be used as a
verification CA. To upload the other two certificates you will need to include both the
certificate and the private key.

• You can now configure the VPN connection on both the Head Office and Branch Office XG Firewalls.
• In the VPN configuration you need to set the ‘Authentication Type’ to Digital Certificate and select a certificate for
each side of the VPN, local and remote.
• When the certificates are selected it will automatically configure the local and remote IDs for the VPN.

MODULE 5: NAT ON VPN
• The solution is for both ends of the VPN to NAT their networks to different subnets
which do not overlap.
• In this example, Sophos XG Firewall in the London office will NAT the entire
192.168.1.0/24 subnet to 10.1.1.0/24.
• Sophos XG Firewall in New York will NAT the entire 192.168.1.0/24 subnet to
192.168.30.0/24.
• As these two subnets do not overlap, traffic can be routed successfully.
• If the client 192.168.1.115 in New York wants to access 192.168.1.10 in London, they
request 10.1.1.10 which is sent through the VPN, and NATed on arrival in London to
the correct IP

MODULE 5: NAT OVERLAP
Here, you can choose to perform a network NAT for one or more of the local subnets.

MODULE 5: VPN FAILOVER ADVANTAGE
The advantages of using VPN failover are that:
• It reduces the possibility of a single point of failure by utilizing multiple WAN links
• It reduces downtime in the event of a failure by removing the need for manual
intervention to establish new connections
• It reduces the failover time of a VPN connection with redundant VPN tunnels and
VPN monitoring
• The firewall implements failover using a VPN connection group. A VPN group is a set
of VPN tunnel configurations. The Phase 1 and Phase 2 security parameters for each
connection in a group can be different or identical, except for the IP address of the
remote gateway. The order of connections in the group defines fail-over priority of
the connection
• When the primary connection fails, the subsequent active connection in the group
takes over without manual intervention and keeps traffic moving. The entire process is
transparent to users

MODULE 5: VPN FAILOVER ADVANTAGE

MODULE 5: RED OVERVIEW
RED connections use a small hardware RED device at the remote location and all
configuration for that device is done locally at the XG firewall.
At the remote location, the RED requires:
1. A power connection
2. A network connection
3. A DHCP server to provide an IP address, DNS server and default gateway
4. Port 3400 TCP
5. Port 3400 UDP (RED 10)
6. Port 3410 UDP (RED 50 and RED 15)

MODULE 5: RED DEPLOYMENT
• On the RED interface, click the Menu icon and select Download Provisioning File from the resulting menu.
• Save the resulting .red file to a location of your choosing that will be available to the XG firewall that will be
acting as the client such as a cloud drive or a USB stick

MODULE 6: SOPHOS TRANSPARENT AUTHENTICATION SUITE (STAS)
• Let’s review the purpose and functionality of the Sophos Transparent Authentication
Suite, or STAS.
• The purpose of STAS is to provide reliable transparent SSO authentication for network
users without requiring a client on the endpoint.
• It employs an agent on the Microsoft Active Directory Domain Controller that monitors
and stores authentication activity and exchanges authentication information with the
XG Firewall making user-based policy enforcement easy.
• The STAS software must be installed on all Domain Controllers to ensure that all logon
events can be monitored. It is important to note that the STAS software only works with
Microsoft Active Directory, and only works with IPv4.

MODULE 6: AUTHENTICATION
• The domain controller writes the login details to the Security event log with ID
4768, this includes the IP address of the computer and the name of the user that
logged in. Note that in Windows 2003 the event ID is 672.
• The Live Users can be found in MONITOR & ANALYZE > Current Activities > Live
Users.
• As STAS is monitoring the event logs, you need to ensure that successful logon
events are being audited in the Local Security Policy.
• STAS, which is installed on the domain controller, monitors the event logs for login
events. When a login event is detected, the STAS records the details.
• STAS notifies XG Firewall of the login and supplies the details recorded from the
event log, this is done on port 6060.

MODULE 6: COLLECTING STAS
• The XG Firewall at the branch office will
then accept the traffic from the
Collector and be able to authenticate
the user.
• Depending on the type of VPN you are
using (SSL or IPsec) will determine what
source IP address will be used for the
response. If the IP address is unknown to
the collector it will reject the response.
• To correct this you can use a local NAT
policy to ensure the response comes
from the correct IP address.

MODULE 6: COLLECTING STAS
• There are a few things that you should remember when deploying and configuring
STAS:
• All of the Collectors should be configured with the IP addresses of all of the XG
Firewalls so that all of the firewalls have all of the logged in users
• All of the Agents should be configured with the IP addresses of all of the Collectors
to provide redundancy
• Collector groups provide redundancy, and you can have a maximum of five
Collectors in a Collector group

MODULE 6: SATC AUTHENTICATION
• When SATC is installed on a Terminal server it registers itself as a service and creates
an LSP hook.
• LSP, or Layered Service Provider, is a feature of Microsoft Windows Winsock 2 Service
Provider Interface (SPI) that uses Winsock APIs to insert itself into the IP stack so that it
can intercept and modify inbound and outbound network traffic.
• SATC will register three different hooks, one for TCP/IP, one for UDP/IP, and a final
one for RAW/IP. These allow the SATC LSP to intercept and modify traffic bound for
the XG Firewall.

• The installation of the SATC software is very straight forward, you simply need to
supply the IP address of the XG Firewall.
• When SATC is installed on a Terminal server it registers itself as a service and creates
an LSP hook.
• LSP, or Layered Service Provider, is a feature of Microsoft Windows Winsock 2 Service
Provider Interface (SPI) that uses Winsock APIs to insert itself into the IP stack so that it
can intercept and modify inbound and outbound network traffic

• To enable LDAPS, you must install a certificate which is located in the Local Computer's
Personal certificate store and has a private key that matches that certificate.
• The private key must also be correctly associated with the certificate. The requirements for
the this include:
• The private key must not have strong private key protection enabled.
• The Enhanced Key Usage extension needs to include the Server Authentication object
identifier.
• The certificate must also have the Active Directory fully qualified domain name of the
domain controller (for example, DC01.DOMAIN.COM) in:
• The Common Name (CN) in the Subject field.
• A DNS entry in the Subject Alternative Name extension.
• Another option is that the certificate was issued by a CA that the domain controller and all
of the LDAPS clients trust.
• A final option could be that trust is established by configuring the clients and the server to
trust the root CA to which the issuing CA chains.

MODULE 6: RADIUS ACCOUNTING
• RADIUS accounting can be configured on the XG firewall so that it can send
accounting start and stop messages to a radius server. This allows the radius server
to track network usage for auditing and billing purposes. There are three main
advantages to radius authentication:
1. Real-time data collection
2. Accounting data can be collected and stored at a central location
3. Third-party products can be used to analyze RADIUS accounting data to provide
charge-back, performance, and exception reports

MODULE 6: API
• The XG Firewall has an XML API
that can be used to allow
applications to communicate with
the device.
• To get started the API needs to be
enabled for a specific set of
allowed IP addresses in SYSTEM >
Backup & Firmware > API.
• The API works by passing XML
formatted requests to the
APIController URL shown here
.

MODULE 7: SYNCHRONIZE SECURITY
.
• We will now take a closer look at how Security Heartbeat works.
• The Security Heartbeat provides intelligent communication between endpoints that
are manage in Sophos Central and the XG Firewall so that they can coordinate their
response to threats. This includes:
1. A small heartbeat, which is a few bytes sent every 15 seconds
2. Events such as detections
3. The health status of the computer, which can be either GREEN, YELLOW or RED
4. And threat source information requested by the XG Firewall

.

.
• XG Firewall can only protect computers and servers from a compromised
computer if the traffic is traversing the XG Firewall as it is in this example. Computers
that are directly connected to the same switch as the compromised computer
would still be vulnerable.
• The XG Firewall will only block the traffic from the infected computer, all of the
other computers connected through the same port will still have network access.
• Once the Sophos Endpoint Agent has cleaned up the malware; Security Heartbeat
will send its updated health status to the XG Firewall, and the XG Firewall can allow
it to access hosts and networks as normal.

• Sophos Central is used to broker trust between the Central managed computer and the XG
Firewall.
• The first stage is for the XG Firewall to be registered with Sophos Central. This is done by
entering the credentials for a Sophos Central administrator on the XG Firewall in PROTECT >
Advanced Threat > Security Heartbeat.
• When the XG Firewall registers with Sophos Central it receives:
1. A certificate to identify itself
2. The IP address and port the computers will use for the heartbeat
3. And a list of IDs for the computers that are managed in that Sophos Central account and
their client certificates
• Shortly after the XG Firewall is registered Sophos Central will provide the supported computers
with the information they need to initiate a heartbeat, including:
1. A list of the CAs used to generate the XG Firewall certificates
2. A list of the XG Firewall IDs that are registered • The IP address and port to use for the
heartbeat This information is stores on the computer in:
3. %ProgramData%SophosHearbeatConfigHeartbeat.xml and is updated with regular
polling.
.

.
• After the XG Firewall has been deployed, discover ports can be managed using the
Console command system discover-mode tap.

MODULE 8: WIRELESS PROTECTION
.
Sophos Access Points are designed to be simple to deploy, however there are a few
places where issues can arise, particularly in larger or more complex networks.
At a high-level there are three steps:
1. Connect the access point to the network and power. The access point must be
connected to a network that provides a DHCP IP address and default gateway
2. The Access Point will appear in the XG Firewall WebAdmin and must be approved. The
Access Point will only appear in the WebAdmin if Wireless Security is enabled in
PROTECT > Wireless > Wireless Settings, and the Access Point is connected from an
allowed zone that is defined in the same place. As part of the approval you must
select the country where the access point is located; this will determine which
channels the access point can use to ensure compliance with local regulations
3. Once an Access Point is accepted in the WebAdmin it needs one or more wireless
networks to be assigned to it before it becomes active
Note: Access points will appear as inactive if they do not have a wireless network
assigned to them, or if the wireless network is not being broadcast because it outside of
its scheduled time

MODULE 8: WIRELESS DEPLOYMENT
.

THANK
YOU
By Sophos Engineer and Architect
Agnes Munisi
0715 000330

SOPHOS-XG Firewall Administrator PPT.pptx

More Related Content

Similar to SOPHOS-XG Firewall Administrator PPT.pptx

Recently uploaded

SOPHOS-XG Firewall Administrator PPT.pptx