MailScanner Installation and Configuration: Part Two

MailScannerIn the previous article, we introduced MailScanner and covered installation as well as basic configuration. In this article, we will look at some of the other configuration options.

If we navigate to Services -> MailScanner, there are nine tabs. The second tab is “Attachments“. Under the “Attachments” heading, there are several settings. The “Attachments features” list box controls how attachments are handled. “Expand TNEF” causes MailScanner to expand TNEF (Transport Neutral Encapsulation Format) attachments. TNEF is a proprietary e-mail attachment format used by Microsoft Outlook and Microsoft Exchange Server. “Deliver Unparsable TNEF” will do the opposite, and leave TNEF attachments unexpanded. “Find Archive By Content” will enable searching archives. “Unpack Microsoft Documents” will expand non-TNEF Microsoft attachments, and “Zip Attachments” will allow zip attachments through.

TNEF Contents” specifies what to do when TNEF attachments are expanded. If this is set to “no”, a TNEF attachment will be listed as an attachment, but not the attachments contained therein. If however, this is set to “add” or “replace”, then the attachments contained in the archive will be added to the list of attachments in the message, and recipients of messages sent in this format will be able to read the attachments even if they are not using Microsoft Outlook.

Maximum Attachment Size” specifies the maximum size (in bytes) of any attachment in a message. If this is set to zero, no attachments will be allowed. If this is set to less than zero, then no size checking will be done. The default value is -1.

Scrolling down, you will see edit boxes containing two separate config files: filename.rules.conf and filetypes.rules.conf. filename.rules.conf allows or denies certain files based on the file’s extension, while filetypes.rules.conf allows or denies certain file types based on their MIME (Multipurpose Internet Mail Extensions) type.

The next tab is “Antivirus“. under the “Antivirus” heading, there are several settings. The first is “Virus scanner features“. “Virus Scanning” is enabled by default, as is “Check Filenames In Password-Protected Archives“. In addition, you can enable such features as “Deliver Disinfected Files” (deliver files after they have been disinfected by the antivirus engine), “Still Deliver Silent Viruses“, “Block Encrypted Messages“, “Block Unencrypted Messages“, and “Allow Password Protected Archives“. The next setting is “Virus scanner“, which controls which virus scanner to use. Possible settings are “auto” (let MailScanner decide what to use), “clamav” (Clam AV), “clamd” (the Clam daemon), or “none” for no e-mail scanning. “Virus Scanner Timeout” controls the maximum length of time the commercial virus scanner is allowed to run for one batch of messages. The default is 300 seconds. The next heading, “Custom antivirus options“, allows you to add any custom parameters you need to specify.

The next tab is “Content“. The first heading is “Removing/Logging dangerous or potentially offensive content“. The first setting is the “Contents” list box, which determines what content for which MailScanner will scan. The default settings are “Dangerous content Scanning“, “Find Phishing Fraud“, “Also Find Numeric Phishing“, “Use stricter Phishing Net“, and “Highlight Phishing Fraud“. Other settings include “Allow Partial Messages“, “Allow External Message Bodies“, “Convert Dangerous HTML To Text“, “Convert HTML To Text“.

External Links:

The official MailScanner web site
MailScanner at Wikipedia

pfSense 2.1.4 Released

pfSense 2.1.4 has been released, about 2 months after pfSense 2.1.3. It is primarily a security release. Packages had their own individual fixes and need updating as well. For a full list of the fixes (security and otherwise) made in this version of pfSense, refer to this blog posting at

MailScanner Installation and Configuration: Part One


MailScanner configuration under pfSense 2.1.3.

MailScanner is an e-mail security and anti-spam package for e-mail gateway systems. It is not designed to be run on Microsoft Windows desktop PCs. Instead, it is designed to be run on mail servers operated by companies and ISPs so that all their users and customers can be protected from one place. This avoids the need for any software to be installed on individual desktop PCs at all. The software works with any Unix-based system and is compatible with a wide range of mail transports, and comes with support for any combination of 25 different virus scanner packages, including the free ClamAV scanner.

