Archive for Technology

Keeping The Network Clean

In today’s environment of mobile computing and the increasing integration of consumer electronics with the corporate network, it has become a necessity to plan accordingly in order to mitigate the risk this presents.

Whether it be an iPhone or guest laptop connecting via wireless or using an unused network port, brings new challenges to network administrators who need, not only be aware of what is on their network but also prevent an un-managed device from infecting other devices on the network.

The situation grows in complexity in higher education where the inherent open network environment becomes a juggling act balancing network security and open access. Students do not patch and fail to run current anti-virus.

Network Access Control, which is more commonly referred to by the acronym NAC, is the most hyped term in networking today. It’s also one of the least understood.

Network Access Control (NAC) is a computer networking solution that uses a set of protocols to define & implement a policy that describes how to secure access to a network nodes by devices when they initially attempt to access the network[citation needed]. NAC might integrate the automatic remediation process (fixing non-compliant nodes before allowing access) into the network systems, allowing the network infrastructure such as routers, switches and firewalls to work together with back office servers and end user computing equipment to ensure the information system is operating securely before interoperability is allowed.

The idea behind Network Access Control (NAC) is to implement a set of pre-admission rules and post-admission controls over where users can go and what they can do. Kind of like an in-versed firewall framework on steroids.

What’s important to understand is the Network Access Control (NAC) is not a device or appliance that is dropped in on the network, but rather a structure that needs to be deployed throughout the enterprise network.

The goals that Network Access Control aims to address can be distilled into three categories.

  1. Identity Management – Which includes device registration, authentication and role based access.
  2. Endpoint Compliance – The ability to prevent devices that lack anti-virus, patches or host prevention software from accessing the corporate network to prevent putting other computers at risk.
  3. Policy Enforcement – Provides the ability to enforce company-specific policies in either block, notify or report mode and integration with other solutions to identify and disable unauthorized activities.

Different vendors take different approaches in order to accomplish these goals, were policies are enforced on a pre-admission vs. a post-admission basis, software clients are installed on the users computer vs. scanning those computers in an effort to gather information to automate decision making at the time the policy is enforced, and finally out-of-band vs. in-line solutions.

In 2005 I started experimenting with Network Access Control technology and came across an open-source solution called NetReg.

NetReg is an in-line, pre-admission, client-less Network Access Control solutions. The system sits between the users and the network. Identity management is accomplished by authenticating the user through a website against an LDAP server and storing in a database the username, the IP address assigned and the devices MAC address.

Endpoint compliance is achieved by 2 dynamic DHCP address pools; one for unregistered (unknown hosts) with non-routable IP addresses (network/Internet blocked) and the second for registered (known hosts) with routable IP addresses (network/Internet accessible). A bogus DNS server prevents users from accessing anything but certain websites where a user can download anti-virus and patches for remediation purposes.

Nessus vulnerability scanning software periodically scans devices to determine if these should be quarantined until they have met the established acceptable use policy. If a computer in the unregistered network is found to be non-compliant, it is notified and only when appropriate action has been taken will the computer be assigned a valid routable IP address. If the computer has already been assigned a valid IP address then it is blocked.

Some of the shortfalls of this approach were the inability to determine which patches were missing and firewalled clients are not checked.

Netreg which was originally developed by Southwestern University at Georgetown branched out into several versions and currently the only one being maintained is by Carnegie Mellon here.

Finally is important to note that there is no silver bullet when it comes to security and there are always ways to get around a system. A thought that came to mind was how these products deal with printers, VoIP phones, gaming consoles, etc, when it comes to registration and how by changing one’s MAC address to mimic a VoIP phone or printer vendor would bypass the authentication.

In researching when writing this blog, I came across another open source solutions started in 2007 called PacketFence which I will take a closer look at.

Major Commercial Solutions:

Open Source Solutions:


Gartner Market Scope for NAC 2008


Anonymizing Web Traffic

I recently wrote about Secure Internet Browsing and the need for it. Not too long thereafter I found an instance were you might want to make sure that your traffic is anonymous so I will take a closer look at “Onion Routing” and “Tor”.

