Linode.com Forum

mdavid8421 · Joined: 21 Nov 2007 Posts: 10

Hi everyone,

I choose linode for my server and it is been running smoothly so far. Hope it continues that way.

I have written a guide on configuring Debian 4 as a server. Please read it at http://technichristian.net/intro/index.php?q=debian-etch-server and let me know how it is.

Thanks,
Michael.

tofu · Joined: 01 Jul 2006 Posts: 27 Location: Ghent, Belgium

Thanks for the tutorial. I have found some things I can change add on my current installation to make it more secure. Like the Postfix anti DOS config settings.
Now I have an installation running comparable with that in the manual. I also use debian, postfix, lighttpd, .. Now could you add a small part how I can set up my server so I can use it as a smtp mail server? So I don't need to use the one from my ISP anymore? :oops: So then I can set some easy SPF records, and I don't have to change my smtp when I change location. :).

mdavid8421 · Joined: 21 Nov 2007 Posts: 10

Thank you.

SMTP is also there on this server.

The SMTP server should be: yourdomain.com. The username is mailusername+yourdomain.com

Try it and let me know if it works.

I need to see how to integrate SPF checking into postfix. Let me try first.

tofu wrote: Thanks for the tutorial. I have found some things I can change add on my current installation to make it more secure. Like the Postfix anti DOS config settings.
Now I have an installation running comparable with that in the manual. I also use debian, postfix, lighttpd, .. Now could you add a small part how I can set up my server so I can use it as a smtp mail server? So I don't need to use the one from my ISP anymore? :oops: So then I can set some easy SPF records, and I don't have to change my smtp when I change location. :).

mdavid8421 · Joined: 21 Nov 2007 Posts: 10

Hi,

I have added instructions for SPF checking on emails RECD by your domain.

For your own domain, use the SPF wizard at http://www.openspf.org/ to publish your SPF record, so that emails SENT by your domain can be verified by other receiving domains correctly.

Thanks again.

Michael.

tofu wrote: Thanks for the tutorial. I have found some things I can change add on my current installation to make it more secure. Like the Postfix anti DOS config settings.
Now I have an installation running comparable with that in the manual. I also use debian, postfix, lighttpd, .. Now could you add a small part how I can set up my server so I can use it as a smtp mail server? So I don't need to use the one from my ISP anymore? :oops: So then I can set some easy SPF records, and I don't have to change my smtp when I change location. :).

SteveG · Joined: 30 Nov 2003 Posts: 212

What's wrong with "apt-get install lighttpd"? If it's simply wanting the latest version, you might look into backports.org.

mdavid8421 · Joined: 21 Nov 2007 Posts: 10

Nothing wrong with backports.org, except that they do not have the latest stable version. A couple of security issues were fixed between the version in backports and the latest stable.

SteveG wrote: What's wrong with "apt-get install lighttpd"? If it's simply wanting the latest version, you might look into backports.org.

mdavid8421 · Joined: 21 Nov 2007 Posts: 10

Hi,

Hope SMTP worked for you. Please let me know.

Regards,
Michael.

tofu wrote: Thanks for the tutorial. I have found some things I can change add on my current installation to make it more secure. Like the Postfix anti DOS config settings.
Now I have an installation running comparable with that in the manual. I also use debian, postfix, lighttpd, .. Now could you add a small part how I can set up my server so I can use it as a smtp mail server? So I don't need to use the one from my ISP anymore? :oops: So then I can set some easy SPF records, and I don't have to change my smtp when I change location. :).

tofu · Joined: 01 Jul 2006 Posts: 27 Location: Ghent, Belgium

