::::Different types of Engines used by the Smoothwall system::::
1. Two web filter engines:
1.Guardian3               2.Web proxy
2.Anti-malware – VIPRE
3.Anti-spam – MailShell
4.IPS – SNORT

:::::IP address format on smoothwall::::::
single IP: 192.168.1.1
range: 192.168.1.1-192.168.1.9
subnet: 192.168.1.0/24 (CIDR) or 192.168.1.0/255.255.255.0

 ::::Updates::::::

(latest update to date is update 68 on smoothwall systems)
1.System » Maintenance » Updates
(summaries of new features, security features and bug fixes)
(each update will also have a reference bug number that has been addresses in the update)
(press download button to retrieve them and then install button to install them)
(after installing update, a reboot will be required)
2. System » Maintenance » Scheduler->Dowload updates management->Download updates(enable)
(update check is done on weekly basis and new alert trigger can be setup, when new updates are available)
(after installing update, a reboot will be required)

Q: What are the main feature differences between the Windows Kerberos and NT LAN Manager (NTLM) authentication protocols? Why is the Kerberos protocol generally considered a better authentication option than the NTLM protocol?

A: NTLM is a challenge/response-based authentication protocol that is the default authentication protocol of Windows NT 4.0 and earlier Windows versions. For backward compatibility reasons, Microsoft still supports NTLM in Windows Vista, Windows Server 2003 and Windows 2003 R2, Windows 2000, and Windows XP.

Starting with Win2K, Microsoft implements Kerberos as the default authentication protocol for the Windows OS. This means that besides an NTLM authentication provider, every Windows OS since Win2K also includes a client Kerberos authentication provider.

Table 1, below, compares Kerberos to NTLM, the default authentication protocol of NT 4.0 and earlier Windows versions. The next paragraphs expand on some of the major feature differences (as listed in Table 1) between the Kerberos and the NTLM authentication protocols and explain why generally Kerberos is considered a better authentication option than NTLM.

• Faster authentication. When a resource server gets Kerberos authentication information (in Kerberos speak “tickets” and “authenticators”) from a client, the resource server has enough information to authenticate the client. The NTLM authentication protocol requires resource servers that aren’t domain controllers (DCs), to contact a DC to validate a user’s authentication request. This process is known as pass-through authentication. Thanks to its unique ticketing system, Kerberos doesn’t need pass-through authentication and therfore accelerates the authentication process.
• Mutual authentication. Kerberos can support mutual authentication. Mutual authentication means that not only the client authenticates to the service, but also the service authenticates to the client. Mutual authentication is a Kerberos option that the client can request. The support for mutual authentication is a key difference between Kerberos and NTLM. The NTLM challenge-response mechanism only provides client authentication. In the NTLM authentication exchange, the server generates an NTLM challenge for the client, the client calculates an NTLM response, and the server validates that response. Using NTLM, users might provide their credentials to a bogus server.
• Kerberos is an open standard. Microsoft based its Kerberos implementation on the standard defined in Request for Comments (RFC) 4120. RFC 4120 defines version 5 of the Kerberos protocol. Because Kerberos is defined in an open standard, it can provide single sign-on (SSO) between Windows and other OSs supporting an RFC 4120-based Kerberos implementation. You can download RFC 4120 from the Internet Engineering Task Force (IETF) at http://www.ietf.org. NTLM is a proprietary authentication protocol defined by Microsoft. The NTLM protocol is not specified in an open standard document (for example in an IETF RFC).
• Support for authentication delegation. Thanks to authentication delegation, a service can access remote resources on behalf of a user. What delegation really means is that user A can give rights to an intermediary machine B to authenticate to an application server C as if machine B was user A. This means that application server C will base its authorization decisions on user A’s identity rather than on machine B’s account. Delegation is also known as authentication forwarding. You can use delegation for authentication in multi-tier applications. An example is database access using a Web-based front-end application. In a multi-tier application, authentication happens on different tiers. In such a setup, if you want to set authorization on the database using the user’s identity, you should be capable of using the user’s identity for authentication both on the Web server and the database server. This is impossible if you use NTLM for authentication on every link, simply because NTLM doesn’t support delegation.
• Support for smart card logon. Through the Kerberos PKINIT extension, Win2K and later versions include support for the smart card logon security feature. Smart card logon provides much stronger authentication than password logon because it relies on a two-factor authentication. To log on, a user needs to possess a smart card and know its PIN code. Smart card logon also offers other security advantages. For example, it can block Trojan horse attacks that try to grab a user’s password from the system memory. The NTLM authentication protocol doesn’t support smart card logon.

Table 1: Kerberos-NTLM Feature Comparison

Kerberos

Capturing Kerberos packets using wireshark

web proxy service can be configured to operate in either transparent or non-transparent mode – but what are the differences, and how should you choose between them?

In transparent mode, there are no special configuration steps needed to setup client browsers, thus allowing the proxy service to be activated and in-use almost immediately. Once activated, all traffic destined for the Internet arriving on port 80 is automatically redirected through the proxy. With the latest Guardian products you can even use NTLM with Active Directory in conjunction with transparent proxying allowing for single sign on and minimal network configuration.

