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

PFSense is a great tool to have that provides a firewall, traffic shaping capabilities, load balancing and failover, and other features plus fully extensible by way of third party opensource “plugins” and packages that you can install via its web console.

Recently though, some of our devs need to connect via FTP to a remote server. And apparently they’ve encountered some weird problem with FTP:

user@ubuntu:~$ ftp some-server.com
Connected to some-server.com.
220 ProFTPD 1.3.1 Server (some-server.com) [143.44.52.54]
Name (some-server.com:user): ftpuser
331 Password required for ftpuser
Password:
230 User ftpuser logged in
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
500 Illegal PORT command
ftp: bind: Address already in use
ftp>

A little investigation revealed that in order for FTP to work, we need to have the FTP Helper proxy application working on the LAN interface of our PFSense box, then add a firewall rule, more like a “transparent FTP proxy”. If you get my drift.

Let’s do it

1. In PFSense, click on Interfaces, LAN

2. Make sure that “Disable the userland FTP-Proxy application” is unchecked.

3. Save your setting, and then click “Apply this setting”.

4. We will now add a rule to permit our LAN traffic to access our FTP-Proxy application ports 8000-8030 on 127.0.0.1 . To do so, click on the “+” button at the bottom or at the top, of the list of rules to add your new rule. Make sure that the new rule will be on top of all the other rules.

5. Save your new settings, and apply.

Test your FTP connection.

Enjoy!

Technorati pfsense, firewall, rule, ftp, access, outbound
Site Search Tags: pfsense, firewall, rule, ftp, access, outbound

This is the first time that I’m going to be posting an article about the DNS issue found by Dan Kaminsky came about. Not because of the severity of this problem, nor is it about how prolific Kaminsky and his skills about hacking is. This post is about how fast something develops within the Internet.

The DNS problem found by Kaminsky, and featured all over the web caused tremendous concern among a lot of security experts, and administrators. Read more to get an idea about DNS and what it does.

In just 2 days since Halvar Flake posted his “speculation” on how Dan Kaminsky can perform a massively successful DNS cache poisoning attack, CaughQ’s Druid and Metasploit’s HD Moore joined efforts in delivering what appears to be the first exploit code specifically targetted at Dan Kaminsky’s DNS bug which Dan happened to be trying to keep hush-hush since its discovery.

The exploit was released and announced at Full Disclosure today at around 3AM local time (11AM Manila Time). Here’s a portion of the mail header for the sent time.

Received: from cpe-24-28-73-141.austin.res.rr.com (HELO ?10.3.3.33?)
(druid@24.28.73.141)
by mail.caughq.org with SMTP; 24 Jul 2008 03:08:35 -0000

Druid and HDMoore’s exploit code, coded on Ruby, appeared to have taken details from Halvar Flake’s “speculation” to implement the attack. Although a lot of people believed that Halvar Flake’s speculation may have been a little off, but it appeared that Halvar may have almost nailed it on the head thus prompting CaughQ and Metasploit to take a look, thus arriving at the latest exploit code.

Disclosure header received at Full Disclosure:


____ ____ __ __
/ \ / \ | | | |
----====####/ /\__\##/ /\ \##| |##| |####====----
| | | |__| | | | | |
| | ___ | __ | | | | |
------======######\ \/ /#| |##| |#| |##| |######======------
\____/ |__| |__| \______/

Computer Academic Underground
http://www.caughq.org
Exploit Code

===============/========================================================
Exploit ID: CAU-EX-2008-0003
Release Date: 2008.07.23
Title: bailiwicked_domain.rb
Description: Kaminsky DNS Cache Poisoning Flaw Exploit for Domains
Tested: BIND 9.4.1-9.4.2
Attributes: Remote, Poison, Resolver, Metasploit
Exploit URL: ------ removed -------
Author/Email: I)ruid
H D Moore
===============/========================================================

Description
===========

This exploit targets a fairly ubiquitous flaw in DNS implementations
which allow the insertion of malicious DNS records into the cache of the
target nameserver. This exploit caches a single malicious nameserver
entry into the target nameserver which replaces the legitimate
nameservers for the target domain. By causing the target nameserver to
query for random hostnames at the target domain, the attacker can spoof
a response to the target server including an answer for the query, an
authority server record, and an additional record for that server,
causing target nameserver to insert the additional record into the
cache. This insertion completely replaces the original nameserver
records for the target domain.

Quoting Dan Kaminsky, “the cat is out of the bag.” Sorry Dan, I don’t think you can stop this now. And I think you know who to blame for this, that is if he/she/they/it can really be blamed?

The rate/speed of development is just truly amazing. The extent?