Tor is a software project that helps you defend against traffic analysis, a form of network surveillance that threatens personal freedom and privacy, confidential business activities and relationships, and state security. Tor protects you by bouncing your communications around a distributed network of relays run by volunteers all around the world: it prevents somebody watching your Internet connection from learning what sites you visit, and it prevents the sites you visit from learning your physical location. Tor works with many of your existing applications, including web browsers, instant messaging clients, remote login, and other applications based on the TCP protocol.

There are several ports of the “Tor” project out there and after evaluating several of them the better one seems to be the Vidalia-Tor-Privoxy Bundle here.

There are several components in this package that warrant explanation.

The Vidalia application is a GUI program to access Tor.

Then we have Tor which uses cryptography in a layered manner working at the TCP stream level as opposed to using application layer solutions like anonymous proxies. Is important to note that Tor (onion routing) is designed to anonymize traffic and does NOT secure it. Additionally there could be some weaknesses that I will address later on DNS leaks, IP address leakage and cookie leakage.

The next component of the bundle is Privoxy which is a non-caching web proxy with advanced filtering capabilities for enhancing privacy listening on port TCP 8118. Privoxy receives requests from the web browser and then forwards web traffic to through the Tor network for anonymity. Tor sits on your PC listening on port TCP 9050 ready to scrub the traffic clean from traffic analysis.

Finally there is TorButton (add-on) which enables Firefox users to enable/disable the use of Tor by the browser with just one click.

I chose not to select this during the install since it has mixed reviews due to bugs and decided to go with a much better add-on called QuickProxy.

There is little you need to do to the default install. You should see Privoxy running on your “Systray” as a blue “P” icon and next to it you should see a “green onion” icon. Clicking on the “green onion” will bring up the Vidalia Control Panel so you can connect to the Tor network.

The last thing that needs to be done is to configure your browser to point to the local proxy (Privoxy) running on your PC as shown below.

Click on the Image to enlarge.

At the button of your Firefox browser you should see a Green/Red “P” (QuickProxy) which determines if the proxy is selected or not.

Finally to test if your browser is anonymized. Make sure your Firefox status bar shows the Red “P” and go to to determine your IP address. Click on the “P” icon and watch it turn to green and then proceed to refresh your browser and your IP address should change to something random.

Now lets look at the weaknesses starting with DNS leaks.

