Fighting SPAM - Sendmail

To Fight SPAM for Sendmail, modification of the sendmail.cf need to be done so that it can be functional well.

The Modification of the sendmail.cf file as below:

define(`confPRIVACY_FLAGS',`goaway')dnl
FEATURE(smrsh)dnl
define(`confMAX_HEADERS_LENGTH',16384)dnl
define(`confMAX_MESSAGE_SIZE',2097152)dnl
define(`confCONNECTION_RATE_THROTTLE',3)dnl
define(`confMAX_DAEMON_CHILDREN',12)dnl
define(`confSMTP_LOGIN_MSG', `$j server ready at $b')dnl
define(`confMAX_RCPTS_PER_MESSAGE,25)dnl

FEATURE(`relay_entire_domain')
FEATURE(`relay_based_on_MX')
FEATURE(`relay_local_from')
FEATURE(`relay_mail_from')
FEATURE(`loose_relay_check')
FEATURE(`accept_unresolvable_domains')
FEATURE(`accept_unresolvable_domains')
FEATURE(`access_db')
FEATURE(`relay_hosts_only')
FEATURE(`blacklist_recipients')
FEATURE(`dnsbl')
FEATURE(`delay_checks')

DNS Software Protection Approach

Best practice protection approaches for DNS software are as follows:
• Running the latest version of name server software, or an earlier version with appropriate patches
• Running name server software with restricted privileges
• Isolating name server software
• Setting up a dedicated name server instance for each function
• Removing name server software from nondesignated hosts
• Creating a topological and geographic dispersion of authoritative name servers for fault tolerance
• Limiting IT resource information exposure through two different zone files in the same physical name server (termed as split DNS) or through separate name servers for different client classes.

BIND 9.5's new features

BIND, which originally stood for Berkeley Internet Name
Daemon, is a suite of DNS (domain name system) software
that provides a DNS server, DNS resolver library, and various
DNS-related tools.

BIND dates back to the early 1980's where it was designed
to serve the needs of distributed computing communities and to
be compatible with the naming service planned for the DARPA
Internet. Since the mid-1990's, BIND has been maintained and
developed by Internet Systems Consortium (ISC) which has become
well-known for their support for many open source projects,
funding and development of BIND and other open source
software, and design and advocacy of many Internet standards.
BIND was rewritten and version 9 was released in September
2000.

According to the Infoblox 2007 DNS Survey, 70% of the Internet's
estimated 11.7 million name servers ran BIND. (Microsoft's
DNS Server ran on 2.7%.) BIND is provided in the default
installations of NetBSD, FreeBSD, OpenBSD, and DragonFly
operating systems. Plus, it is the frequently recommended
DNS server used on most Linux distributions and various
Unix flavours.

For over a year, ISC has been developing and testing many new
features for BIND 9.5. This article will quickly summarize some of
the significant new features:
• GSS-TSIG support
• DHCID
• Statistics support for named via XML
• UDP Socket Pool
• Handling EDNS timeouts
• O(1) ACL processing

GSS-TSIG, or the Generic Security Service Algorithm for
Secret Key Transaction Authentication for DNS, is documented
in RFC 3645. It is an update for Secret Key Transaction
Authentication.

GSS-TSIG is the authentication mechanism of choice for DNS
dynamic update in Microsoft Active Directory.

It is potentially useful for other things, said Rob Austein of
ISC, but the big push for BIND 9.5 was to allow named (the
BIND DNS server) to act as the DNS server for an Active Directory
zone.

GSS-TSIG is a composite of GSSAPI and TSIG – a wrapper
layer built on top of a wrapper layer. It is insanely general, said
Austein, but the common usage is DNS wrapping TSIG wrapping
GSSAPI wrapping SPNEGO wrapping Kerberos 5 – thus for
practical purposes it is a mechanism for using Kerberos 5 to authenticate
DNS.

BIND added the new DHCID Resource Record (RR) type
to keep up with standards. The DHCID RR is used for encoding
DHCP information and DHCP servers and clients use it to identify
DHCP clients with a DNS name with a strategy of reducing
conflicts in the use of fully-qualified domain names. The data is
a one-way SHA-256 hash computation. More details are in RFCs
4701 and 4703.

BIND 9.5 adds an experimental HTTP server and statistics
support for the DNS server via XML. It is not a web-based configu-
BIND 9.5's new features ration interface, but a statistics feed that happens to use the HTTP
protocol for delivery because it is flexible and very well-supported,
said Evan Hunt of ISC.

Also BIND 9.5 makes it a bit harder to play games with insecure
DNS by brute force attack on the 16-bit DNS ID space,
said Austein. The server provides a pool of UDP sockets for queries
to be made over, for example, using eight ports instead of
one in effect adds three more bits to the search space.

BIND 9.5 makes fallback to plain DNS from EDNS due to timeouts
more visible. EDNS (Extension Mechanisms for DNS)
have been available for around eight years and many servers (and
all root servers) support it.

The problem is that some firewalls do not support EDNS by
default, said Mark Andrews of ISC. Also there are some authoritative
servers that fail to respond when they see a EDNS query
rather than return an error code as is required, said Andrews. Timeouts
may mean network problems, dead servers, broken middle
boxes, and broken authoritative servers.

Falling back to plain DNS will help with the later, said Andrews,
but has a negative impact on DNSSEC (which requires
EDNS) especially when there are overloaded links causing
packet loss.

On timeouts, named retries EDNS with a 512 octet UDP size
(which usually allows EDNS to get through a firewall as it
is generally not fragmented and is within the sizes allowed by
plain DNS) and then tries plain DNS if still needed. The server
logs this to draw attention to the issue and to get any non-RFC
compliant boxes replaced or re-configured, said Andrews.

Andrews said at some point soon, BIND will not fallback from
EDNS to DNS on timeout. He suggests the following for BIND administrators
for EDNS:
• Firewalls and NAT boxes need to handle fragmented
responses both in and out of order.
• Firewalls need to handle EDNS responses.
• Broken authoritative servers need to be replaced or upgraded
which first means they need to be identified.

Also BIND 9.5 introduces a new ACL-processing engine.
Instead of storing ACLs (i.e., allow-query, allow-recursion,
et cetera) as linear lists that have to be searched every time
a query comes in, they are now modified radix trees. There
should not be any change in the way things are configured,
said Evan Hunt of ISC, but sites with ACLs containing more
than one or two addresses should hopefully see an uptick in
queries per second.

More details about BIND 9.5 features can be found in the
BIND Administrator Reference Manual and manual pages.

Foundation of Security – C.I.A

Confidentiality protects information or resources from unauthorized
access.
Integrity ensures the trustworthiness of data or resources through the
management and control of changes.
Availability refers to continual accessibility of information and
resources

DNS Transaction Threats and Security Objectives

Recommendations for Electronic Mail Security

Here are some guidelines in planning, implementing, and maintaining secure electronic mail systems for suitable to execute in most of the organization:
? Carefully plan and address the security aspects of the deployment of a mail server.
Careful planning is critical to the efficient implementation of a secure mail server. It is more difficult and costly to address security issues once the mail server is deployed. With careful planning, organizations can make sure that their mail servers meet their security requirements and are in compliance with all relevant organizational policies prior to installation, configuration, and deployment. Management controls are especially important in organizations where the information technology support structure is highly fragmented. This fragmentation can lead to inconsistencies in managing systems, and these inconsistencies often result in security vulnerabilities.
Organizations are more likely to make decisions about configuring computers appropriately and consistently when they develop and use a detailed, well-designed deployment plan. The development of such a plan will support mail server administrators in making the inevitable trade-off decisions between usability, performance, and risk.
Some of the issues that should be addressed in the organization’s deployment plan include:
* Purpose of the server and the services to be provided;
* Software to be installed;
* Users and their privileges;
* Security and privacy issues;
* Management practices and procedures to assure secure systems;
* Types of personnel required for deployment and operational phases of the mail server and the supporting infrastructure. Personnel types that should be considered include system and mail server administrators, network administrators, and information systems security officers;
* Skills and training required by assigned personnel; and
* Availability of personnel.
? Implement appropriate security management practices and controls when maintaining and operating a secure mail server.
Appropriate management practices are essential to operating and maintaining a secure mail server. As part of their comprehensive planning and management practices, organizations should identify their systems and information to be protected, and then develop, document, and implement the policies, standards, procedures, and guidelines that will help to ensure the confidentiality, integrity, and availability of information system resources.
To ensure the security of a mail server and the supporting network infrastructure, the following practices should be implemented:
* Organization-wide information system security policy;
* Configuration/change control and management;
* Risk assessment and management;
* Standardized software configurations that satisfy the information system security policy;
* Security awareness and training;
* Contingency, continuity of operations, and disaster recovery planning; and
* Certification and accreditation.
? Ensure that the mail server operating system is deployed, configured, and managed to meet the security requirements of the organization.
The first step in securing a mail server is to secure the underlying operating system. Most commonly available mail servers operate on a general-purpose operating system. Many security issues can be avoided if the operating system’s underlying mail servers are configured appropriately. Default hardware and software configurations are typically set by manufacturers to emphasize features, functions, and ease of use at the expense of security. Because manufacturers are not aware of each organization’s security needs, each mail server administrator must configure new servers to reflect their organization’s security requirements and reconfigure them as those requirements change. Using security configuration guides or checklists can assist administrators in securing systems consistently and efficiently. To secure the operating system, organizations should carry out the following steps:
* Patch and update the operating system;
* Remove or disable unnecessary services and applications;
* Configure operating system user authentication;
* Configure resource controls;
* Install and configure additional security controls if needed; and
* Perform security tests on the operating system.
? Ensure that the mail server application is deployed, configured, and managed to meet the security requirements of the organization.
Many of the steps outlined for the security of the operating system apply also to the secure installation and configuration of the mail server application. The basic recommendation is that organizations install the minimal mail server services required and eliminate any known vulnerabilities through patches or upgrades. If an installation program installs unnecessary applications, services, or scripts, they should be removed immediately after the installation process has been completed. The following steps should be performed in securing the mail server application:
* Patch and upgrade the mail server application;
* Remove or disable unnecessary services, applications, and sample content;
* Configure mail server user authentication and access controls;
* Configure mail server resource controls; and
* Test the security of the mail server applications.
? Consider the implementation of cryptographic technologies to protect user authentication and mail data.
Most standard mail protocols default to unencrypted user authentication and send email data unencrypted through the network. When unprotected data is sent, an attacker may be able to easily compromise a user account and to intercept or alter unencrypted email messages. Most organizations should consider encrypting the user authentication session even if they do not encrypt the email data itself. Encrypted user authentication is now supported by most standard and proprietary mailbox protocols.
Organizations should examine closely the decision about whether to encrypt and sign email data. Encrypting and signing email places a greater load on the user’s computer and the organization’s network infrastructure, and this practice may complicate malware scanning and email content filtering. Encrypting and signing messages may also result in significant administrative overhead and may increase the costs of managing email systems. However, for many organizations, the benefits of email encryption and signatures will outweigh the costs.
? Employ the network infrastructure to protect mail servers.
The network infrastructure includes the firewalls, routers, and the intrusion detection and prevention systems that support the mail server. These systems play a critical role in the security of the mail server. In most configurations, the network infrastructure will be the first line of defense between the Internet and a mail server. Network design alone, however, cannot protect a mail server. Because of the frequency, sophistication, and variety of mail server attacks that occur today, organizations should consider protecting their mail servers through layered and diverse protection mechanisms.
? Ensure that the mail clients are deployed, configured, and used properly to meet the security requirements of the organization.
The client side of the electronic mail process may represent a greater risk to the security of the mail system than the mail server functions. Organizations must address numerous issues in order to provide an appropriate level of security for email clients. The following steps will help organizations with the secure installation, configuration, and implementation of mail client applications:
* Patch and upgrade the mail client applications;
* Configure mail client security features, such as disabling automatic opening of messages and enabling antispam and anti-phishing features;
* Configure mailbox authentication and access; and
* Secure the client host’s operating system.
? Maintain the security of a mail server as an ongoing process.
Organizations should devote constant effort, resources, and vigilance to maintain a secure mail server. The mail server should be monitored and maintained on a daily basis to assure mail security. To maintain the security of a mail server, organizations should take the following actions:
* Configure, protect, and analyze log files;
* Back up data frequently;
* Protect against malware (e.g., viruses, worms, Trojan horses);
* Establish and implement procedures for recovering from compromise;
* Test and apply patches in a timely manner; and
* Test the security of the system periodically.

Functions of Intrusion Detection and Prevention Systems

Intrusion detection is the process of monitoring the events occurring in a computer system or network and analyzing them for signs of possible incidents, which are violations or imminent threats of violation of computer security policies, acceptable use policies, or standard security practices. Incidents have many causes, such as malware (e.g., worms, spyware), attackers gaining unauthorized access to systems from the Internet, and authorized users of systems who misuse their privileges or attempt to gain additional privileges for which they are not authorized.

Although many incidents are malicious in nature, many others are not; for example, a user could enter an incorrect address of a system and accidentally attempt to connect to a different system without authorization.

An intrusion detection system (IDS) is software that automates the intrusion detection process. An intrusion prevention system (IPS) is software that has all the capabilities of an intrusion detection system and can also attempt to stop possible incidents. Intrusion detection systems (IDS) and intrusion prevention systems (IPS) have many of the same capabilities, so for brevity this publication refers to them collectively as intrusion detection and prevention systems (IDPS).

Intrusion detection and prevention systems identify possible incidents, log information about them, attempt to stop them, and produce reports for security administrators. The systems also assist organizations in identifying problems with security policies, documenting threats, and deterring individuals from violating security policies.