Recieving some *smart* spam

Recently I have witnessed and received some spam that appears to be more resiliant to some filtering techniques. I have noticed this from work as well as mail that I host from home. The email headers look a lot nicer and seem less random.

Spam filtering at work uses a combination on Postfix header checks, RBL’s, SpamAssassin, SFP checks and greylisting. At home I use the same combination except I currently omit greylisting.

Ill give you an example of the spam message I revieved

Salve,
Fuck beer! Got sexy girl?
Click here 
Andyou meanthe police will have to be involved? Comprehend?
that which i see, i seei long have for sixteen hours we
halted at eight o'clock a.m. But as soon as they entered
such places, the diamond statues which represent buddha
in his lotus, or eyes on him again. I do hope he wasn't
hurt. Lavinia he said. Things are much worse for jim pearson
next to it is the very handsome fruit garden of rack, or
loin, of mutton, otherways, whole, or seems my weeks of
training these dropout, unemployed, and it hurt dr. Conwell
so much that for ten years and get along. The thing for
you to do is to go me to clear out for a bit till she came
to her bad nervous breakdown. Finally, they said she and
shaves at least once a day. Like most men

This looks like a pretty typical spam email so far. The part that I find interesting is in the headers. I’ll only show the parts that are important.

Received: from oexrk.telecomitalia.it (hostxxx-68-static.89-82-b.business.telecomitalia.it [82.89.68.xxx])

The part that I find interesting is that the SMTP helo was from oexrk.telecomitalia.it and the reverse DNS is host198-68-static.89-82-b.business.telecomitalia.it. It looks like the spam bot is aware of the reverse DNS of the client computer that it has infected and making sure that it appears in the helo. The hostname part of the helo (oexrk) looks to be random characters that are then appended to the domain name. This could potantially trick some spam filtering software into a lower score as the helo is related to the reverse DNS. As well, the spam bot is also aware of greylisting and waits the appropriate length of time. This can be seen on the headers of the spam filtering at my work.

X-Greylist: delayed 306 seconds by postgrey-1.27 at mail.mywork.example.com; Fri, 11 Jul 2008 04:51:35 EST

We recieved several more spams from various other ISP’s that seem to all be infected with the same bot. Below are some more examples of the helo’s that were sent. They all follow a simmilar pattern of 2 levels of the domain name with 4-6 random characters appended as the hostname.