The Problem: When your applications connect to servers on the Internet, they need to resolve hostnames that you can read (like into IP addresses that the Internet can use (like To do this, your application sends a request to a DNS server, telling it the hostname it wants to resolve. The DNS server replies by telling your application the IP address.

Clearly, this is a bad idea if you plan to connect to the remote host anonymously: when your application sends the request to the DNS server, the DNS server (and anybody else who might be watching) can see what hostname you are asking for. Even if your application then uses Tor to connect to the IP anonymously, it will be pretty obvious that the user making the anonymous connection is probably the same person who made the DNS request.

Using Tor in concert with Privoxy pretty much takes care of this, since its a socks4a-capable HTTP proxy but if you intend to anonymize other non-SOCKS aware applications (for instant messaging, Jabber, IRC, etc), that are connected directly to Tor using SOCKS 4 of SOCKS 5 you will be prone to DNS leaks and not be as anonymous as you might think.

The Tor project is working to resolve this in their next release by including a DNS resolver that will send queries over the mixed network.

Alternatively you can modify how Firefox performs DNS lookups which is generally done by handing down the request to the operating system.

To force DNS requests into the Tor channel, visit the special URL about:config and find the key network.proxy.socks_remote_dns. Set it to true

Now what about cookie leakages.

Websites are allowed unless specifically told otherwise to store bits of information on your PC, to determine its you the next you visit. This allows for a more fluent and pleasant experience on any site you log into.

Now when you want to disassociate yourself from your identity it presents a problem. When you visit a website that has already placed a cookie on your computer and then you visit it again with your Tor identity, the website can determine that even though the originating IP addresses are different, it is in fact the same person. Making sure you have a second Firefox account or have erased your cookies becomes paramount to maintain your identities separate.

Additionally you have to worry about cross-site cookies which can be solved by allowing cookies for the originating website only, and have them kept only until Firefox is closed as seen below.

Click on the Image to enlarge.

Finally a word on security.

As Tor relies on a network of people around the world serving as relays to the traffic, you can easily see how a particular request to a website sending over a clear channel a username/password combination might be problematic. Someone actually listening (Tor Relay) to the traffic relayed through them will be able to pick up this information.

Even worse scenario would be someone phishing for information at an exit node and pretending to be a website you are visiting.

The most simple solution for this is to only use SSL and forcing Firefox to tell you if you are about to send information to an un-encrypted website.

Turn on warnings for secure and insecure sites. At the Firefox configuration URL about:config, find the keys beginning with security.warn_. Set all of them to true, except for the once ending in .show_once, which should be set to false. Then set security.warn_entering_secure to false — you really don’t need to be alerted to that.

If you visit a site and the browser tells you that the SSL certificate may be invalid, don’t trust it!




The Tor Project

FTC’s Red Flag Rule – Identity Theft

Last year the Federal Trade Commission (FTC) and several Federal Banking agencies issued a new regulation named the Red Flag Rule, which is intended to reduce the risk of identity theft.

Background on Red Flags Rule

The FTC issued the Red Flags Rule under sections 114 and 315 of the Fair and Accurate Credit Transactions Act (FACT Act), which amended the Fair Credit Reporting Act (FCRA). The rule requires “financial institutions” and “creditors” that hold “covered accounts” to develop and implement an identity theft prevention program” for new and existing accounts.

The Red Flags Rule is actually three different but related rules, one or two of which apply to many colleges and universities:

(1) Debit and credit card issuers must develop policies and procedures to assess the validity of a request for a change of address that is followed closely by a request for an additional or replacement card. (This provision is likely not applicable to colleges and universities, because, as discussed in the preamble to the Red Flags Rule, the definition of “debit card” specifically does not include stored value cards. However, this provision could implicate student ID’s that also can be used as part of a national debit card network, such as Visa or MasterCard.)

(2) Users of consumer reports must develop reasonable policies and procedures to apply when they receive notice of an address discrepancy from a consumer reporting agency. (This provision applies to colleges and universities when they use consumer reports to conduct credit or background checks on prospective employees or applicants for credit.)

(3) Financial institutions and creditors holding “covered accounts” must develop and implement a written identity theft prevention program for both new and existing accounts. (This provision likely applies to many colleges and universities).

This rule adds to the burden institutions already have having to comply to law already on the books, including FERPA, HIPPA, GLBA, DMCA and Federal Copyright Laws.

Even though there needs to be something done about the escalating problem of identity theft, I seriously doubt that additional laws are going to make a difference, specially if those laws go too far.

With the extensive laws already on the books, what really need to happen is for them to be enforced. Too many times institutions take for granted these laws and only go as far as writing some paragraphs and naming it their policy.

No real enforcement of any kind, but instead drafting a piece of paper to say something was done when the shut hits the fan.

Examples need to be made from the big guy to the little guy, to send a message that the customer information these institutions hold is valuable and not taking appropriate steps to guard it will be dealt with swiftly and with severe consequences for management of those institutions.

Getting back to identity theft, one of the major reasons identities are stolen is for fraud.

LifeLock’s approach to this offers some interesting lessons on the way credit is issued.

In December 2003, as part of the Fair and Accurate Credit Transactions Act, or Facta, credit bureaus were forced to allow you to put a fraud alert on their credit reports, requiring lenders to verify your identity before issuing a credit card in your name. This alert is temporary, and expires after 90 days. Several companies have sprung up — LifeLock, Debix, LoudSiren, TrustedID — that automatically renew these alerts and effectively make them permanent.

This method is simple and straight forth.

This is what policy should be about. Simple to write, simple to implement and simple to execute.

Some examples of this within a company could be:

  1. Scanning PC’s for Social Security Numbers (SSN) and Credit Card numbers and erasing them using software like Identity Finder.
  2. Wiping all computer hard drives and media before it leaves the premises for disposal. Darik’s Boot and Nuke is a tool which securely wipes information on media.
  3. Implement policies for the centralization of data, making IT responsible for the security and integrity  of the data. (Its not feasible for IT to protect an undetermined number of data repositories)
  4. Implement polices preventing the communication of SSN’s and credit card information via e-mail.
  5. Enforce password changes on a regular basis.
  6. Restrict outbound access from servers, only allowing limited access for required tasks.
  7. Deploy Intrusion Detection Systems (IDS) and/or Intrusion Prevention Systems (IPS)
  8. Deploy solutions capable of logging transactions and monitor them.

The original date for compliance for the new Red Flag Rule was November 1, 2008; which has now been extended to May 1, 2009.


Setting up a Mail Relay on CentOS 5

This will give you the capability to scan e-mails for spam, viruses and phishing using a variety of open source programs before they arrive to your e-mail server.

From Sekipedia
Jump to: navigation, search

* Install CentOS 5.1 barebones (customizing the install with nothing checked.)

* Update the system

yum update

* Install Additional packages

yum install ntp

yum install vixie-cron crontabs

* Download and install Webmin

cd /opt


yum install perl-Net-SSLeay

rpm -ivh webmin-1.430-1.noarch.rpm

* Disabled unneeded services

service iptables stop
service ip6tables stop
service netfs stop
chkconfig iptables off
chkconfig ip6tables off
chkconfig netfs off

* Install Postfix

yum install postfix

* Configure Postfix

myhostname =
mydomain = localhost
myorigin = $mydomain
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, $mydomain
mynetwork_style = class

* Configure Postfix to forward email

relay_domains =

This tells Postfix which domains it should relay mail. All mail destined for this domain (and only this domain) will be forwarded to its remote SMTP server. You can put multiple domains here, just separate them with a comma or whitespace.

Add line to end of

transport_maps = hash:/etc/postfix/transport
mailbox_size_limit = 20480000
mailbox_size_limit = 20480000

This tells Postfix what method to use to resolve the destination address for relayed mail:

Add line to end of “/etc/postfix/transport” smtp:[]

This command specifically maps the domain “” to the IP address and tells Postfix to use SMTP as the transport. All mail destined for which is relayed through this Spam Gateway will be forwarded via SMTP to

Then run command:

postmap /etc/postfix/transport

This command builds the hash table/file which Posfix will use to forward mail. If you don’t do this, it wont work.

Finally add this line to

append_at_myorigin = no

These lines will make sure your Spam Gateway does not add any of its own header domain info to the mail as it passes thru.

* Test Again

Stop and start postfix to make sure all changes take.

service postfix stop
service postfix start

I know this is redundant, but you really should test your system again before installing MailScanner. Make sure that mail gets passed through the system without problem. If you do encounter a problem, it will be a lot easier to fix it now than after you’ve installed MailScanner, SpamAssassin and ClamAV.

At this point incoming e-mail should go through the Mail Relay and be forwarded to the internal E-mail server.

* Install DAG’s GPG key

rpm –import

* Verify the package you have downloaded

rpm -K rpmforge-release-0.3.6-1.el5.rf.*.rpm

Security warning: The rpmforge-release package imports GPG keys into your RPM database. As long as you have verified the package and trust Dag then it should be safe.

* Download and Install the package

rpm -ivh rpmforge-release-0.3.6-1.el5.rf.*.rpm

This will add a yum repository config file and import the appropriate GPG keys. At this point, you can set the priority of the RPMForge repository, and also of the CentOS repositories if you have not done so yet.

* Test with this command:

yum check-update

* Update the system

yum update

* Install perl modules and dependencies for MailScanner

yum install –enablerepo=rpmforge perl-Archive-Zip perl-Convert-BinHex perl-Convert-TNEF perl-DBD-SQLite perl-Filesys-Df perl-HTML-Parser

yum install –enablerepo=rpmforge perl-IO-stringy perl-MIME-tools perl-Net-CIDR perl-Sys-Hostname-Long perl-OLE-Storage_Lite

yum install tnef

* Download and Install MailScanner


tar -zxvf MailScanner-4.71.10-1.rpm.tar.gz

cd MailScanner-4.71.10-1

rpm -ivh mailscanner-4.71.10-1.noarch.rpm

chkconfig postfix off

service postfix stop

chkconfig MailScanner on

* Configure MailScanner Settings

Updates to postfix’s by adding this line:

header_checks = regexp:/etc/postfix/header_checks

In the file /etc/postfix/header_checks add this line:

/^Received:/ HOLD

Here are the edits to Mailscanner – place / update in /etc/MailScanner/MailScanner.conf

Run As User = postfix
Run As Group = postfix
Incoming Queue Dir = /var/spool/postfix/hold
Outgoing Queue Dir = /var/spool/postfix/incoming
MTA = postfix

Optional edits to MailScanner

Change %org-name%
Change %org-long-name%
Change %web-site%

Here’s some file permissions changes you’ll need to make:

chown postfix.postfix /var/spool/MailScanner/incoming
chown postfix.postfix /var/spool/MailScanner/quarantine

service MailScanner start

Its a good idea to test the server now. Send a message to the remote server and see if it goes through. It should, and then you can move to installing SpamAssassin.

* Install perl modules for SpamAssassin

yum install perl-Digest-SHA1 perl-Net-DNS perl-Archive-Tar perl-IO-Zlib

yum install –enablerepo=rpmforge perl-Encode-Detect perl-Mail-SPF perl-IP-Country perl-Mail-DKIM perl-Net-Ident

* Update the system

yum update

* Install and Configure SpamAssassin

yum install spamassassin

You don’t need to edit any of the SpamAssassin conf files because all of the configuration is done through MailScanner.

In /etc/MailScanner/MailScanner.conf we will make these changes:

Change this line:

Use SpamAssassin = no


Use SpamAssassin = yes

Update the SpamAssassin User State Dir setting:

SpamAssassin User State Dir = /var/spool/MailScanner/spamassassin

and then run commands:

mkdir /var/spool/MailScanner/spamassassin
chown postfix.postfix /var/spool/MailScanner/spamassassin

Restart MailScanner to make changes stick.

service MailScanner restart

* SELinux exception for Clamav

setsebool -P clamd_disable_trans=1 or disable SELinux while Clamav is installed.

* Install ClamAV

yum install clamav clamav-db –enablerepo=rpmforge

* Configure ClamAV and MailScanner Settings

In /etc/freshclam.conf make the following edits:

Add ‘#’ in front of the word ‘Example’

Do the same in /etc/freshclam.conf

Now you need to update ClamAV’s virus signature files

[root@smtp]# freshclam

ClamAV update process started at Fri Sep 19 12:45:42 2008
main.cld is up to date (version: 48, sigs: 399264, f-level: 35, builder: sven)
daily.cvd is up to date (version: 8287, sigs: 29596, f-level: 35, builder: arnaud)

Update MailScanner’s configuration file to use ClamAV

‘Virus Scanners = clamav’

In MailScanner.conf, check the setting of ‘Monitors for ClamAV Updates’ to ensure it matches the location of your ClamAV virus database files.

This should be “/var/clamav/*.cld /var/clamav/*.cvd”.

* Installing Postgrey

yum install postgrey

* Configuring Postgrey

Edit /etc/postfix/ and add the following to smtpd_recipient_restrictions.

check_policy_service unix:postgrey/socket

check_policy_service unix:postgrey/socket performs the greylisting while adding reject_unlisted_recipient before it enables Postfix to immediately reject unknown recipients instead of having clients go through the greylisting process before being informed that the recipient does not exist.

To disable greylisting for certain IP addresses or hostnames, add the IP address, hostname or regular expression to match hostnames into the file /etc/postfix/postgrey_whitelist_clients.local.

Hostnames are identified by performing a reverse DNS on the client’s IP address.

For sample entries, view the file /etc/postfix/postgrey_whitelist_clients.

* Update the system

Make one last final update to make sure your system is updated.

yum update