Both transparent and non-transparent proxying can be used together at the same time. Enabling transparent does not stop non-transparent from working. In situations where transparent is the norm but a specific application requires non-transparent you can simply configure the proxy settings in that application. Both modes have pros and cons. This article explains how to decide on the most appropriate mode for your network.
When to avoid transparent proxying
Transparent mode should be avoided in the following situations:

• When you want to filter HTTPS sites – Content filtering cannot be applied to HTTPS traffic because transparent proxying cannot redirect HTTPS. HTTPS pages are encrypted, so content filtering cannot be applied to HTTPS pages – only filtering on the unencrypted URL will work. In general, transparent proxying is not robust enough to guarantee restrictions on web downloads or access to inappropriate sites. What you can do, however, is block all HTTPS through traffic using outgoing firewall rules and then those few that require HTTPS can have their browser settings configured to manual proxy settings.
• When using proxy authentication – Proxy authentication cannot be used when operating in transparent mode. This is because the browser does not know that a proxy is being used (i.e. the proxy is transparent) and consequently does not know how to respond to a proxy authentication request.
• When using Ident for authentication – Ident with transparent proxying is possible, but all Ident servers must be configured to accept any request, not just one qualified by correct destination IP and ports.
• When using web-enabled client applications – Applications that connect to the Internet are often confused by transparent proxying. This can normally only be resolved by configuring the client application with the proxy details.
• When you want to use the SSL Login authentication method. – It is not possible to be redirected to the requested website once logged in – this requires the use of the Guardian proxy in non-transparent mode.
• When exceptions are required – If a client needs to have direct access to a particular domain without going through the proxy, transparent mode should not be used as such a setup is very difficult to configure and manage.
• When you have no local DNS server – If your computers are using transparent proxying and you have no local caching DNS server then all requests will require a DNS lookup to your ISP slowing down browsing. Using manual proxy settings will cause the proxy to do the DNS lookups, which it will cache, and speed up web browsing. An example might be in a basic Web Cafe with no firewall or router that has a caching DNS.

Why use non-transparent proxying?

The main reason to use non-transparent (or manual proxying) is so that the web browser and other client applications know that a proxy is being used, and so can act accordingly. Initial configuration of a non-transparent proxy might be trickier, but ultimately provides a much more powerful and flexible proxying service.

Another advantage of non-transparent proxying is that spyware and worms that use the web for transmission may not be able to function because they don’t know the proxy settings. This can reduce the spread of malicious software and prevent bandwidth from being wasted by infected systems.

Configuring proxy settings in non-transparent mode

When using non-transparent proxying, appropriate proxy settings must be configured on client machines and browsers. This can be achieved in a number of different ways:

• Manually – Proxy settings can be entered manually in most web browsers and web-enabled applications. Usually such settings are entered as part of the applications Connection Settings or similar. The address of the proxy is required, along with the proxy port number. These settings are displayed on the “Services / web proxy” and “Guardian / web proxy” pages as part of the “Automatic configuration script” region.
• Automatic configuration script – The Smoothwall proxy provides aproxy.pac file that can be used to automatically configure proxy settings in most Internet browsers. To use the automatic configuration script, enter the URL displayed in the “Automatic configuration script” region of the “Services / web proxy” and “Guardian / web proxy” pages into your browser software.
• Microsoft Windows 2000 domain – In a Windows 2000+ domain, proxy settings can be configured in the domain security policy. This eliminates the need to manually configure any part of the users system.
• Automatic discovery – Many browsers support automatic discovery of proxy settings using the WPAD (Web Proxy Auto-Discovery) protocol. This is relatively easy to configure if you have a local DNS server.
• Using DHCP to distrubute proxy settings – DHCP can also be used to set proxy settings. That might be a better method than using security policies. Currently the DHCP server on the Smoothwall firewalls cannot be used for giving out proxy.pac locations.
• Microsoft Windows login script – The Windows login script can be used to import a registry file which will automatically configure the system wide proxy settings.
• .ini files – Browsers like Firefox can be configured automatically with ini files. Such files could be copied or modified as part of the login script on a Microsoft Windows or Linux network.
• Third party solutions – Third party applications are available for Windows which can, at login, automatically configure web browser proxy settings. These range from simple programs designed specifically to automate proxy configuration, or more sophisticated applications that provide a range of services such as monitoring the users desktop.

When to use transparent proxying

• When minimal or no network configuration is required.
• Transparent proxying can be useful in mixed environments containing Unix, Linux, Apple Mac and Microsoft Windows systems. This allows quick access to the web proxy for everyone, without having to configure a multitude of different platform specific applications and browsers.
• Transparent mode can be used for convenience if Guardian is being used to provide non-HTTPS filtering. However, if Guardian is being used to guarantee prevention of abuse, non-transparent proxying should be used or instead use transparent and have outgoing HTTPS blocked at the firewall.