Received: from uezvl.inetia.pl (77-253-25-xxx.adsl.inetia.pl [77.253.25.xxx)
Received: from mmdodz.telecomitalia.it (hostxxx-123-static.23-87-b.business.telecomitalia.it [87.23.123.xxx])
Received: from peiwjh.telecomitalia.it (hostxxx-171-dynamic.16-87-r.retail.telecomitalia.it [87.16.171.xxx])
Received: from edny.telecomitalia.it (hostxxx-155-dynamic.40-79-r.retail.telecomitalia.it [79.40.155.xxx])

July 17 2008 | Linux | No Comments »

Active HTTP virus filtering with Squid and ClamAV using HAVP

***UPDATE 11.05.2008***: You will occasionally get errors about temporary directories that are failing to be created properly. To be honest, I don’t know what the cause of this is. It seems that either my setup (more likely) or HAVP is not production ready. If you force reload the page (ctrl + F5) the page should load properly afterwards. Also, after I wrote this tutorial, I realised that there was a HAVP RPM in the Dag repository. If you want to tweak this setup to use the Dag RPM, go ahead. Configuration file locations may vary though, so I cannot guarantee that these instructions will be completely portable.

I have had some trouble with finding a suitable solution for virus scanning using Squid. I tried squidclam which I didn’t have too much success running. There was also a plug-in for DansGuardian that provided virus filtering but I didn’t want the overhead of Dans and only wanted the virus scanning. Most of this guide is taken directly from http://www.opensourcehowto.org/how-to/squid/squid-clamav–havp.html with a few adjustments that were needed for my setup.

This setup assumes that you using CentOS 5 and already have Squid running and installed. If you need to setup Squid, Google is going to be your friend. There are heaps of tutorials around dealing with this. Also, if you run any redirect scripts such as Adzapper, this is fine as we will not be using this functionality of Squid to plug-in, but setting up a cache peer. More on that later.

INSTALLING CLAMAV

If you have not got Dag Wieers repo you will need to add this to the /etc/yum.repos.d/ directory to install ClamAV. Create a file in the yum.repos.d directory, /etc/yum.repos.d/Dag.repo and add the following:

[dag]
name=Dag RPM Repository for Red Hat Enterprise Linux
baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag/
gpgcheck=1
gpgkey=http://dag.wieers.com/packages/RPM-GPG-KEY.dag.txt
enabled=1

We will need the development tools to compile HAVP. Install these and ClamAV with the following commands.

yum groupinstall "Development Tools"
yum install clamav clamav-devel

This will take some time. You could probably install the tools that you will need to compile HAVP by hand, but the Development Tools meta-package will alleviate some headaches later on. An updater script will be placed in /etc/cron.daily/freshclam. Modify the frequency of this to your own needs.

Now we will download HAVP and compile it. Head over to http://www.server-side.de/download.htm to get the latest version. 0.87 was the most current at the time of writing.

cd /tmp
wget http://www.server-side.de/download/havp-0.87.tar.gz
tar zxvf havp-0.87.tar.gz
cd havp-0.87
./configure
make
make install

SETTING UP FOR HAVP

This will install most of the files in /usr/local. Before we start messing around with the config file, we need to create a new user account for HAVP to run under and create a few directories/change some permissions.

First we will add the havp user

adduser -c "HAVP proxy virus scanner" -M -s /bin/false havp

Now we need to change the permissions of some directories that HAVP uses

chown -R havp:havp /var/run/havp
chown -R havp:havp /var/log/havp

HAVP requires a directory to store its temporary files. This file system MUST have mandatory locking enabled to function. We can cheat a bit to get around this by creating an image file and then mounting the image on the file-system with locking enabled. For this we will use the command dd.

dd if=/dev/zero of=havp.img count=1 bs=256M

This will create the image, havp.img with a size of 256 MB. Change the size to suit but I feel 256 MB is about enough. Move the image to an appropriate directory, format it and then mount it. This shown below.

mv havp.img /usr/
mke2fs /usr/havp.img
(You will get some errors about doing this operation, Just accept them).
mount -o loop,mand /usr/havp.img /usr/tmp/havp
chown -R havp:havp /usr/tmp/havp

We will also want this to mount at boot time so add the following to your /etc/rc.local. I originally added a line in my fstab, but realised this didn’t work when my machine failed to boot properly next time i rebooted it.

mount -o loop,mand /usr/havp.img /var/tmp/havp

CONFIGURE HAVP

Now its time to configure HAVP. Open /usr/local/etc/havp/havp.config in your favorite editor. Everything is commented out. There are a lot of defaults set, but we will take away a lot of the commented out lines just so we know exactly what is going on. Below are all the changes you will want to make.

#REMOVETHISLINE deleteme
USER havp
GROUP havp
DAEMON true
PIDFILE /var/run/havp/havp.pid
SERVERNUMBER 20
MAXSERVERS 100
ACCESSLOG /var/log/havp/access.log
ERRORLOG /var/log/havp/havp.log
LOG_OKS false
LOGLEVEL 0
SCANTEMPFILE /var/tmp/havp/havp-XXXXXX
TEMPDIR /var/tmp
PORT 8080
BIND_ADDRESS 127.0.0.1
SCANIMAGES false
(leave this enabled if you have a fast machine)
MAXSCANSIZE 5000000
KEEPBACKBUFFER 200000
ENABLECLAMLIB true

You will only really want to change settings relating to the scan size, buffers and streaming options. Also enable image scanning if you have the grunt.

Save and start HAVP using the init script that it installed

/etc/init.d/havp start

The HAVP init script does not work with chkconfig, so we can just tell it to start upon system boot by entering it in the /etc/rc.local file.

echo "/etc/init.d/havp start" >> /etc/rc.local

Check the logs to make sure that it has started properly. The logs a pretty useful and do give you a good indication to the cause of a problem if you have one. It will most likely be problems with permissions so checking these will be a good start.

CONFIGURE SQUID

Lastly we need to add HAVP as a cache peer of Squid, Open the /etc/squid/squid.conf file and enter the following line.

cache_peer 127.0.0.1 parent 8080 0 no-query no-digest no-netdb-exchange default

TESTING

Now restart Squid. Once Squid as restarted and all calmed down (the AdZapper script initially seems to add quite a delay to Squid responding once it has started), check you can initially access the web. If this is fine, we can now test our virus scanning. A special test signature called “eicar” has been created for the purpose of testing anti-virus programs. Head over to http://www.eicar.org/anti_virus_test_file.htm and try to download one of the files (through HTTP). If all goes well, you should receive a message such as shown below.

If you have got to this point, congratulations. If you are still having trouble, check the Squid logs as well as the HAVP logs. You might want to change the verbosity of the HAVP logs to check exactly what is happening. Remember, this is definitely not bulletproof. Both the fact that ClamAV is not the best engine for detecting viruses as well as the fact that only a certain file size will be scanned.

April 11 2008 | Linux and Uncategorized | No Comments »

Getting laptops to work seamlessly in a 2003 domain environment

It can be a hard decision weather to join a staff laptop to the work domain or not. Easier managment by having the machine on the domian comes at a cost of some functionality of the user; especially if the laptop is a personal computer and not from the compary itself.

The goal was for staff laptops to work just the same as if they were logged into a domain-joined desktop PC. Everything should be seamless to the user and be completely SSO, the same as domain-joined desktop computers. To do this, follow the few steps below:

Navigate to Control Panel > User Accounts. Depending if you use the welcome screen or not, the window that appears may differ to what is shown below. If you are using the welcome screen, click the current user’s name and then click the link “Manage my network passwords”. If you are not using the welcome screen, click on the advanced tab and then “Manage Passwords” button.

ssolaptop1.JPG

Click Add.

ssolaptop2.JPG

Enter in the domain name and then the user name in the form of “domainname\username” and the appropriate password. You may get prompted if you wish to change the password on the domain. Click Cancel if this does occur.

ssolaptop3.JPG

Now try and access a resource on the network. Go to Run and enter in a share name as a test. You shouldn’t need to enter a password in as it will automatically send this for you. This works fine for windows shares and any other NTLM authentication mechanism such as Outlook.

If you run Exchange server and use the webmail client, chances are that it will automatically detect that you are in an intranet zone and automatically send your user name and password. There is one more modification that we will perform to ensure that the stored password gets used for all resources within our domain. This includes webmail when the user is at home. The default settings of Internet Explorer will detect that our example.com domain is an internet domain when we are at home. What we will do is add it as a trusted zone and modify the security template to ensure that it passes the user name and password wherever we are.

Open up Internet Explorer and navigate to Tools > Internet Options > Security (tab) . Click Trusted sites to make sure it is selected and then click the Sites button.

ssolaptop4.JPG

Add the site *.example.com and click Add. You may need to de-select “Require server verification…” if you are not using HTTPS.

ssolaptop5.JPG

Add and close this window and then click the Custom Level button. Once this window opens, scroll right down to the bottom of the list and change “Automatic logon only in Intranet zone” to “Automatic logon with current user name and password”.

ssolaptop6.JPG

Click OK and close this all off. Now you should not need to enter a user name and password every time you go t check you webmail or access any network resources.

SECURITY CONCEARNS

There are some security concearns surrounding this implementation.

  1. Seeing as staff use these laptops at home and are not managed by IT services, there is a higher risk of them becoming infected malware or the privilages abused by having them stored on the computer. If the staff memeber had another user of the laptop, they should create another use account for this purpose.
  2. Single point of failure regarding security. Once a villan has the laptop and is logged in, they also can access all their network resources.
  3. The encrypted NTLM password is sent through HTTP when the user is accessing webmail from home. This isn’t really a major concearn as the password is encrypted and is much better than the basic authentication that NTLM will fall back to if the user doesn’t pass NTLM requests properly.

February 03 2008 | Windows | No Comments »

Extended ACLs with Samba 3 in a 2K3 environment

There are a few documents around dealing with extended ACL support in Linux and Samba, but little documentation about its current implementation. The solution I came up with allows for domain admins to have the same level of control on files and directories as the root user and set permissions as one would on a 2003 server with NTFS permissions.

First, I am going to assume that you have Samba authenticating off a Windows 2000/2003 domain using Winbind. If you haven’t set this up, there are numerous documents around that deal with this. I will write another post at a later date on how to do this when I get the time. Also, I will assume that you are using the latest Samba RPM as it should contain support for extended ACLs. The third assumption is that you are using ext3 and that ACL support is enabled in the kernel. CentOS 5 has all of this enabled, so I will be using this as a base.

First, lets enable ACL support on our file system that will host out Samba shares. Open up /etc/fstab and change the line below

/dev/sda1 / ext3 defaults 1 1

to:

/dev/sda1 / ext3 rw,acl 1 1

Now we need to remount the root file system by issuing the following command

mount -v -o remount /

This may take a few minutes. It took about 3-4 for myself. Once this is complete, we will edit our smb.conf file to include the following [global] configuration options

[global]
….
map acl inherit = yes
nt acl support = yes
….

This allow extended ACLs to be applied to the file system. Now we need to allow domain admins permission to change ACLs on the files contained within the shares. Because Linux/UNIX only allows the owner or root to change the permissions of a file, we use the “admin users” option on the share to overwrite this. Edit the smb.conf file to include the following on the selected share.

[sharename]
path = /home/share
….
admin users = @”DOMAIN\Domain Admins”

Restart samba and now try accessing the share from a Windows machine. Check the security tab and add a user in just for kicks. Apply and close the properties window. Now open it again to make sure that the security was retained. If everything was setup correctly, the user you added permission to should still be there. It should look something like below.

extended acls 1

We can also check our Samba server file system permissions using the getfacl tool. This is what it look like if we execute it on the share that we set the permissions on before.
extended acls 2

Here we can see that there are both the normal UNIX permissions (displayed up the top of the window, on each line starting with #) and the extended permissions.

Conclusion
Extended ACLs aleviate a lot of permissions headaches when working with Samba in a Windows domain environment. It saves having to continuously chown files that get re-owned by root when you do ceartain functions on them. Also, some files are required to be owned by root (such as VMware virtual machine configuration files), and adding extended ACLs means that we can still copy and manage these VM files without having to chown them to move the files and then chown them back one they are copied accross.

Referrences
http://c.mills.ctru.auckland.ac.nz/Samba/XfsAclWinAuth.html
http://articles.techrepublic.com.com/5100-10878_11-6091748.html

December 20 2007 | Linux and Windows | No Comments »

Sender Policy Framework and ISP’s blocking port 25 seems problematic

EDIT: I found an article describing this scenario avaliable on the open SPF website, here

Sender Policy Framework is the RFC the defines an authorisation system for who is allowed to send email from a particular domain. It works by publishing TXT records in the root DNS for that domain that follow a correct syntax. This TXT record defines what servers are allowed to send mail from that domain. You can specify a network range, individual servers, hosts that are also listed as MX servers and so on. Its a good system that is slowly being adapted in an effort to reduce spam.

Another method that relies on the cooperation of ISPs is blocking outgoing port 25 outside of the ISP network. This means that infected zombie PC’s of DSL and cable subscribers wont be able to send mail out of the ISP network as this traffic will be blocked. To send legitimate mail, the user needs to setup their mail client to send mail via the ISPs SMTP server, which will then send it out to the rest of the world.

SPF blocks legit users from home internet connections

Therein lies a problem. We are combatting spam by blocking any outgoing traffic from port 25, but at the same time we are defining what servers can send mail from a particular domain. Say you have hundreds of remote users behind different ISPs, what do you do then? Do you manually add ALL of these servers to the allowed list? Unforunately there are many drawbacks of the SMTP protocol. It was drafted back in 1982 for a start, and really hasn’t seen any improvements to fighting spam over the years. The problem is, you cannot just change everything over in a day. It takes years and years to be adopted. Hopefully we can find patches to the current problems and ensure that any new standards have digital signing built in by default.

A few practical solutions to these problems would for the user to use a webmail client or perhaps VPN into the workplace (assuming we are talking a work environement) and use the company’s SMTP server.

Another technology called “Domain Keys” is simmilar to SPF in its operation to verify that the mail has been sent from a domain that is authorised to send. How it works is that the sent mail is digitally signed and the public key is avaliable through a DNS record. One small drawback is that this method requires inspection into the body of the message to get the domain key information, meaning more bandwidth is wasted on spam email.

SPF and DKIM only really addresses domain-wide authentication as to who (which servers) are allowed to send email. Anyone can technically send mail from anyone elses email address. There is no security as to who is allowed to send. There is no authentication stage for the user to send mail. For SMTP servers that are SASL aware and require a user name and password before the mail is relayed, only checks for a valid user. It does not check the sender of the email and make sure that the username and password entered is the same username that is authorised to send from that particular address. PGP (Pretty Good Privacy) and S/MIME can be implemented to sign mail to ensure that it did originate from the actual sender, but this is not widely adopted.

December 13 2007 | Uncategorized | 2 Comments »

Local web pages and Proxy Caching

Recently I encountered a seemingly random problem with external links in files hosted locally that would no longer use the proxy server to connect to the external site. Its a bit hard to explain exactly what I mean without breaking it down, so I will give an example.

  1. Create a blank html page on your desktop and add
    <html><body><a href=http://www.google.com>GOOGLE</a></body></html>
  2. Make sure that you have your proxy settings configured in Internet Explorer.
  3. Also make sure that you don’t have direct routed access to the Internet (IE: Without the proxy settings, you would not be able to connect)
  4. Open up the html file you created in Internet Explorer. (So that the URL is “C:\Documents and Settings\Username\Desktop\htmlfile.html”)
  5. Click on the google link and it should fail to load.

If it does work, congratulations, you don’t need to read on. If it doesn’t then continue. What it looks like is happening is that the proxy settings are cached and then not used when you go to an external site. Whilst reading more about proxy auto-config files (PAC files), I noticed some mention of this cached setting that is enabled in Internet Explorer.

I disabled it with a GPO, and afterwards, everything seemed to work properly. To get to it follow:

User Configuration > Administrative Templates > Windows Components > Disable Caching of Auto-Proxy scripts

and set it to enabled.

November 21 2007 | Windows | No Comments »

Webmin for CentOS 5

I was supprised to find that there was no RPM provided by yum for webmin; neither in the base packages or Dag repository. For anyone who wants it is is avalible using my yum repository. Add the following to a file /etc/yum.repos.d/Doylenet.repo

[doylenet]
name=Doylenet custom repository for CentOS
baseurl=http://files.doylenet.net/linux/yum/centos/5/i386/doylenet/
gpgcheck=1
gpgkey=http://files.doylenet.net/linux/yum/centos/RPM-GPG-KEY-rdoyle
enabled=1

You can now install it using the command below

yum install webmin

Accessing Webmin is as easy as going to https://server:10000 and logging in with your root account.

October 28 2007 | Linux | 4 Comments »

PPTP using Poptop on CentOS 5

Just recently I needed to setup a quick and dirty VPN solution. I’ve used Poptop before on Mandrake 9 many years ago and it proved to be pretty easy to setup. Its even easier with CentOS 5, as the kernel is already patched with MPPE and MPPC encryption and authentication that is really required to create a secure VPN solution.

INSTALL AND CONFIGURE POPTOP

Firstly, make sure that ppp is installed using yum.

yum install ppp

I compiled the latest pptp version so grab the RPM from here and install it or add my custom yum repository. I would reccomend the latter as yum will update PPTP if I put an updated PPTP package on my yum repo.

If you would prefer to use my yum repository which also has a few other updated packages such as the patched iptables for L7 filtering (which I will talk about in a later post), you can add it by creating a new file “/etc/yum.repos.d/Doylenet.repo” and adding the following lines

[doylenet]
name=Doylenet custom repository for CentOS
baseurl=http://files.doylenet.net/linux/yum/centos/5/i386/doylenet/
gpgcheck=1
gpgkey=http://files.doylenet.net/linux/yum/centos/RPM-GPG-KEY-rdoyle
enabled=1

Once you have created this file, we need to install pptpd through yum.

yum install pptpd

Now we want to edit the /etc/pptp.conf file. Disable the line “logwtmp” by commenting it out otherwise PPTP will fail to start and get this error in the syslog, “Plugin /usr/lib/pptpd/pptpd-logwtmp.so is for pppd version 2.4.3, this is 2.4.4″. Like the error says, the library file is for PPP 2.4.3, but CentOS 5 uses 2.4.4. EDIT: This has now been corrected in the RPM package as pointed out by Peter. It is no longer required to disable this line.

Scroll down to the area localip and remoteip. So that we can keep routing issues to a minimum, set this to a range in your local LAN. For example, I use 10.0.0.0/24 for my private LAN. 10.0.0.1 is the IP address of my router and VPN server. I set the localip value to 10.0.0.2 and the remoteip range to 10.0.0.200-220, outside the DHCP assigned range.

localip 10.0.0.2
remoteip 10.0.0.200-220

Now edit the /etc/ppp/options.pptpd file. The defaults in here are fine as they are secure by default. The VPN will not form unless MSCHAPv2 is being used for authentication and 128bit MPPE encryption. Scroll down to “ms-dns”. It is commented out by default. Edit this to your internal DNS server address. Do this for WINS as well. If you don’t have an internal DNS server, this is fine, but name resolution is a lot less painful if you are using DNS and not relying on NetBIOS which requires broadcasts and doesn’t really work to well over a VPN.

# If pppd is acting as a server for Microsoft Windows clients, this
# option allows pppd to supply one or two DNS (Domain Name Server)
# addresses to the clients. The first instance of this option
# specifies the primary DNS address; the second instance (if given)
# specifies the secondary DNS address.
ms-dns 10.0.0.240
#ms-dns 10.0.0.2# If pppd is acting as a server for Microsoft Windows or "Samba"
# clients, this option allows pppd to supply one or two WINS (Windows
# Internet Name Services) server addresses to the clients. The first
# instance of this option specifies the primary WINS address; the
# second instance (if given) specifies the secondary WINS address.
ms-wins 10.0.0.240

Finally we want to edit the file /etc/ppp/chap-secrets. This is where we will specify user names and passwords. Each user is specified on a new line.

username * password *

This is all the configuration that is needed as far as the PPTP server goes. Start it using the following command.

/etc/init.d/pptpd start

FIREWALL AND ROUTING

The only issues now that need to be resolved are routing and firewall issues. This is only relevant if the VPN server is on the same server as your firewall/router. By having the VPN clients on the same subnet as the rest of the trusted LAN, it makes it easier for the client, but slightly harder to configure, as we aren’t dealing with Layer 3. We need to allow the interface ppp0 access to the trusted interface. We will assume eth0 is the trusted interface

iptables -A INPUT -i ppp0 -j ACCEPT
iptables -A FORWARD-i ppp0 -o eth0 -j ACCEPT

This could also be done using the 10.0.0.0/24 range, but this will only work for unicast addresses. To make these statements safe, 10.0.0.0 should be dropped at the external interface as well if not already done so. Its good practice to drop all RFC 1918 private addresses that which have their source address incoming from the external interface. A lot of malformed and spoofed IP packets often have source addresses from the private address range.

iptables -A INPUT -i eth0 -s 10.0.0.0/24 -j ACCEPT
iptables -A FORWARD -i eth0 -s 10.0.0.0/24 -j ACCEPT

Now we need to allow the VPN protocols that will be used to connect and communicate with the VPN server through our firewall. The authentication part of our VPN server uses the PPTP protocol which is on TCP port 1723. Actual data is then transfered using IP protocol GRE (Genertic Routing Encapsulation). Configure the following iptables commands.

iptables -A INPUT -i $external_interface -p tcp --dport 1723 -j ACCEPT
iptables -A INPUT -i $external_interface -p gre -j ACCEPT

CONNECTING A WINDOWS CLIENT

Lastly, we will want to setup the client. Windows 2000 and XP and (i assume) Vista, come with a PPTP VPN client that is installed by default. You can get to it by going to the “Network Connections” dialog and clicking “Create a new connection”. Follow the wizard through selecting Connect to the network at my workplace > Virtual Private Network connection > Enter in a name for the connection > Enter in the IP or preferably DNS name of the VPN server. If the VPN server is the router/gateway, you can use your external IP address in your LAN. For testing purposes, I used the internal address of 10.0.0.1. If you run an internal DNS, use that name so when you are away from home you VPN in, it will grab the external address as long as you have set everything up properly (in terms of external DNS). For this, I reccomend you use the services provided at DynDNS or a simmilar free DNS provider.

vpn1.JPG

Click “Properties”.

vpn2.JPG

Navigate to the screen above and click “Properties” again.

vpn3.JPG

Then “Advanced”

vpn4.JPG

Then untick “Use default gateway on remote network”. This statement is important and needs to be unticked most of the time for simple VPN setups. What this means is that you existing default gateway will be used (what ever you are connecting through the internet to) for all traffic that isn’t related to the VPN. Remember how we used the same subnet for the VPN clients as the LAN clients? This is because if we used another subnet, the VPN clients would not know how to get to the LAN. This would require the Use default gateway on remote network to be ticked, but would also mean all unrelated traffic would go through the VPN. The technical term for this is “Split Tunneling” and can be a security concearn with larger enterprises as there is a potential for the remote user to be a gateway into the corporate network. Our setup is rather simple and we trust the users that are connecting, so this is not a concearn.

Once you have this option set, use the username and password that was set in the chap-secrets file to connect and to test your VPN.

October 01 2007 | Linux | 35 Comments »

Disallowing .EXE’s in a WindowsXP/2003 Environment

We recently had a problem with students running a host of different executable files on the computers managed by IT services. One of the favorite tools was one called Bosskey. This allowed students to have several virtual desktops and allow them to switch using a sinple keystroke. Think of it like Alt+Tab, but the window doesn’t appear in the taskbar.

As well as this, students would be playing games that they has stored in their folders and on flash drives. It is easy to remove games from students folders, but practically impossible to remove games from the students flash drives. Not really sure where to start with this, I had a look around for group policies that might be able to help me out. And what would you know, Microsoft had delivered.

Before I do into too much detail, Ill explain about the background of your setup. Each student has a unique user name and password to log into the domain environment. Their desktop and My Documents folders are redirected to a UNC path \\files\student\yearX\username\documents and \\files\student\yearX\username\desktop. This is the only remote place that they have read and write access to as well as a directory, c:\temp. As well as this, whenever a student logs into the computer it generates a folder in documents and settings, c:\Documents and Settings\username. Although they are using a manditory profile, Windows XP will generate a local profile once they log in. This is another place where the students can now read and write to. To summarise this, listed below are the only places where students can read and write.

  • \\files\student\yearX\username
  • C:\temp
  • C:\Documents and Settings
  • Any USB drive that is plugged into the computer

Once we have identified where the students can write to, we can open the Group Policy Managments console and create a new policy. You can make this domain wide so that is applies to everyone or select individual organisational units of either user or computer accounts. This policy can be applied to either users or computers, so you can take your pick. I will be describing this on a per-computer basis, located in the root of the OU where all the computer accounts are located.

Create a group policy object called “Software restriction” and edit it.

softwarerestrict1.JPG

Right click on Software Restriction and click Create new policies.

softwarerestrict2.JPG

The set of file types that Windows defaults to is quite restrictive. It includes .lnk’s (Shortcuts) and some Access and VB components. We want to remove these file types from being restricted, so open Designated File Types.

softwarerestrict3.JPG

Remove any types that you don’t want included and then click OK. As mentioned earlier, you will want to remove LNK file types and a few others as well. You could remove everything except EXE files, but to be safe we will leave most file types there.

We have now set what file types we want restricted, now we need to specify the rules on how we enforce this. Before we do this though, we want to make sure that these retrictions are not placed upon administrators of the computers. Open up Enforcement.

softwarerestrict4.JPG

Change Apply software restriction policies to the following users: from All users to All users except local administrators. Click OK to return to the previous window. Now open the folder called Additional Rules.

softwarerestrict5.JPG

Notice how there are already a few rules contained in here. These allow execution of EXE’s in the windows paths. It is important to leave these, otherwise you could potentially lock all your users out from being able to use computers all together. Right click in the window and choose New Path Rule. Now we can add in the paths we defined earlier. First we can do the USB drives. These can take letters E: through to as many drives that you have. We will define E:, F:, G:, and H:

softwarerestrict6.JPG

Repeat this process for the remaining drive letters. Now we can do the UNC paths.

softwarerestrict7.JPG

Seeing as we don’t want to restrict all of \\files\student, we will list all the sub folders. There are other folders in \\files\student\ where we want to allow running programs. Finish off by adding C:\temp and C:\Documents and Settings\ to the disallowed list. Once this is done, close of the policy and do a gpupdate /force on the workstations at the command prompt to update these policies, or just wait the few hours for them to be pushed to your workstations.

September 02 2007 | Windows | 4 Comments »

LDAP Authentication with Apache2 using Acitve Directory

LDAP authentication in Apache allows user and group authentiction from Active Directory to provide secutiry for files and folders using the users domain credentials. The only downfall of using LDAP authentication is that it isn’t SSO (Single Sign On). The user name and password used to authenticate is the same, but the browser doesn’t pass this info on like NTLM does. Anyhow, it is a useful authentication method regardless, as NTLM lacks proper group support in Apache.

Like everything else, this will be built using CentOS5. Install it in a minimal install. I will go through the packages that need to be installed next. Once CentOS is installed and up and running, login and we will install Apache. The default httpd package includes LDAP suppor, so we don’t need to install any other modules for it. There is a module called mod_authz_ldap. When I was originally setting this up, I thought that this was required, but didn’t realise that Apache supported LDAP out of the box.

Before we install Apache, we may as well update the all packages of the system.

yum update

This will take a while to complete and may download a few hundred MB of updates depending on what you installed. When this is complete, we will install Apache2

yum install httpd

This should only be a little over a MB. Once this is installed, we will create a directory that we want secured. For simplicity sake, we will just create it in the default web root. It can be applied for vhosts etc… as well.

mkdir /var/www/htlm/secure

Just to test it, we will make a simple web page in this folder

echo “<htlm><h1>It works!</h1></html>” > /var/www/htlm/secur/index.html

Now we will edit the /etc/httpd/conf/httpd.conf file to apply security to the “secure” directory. This can also be achieved using a htaccess file, but I really DON’T like htaccess files. They are harder to organise than applying security settings directly to vhost files of the httpd.conf file. Open the httpd.conf file in Vim

vim /etc/httpd/conf/httpd.conf

Go right to the end of the config (just hold page down) . Oncethere we want to enter the following.

<Directory “/var/www/htlm/secure”>
AuthType Basic
AuthName “LDAP Authentication”
AuthBasicProvider ldap
AuthLDAPURL ldap://dc.example.com:389/OU=USEROU,DC=example,DC=com?sAMAccountName?sub?(objectClass=user)
AuthLDAPBindDN cn=binduser,ou=SPECIAL,ou=USEROU,dc=example,dc=com
AuthLDAPBindPassword bindparseword
AuthzLDAPAuthoritative off
require ldap-group cn=Staff,ou=GROUPS,ou=USEROU,dc=example,dc=com
</Directory>

Once this is entered, save it. We need to now create the bind user. The orginisational units may change depending on your directory structure so you can go back into the httpd.conf file to change these accordingly.

Open Active Directory Users and Computers and navigate to where you want to create your bind user. In this example, we have an orginisational unit under the domain root called USEROU and the bind user in an OU called SPECIAL. Make the name of the user “binduser”. The first and last name can be “bind” and “user” respectivly, but make sure that the display name doesn’t include the space. Make the username binduser as well. As for the password, this is up to you. Make sure it reflects what is in the httpd.conf file.

Once this user is created, make sure that any changes in the location of the user is relflected in the httpd.conf file.

Als, before I forget, make sure that the hosts file is configured corectly. I have had some trouble when Apache doesn’t look up the name of the server using the name servers in the /etc/resolv.conf file. Add the server name to the hosts file as shown below. Of course, change your IP and name of the server to that of your orginisation.

echo “10.0.0.20 dc dc.example.com” >> /etc/hosts

Now start Apache

/etc/init.d/httpd restart

Now nagivate to the address of your web server and try to access the /secure directory. If it is successful you should be asked for a username and password. If you are a member of the “Staff” group or any group that you specified in the httpd.conf file you should see the “It Works!” text on the screen. If this is not the case have a look in the Apache log files for a clue. On thing that I find useful is changing the LogLevel to “debug” if there is nothing in the error logs that I can see. The most common error that there really is is getting the right syntax for the LDAP distinguished name. Double check that is is correct before looking at other errors.

July 19 2007 | Linux | No Comments »

Next »