Identification:
Syslog on the affected server will present multiple lines containing daemon per_source_limit for 0.0.0.0.

Cause:
You have exceeded per_source_limit defaults imposed by your xinetd configuration. Many distributions include per_source limits that may not be suitable for your use case. Evaluate your needs carefully.

Resolution:
Modify the default setting for per_source in /etc/xinetd.conf or modify the service specific configuration (recommended) under /etc/xinet.d. per_source limits may be set as follows:

per_source may be set to an integer or UNLIMITED (the number represents the number of connections allowed per host). A sensible fixed value is always better than UNLIMITED.

Reference: xinetd.conf(5)

Investigating the log on the PIX/ASA will yield a corresponding error:

Cause:
The issue is the result of a corrupt or missing RSA key on the firewall.

Resolution:
You need to generate a new RSA key on the firewall.

Magic juju (from either SDM or a prompt):

Issue:
The error presented when attempting to label S3 buckets for use by Amanda in a virtual tape changer configuration. The OS is Linux and the distribution, Gentoo.

The exact error encountered was

labeling tape in slot 1 (s3:myBucket/backupSet/0001/):
Reading label...
While trying to read tapestart header: CURL error: SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (CURLcode 60)
Reading the tape label failed:
  Error was Device error.

Cause:
The error is related to curl's desire to perform peer SSL certificate verification as a default. This is a "good thing" and requires minimal intervention to work around once an admin is aware of the issue.
Reference:
http://curl.haxx.se/docs/sslcerts.html

Resolution:
Gentoo centralizes a collection of CA certificate PEM files with the app-misc/ca-certificates package in portage. This should be installed as part of a normal Gentoo system, however, it is possible that a particular CA PEM may be absent. In this case, download the missing PEM file and place it in /etc/ssl/certs. Once this is done be sure to run the following command to update the local system certificate store:

update-ca-certificates

Tools for extracting Common CA PEM files from Mozilla projects and a standard PEM bundle can be found at: http://curl.haxx.se/docs/caextract.html

The syntax of /etc/hosts.allow is actually quite simple and easy to understand, unlike, say, sendmail.cf or the scattered nature of qmail. Most of the rules and settings are used in the following form:

service : host/network : option [: option] ...

where:

service
The name of the dæmon or service program that rule will be written for. Examples include popa3d, imapd, and sshd. You can also use the ALL wild card to cover all services and dæmons.
host/network
The host or network that the rule will apply to. You can use the any of the following notations to best suit your needs.

* IP Address: 10.4.2.5 or 172.16.7.4
* IP Class A/B/C Subnet: 10.4. or 172.16.7.
* IP Network with Subnet Mask: 10.4.0.0/255.255.0.0 or 172.16.7.0/255.255.255.0
* IPv6 Addresses: [2f3f::]/10 or [4c20:fe37:1:1::]/64
* Fully Qualified Domain Name: foo.insecure.net or bad.hairday.insecure.net
* Domain Name: insecure.net or hairday.insecure.net
* Relative Hostname: foo or bad
* Wild Cards: Wild card optionss that can be used are:
o ALL: All clients regardless of IP address or domain name.
o PARANOID: Clients that have hostnames that don't match its ident/domain lookup names. This does not apply to machines that do not have any reverse domain lookup names.
o LOCAL: A client that comes from the same machine or domain as the host.
o UNKNOWN: A client that cannot be resolved to anything known.
o KNOWN: A client who's name and addresses can be resolved.

option
A command or an option telling it how to treat the connection request. In majority of the cases, you will see or use allow or deny for the command. spawn or twist commands can also be used to send a customized error to the requester or send an alert to the administrator. Some of the most commonly used options will be covered a bit later in this article.

Options

The option field for each of the rules provides the basic allow and deny directives, plus several other options that allow you to customize how it logs the connection attempt (via syslog or e-mail), run a system command and other options that control the connection. Below are the most common options that you may use in /etc/hosts.allow and how they affect the connection.

