The HotBrick HSS 6000 is a
secure hardware appliance designed to remove spam and
viruses from the email systems of small, medium, and
large enterprises. With its bandwidth aggregation
feature the HSS 6000 is the perfect solution to increase
your network speed. This product's superior features
include two WAN Ports for redundancy or load-balancing.
In the event that a VPN tunnel fails, the HSS 6000 will
re-establish a tunnel over the second WAN port
connection - Auto Failover. With its unique features
such as QoS, Dynamic DNS, multiple IP's, DMZ, the HSS
6000 gives you the best return on your investment.
- Stateful packet filter
(Deep packet inspection) - Denial of Service
(DOS) - Source Network Address Translation
(SNAT) - Destination Network Address Translation
(DNAT) - Multi DMZ - Real DMZ (unprotected) -
Port forwarding - Advanced IDS – Intrusion Detection
System - IPS/also internal network scan
The firewall is equipped
with a mail transport agent (MTA) thus enabling the
firewall to send/receive mail using the SMTP protocol
and reroute this mail according to internal
configuration and/or MX-records. Part of this
mail-handling consists of queuing the mail for deferred
delivery.
Setup an IPSec connection
according to RFC 2401 through RFC 2409, thus enabling
the firewall to participate in any of the following
network layouts:
● Transport mode IPSec
(host-host)
● Tunnel mode IPSec (lan-host,
host-lan, lan-lan)
The firewall will support the
following encryption algorithms: AES, 3DES,
blowfish.
Hashing will be done using any of the
following algorithms: MD5, SHA-1.
Both “main
mode” and “aggressive” mode, using Diffie-Hellman groups
1 and 2, will be supported.
The user can configure the
firewall to accept specific traffic. Any traffic not
specified by the user will not be accepted. A graphical
network selection system is provided to allow the user
to select acceptable traffic. This system will be
augmented with several install wizards to provide faster
and easier setup paths. These wizards include: LAN
management, internet connection setup, Port forwarding
(DNAT), IPSEC tunnel management, VPN user management,
DMZ server management.
The Rede service is a very
low-cost solution, considering the great benefits it
provides in productivity and bandwidth saving. 1.5
billion web pages database with more than 30 categories
P2P control. IM(Instant Messaging)
Control Music download control Customizable
Reports. Scalability and Load Balance Support
Constant database upgrade Customizable rules by
IP, User, Group and Time Download Control SSL
Enabled
Due to the ability to use
AntiVirus, all mail handled by the MTA can be scanned.
The user will be provided with a means to load a license
key, thus enabling to be automatically updated hourly.
Mail found to contain a virus can be quarantined,
bounced, discarded, or passed unmodified. A warning
message will be sent to a postmaster account stating
that the mail contained a virus and what action has been
taken. This message can optionally be included in a
digest mail sent at regular intervals to the warning
account.
Besides providing content filtering, the
web content filter will also be used to provide
antivirus services on downloads. The AntiVirus scanner
used to scan email will also be used to scan these
downloads. Because not all features of the web content
filter are always desired but antivirus generally is, a
method is provided to switch off the scoring system to
only virus-scan downloads and bypass other filters. When
a virus is found the download will be invalidated by
replacing the downloaded content with an HTML page
describing the problem. When user authentication is used
a message will be sent to the following email address:
proxyusername@localdomain, stating the fact that a virus
has been found during
downloading.
The firewall will feature a
caching web-proxy server. This server will be able to
authenticate web access of users on the local network.
This authentication can be based on a network address or
a username/password combination in conjunction with the
network address. User authentication can be done against
a local user list or via Radius.
Several access
control methods will be provided:
proxying and
caching of HTTP, FTP, and other URLs proxying for
SSL cache hierarchies ICP, HTCP, CARP, Cache
Digests transparent caching WCCP extensive
access controls HTTP server acceleration SNMP
caching of DNS lookups
The proxy server will
be equipped with a statistical tool, capable of
collecting data about frequently visited pages. Using
this tool, in combination with blacklisting, unwanted
web access can be prevented.
The firewall will be
able to regularly check for software updates at a
configurable update server. These updates will need to
be signed by a Hotbrick-only certificate, thus
preventing any non-Hotbrick updates from being
installed.
Besides software updates the firewall
will regularly check for updates of the onboard virus
scanner and will install these updates. This check will
automatically be performed at the update site of the
used virus scanner.
- 19" 1U chassis, PIV level
system platform - CPU: P4 2.8 Ghz - Memory 1GB
SDRAM - Harddisk 40 Gb - 200W ATX Power
Supply - Serial port for external backup modem/ISDN
or console port - 2WAN FLEX - 2DMZ FLEX - 2LAN
FLEX
The firewall will be able
to connect to the internet using any of the following
protocols: Static IP,DHCP,PPTP, PPPoE, and L2TP.
Load balancing provides
multiple routes to the internet, each of which will
carry a part of the TCP load. This will be session based
and will therefore not split a single TCP session over
multiple routes since this is not possible in standard
TCP networking. UDP and ICMP datagrams will be balanced
evenly along the routes. This behavior should be
combined with failover to prevent part of the traffic
from disappearing in the event of a failed line.
Multiple routes to the
internet are provided, but only one will be used for
normal traffic. Along with the traffic, a check using an
ICMP datagram will be sent to determine the status of
the line. When this line-down detection system discovers
a down state, the traffic will be switched to a backup
line. The line-down detection will retry the failed line
until a line up state is discovered. The traffic will
then be rerouted along the primary route.
Both functions will be
generally implemented:
Every route can be (and
should be) provided with a check mechanism. The failover
behavior will be provided by a priority mechanism. When
2 or more lines have the same priority load-balancing
will be performed. When a line has a lower priority it
will function as a failover backup line. When no more
backup lines are available the traffic will
fail.
A user interface mechanism will be provided
to mark a line as failed or free, overruling the
automatic discovery.
DMZ support is implemented
by using a firewall bridge configuration. The
DMZ-segment (carrying public addresses) will be bridged
over two or more devices. ARP traffic will be bridged as
is, IP traffic will be filtered by the packetfilter
subsystem. Every single host in the DMZ can be given a
separate policy.
Using this flexibility some
standard configurations will be available via an
install-wizard:
1) A unfiltered DMZ (similar to a
open hardware DMZ)
2) An filtered DMZ with
unspecified hosts
3) Specific DMZ hosts, each
with a separate policy.
The firewall will be able
to maximize traffic on a per protocol
basis.
The firewall will be
equipped with a DynDNS client script, allowing the
firewall to register it's current address at the DynDNS
servers using a user provided account.
The firewall will be
equipped to allow VPN connections from computers on the
internet using the PPTP protocol. These connections will
allow the client computers access to the internal
networks. The PPTP server will support authentication
using the MS-CHAPv2 protocol and will support Microsoft
Peer-to-Peer Encryption(MPPE).
The firewall will be
equipped to allow VPN connections from computers on the
internet using the IPSec/L2TP protocol suite. These
connections will react similarly to the above mentioned
PPTP clients, but support an underlying IPSec Transport
mode tunnel.
When both ends of an IPSec
tunnel consist of this type of firewall (or later
versions) and one of these firewalls has a backup
internet connection, the firewall will be able to switch
the IPSec tunnel to the backup connection when the
primary route fails. Thus traffic will be restored in
case of a failed line at one end of the tunnel.
The firewall will be
equipped with the ability to scan incoming email for
signs of Unsolicited Bulk mail (SPAM). When spam is
detected the same options hold as for virus scanning,
augmented with the ability to mark the mail with a spam
tag before passing them to the original receiver
The firewall will be able
to fetch mail from remote POP servers and feed this mail
to the MTA.
The firewall will have the
ability to store mail destined for local users in
onboard POP3 boxes.
The firewall will be
equipped with an IDS implementation to protect any
passing traffic against currently known security
vulnerabilities. When such traffic is detected the
system will be able to alert the administrator by an
email alert and a log entry.
A prevention system, based
on the above mentioned IDS system, will be provided.
This system will be alerted by the IDS system and will
enable a blocking rule in the packet filter, thus
preventing any traffic from the hazard source from
entering the firewall and the protected networks behind
it. This blocking rule will remain for a configurable
timeout period after which the rule will be
automatically removed. Optionally the rule can be frozen
by the administrator to keep it enabled. Likewise a
whitelist option will be available to exclude a given
host from ever being blocked by the IPS system.
The firewall will be
equipped with an internal radius server. The RADIUS
software can read multiple password databases and use
several kinds of authentication
schemes
Besides having an onboard
radius server, the firewall will be able to authenticate
VPN clients by contacting a Radius server: either the
onboard server or another one via the network.
The firewall will be
equipped with a DHCP server. This server will provide
hosts on the local area networks with a valid IP address
from the local range. This address will be taken from a
pool of 100 addresses per lan, using the range between
addresses 100 to 200 in the last octet of the network
address. E.g. a 192.168.99.0/24 network will provide a
DHCP range of 192.168.99.100 to 192.168.99.200. The DHCP
server can also provide static IP-addresses to internal
hosts using the entire network range as a
pool.
This chosen range is a result of a policy
decision based on the following arguments:
The
DHCP server is only meant for small network topologies.
When a larger network is required the network
administrator should migrate DHCP services to an
internal server. From a security point of view the
firewall should know as little as possible about the
internal topology, therefore in larger networks (with
internal servers) these kind of services should not be
provided by the firewall.
Besides addresses, the
DHCP server provides some metadata about the network
layout.
This metadata consists of:
● An
appropriate subnet mask.
● The network's
broadcast address.
● A default gateway pointing
to the firewall itself.
● A DNS server pointing
to the firewall itself.
● A DNS search string
using the primary domain of the firewall.
●
Timeserver information, pointing to the firewall
itself.
Again, because of the same policy
decision, these values can not be changed in the
interface.
The firewall will be
equipped with a caching DNS server. Using this server
the firewall can resolve name queries without the need
to forward the request to the provider. Optionally a DNS
forwarder can be selected. The DNS will cache responses
to provide a lower latency to future requests. The
firewall will also answer queries for a top-level domain
called "firewall" and respond with it's own address.
This also goes for the MX-record "firewall", thus
providing a uniform way to mail to the firewall.
The firewall will be
equipped with a timeserver. This timeserver will operate
according to the NTP standard. Besides the server a NTP
client will also be provided. This client can be
configured by the user to use specific time sources.
The firewall will be
equipped with a data collection system based on SNMP V2
to provide network statistical data. This SNMP server
will be reachable by the community name “firewall” and
will be a read-only configuration.
The firewall will be
equipped with several network diagnostic tools. These
tools include: Ping, traceroute, a network statistical
tool (NTOP), a DNS query tool, and a traffic dumper.
The firewall will be
equipped with a means to read and search the onboard
logfiles. These files will provide information about all
relevant subsystems, including proxy, firewall, and
maillogs. Optionally any logfile can be remotely logged
by one or more of the following means: daily E-mail,
remote loggingserver (running BSD-style syslogd) and/or
download of the logfile.
The firewall will be able
to regularly check for software updates at a
configurable update server. These updates will need to
be signed by a Hotbrick-only certificate, thus
preventing any non-Hotbrick updates from being
installed.
Besides software updates the firewall
will regularly check for updates of the onboard virus
scanner and will install these updates. This check will
automatically be performed at the update site of the
virus scanner
The configuration of the
firewall can be downloaded in binary format. This
enables a fast replacement procedure in the event of a
hardware failure or configuration errors.
