Debian – Securing dnsmasq – interface(s)

David's answer is a good baseline of the general principles of server hardening. As David indicated, this is a huge question. The specific techniques you take could depend highly on your environment and how your server will be used. Warning, this can take a lot of work in a test environment to build out and get done right. Followed by a lot of work to integrate into your production environment, and more importantly, business process.

First, however, check to see if your organization has any hardening policies, as those might be the most directly relevant. If not, depending on your role, this might be a great time to build them out. I would also recommend tackling each component separately from the bottom up.

The L
There are lots of good guides available to help you out. This list may or may not help you depending on your distribution.

• Center for Internet Security Benchmarks - Distribution specific for the major flavors
• CentOS Hardening HowTo - Follows closely to the CIS RHEL5 guide, but is a much easier read
• NIST SP800-123 - Guide to General Server Security
• NSA Hardening Factsheets - Not as recently updated as CIS, but still mostly applicable
• Tiger - Live System Security Auditing Software

The A
Apache can be fun to secure. I find it easier to harden the OS and maintain usability than either Apache or PHP.

• Apache Server Hardening - This question on the IT Security sister site has lots of good information.
• Center for Internet Security Benchmarks - Again, Apache benchmarks.
• Apache Security Tips - Straight from the Apache project, it looks like it covers the basics
• DISA Hardening Checklist - Checklist from the DoD Information Assurance guys

The M

• Center for Internet Security Benchmarks - Again, but for MySQL benchmarks
• OWASP MySQL Hardening
• General Security Guidelines - Basic checklist from the project devs

The P
This runs headlong into the whole idea of Secure Programming Practices, which is an entire discipline of its own. SANS and OWASP have a ridiculous amount of information on the subject, so I won't try to replicate it here. I will focus on the runtime configuration and let your developers worry about the rest. Sometimes the 'P' in LAMP refers to Perl, but usually PHP. I am assuming the latter.

• Hardening PHP - Some minor discussion, also on IT Security SE site.
• Hardened PHP Project - Main project that produces Suhosin, an attempt to patch the PHP application to project against certain types of attacks.
• Hardening PHP With Suhosin - A brief HowTo specifically for Suhosin
• Hardening PHP from php.ini - Short, but not bad discussion on some of the security related runtime options

dnsmasq has dhcp server disabled by default. To enable it you have to uncomment dhcp-related lines in /etc/dnsmasq.conf

to forward all requests to 208.67.222.222 it's sufficient to add (without touching dnsmasq config) in /etc/resolv.conf:

nameserver 127.0.0.1 
# In order to configure dnsmasq to act as cache for the host on which  it
# is  running, put [as the first line] "nameserver  127.0.0.1" in /etc/resolv.conf to force
# local processes to send queries to dnsmasq. [...]
# dnsmasq is smart enough to ignore this line and forward all queries appropriately, 
# while all other applications will send all their queries to dnsmasq. 
nameserver 208.67.222.222

That's it :)