mdavid8421 wrote: Nothing wrong with backports.org, except that they do not have the latest stable version. A couple of security issues were fixed between the version in backports and the latest stable.
Is Quote: apt-get install -t unstable lighttpd not a good alternative then?
mdavid8421 wrote: Hope SMTP worked for you. Please let me know. Super! Thanks for adding in you tutorial. Unfortunately I'm still stuck in making a smtp server :cry:.
Code: warning: xsasl_cyrus_server_get_mechanism_list: no applicable SASL mechanisms
fatal: no SASL authentication mechanisms
warning: process /usr/lib/postfix/smtpd pid 22757 exit status 1
warning: /usr/lib/postfix/smtpd: bad command startup -- throttling
Can't even connect to the smtpd
Code: $ telnet tufus.info 25
Trying 70.85.129.231...
telnet: connect to address 70.85.129.231: Operation timed out
While my firewall (firehol) has the smtp port open.
/etc/default/saslauthd:
Code: START=yes
MECHANISMS="pam"
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd -r"
/etc/postfix/sasl/smtpd.conf
Code: pwcheck_method: saslauthd
mech_list: plain login /etc/postfix/main.cf Code: # See /usr/share/postfix/main.cf.dist for a commented, more complete version

# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
delay_warning_time = 4h
TLS parameters
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = tufus.info
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = tufus.info, localhost.info, ,localhost, saai.be
relayhost =
mynetworks = 127.0.0.0/8
mailbox_command = /usr/bin/procmail
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,rejec
virtual_maps = hash:/etc/postfix/virtusertable
unknown_local_recipient_reject_code = 450
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_tls_auth_only = no
smtpd_helo_required = yes
message_size_limit = 31457280
smtp_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

#Protect against DOS attacks
disable_vrfy_command = yes
smtpd_error_sleep_time = 0s
smtpd_soft_error_limit = 5
smtpd_hard_error_limit = 10
smtpd_timeout = 30s
smtpd_delay_reject = no

sweh · Joined: 13 Apr 2004 Posts: 223

Where where you trying to smtp _from_ ? Some home DSL/cable/whatever providers block outgoing port 25 connections (to stop spam). So in your testing make sure you're not testing from a blocked network :-)

mdavid8421 · Joined: 21 Nov 2007 Posts: 10

Looks like the postfix installation is messed up. My suggestion would be to remove both postfix,courier and saslauthd and start again.

apt-get remove --purge postfix libsasl2 sasl2-bin libsasl2-modules libdb3-util procmail

Then start again.

After full installation, install nmap [apt-get install nmap], then run nmap localhost to see all the ports open. 25 should be open.

Also the user name is just the mailusername.

tofu wrote: mdavid8421 wrote: Nothing wrong with backports.org, except that they do not have the latest stable version. A couple of security issues were fixed between the version in backports and the latest stable.
Is Quote: apt-get install -t unstable lighttpd not a good alternative then?
mdavid8421 wrote: Hope SMTP worked for you. Please let me know. Super! Thanks for adding in you tutorial. Unfortunately I'm still stuck in making a smtp server :cry:.
Code: warning: xsasl_cyrus_server_get_mechanism_list: no applicable SASL mechanisms
fatal: no SASL authentication mechanisms
warning: process /usr/lib/postfix/smtpd pid 22757 exit status 1
warning: /usr/lib/postfix/smtpd: bad command startup -- throttling
Can't even connect to the smtpd
Code: $ telnet tufus.info 25
Trying 70.85.129.231...
telnet: connect to address 70.85.129.231: Operation timed out
While my firewall (firehol) has the smtp port open.
/etc/default/saslauthd:
Code: START=yes
MECHANISMS="pam"
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd -r"
/etc/postfix/sasl/smtpd.conf
Code: pwcheck_method: saslauthd
mech_list: plain login /etc/postfix/main.cf Code: # See /usr/share/postfix/main.cf.dist for a commented, more complete version

# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
delay_warning_time = 4h
TLS parameters
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = tufus.info
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = tufus.info, localhost.info, ,localhost, saai.be
relayhost =
mynetworks = 127.0.0.0/8
mailbox_command = /usr/bin/procmail
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,rejec
virtual_maps = hash:/etc/postfix/virtusertable
unknown_local_recipient_reject_code = 450
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_tls_auth_only = no
smtpd_helo_required = yes
message_size_limit = 31457280
smtp_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