allow
As the name implies, it simply lets the connection through; this option must be at the end of a rule.
deny
Denies the connection without providing the requester any chance to try again. All denied connections are logged to syslog with the service and host that the deny rule matched.
spawn (command(s))
Generates a new process that will run the command(s) given, but the spawn commands themselves will not allow or deny the connection, so you must have either " : allow" or " : deny" at the end of the rule in order to make the rule truly effective.
twist command(s)
Like spawn, it will create a new process to allow you to run the necessary commands, with the common standard input, output and error objects are linked to the twist option. This option can be used to print out a customized message when someone tries to connect to a service like ftpd. Instead of allowing or denying the connection immediately, the twist commands determine if the requester should be let through or not. A twist option followed by only an echo command will send the echo'd text to the client and closes the connection.
rfc931 [timeout]
This option does a username lookup of the requester via ident, and checks to see if the username and the information povided by the requester match up. The timeout option is used to limit the amount of time that the machine will wait to receive a ident response.
nice [priority]
Like the nice in BSD, this option allows you to change a process' priority; thus provides means to limit how much processor a guest or a not-quite-so-trusting client can use.
banner /dir/path
This option searches for a file named after the specified service in /dir/path, reads in the contents, resolves expansions (a list of expansions can be found in hosts_access(5) manual page. This option is valid only for TCP services and dæmons, not for UDP services.

Comments in the /etc/hosts.allow are very similar to shell scripts where each comment line starts with a hash mark (#) and extends to the end of the line. There is one significant difference in how comments are handled in hosts.allow and shell scripts is that comments are not allowed after a rule. The following example shows valid uses of comments in the file.

# this is a valid comment
portmap : 1.2.3.4 : deny
# so is this

sshd : 9.8.7.6 : deny # but not this one

Tightening Down Your Services

Once you understand the syntax of setting up access controls and options, you are now ready to write your own hosts.allow file. Without the use of deny rules all running TCP-wrapped services or enabled in inetd will be wide open until you explicitly. The example below allows shows some of the possible ways to configure the hosts.allow file.

portmap : localhost : allow
portmap : 10. : allow
portmap : .insecure.net : allow
portmap : ALL : deny

sshd : ALL : allow
sshd : bad.host : deny
sshd : 88.4.2. : deny (1)

ALL : ALL : deny

Taking a look at the portmap section of the configuration, we are allowing localhost, any machines with an IP address starting with 10. and any machines that have .insecure.net for a domain name or ident name. All other machines and hosts are disallowed. If you do not include localhost in a rulset, you will lock the host out which may or may not be a good thing.

The sshd section states that all machines are allowed at first, but then blocks any machine with the relative hostname of bad.host or any machines with an IP address starting with 88.4.2 (1). The last rule in the configuration pretty does what it says, which is to deny all machines access to the other "tcp wrapped" services and dæmons that do not have any explicit rules stating otherwise. If you want to allow all hosts to the other services without intervention, replace the last line with:

ALL : ALL : allow

If you do include a rule that denies all hosts access to a particular service and forget to include the localhost or management hosts, you may end up inadvertantly lock yourself (and others) out. If you setup a rule that allows all hosts to use a service and deny specific hosts, you may still leave yourself open to other untrusted hosts. To limit such exposures, check /etc/inetd.conf for any services that are enabled but really do not need to be enabled, and disable them. One perfect example on restricting access to services that are known to be inherently insecure is to only allow clients from the internal network access to the telnet dæmon (telnetd).
Words Of Caution

No matter how tempting it is to setup a rule that says

ALL : ALL : deny

at the very top if the hosts.allow file, DO NOT DO IT!. The access control facility takes each rule literally, meaning that it will see that rule and deny the connection before going through the rest of the rules. The same applies to denying access to all hosts to a particular service first, then allowing the trusted hosts; the deny rule will be enacted upon and the connection is rejected. For example, a bad way of writing a ruleset would be:

sshd : ALL : deny
sshd : localhost : allow
sshd : 10.0.3. : allow

Instead, re-write the ruleset to be:

ssh : 10.0.3. : allow
ssh : localhost : allow
ssh : ALL : deny

That way, the hosts that should be allowed will be allowed through, the rest will fail the first two rules and then finally gets denied when it reaches the deny rule.

If you write any rules that use domain or hostnames for the second field, you could be denying access to hosts that do have a valid reverse domain lookup name (this includes IP addresses that do not have any PTR records setup on the domain name server that is responsible for that subnet) or do not have any ident dæmons running, if you do not include any allow rules for them before a ": ALL : deny" rule. Instead, you may want to allow specific subnets or IP address ranges to allow access to those services.
Other Notes

Any changes that are made to /etc/hosts.allow take effect immediately (there is no need to restart inetd or restart the network services). There are some options that will only work with TCP services or cause problems when used with UDP services. Some of the caveats and warnings are documented in both hosts_access(5) and hosts_options(5) manual pages. By using rules to allow or deny connections, each connection made to the host requires some additional overhead to check the validity of the client information and to compare that information with each of the applicable rules. Depending on the average load on the host, number of connection attempted in a given time, and the available resources, using hosts.allow may not be a viable option.

Some services or dæmons provide more detailed facilities to allow or deny connections based on IP address, domain name and other criteria that could be easier to configure than what is possible with hosts.allow. In addition, hosts.allow cannot act as a filter for malicious code or application level denial-of-service attacks (like the file-globbing exploit in earlier versions of ProFTPD or a man-in-the-middle attack with ssh).
Conclusion

hosts.allow is quite an interesting and useful facility that can help increase the security of the host, but typos and poorly written rules can make the host as or more susceptable to exploits than without those rules. Typos could also end up locking yourself out of the box when you least expect it. As stated above, using the access control facility for "tcp wrapped" services and dæmons can and probably will take a hit on the host's performance and possibly limit the response rate for the client.

The facility is not a complete security solution nor should it be treated as such, rather it's a compliment to packet filtering and firewall solutions available (be it gratis, free-speech or commercial). There are some features that are available only by using the hosts.allow facility such as redirecting specific clients to other services, or returning specific error messages, and banners specific to the service and/or client. Nonetheless, this is a great facility that some people overlook as a method to provide a simple means to deny access to specific servies to specific hosts.

Reference: http://closedsrc.org/_static/dn-articles/hosts_allow.html

Note:
If the last line of a hosts access file is not a newline character (created by pressing the Enter key), the last rule in the file fails and an error is logged to either /var/log/messages or /var/log/secure. This is also the case for a rule that spans multiple lines without using the backslash. The following example illustrates the relevant portion of a log message for a rule failure due to either of these circumstances:

 warning: /etc/hosts.allow, line 20: missing newline or line too long

Reference: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/en-US/Reference_Guide/s1-tcpwrappers-access.html

References:
http://developer.amazonwebservices.com/connect/thread.jspa?messageID=51028읔
http://developer.amazonwebservices.com/connect/message.jspa?messageID=107770