I needed only one Apache HTTPD server visible over the Internet, and subdomains provided by internal webservers. I proceeded with mod_proxy.

On SLES10, go to /etc/apache2 and create a file named proxy.conf:

# Sample configs
# by hardwyrd
# 05/22/2009
#
# Disclaimer:
# Use at your own risk. It works for me, it might not work for you.
# If you decide to use or follow this config, you agree that I am not responsible for the damage
# to your system.

# Listen on internal interface only. Only mod_proxy uses this.

Listen 192.168.10.1:8080

# Set the user for mod_proxy
User nobody
Group nobody

# Turn on proxy requests
ProxyRequests On

Order deny,allow
Deny from all

# Declare your subdomain rechable from the internet.

Order deny,allow
Deny from all

# Allow only from specific IP addresses or allow all if this is accessible from the net.
Allow from all

# You can add as many
declarations as you can.

Create a virtual host on the public-facing Apache server. In SLES10, the config is at /etc/apache2/vhosts.d:

# Sample configs
# by hardwyrd
# 05/22/2009
#
# Disclaimer:
# Use at your own risk. It works for me, it might not work for you.
# If you decide to use or follow this config, you agree that I am not responsible for the damage
# to your system.

# A virtual host config is needed so that we can redirect the subdomain requests coming in at port 80 to the internal Apache server.
# Create equivalent virtual host entries for every
declaration in the proxy.conf .


ServerName your-subdomain.your-domain.tld
ServerAlias your-subdomain.your-domain.tld
ProxyPass / http://your-subdomain.your-domain.tld/
ProxyPassReverse / http://rspace.focusoutsourcing.com/


To enable the public Apache server forward the requests to the proper internal Apache server, you can use an internal DNS server with the correct A record for the domain pointing to the IP of the internal Apache server. Or, the quickest way is to add the subdomain to the hosts file (/etc/hosts).

#/etc/hosts
192.168.10.22 your-subdomain.your-domain.tld

On the internal Apache server, create a standard virtual host for the subdomain.

That’s it! Only one apache server will be visible to the public, and yet serve multiple subdomains, spread among various internal Apache servers.

Enjoy!

Technorati : apache, mod_proxy, web+server, linux
Site Search Tags: apache, mod_proxy, web+server, linux

Funny as it may seem, I fell for it (yet again perhaps?). I’ve installed CentOS5 on top of VirtualBox 2.2.2 on my Ubuntu Hardy 8.04 for the sole purpose of testing out ASP.NET hosting using Mono, XSP, and Apache. And I was in for a surprise that I could not access my virtual machine’s Apache web server instance.

I was able to install VirtualBox 2.2.2 vanilla (not the official Ubuntu package) without any problems. I followed it up by installing CentOS5 as a virtual machine. I then proceeded and configured the network interface for the virtual machine on the VirtualBox Management panel, and set it up to use “Bridged” networking.

I proceeded by booting the virtual machine and watched every boot message zip by without a hitch. I then logged into the virtual machine as root and configured the IP address for the network interface. After which, I pinged the IP address and got the reply I want. I then tried to log in via SSH, ang was able to get in. “Hmm… everything seems to be in order. Might as well continue.” I said to myself. Boy was I in for a surprise.

I proceeded and configured the web server, enabling name-based virtual hosting, started Apache and tried to browse the test page. And then… nothing! ACCKK!!! I checked the IPTables rules if there’s something a-miss. So far everything seems to be in order (really?) . Tried a couple more times, and still get a failure from Firefox. Hmmm.. what could it be. Pondering for hours what could have been missed. A colleague suggested to flush the entire set of IPTables rules, which I did and tried accessing the web server. What do you know! I was able to browse the basic landing page. “Hmmm.. there must be something wrong with the IPTables rules” I said whispering.

I proceeded and checked again /etc/sysconfig/iptables and sure enough, I found the culprit. I mistakenly added the IPTables rule that opens port 80 AFTER the reject rule! No wonder port 80 doesn’t open up. I edited the /etc/sysconfig/iptables again, and place the port 80 rule on top of the reject rule, which will then allow it to take effect first, before the reject rule is activated. And then everything worked as it should.

Lesson? Sometimes the obvious things are really hard to find and double checking definitely will prevent the unnecessary debugging for when your system goes to production. I’m just glad this is a simulation system and not production.

I think it was stupid of me not to notice the order of the rules in the iptables file. What do you think?

Technorati linux, virtualization, virtualbox, centos5, apache, webserver, iptables
Site Search Tags: linux, virtualization, virtualbox, centos5, apache, webserver, iptables

We needed a helpdesk and a knowledgebase system and we prefer that it be opensource. We have found OneOrZero HelpDesk and KnowledgeBase to be a good candidate. We decided to take a look at it and see for ourselves. Installation was tad easy. All you need is an Apache server, PHP, and MySQL and voila! We have been running it using MySQL for sometime but we didn’t as of yet let users use the system.

