Sender Policy Framework (SPF) details

* DNS Sender Policy Framework (SPF) aids in fighting spam. It lists the authorized mail servers for a DNS domain or host name. Receiving email servers can check SPF record to verify the authorization. In case of authorization failure, receiving email servers can reject the incoming email. An example SPF record is of the format, 'v=spf1 ip4:10.0.0.0/8 -all'.

* SPF is DNS TXT record. It consists of the following mechanisms (zero or more),
all, a, mx, ptr, ip4, ip6, include and exists
Mechanisms describe the designated outbound mailers for a domain. It can also describe domain email policy such as GPG-signed or hasbeas headers for all emails. SPF record can also have redirect and exp modifiers. Mechanisms can be prefixed with one of four qualifiers, - (fail), ~ (softfail), + (pass) and ? (neutral). Default prefix value for any mechanism is +. If no mechanisms or modifier matches, default prefix is ?. Mechanisms are evaluated in order.

* Following are the results of mechanism evaluation,

Result Intended action
none (no spf record) Accept
neutral (?) Accept
pass (+) Accept
fail (-) Reject
softfail (~) Accept but mark
TempError (temp DNS err)Accept or Reject
PermError (invalid syntax)Unspecified

* 'all' mechanism matches any sender IP/hostname and it is placed at the end of SPF record. For 'a' mechanism, all A records for a domain are tested, mechanism matches if sender IP is found among them. 'mx' mechanism means that all A records for all MX records are tested in order of priority. Sender IP should be one of them. 'ptr' mechanism means that hostname of sender IP will be looked up using PTR queries. Hostnames are validated, at least one of the A record for a PTR hostname much match the sender IP. It is best to avoid ptr mechanism because of larger no of expensive DNS lookups. ip4 mechanism defines a designated host in CIDR notation, e.g ip4:192.168.0.1/16. ip6 mechanism defines a designated IPv6 IP. 'exists' mechanism does a simple A query for the domain, which should give a result, any result to match. 'include' mechanism means that specified other domain is searched for spf record for a match. This mechanism cross administrative boundaries. It is better to give a neutral response than a pass response.

* redirect modifier is used to replace current set of SPF directives by what is mentioned in the modifier. exp modifiers enforce a TXT lookup for a domain that is shown to the sender.

Solaris Role based Access Control (RBAC)

* root is an all-powerful unix account. RBAC provides an alternative to all-or-nothing superuser model. It uses the concept of roles, assigned to individuals. Three recommended roles are primary administrator, system administrator and operator.

* RBAC consists of privileged applications, role, authorization and rights profile. Users are assigned to roles, which get their capabilities from rights profiles and authorizations. Rights profiles are system overrides. Authorizations are generally assigned to right profiles but can be assigned directly to roles. They are discrete rights. Commands can be assigned to rights profiles. Roles have password assigned to them and are special type of user accounts. They have a home directory, groups, password etc. Roles information is stored in password, shadow, user_attr and audit_user databases. Normal users can assume role from 'su' command. RBAC provides commands that check for authorizations. Users can obtain privileges from a profile shell. Profile shell enables profile related privileged applications.

* Preferred way to manage RBAC is via Solaris Management Console.

* First role is created using root account. Subsequent roles can be created using the first role instead of 'root' account. Restart name service cache daemon for the new role to take affect. roleadd can be used to create a local role and its attributes. Roles can also be created by directly editing /etc/user_attr file. For roles in a name service (LDAP, NIS, NIS+), use smrole command. smrole runs as a client of Solaris management console server. rolemod command is used for modifying role attributes. smprofile command is for managing rights profile. smuser command is used for modifying authorizations, roles and rights profiles assigned to a user. auths command is used to print authorizations for any user.

* /etc/user_attr is extended user attributes database.

All about Network Information Service (NIS)

-- NIS server stores information in databases called maps. NIS namespace is flat. One organization domain maps to one NIS map. Each domain must have only one master server. NIS domain is a collection of machines that share a common set of NIS maps. There can however be different master servers for different maps. NIS domain is case-sensitive.

-- NIS provides a forwarding service to forward host lookups to DNS, if information is not present in NIS map. NIS+ is a different software that supports features such as hierarchical namespace and namespace security that NIS doesn't support. NIS+ server can run in NIS compatibility mode servicing the requests of NIS clients.

-- Principal NIS servers are called masters, whereas backups are called slave.

-- NIS service is provided by five daemons, ypserv, ypbind, ypxfrd, rpc.yppasswdd and rpc.ypupdated. makedbm, ypcat, ypinit, yppmatch, yppoll, yppush, ypset, ypwhich and ypxfr are nine utilities. Ypbind must run on all servers and clients. Ypinit creates maps from text files. ypcat, ypwhich and ypmatch commands get information from maps. ypwhich shows master server for a map. yppush only works for maps that are already defined on slaves. Otherwise use ypxfr on the slave to get the maps. ypxfr can be scheduled in cron. ypxfr activities are logged into /var/yp/ypxfr.log file.

-- NIS maps are two-column tables. One column is the key and the other is value related to the column. Maps are located in /var/yp/domainname directory. Maps can be queried by their name or their nicknames. Nicknames are stored in a text file, /var/yp/nicknames, which is user-editable. Maps are created from input text files. They should not be the files in /etc directory. /usr/ccs/bin/make passwd command is used to update maps. It also propagates changes to other servers. Each map has an entry for its master server, that needs to be modified in case of change in master. Supported maps are modified in /var/yp/Makefile directory. makedbm is used for updating non-default maps, one which are not defined in Makefile. Map are made of two well-formed dbm files. hosts.byname and hosts.byaddr maps can be modified to forward queries to DNS server, in case they are not found in NIS maps.

-- NIS request can be made in two modes, server-list mode, where ypbind daemon on client refers to the file /var/yp/binding/[domainname]/ypservers file to locate servers and broadcast mode, where ypbind issues an RPC broadcast to server an NIS server. RPC broadcast doesn't cross subnets, therefore there must be at least one server in each subnet. Once a client binds to a server, it remains so until server goes out of service. /var/yp/securenets file provides IP based access control for client requests.

-- NIS netgroups are users and machines defined for administrative purposes. They are placed in maps in place of users or machines. netgroups can be defined in /etc/netgroup file and uploaded to netgroup map.