David Goodwin

Server: Debian Lenny

Installed .deb from here

# wget http://sourceforge.net/projects/postfixadmin/files/postfixadmin/postfixadmin_2.3_all.deb/download

....

# dpkg -i postfixadmin_2.3_all.deb

... dpkg moans about missing dependencies

Selecting previously deselected package postfixadmin.(Reading database ... 38632 files and directories currently installed.)Unpacking postfixadmin (from postfixadmin_2.3_all.deb) ...dpkg: dependency problems prevent configuration of postfixadmin: postfixadmin depends on dbconfig-common; however:  Package dbconfig-common is not installed. postfixadmin depends on wwwconfig-common; however:  Package wwwconfig-common is not installed. postfixadmin depends on php5-imap; however:  Package php5-imap is not installed.dpkg: error processing postfixadmin (--install): dependency problems - leaving unconfiguredErrors were encountered while processing: postfixadmin

# apt-get -f install

(dependencies now get installed...)

…. Goes into the Postfixadmin .deb installer thing.

• Tell it to use Apache2 (in my case) as the webserver,
• Give it the ‘root’ user’s database password (if MySQL).
• Tell it to generate a password for the postfixadmin user…
• Tell it to use the package maintainers version of /etc/postfixadmin/config.inc.php (well I did).

I think something went wrong for me – as I needed to do this afterwards; perhaps you’ll have better luck.

# mv /etc/postfixadmin/config.inc.php.ucf-dist /etc/postfixadmin/config.inc.php

Next, goto http://yourserver/postfixadmin/setup.php – you should see lots of text saying how it’s updating the database to version xyz, xyz+1 etc.

Choose a password to protect the setup.php page; press submit, and you’ll be presented with a ‘hash’ – copy and paste this into the config.inc.php file – so you get something like this on line 32 :

$CONF[‘setup_password’] = ‘my long hash thingy goes in here’;

Next, create a super admin account, using the setup.php page – remembering to type in the setup password you used to create the hash above.

That’s it.

(Well, now you need to configure Postfix and/or courier and/or dovecot etc etc)

You might want to read my other article which covers this…

Today I had a phone call which went along the lines of ….

Prospect: Do you develop web applications?
Me: Yes… <cue sales pitch>
Prospect: I’ve got a great idea, it’s like eBay…. I need a programmer….
Me: <thinking: oh not another….>
Prospect: I think it’s about 2 developer months worth of work….
Me: Well, we’d need to see your requirements spec to determine that.
<snip>
Prospect: Would you be willing to do the work for free in return for a stake in the resultant venture? How much would it cost?
Me: Well, I’ve not seen any sort of requirements specification; I’ve no idea what’s involved….. Just how long is a piece of string?

I don’t quite understand why people think they’ll be able to create an eBay/Amazon/Google/whatever killer/competitor with minimal funding, a couple of months development and also persuade me to do the work for free on the outside chance they’re successful (that’s like a <5% chance). I might consider reducing the price of the development in return for a share in any resultant company – but I’m sure as not going to commit to anything before I’ve seen any sort of business plan.

Perhaps tomorrow I’ll get someone wanting a site “like Facebook” costing a few thousand pounds… ‘cos we do PHP just like them… and it can’t be hard can it?

A customer has a relatively busy web site, which contains lots of juicy information (business names, addresses, email address, phone numbers etc etc). Currently there is nothing in place to stop people spidering it – unless someone explicitly looks at the log files and does something.

Blocking annoying people who spider the site is easy enough –

iptables -I INPUT -s 80.x.x.x -j REJECT

However, I’d obviously rather automate this if possible – and ideally without having to change the PHP code (as each request would need perform some sort of DB lookup it’s part of a spidering attempt)

So, my first idea was to manipulate an existing rule I have to limit SSH connection attempts, giving something like :

iptables -I INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --set

iptables -I INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 40 -j LOG --log-prefix "http spidering?" --log-ip-options --log-tcp-options --log-tcp-sequence --log-level 4

Annoyingly however, even though these are the first rules in the iptables output – and they should therefore work, they don’t – i.e. I’m not seeing anything being logged, when doing e.g. the following on a remote server :

while [ true ] ; do

wget -q -O - http://server.xyz/index.php

done

So, I’m still trying to avoid making changes to the code base – although doing so would produce the best user experience (namely we could display a captcha or something and if someone really can browse that quickly they’d not encounter any problems).

And as I’ve just found mod_evasive which claims to provide DoS and DDoS protection. Thankfully Jason Litka has packaged it – so I have no problems from an installation point of view 🙂 (yum install mod_evasive)

Installation on Debian doesn’t result in a config file – but it’s not difficult to create (see /usr/share/doc/mod_evasive). However, it’s not a shiney, sunny ending – mod_evasive appears to be “tripped” by people requesting images – and in my case the client has about 10-20 images per page; so it’s difficult to differentiate between a normal user loading a page or someone running httrack on the website and only requesting the “php page”. If only mod_evasive took a regexp to ignore/match… and I can’t seem to find anyway of fixing this.

So application logic it is :-/ Perhaps caching in APC may be the way forward ….