We have been mulling over the idea of integrating OneOrZero HelpDesk and KnowledgeBase authentication with our existing LDAP server which also authenticates our Windows domain users via our Samba PDC. OneOrZero is pretty much convenient for us since it already has LDAP authentication capability. Or so we thought.

Setting up LDAP for OneOrZero HelpDesk, required us to modify its settings. You can do this using its own control panel, by logging in as an administrator, or you can go brute it out by going to where the OneOrZero configuration files are located. In my case it is in

/srv/www/onezero/configuration/website_settings.php

Please note that the location may not be the same in your case, depending on where you extracted your files, and where your Apache DocumentRoot is located. Make the necessary adjustments.

After locating the file, make a copy first of the existing file (you dont want to lose working settings do you? then edit website_settings.php by opening your favorite text editor - which in my case is VI.

vi website_settings.php

Navigate your way down towards near the end of the file, and review the LDAP-related parameters. Please note, I’ll be using my own LDAP parameters as examples and yours might be different depending on your LDAP server flavor (AD, OpenLDAP, Netware/OES/others).

# Enable LDAP authentication. This is DB by default.
auth_method = "LDAP"

# IP address of your LDAP server
ldap_host = "192.168.10.10"

# If you are using AD, specify the domain name. I'm using OpenLDAP so, I ignored this.
ldap_domain = ""

# Specify the user that will be used to bind to your LDAP server. Not needed if anonymous bind is allowed
ldap_binddn = "cn=ldapbinder,dc=mydomain,dc=com"

# Specify the password for the binding user
ldap_bindpwd = "secret"

# Set the location in your LDAP schema where the search will start from. In my case, I have an OU called "Users"
ldap_rootdn = "ou=Users,dc=mydomain,dc=com"

# Provide here the search attributes. Note though that this might be different on your particular flavor of LDAP.
# Use an LDAP browser utility to double check.
ldap_searchattr = "uid"
ldap_fname = "givenname"
ldap_lname = "sn"
ldap_uname = "uid"
ldap_email_add = "mail"
ldap_office = "l"
ldap_phone = "telephonenumber"
ldap_context = "dn"


Save your file after editing.

We then tried logging in using our LDAP accounts, however it seems that OneOrZero cannot find our accounts, or rather LDAP cannot find the accounts passed by OneOrZero to it. So, I then looked at the LDAP log and checked what the problem is. Sure enough, I found the culprit.

Jan 14 11:18:15 x2100 slapd[4044]: conn=5857 op=1 SRCH base="ou=Users,dc=mydomain,dc=com" scope=2 deref=0 filter=”(uid=minime)”

No wonder LDAP cannot locate the user. Even though it is searching on the right section of the LDAP tree, it doesn’t know which one to pick up. Remember, we use our LDAP server as authentication for our Windows users via Samba as well. Heck, we even authenticate our SSH users via LDAP also.

Another challenge!

How do I hack the filter in OneOrZero so that it works for my LDAP server ? (GOD I LOVE THIS WORK!)

Simple, I have to locate the filter string deep in the vowels of OneOrZero’s source code and insert my own filter or manipulate it so that the output filter will meet what my LDAP server really needs.

OK OK! Enough suspense, how did I do it? Simple.

Navigate yourself to where you extracted OneOrZero - in my case /srv/www/onezero/common , and edit the file common.php . When you open the file, navigate yourself towards line 164 . There you will find the $filter variable which receives the value from the LDAP search attribute that was set in website_settings.php .

When you locate the $filter variable, comment the existing one, and replace it so that it looks like this:

// $filter = "($ldap_searchattr=$name)"; //This is the default filter string

$filter = "(&(objectClass=posixAccount)($ldap_searchattr=$name))" // This is my new filter string to fit my LDAP server.

Save the file and do a test login. That’s it!

If you still have trouble setting it up (which I doubt), feel free to look at the Administration guide at http://www.oneorzero.com/wiki/index.php?title=OneOrZero_Settings

Enjoy!

Technorati : oneorzero, helpdesk, linux, ldap, authentication
Site Search Tags: oneorzero, helpdesk, linux, ldap, authentication

You now have your nice PFSense firewall connected to the net and your users are happily connected then you decided to put up publicly-accessible network services like a web server. But horror starts to creep in when you found out that your users (or your developers) cannot access your public server using their workstations within your local network.

You tried everything in vain and suddenly felt the urge to scream with all your might.

AAAARRGGGHHH!!!!

As far as you’re concerned, you’ve setup PFSense correctly. You have enabled port forwarding quite perfectly. The web server is running without a hitch. You have your DNS working perfectly. But your users cannot seem to access your internal server using your public IP address or domain..

..then you raised your limp hands in resignation.

Dont despair. It’s really simple.

1. Open your PFSense web gui.

2. Move your mouse over to System, and click Advanced.

3. Scroll down, and look at the Disable NAT Reflection field. Make sure that it is unchecked.

4. Click on Save.

That’s all there is to it! Enjoy!

Technorati PFSense, NAT, reflection
Site Search Tags: PFSense, NAT, reflection

Here’s a video article by Laura Chappell on how you can make your wireless snooping a bit more comfy by adding columns for your wireless antenna signal strength.

Video is being hosted at Novell.

Wireshark Training : Adding Columns for Wireless Antenna Signal Strength (Hosted by Novell)

Enjoy!

Technorati wireshark, wireless,
Site Search Tags: wireshark, wireless,

Microsoft announced last December 15 of yet another major flaw in version 7 of its Internet Explorer browser which allows remote code execution on the target computer (as if the others do not already).

Dubbed as Microsoft Security Advisory (961051), the advisory went on to discuss the issue as follows:

The vulnerability exists as an invalid pointer reference in the data binding function of Internet Explorer. When data binding is enabled (which is the default state), it is possible under certain conditions for an object to be released without updating the array length, leaving the potential to access the deleted object’s memory space. This can cause Internet Explorer to exit unexpectedly, in a state that is exploitable.

It appears also that its not only IE7 that’s affected. It affects versions up to IE8 also. Even the BBC has snatched this issue as well.

What was weird for me was that the Full Disclosure community did not make any reaction to this disclosure by Microsoft. Or it might be too early as the secinfo experts and enthusiasts are scrambling to verify this if at all.

My take on this is - what’s new? Honestly, I’m not surprised at all.

Technorati browser, internet, explorer, IE, major, flaw, microsoft, security
Site Search Tags: browser, internet, explorer, IE, major, flaw, microsoft, security

This is just a quick tip I’m putting up in replicating existing packages between Ubuntu installs. I tend to keep forgetting how to do it every time I do a total reinstall of my Ubuntu box. The following simple commands will list down all installed packages and export it to a file, copy to a USB thumbdrive, and import later after doing a reinstall/upgrade. In other words, the following steps will automate your package reinstall that will mimic your old Ubuntu install.

hw@myubuntu:~$ dpkg --get-selections > pkginstalled

The above snippet uses the dpkg command with the --get-selections parameter to read the installed packages and dumps them to a plaintext file. You can then proceed and copy pkginstalled to an USB thumbdrive for later, and proceed with the reinstall or system wipeout/upgrade.

After your new system has been reinstalled, instead of manually installing all the applications that you had previously, just do the following commands to automate the process.

hw@newbox:~$ dpkg --set-selections < /media/disk/pkginstalled
hw@newbox:~$ apt-get dselect-upgrade

The above snippet imports the list of packages from the file pkginstalled from /media/disk (USB thumbdrive) or replace it with the path where you copied you package list file. The next command does the actual package installation based on the list of packages imported.

NOTE: If you were using non-official repositories, please add the necessary third-party repo prior to doing the steps mentioned above.

Enjoy!

Technorati ubuntu, linux, dpkg, package, import, export, automate, cli
Site Search Tags: ubuntu, linux, dpkg, package, import, export, automate, cli

I was doing my daily round of sifting through opensource newsbits when I came across Adeona. According to its creators, it can be described as:

Adeona is the first Open Source system for tracking the location of your lost or stolen laptop that does not rely on a proprietary, central service. This means that you can install Adeona on your laptop and go — there’s no need to rely on a single third party. What’s more, Adeona addresses a critical privacy goal different from existing commercial offerings. It is privacy-preserving. This means that no one besides the owner (or an agent of the owner’s choosing) can use Adeona to track a laptop. Unlike other systems, users of Adeona can rest assured that no one can abuse the system in order to track where they use their laptop.

Adeona is designed to use the Open Source OpenDHT distributed storage service to store location updates sent by a small software client installed on an owner’s laptop. The client continually monitors the current location of the laptop, gathering information (such as IP addresses and local network topology) that can be used to identify its current location. The client then uses strong cryptographic mechanisms to not only encrypt the location data, but also ensure that the ciphertexts stored within OpenDHT are anonymous and unlinkable. At the same time, it is easy for an owner to retrieve location information.

Adeona has builds for Linux, Mac OS X, and Windows ready for download and follow the installation steps should anyone wanna try it out.

Though I currently do not own a laptop or a UMPC (planning to), but this sure is a nice must-have for anybody that does have one or several. I gotta see this for myself.

Technorati Adeona, laptop, tracking, theft, opensource,
Site Search Tags: Adeona, laptop, tracking, theft, opensource,