The following lines were added (+) and removed (-):
* postfix - The mail transfer agent (MTA), the boss.* postfix - The mail transfer agent (MTA).The offending attacker connects to dovecot and issues several attempts to send messages as a number of different users. Dovecot only logs the initial connection, that process ID is tagged along with the IP address of the attacker. Then PAM gets the requests for all of the different login names being thrown at it. PAM has to work with SASL to check if the logins are valid. Each time a process ID is generated that tags both PAM and SASL with the same ID, however, the IP address is not captured here. It is not PAM's job to communicate with the system to capture IP addressing, as this would create unnecessary overhead for PAM and negatively impact an otherwise quick process. The problem is, other than a relative timestamp, the PID, or tagged id to the log entry only match the PAM to SASL communication, and cannot be matched up against Dovecot. This is fine for a small mail server with few users. However, when other user authentication requests are coming though on the same timestamp, it can be difficult to match up the log entries generated by pam in the messages and secure log against the offending postfix log entry in maillog, the only place the actual attacker IP address can be gleaned.[[Postfix mailer and Dovecot]] handles email accepting and delivery for messages to local users and from local users to remote destinations. The attacker connects to dovecot and issues several attempts to send messages as a number of different users. The attacker doesn't know actual system usernames, so the attacker uses a dictionary list of common names and hopes to try name after name until there's a match. What can happen is there are so many saslauthd processes open that legitimate users are unable to login and authenticate.Dovecot only logs the initial connection, that process ID is tagged along with the IP address of the attacker; that is logged in log/'''maillog''' . PAM then gets the requests for all of the different login names being thrown at it. PAM has to work with SASL to check if the login names are valid. Each time a process ID is generated that tags both PAM and SASL with the same ID. Log entries are generated in two places, log/'''messages''' and log/'''secure''' . The problem with the entries in the '''messages''' and '''secure''' log is that no IP address is captured. It is not PAM's job to communicate with the system to capture IP addressing, as this would create excess overhead for PAM. Matching these entries with the '''maillog''' is difficult. Other than a relative timestamp, the PID, or tagged id to the log entry only match the PAM to SASL communication, and cannot be matched up against Dovecot. This is fine for a small mail server with few users. However, when other user authentication requests are coming though on the same timestamp, it can be difficult to match up the log entries generated by pam in the '''messages''' and '''secure''' log against the offending postfix log entry in '''maillog''', the only place the actual attacker IP address can be gleaned. What can happen is there are so many saslauthd processes open that legitimate users are unable to login and authenticate. In data center (A) a mail server was so overloaded with saslauthd processes, the system admin couldn't even connect directly to the system to perform an emergency shutdown of dovecot.