MailScanner is implemented in around 50,000 lines of Perl. It links with other software packages in order to perform its functions:

  • E-mail server (e.g. sendmail)
  • Anti-virus software (e.g. ClamAV)
  • Anti-spam software (SpamAssassin)

MailScanner Installation

To install MailScanner under pfSense, navigate to System -> Packages, and scroll down to “Mailscanner” in the package list. Press the “plus” button to the right of the listing, and on the next page, press the “Confirm” button to confirm installation. It will take a few minutes for the Package Installer to extract and install MailScanner.

Once MailScanner is installed, there will be a new entry on the “Services” menu called “MailScanner”. If you navigate to it, you will be able to modify several settings. There are 9 tabs: “General”, “Attachments”, “Antivirus”, “Content”, “AntiSpam”, “Alerts”, “Reporting”, “XMLRPc Sync”, and “Help”. Under the “General” tab, the first heading is “System Settings”. The “Enable Mailscanner” check box will enable the mailscanner daemon if checked. “Max Children” allows you to choose how many MailScanner processes you want to run at a time (the default is 50. “Processing Incoming email” allows you to either scan messages or reject messages.

In the “Logging” secion, “Syslog Facility” allows you to specify what type of program is logging the message. The default is “mail”, and that is probably what you want to leave it at, but there may be circumstances when you may want to specifiy a different Syslog facility. See the Syslog entry on Wikipedia for a list of facility levels, or read RFC 1164 for more information. The “Logging” list box allows you to choose which messages to log.

“Advanced Settings” has some additional options. “Advanced features” allows you to select several options. By default, only “Deliver in Background” is selected. “Deliver Method” allows MailScanner to attempt immediate delivery of messages, or just place them in the outgoing queue for the MTA to deliver when it wants. “Minimum Code Status” lets you set the minimum acceptable code status; if MailScanner comes across a code that is not at least as stable as what it set here, it will stop running.

In the next article, we will continue our look at MailScanner’s settings.

External Links:

The official MailScanner web site
MailScanner at Wikipedia

Using the OLSR Daemon in pfSense


Configuring the OLSR daemon in pfSense 2.1.3.

The OLSR daemon is an implementation of the Optimized Link State Routing protocol. The Optimized Link State Routing Protocol is an IP routing protocol optimized for mobile ad hoc networks, which can also be used on other wireless ad hoc networks. OLSR is a proactive link-state routing protocol, which uses hello and topology control message to discover and then disseminate link state information throughout the mobile ad hoc network.

Link-state routing protocols such as Open Shortest Path First (OSPF) and IS-IS elect a designated router on every link to perform flooding of topology information. The link-state protocol is performed by every switching node in the network. The basic concept of link-state routing is that every node constructs a map of the connectivity to the network, in the form of a graph, showing which nodes are connected to other nodes. Each node then independently calculates the next best logical path from it to every possible destination in the network. The collection of best paths will then form the node’s routing table. Open Shortest Path First (OSPF) takes this one step further, using the information to construct a topology map of the network. It computes the shortest math tree for each route using Dijkstra’s algorithm, a shortest path first algorithm.

This is a workable routing protocol for wired networks, but in wireless ad hoc networks, things are different. Every node in the network is potentially a switching node; hence, a different approach is needed in order to optimize the flooding process. Using Hello messages, the OLSR protocol at each node discovers 2-hip neighbor information and performs a distributed election of a set of multipoint relays (MPRs). Nodes select MPRs such that there exists a path to each of its 2-hop neighbors via a node selected as an MPR. These MPR nodes then source and forward TC messages that contain the MPR selectors. This functioning of MPRs makes OLSR unique from other link state routing protocols in a few different ways. The forwarding path for TC messages is not shared among all nodes but varies depending on the source. Not all links of a node are advertised, but only those that represent MPR selections.

Since link-state routing requires the topology databased to be synchronized across the network, OSPF performs topology flooding using a reliable algorithm. Since a reliable algorithm is hard to design for an ad hoc wireless network, OLSR doesn’t bother with reliability. It simply floods topology data often enough to make sure that the database does not remain unsynchronized for extended periods of time.

OLSRD: Installation and Configuration

Installing OLSRD under pfSense entails navigating to System -> Packages, and scrolling down to the oLSRD entry. Press the “plus” button to the right of the entry, and press the “Confirm” button to confirm installation. OLSRD installation should not take long.

Once OLSRD is installed, there will be a new item on the “Services” menu called “OLSRD“. If you navigate to Services -> OLSRD and press the “plus” button, you can configure OLSRD settings. Checking the “Enable OLSR” check box enables the dynamic mesh linking daemon.

The next setting is the “Link Quality Level” dropdown box. There are three possible settings: 0, 1, and 2. Setting this parameter to 0 disables the link quality extensions, and OLSRD works as it did before (it is RFC-compliant, uses HELLO and TC messages, and calculates routes by minimizing the hop count). Hysteresis will be used, and the links will be more robust at the cost of speed. Setting this parameter to 1 enable the link quality extensions and tells OLSRD to select MPRs based on the link quality information. A neighbor is selected as an MPR, if it has the best route to any 2-hop neighbor. Setting this paramter to 2 not only selects MPRs based on the link quality but also considers link quality information when calculating the routing table. Setting this parameter to 0 or 1 seem fairly safe; while setting it to 2 may cause oLSRD to crash in some cases.

The next setting, the “Interfaces” list box, allows you to select the interfaces to which OLSR will bind. Of the remaining settings, the most notable are “HTTPInfo Port” (the port that HTTPInfo will listen on and “Enable Dynamic Gateway” (to enable the OLSR Dynamic Gateways feature, to add or remove Internet routes if a change is detected).

External Links:

Optimized Link State Routing Protocol on Wikipedia

The official olsrd web site

olsrd Link Quality Extensions

Service Discovery with Avahi


Configuring Avahi under pfSense 2.1.3.

Avahi is a free zero-configuration networking implementation, including a system for multicast DNS/DNS-SD service discovery. It is licensed under the GNU Lesser General Public License (LGPL). It allows programs to publish and discover services and hosts running on a local network.

Avahi implements the Apple Zeroconf specification, mDNS, DNS-SD and RFC 3927 IPv4ALL. other implementations include Apple’s Bonjour framework. Avahi provides a set of language bindings and ships with most Linux and BSD distributions. Because of its modularized architecture, major desktop components like GNOME’s Virtual File System and the KDE input/output architecture already integrate Avahi.

Most Linux distros have Avahi available in their repositories, and thus installing Avahi is as simple as invoking apt-get at the command line:

sudo apt-get install avahi-daemon

This will work unless the graphical front end does not have Zeroconf support built into it, in which case you would have to download and compile Avahi from sources, and then recompile the desktop environment to include Zeroconf support.

Service Discovery with Avahi: Installation and Configuration

Fortunately, getting Avahi to work under pfSense is very simple. To install Avahi in pfSense, navigate to System -> Packages, and scroll down to “Avahi”. Press the “plus” button next to the listing, and on the next page, press “Confirm” to confirm the installation. The installation will take a few minutes to complete.

Once installation is complete, there will be a new item on the “Services” menu named “Avahi“. If you navigate to Services -> Avahi, you can configure the settings for Avahi discovery. The “Enable” check box enables the Avahi Bonjour/Zeroconfig proxy. The “Browse domains” edit box allows you to enter domains you would like to have proxied. The “Deny interfaces” list box allows you to specify interfaces that you do not want Avahi to listen on (WAN is disabled by default). Finally, the “Disable IPv6” and “Disable IPv4” disables IPv6 and IPv4 support in Avahi respectively.

Once you have Avahi enabled, systems on interfaces on which Avahi is listening should be able to publish and/or discover Bonjour/Zeroconfig services.

External Links:

The official Avahi web site

Avahi on Wikipedia

BEAST Attack Mitigation in pfSense

BEAST attack

Enabling BEAST attack protection in pfSense 2.1.3.

On September 23, 2011 researchers Thai Duong and Juliano Rizzo demonstrated a proof of concept called Browser Exploit Against SSL/TLS (BEAST). A BEAST attack involves intercepting and decrypting HTTPS cookies. Whenever you log into an HTTPS page, after your authentication, you can see your autenticated page, and if you look carefully at the page’s URL, you can see the session ID. A session ID is a random number or combination of numbers and string that maintains the state of the page, it is assigned by the website server to the client browser. The session ID can be found in either the cookie or the URL of the web browser. Usually, session IDs will be encrypted to prevent hijacking of the session.

A successful BEAST attack entails first sending a malicious JavaScript to run on the victim’s machine. This can be achieved by several means: Cross Site Request Forgery (CSRF), social engineering, a download, or a web page containing JavaScript. This malicious script runs on the victim’s machine and can capture the entire header info and the encrypted cookie that is assigned from the web server running Transport Layer Security (TLS) 1.0 and can then send the information to the website.

Next, the attacker utilizes a vulnerability in SSL/TLS. In TLS 1.0, if there are two identical plaintext messages, then after encryption, the cipher text is the same. Thus, by comparing the encrypted session details and the unencrypted data sent by the script, the attacker can find the initialization vector. Once the attacker gets this information, it can decrypt future cookies sent from the web server.

Using this blueprint, Duong and Rizzo built the BEAST tool, which is capable of decrypting HTTPS cookies and hijacking browsing sessions in order to steal credentials. Major browser makers, except for Apple, addressed the issue on the client side by implementing a technique known as the 1/(1-n) split. The technique stops attackers from being able to predict the initialization vector blocks that are used to mask plaintext data before it is encrypted.

Enabling BEAST Attack Protection in pfSense

Fortunately, pfSense provides some measure of protection against BEAST attacks on your web configurator sessions. If you navigate to System -> Advanced, and click on the “Admin Access” tab, under “webConfigurator“, there is a “BEAST Attack Protection” check box. It is left unchecked by default because it does not work with Hifn cryptographic accelerators, and if it is used when such accelerators are being utilized, the web GUI will not work. If you are not using such cryptographic accelerators, however, you should be able to enable this option without having any issues.

External Links:

Not So Fast on BEAST Attack Mitigations at

BEAST vs. CRIME Attack at

Virus Check with HTTP AntiVirus Proxy

virus check

The HTTP Proxy settings page in HAVP under pfSense 2.1.3.

HTTP AntiVirus proxy (HAVP) is a proxy with an anti-virus filter. it does not cache or filter content, but completely scans incoming traffic while doing a virus check. The main objectives of HAVP are: [1] continuous and non-blocking downloads, and [2] smooth scanning of dynamic and password protected home pages.

HAVP’s virus check works by writing data from a server in a temporary file and hard locks the end of a file. A second fork begins scanning all written data. During this time, the data is sent to the client. You can define the size of data which is held back and only deliver it to the client when scanning is complete. This way, scanning starts simultaneously with the download. If the scanning process is too slow and the file is larger than the defined “hold back data”, you can still receive a virus. Moreover, if the file contains a virus and the file is bigger than the defined “hold back data” buffer size, the download will be canceled without warning.

Virus Check with HTTP AntiVirus Proxy: Installation and Configuration

Like all packages, installation of the HAVP virus check package is fairly easy. Just navigate to System -> Packages and scroll down to HAVP antivirus. Press the “plus” button to the right of the listing, and on the next page, click on the “Confirm” button. Installation of HAVP antivirus will take a few minutes.

Once HAVP antivirus is installed, there will be a new item on the “Services” menu called “Antivirus“. There are three available tabs: “General Page“, “HTTP Proxy“, and “Settings“, containing relevant settings for the HAVP virus check. If you click on the “Settings” tab, you will find several parameters relevant to HAVP antivirus configuration. The “AV base update” dropdown box defines at what interval the antivirus database will update itself. You can update at intervals between 1 and 24 hours. The “Regional AV database update mirror” dropdown box allows you to select the location of the update server. You can specify additional servers in the “Optional AV database update servers” box. The “Log” check box allows you to enable logging; the “SysLog” check box enables the SysLog.

The second tab is “HTTP proxy“. Checking the “Enable” check box here enables the HTTP proxy to perform a virus check. The next setting is the “Proxy mode” dropdown box. If you select “Standard“, clients will bind to the proxy port on the proxy interface. But if you choose “Parent for Squid“, then HAVP will insert itself between the Squid proxy and the WAN interface (Internet). If you have the Squid proxy installed, you probably want to choose this option. “Transparent” causes HAVP to act as a parent for Squid with a transparent Squid proxy, while “Internal” causes HAVP to listen on the loopback on the configured proxy port.

virus check

The HAVP dashboard.

Proxy interface(s)” allows you to select one or more interfaces for client connections to the proxy. Normally, clients will be connecting through the LAN interface, so you probably want to leave only “LAN” selected. “Proxy port” allows you to select the port the proxy server will listen on. The port must be different than the Squid proxy port. You can probably leave it as the default of 3125. Moving further down the page, you probably want to change the “Language” in which the proxy server will display error messages to users.

Most of the remaining “HTTP proxy” settings can remain unchanged, but a few are worth noting. “Max download size” allows you to enter a value (in bytes) of the maximum file download size. But be warned: downloads larger than this size will be blocked if not whitelisted. “Whitelist” allows you to specify URLs that will be accessible to users without scanning, while “Blacklist” allows you to specify URLs that will be blocked. “Enable RAM Disk” allows you to use a RAM disk for HAVP temporary files for a quicker traffic scan in virus checking. The RAM disk size will be either 25 percent of the available system memory or 100 times the maximum scan file size, whichever is greater. “Scan max file size” allows you to select the maximum file size or not set a maximum file size at all. If you set a maximum file size, then file sizes larger than the limit won’t be scanned, so there is a security risk involved in setting this parameter. The “Scan images” check box allows you to scan image files, and “Scan media stream” allows you to scan audio/video streams. The “Log” check box enables logging.

Once you are done configuring the settings, press the “Save” button at the bottom of the page to save the settings. In order to ensure the HAVP virus check is working correctly, you probably should download the EICAR virus test file from The test file is not an actual virus, but contains a standardized signature that is used to test antivirus programs. If the HAVP virus check is working properly, you should be redirected to a page with an access denied message.

If you click on the “General Page” tab, you can see the HAVP dashboard. You will be able to see which services are started, the update status and scanner status, and which if any viruses have been found.

One additional caveat is that HAVP requires a fair amount of memory to work, and if it is enabled on pfSense systems that are towards the low end of pfSense’s memory requirements (e.g. 256 MB), pfSense may become slow and unresponsive. Ideally you should have at least 1 GB of RAM if you are running HAVP.

External Links:

The official HTTP AntiVirus Proxy web site

How to Set Up an HTTP Anti-Virus Proxy Using pfSense and HAVP at

Anti-Malware testfile from

Backup Your Network with Bacula


Adding a director to bacula-client under pfSense 2.1.3.

Bacula is an open source, enterprise-level computer backup system for heterogeneous networks. It is designed to automate backup tasks that had often required intervention from a systems administrator. Bacula supports Linux, UNIX, Windows and Mac OS X backup clients, although here we are mainly concerned with the Bacula package running under pfSense. It also supports a range of professional backup devices, including tape libraries. Administrators and operators can configure Bacula via a command-line console, GUI or web interface. Its backend is a catalog of information stored by MySQL, PostgreSQL, or SQLite. Bacula is the collective work of many developers, including Kern Sibbald, and has been under development for fourteen years as of this writing. It is open source and is available without fees for both commercial and non-commercial applications, under the AGPL version 3 license, with exceptions to permit linking with OpenSSL and distributing Windows binaries.

Bacula Backup: Installation and Configuration

The Bacula server has to be installed separately. Depending on which platform/operating system you are using, you may have to compile Bacula, although Bacula seems to be present in the Red Hat Enterprise Linux (RHEL) and CentOS repositories. To install the Bacula client under pfSense, navigate to System -> Packages, and scroll down to bacula-client on the package list. Press the “plus” button to the right of the entry, and press “Confirm” to confirm installation. Installation of Bacula should not take long.

Once installation is complete, there will be a new entry under the “Services” directory called “Bacula-client“. The configuration files for Bacula will not be generated until you have saved a configuration change. To understand the configuration options, it helps to understand the architecture of Bacula.

Bacula is made up of the following five major components or services: Director, Console, File, Storage, Catalog and Monitor services:

  • Director: The director service is the program that supervises all the backup, restore, verify and archive operations. The system administrator uses the director to schedule backups and to recover files. The director runs as a daemon in the background.
  • Console: The console service is the program that allows the administrator or user to communicate with the director. Currently, the console is available in three versions: text-based console interface, QT-based interface, and a wxWidgets graphical interface. The simplest is to run the Console program in a shell window. Most system administrators will find this completely adequate. The GNOME GUI interface is not yet complete, but has most of the capabilities of the of the shell console. the third version is a vxWidgets GUI with an interactive file restore.
  • File: The file service is the software program that is installed on the machine to be backed up. The file services are also responsible for the file system dependent part of restoring the file attributes and data during a recovery operation.
  • Storage: The storage services consist of the software programs that perform the storage and recovery of the file attributes and data to the physical backup media or volumes. In other words, the storage daemon is responsible for reading and writing your tapes or other storage media.
  • Catalog: The catalog services are comprised of the software programs responsible for the maintaining the file indexes and volume databases for all files backed up. Bacula currently supports three different databases: MySQL, PostgreSQL, and SQLite.
  • Monitor: The monitor service is the program that allows the administrator or user to watch the current status of Bacula directors, file daemons, and storage daemons. Currently, only a GTK+ version is available.

If you navigate to Services -> Bacula-client, there are three tabs: “Directors“, “FileDaemon“, and “View Configuration“. The first tab, “Directors“, enables you to add directors by pressing the “plus” button on the right side. You can specify the “Director Name” and provide a description in the “Description” field. You need to supply a password at “Password“, and at the “Director type” dropdown box, you can select the director attributes. “Director” just specifies that it is a director. “Local” causes the Monitor attribute in bacula-fd.conf to be set to “yes” and the director attribute in the Messages section of bacula-fd.conf to be set to this director. Setting the director type to monitor causes the Monitor attribute to be set to “yes“, but leaves the director attribute unchanged.

On the “FileDaemon” tab, there are currently only two settings: “File Daemon port” (the default is 9102), and “Maximum Concurrent Jobs” (the default is 20). The Volume format becomes more complicated with multiple simultaneous jobs; consequently, restores may take longer if Bacula must sort through interleaved volume blocks from multiple simultaneous jobs. Thus, you should probably leave “Maximum Concurrent Jobs” set to 20 unless you have a specific reason otherwise. Finally, “View configuration” allows you to view (but not alter) the bacula-fd.conf file.

External Links:

The official Bacula web site

Bacula on Wikipedia

UPS Monitoring with NUT in pfSense

UPS monitoring

NUT configuration page under pfSense 2.1.3.

Network UPS Tools (NUT) is a collection of programs which provide a common interface for UPS monitoring and administering, as well as monitoring and administering PDU (power distribution unit) and SCD (secure cryptographic device) hardware. It uses a layered approach to connect all of the parts.

The UPS monitoring capabilities of NUT are extensive. Drivers are provided for a wide assortment of equipment. They understand the specific language of each device and map it back to a compatibility layer. Any device supported by NUT can be handled transparently with a uniform management interface. This information is cached by the network server upsd, which then answers queries from the clients. upsd contains a number of access control features to limit the abilities of the clients. You can set it up so only authorized hosts may monitor or control your hardware. Since the notion of monitoring over the network is built into the software, you can hang many systems off one large UPS, and they will shut down together. You can also use NUT to power on, off, or cycle your data center nodes, individually or globally through PDU outlets.

UPS Monitoring with NUT: Installation and Configuration

Installing NUT for UPS monitoring under pfSense is easy. Navigate to System -> Packages and scroll down to NUT on the list. Press the “plus” button to the right of the listing to select the package, and press the “Confirm” button on the next page to confirm installation. It should take a few minutes for installation to complete.

Once installation is complete, there will be a new item on the “Services” menu called “NUT“. If you navigate to “NUT“, you will find two tabs: “NUT Settings” and “NUT Status“. Under “Nut Settings“, there is a “General Settings” header with two options: the “UPS Monitoring” dropdown box and the “Power Down Instead of Halt” check box. The “UPS Monitoring” dropdown box has several options: “Disabled” (to disable UPS monitoring), “Local UPS” (to monitor a local UPS), “Remote SNMP UPS” (to monitor a remote UPS using the Simple Network Management Protocol), “Remote NUT UPS” (for UPS monitoring of a remote UPS using NUT).

The next heading, “Remote Access Settings“, lets you specify a remote access address, username and password. Under “Local UPS Settings“, you can specify the “Local UPS Name” and the “Local UPS Model” (you can pick a generic profile if your specific model is not listed). For “Local USB Port“, you can specify “auto (USB only)” in most cases. But if you are using another port, you can specify it here (e.g. cuau0 for COM1, cuau1 for COM2, ttyu0 for the first console device, etc.). At “Local UPS Generic Type“, you can specify the UPS type (APC, Best Power Patriot, etc.) and at “Local UPS Cable Type” you can specify the cable type.

The next heading is “Remote SNMP UPS Settings“. You can specify the “SNMP UPS Name” and the “SNMP UPS Address” (its IP address). At “SNMP UPS Community“, you can set the community name (default = public). Note that a RW community name is required to change UPS settings (as for a powerdown). At “SNMP Version“, you can specify the SNMP version (default = v2). At “SNMP UPS MIB“, you can set MIB compliance. With “auto“, the driver will try a select set of SNMP objects until it finds one that the device responds to. Note that since NUT 2.6.2, snmp-ups has a new method that uses sysObjectID (which is a pointer to the preferred MIB of the device) to detect supported devices. This renders void the use of the “MIB” option. The last two settings under this heading are “SNMP UPS Polling Freq” (default is 30 seconds), and “Disable transfer OIDs” (for use on APCC Symmetras).

The last heading is for “Remote NUT UPS Settings“. Here you can specify the “Remote NUT UPS Name” as well as the address, username and password. Press the “Change” button at the bottom of the page to update your UPS monitoring  settings. Now, you can click on the “NUT Status” tab and monitor the status of your UPS.

External Links:

The official Network UPS Tools website


Amazon Purchases

Here are a a few items readers purchased through our Amazon affiliate links:

BitFenix Recon Black Fan Controller (BFA-RCN-KS-RP)

Cooler Master SickleFlow 120 – Sleeve Bearing 120mm Blue LED Silent Fan for Computer Cases, CPU Coolers, and Radiators

NZXT Technologies Sentry 3 5.4-Inch Touch Screen Fan Controller Cooling AC-SEN-3-B1

Call of Duty Black Ops II 3D Gaming Eyewear – Xbox 360

Remember, your purchases through our Amazon affiliate links help keep the lights on here at

© 2013 David Zientara. All rights reserved. Privacy Policy