#Protect against DOS attacks
disable_vrfy_command = yes
smtpd_error_sleep_time = 0s
smtpd_soft_error_limit = 5
smtpd_hard_error_limit = 10
smtpd_timeout = 30s
smtpd_delay_reject = no

SteveG · Joined: 30 Nov 2003 Posts: 212

tofu wrote:
Is Quote: apt-get install -t unstable lighttpd not a good alternative then?

The downside of installing from unstable is that you're likely to pull in a new libc6 and a bunch of other libraries. Using backports gives you (reasonably) current versions of specific software compiled against the stable version of the core libraries. The downside, as mdavid noted, is that backports.org versions are not always updated w.r.t. security issues; it depends on the individual backport maintainer. OTOH, if you build from scratch, then *you're* responsible for security updates. Of course, that's generally true anyway, but "apt-get upgrade lighttpd" is lot easier than grabbing and building new source. Especially since I personally have an aversion to installing compilers etc. on Internet-facing boxes. YMMV.

rm · Joined: 26 Aug 2007 Posts: 7

Don't try to pull binary packages from sid, its going to end in pain. Better to backport it from sid if backports.org isn't to your favour.
One can build lighttpd this way.

::: Irssi: Starting query in freenode with dpkg
<dpkg> told random about simple sid backport
(First: See if the package has already been backport
ed. Ask me about <backports>.
If it hasn't,
1) Add a deb-src line for sid to your sources.list.
2) apt-get update
3) apt-get build-dep packagename;apt-get -b source packagename; 4) install the resultant debs.)

Or if you want to do the ./configure && make && make install drill I suggest using stow.
The procedure changes to ./configure --prefix=/usr/local/stow/progam --exec-prefix=/usr/local/stow/program && make && make install && cd /usr/local/stow/ && stow -v program

Is there a specific reason to ./configure --prefix=/usr instead of /usr/local/ in the howto? Feels like it could be bring up an issue or few later on.

mdavid8421 · Joined: 21 Nov 2007 Posts: 10

Steve, I am also allergic to keeping compilers on internet boxes. That is the reason why I delete all compilers and development stuff after our job is done.

As far as security is concerned, any admin has to read through security lists, find out if anything affects his/her server and accordinly patch the system.

SteveG wrote: tofu wrote:
Is Quote: apt-get install -t unstable lighttpd not a good alternative then?

The downside of installing from unstable is that you're likely to pull in a new libc6 and a bunch of other libraries. Using backports gives you (reasonably) current versions of specific software compiled against the stable version of the core libraries. The downside, as mdavid noted, is that backports.org versions are not always updated w.r.t. security issues; it depends on the individual backport maintainer. OTOH, if you build from scratch, then *you're* responsible for security updates. Of course, that's generally true anyway, but "apt-get upgrade lighttpd" is lot easier than grabbing and building new source. Especially since I personally have an aversion to installing compilers etc. on Internet-facing boxes. YMMV.

tozz · Joined: 28 Nov 2007 Posts: 5 Location: San Francisco, CA

Is there any way to prevent PHP from roaming freely?

Both lighttpd and php-cgi is running as www-data but they can still access directorys everywhere (which is strange since I would think the filesystem would disallow it).

SteveG · Joined: 30 Nov 2003 Posts: 212

Well, they can't go *everywhere*, but then can access any directory/file that has read permission for "other". Traditionally, this is the default. Note that they shouldn't be able to *write* everywhere.

The only easy way to prevent this (AFAIK) is to run the PHP et. al. stuff in a chroot. Well, not easy, really; straightforward is probably a better adjective.

As a side note, while the PHP "system" can access anything not explicitly forbidden, PHP *applications* shouldn't allow web users arbitrary access. But we all know bugs exist.

New debian 4 server article