Technorati DNS, Kaminsky, working+exploit, hacking, metasploit, caughq
Site Search Tags: DNS, Kaminsky, working+exploit, hacking, metasploit, caughq

Covered OS versions:

- Netware 5, 5.5, 6, 6.5
- Open Enterprise Server (OES) Netware Kernel 6.5

iManager versions:

- iManager 2.5
- iManager 2.6
- iManager 2.7

Issue:

You have installed Netware, and iManager on your server box. Suddenly, when you tried to access iManager from your browser, you’re greeted with the “Error 503: Service Unavailable” notification.

This is related to how Novell LDAP (NLDAP) and Netware’s server certificates, and how iManager authenticates through LDAP via Apache Tomcat. There’s a possibility that the server certificates are corrupted or the changes that took place for the server certificates were not propagated to the services that need them. Yes, Netware does suffer corruption every now and then due to the nature of the file system it currently uses. It still uses FAT/FAT16/FAT32. This could be resolved by moving to OES-Linux kernel instead of using pure Netware or OES-Netware kernel.

Solution:

We will need to stop Tomcat, Apache web server, and Java. We will then need to rebuild our server certificates. After which we will need to restart our services.

Actual Commands:
On the Netware command line, type the following commands:

NETWARE: tc4stop
(Terminate Tomcat. For Tomcat 5.0, use tc5stop instead.)

NETWARE: ap2webdn
(Shutdown the Apache web server.)

NETWARE: java -exit
(Shutdown Java.)

NETWARE: pkidiag
(This will open the PKI wizard for detecting and repairing public key infrastructure in Netware. Follow the menu items namely 4, 5, 6, 0)

NETWARE: tckeygen
(Restore LDAP connectivity for Tomcat.)

After a few minutes, start the services.

NETWARE: tomcat
(You may also use /tomcat/5.0/bin/startup start to start Tomcat 5.0.)

NETWARE: ap2webup
(Start up the Apache web server.)

Try opening your iManager again and login (http://ip_of_your_server/nps/iManager.html)

If you found anything erroneous in this tip, feel free to post a comment.

Technorati Tags: Netware, iManager, OES, LDAP, Apache, Tomcat, Novell, Error,503
Site Search Tags: Netware, iManager, OES, LDAP, Apache, Tomcat, Novell, Error, 503

This problem appeared early on sometime around November 25, 2007. To put it simply, its a malware propagation scheme that takes advantage of vulnerabilities of the web servers, CMS, cPanel, some framework, as well as the machines that visit the infected sites. Yes, the magnitude of this exploit is quite huge. What’s more, it infects machines irrespective of operating system platform.

So what is this “problem” really? Its a propagation “framework” if you must — that uses good old Javascript and more of it. It also includes a dash of rogue .htaccess in your Apache server for good measure. How ingenius this is? Well, to put it simply, when you visit an infected site, you’re treated to the sweet taste of Javascript. Except that you’re not seeing anything obvious. Everything is transparent and oblivious to the visitor. You wont feel a thing when this bugger hits your browser. And the icing on the cake on this bugger is that each iteration of the Javascript that will be thrown at your browser will only be once per IP. And no, you cannot wget again using the same IP you’re using now. Once you try and wget the same JS script file, you’d get 404 outright. Once you’re infected, you’ll be deluged with requests from the other infected sites begging your machine to download their own randomly generated versions of the same JS script.

For a more deep down penetration, it scans the visiting machine for vulnerabilities that can be exploited. Yes, your favorite iTunes cuddles with this bugger too along with some of your favorite applications. On Win-machines, ActiveX is the main culprit. However on the server side, whitehats are still continually looking for ways to neutralize this silent threat. The mystery is not on the infection. Its how the servers were compromised and made them host to the rogue code. And most of the detailed discussions were hidden from public view for fear of feeding the kiddies further. Good bet is that automated exploit tools were used to compromise the sheer number of servers in record time. Probably a mutated variant of Metasploit running on various hosts on a botnet simultaneously doing their rounds randomly until an unwitting, seldomly patched server is encountered. And then the carnage starts again until a good number of machines are “droned”. Then when the visits come trickling into the sites, there’s no turning back.

Its already 2008 and this critter is still happily frolicking under the virtual sun. You might have an updated AV (Kaspersky and AVG were known to catch this), however, its a matter of time before you too will be assimilated.

No I won’t give more details about this. Google might give the answer but not me. I’m already busy.

---

Technorati Tags: Javascript+worm, security, exploit, hacking, penetration, Apache, Linux,
Site Search Tags: Javascript+worm, security, exploit, hacking, penetration, Apache, Linux,