The logs on my mail server are filling up with this kind of thing:
Oct 19 17:03:51 bnofmail kernel: REJECT: IN=eth0 OUT= MAC=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX SRC=195.140.240.6 DST=XX.XX.XX.XX LEN=189 TOS=0x00 PREC=0x00 TTL=52 ID=6284 DF PROTO=TCP SPT=25 DPT=32776 WINDOW=65535 RES=0x00 ACK PSH URGP=0
The source port is always 25 and the destination is a high-numbered port. The destination address is the private IP of the server. These seem to be related to outgoing email connections based on the source IPs, but I don't know why they are not part of an established connection. The mail server seems to be running just fine regardless of these blocked connections.
Any ideas?
Bowie Bailey wrote on Mon, 19 Oct 2009 17:18:16 -0400:
The destination address is the private IP of the server. These seem to be related to outgoing email connections based on the source IPs
Is 195.140.240.6 the public IP of that machine? Why do you obfuscate a private IP number? Do you want to say that these are internal mail server connections? If not, the explanation about the IP numbers doesn't make sense to me.
Kai
Kai Schaetzl wrote:
Bowie Bailey wrote on Mon, 19 Oct 2009 17:18:16 -0400:
The destination address is the private IP of the server. These seem to be related to outgoing email connections based on the source IPs
Is 195.140.240.6 the public IP of that machine? Why do you obfuscate a private IP number? Do you want to say that these are internal mail server connections? If not, the explanation about the IP numbers doesn't make sense to me.
No, 195.140... is the IP of the remote machine. I obfuscated the private IP of the mail server (and MAC address) on general principles since they are not relevant to the question.
What I am seeing is a remote server trying to make a connection from port 25 to a high-numbered port on my mail server. Iptables rejects the connection since it is not on an allowed port or part of an established conversation. The question is: why are all of these remote servers trying to make connections back to me on high-numbered ports? Should I be allowing these connections somehow?
For clarity's sake, here are a few non-obfuscated examples:
Oct 20 11:42:27 bnofmail kernel: REJECT: IN=eth0 OUT= MAC=00:50:8d:59:60:2e:00:90:27:c2:79:77:08:00 SRC=209.27.55.194 DST=172.16.17.169 LEN=107 TOS=0x00 PREC=0x00 TTL=52 ID=56970 DF PROTO=TCP SPT=25 DPT=40312 WINDOW=62928 RES=0x00 ACK PSH FIN URGP=0 Oct 20 11:42:49 bnofmail kernel: REJECT: IN=eth0 OUT= MAC=00:50:8d:59:60:2e:00:90:27:c2:79:77:08:00 SRC=203.17.219.68 DST=172.16.17.169 LEN=52 TOS=0x00 PREC=0x00 TTL=117 ID=19851 DF PROTO=TCP SPT=25 DPT=40289 WINDOW=64167 RES=0x00 ACK FIN URGP=0 Oct 20 11:43:01 bnofmail kernel: REJECT: IN=eth0 OUT= MAC=00:50:8d:59:60:2e:00:90:27:c2:79:77:08:00 SRC=204.127.217.16 DST=172.16.17.169 LEN=72 TOS=0x00 PREC=0x20 TTL=50 ID=15125 DF PROTO=TCP SPT=25 DPT=40346 WINDOW=64296 RES=0x00 ACK URGP=0
172.16.17.169 is the private IP of one of my mailservers. The other IPs are remote servers not under my control. About 20% of them are servers that have received outbound email from my server recently. I have no idea where the others come from.
I have gotten over 83,000 of these connection attempts so far today from 267 unique IP addresses.
conversation. The question is: why are all of these remote servers trying to make connections back to me on high-numbered ports? Should I be allowing these connections somehow?
The remote server probably thinks that it's still supposed to be making connections back to you -- a couple of the lines you posted showed FIN flags indicating that the TCP connection was being shut down. At that point, the mail message has already been sent.
If you get REJECT messages for all SMTP connections, look at your iptables rules and see if you have a specific rule for smtp that only permits NEW conns.
One possibility is that iptables no longer thinks that the connection is active -- possibly the connection tracking database has already pushed that connection out. You can check your conntrack max value with the command
cat /proc/sys/net/ipv4/ip_conntrack_max
Yet another possibility is that these are duplicated packets (for whatever reason) and the connection has already been closed out.
M
Meenoo Shivdasani wrote:
conversation. The question is: why are all of these remote servers trying to make connections back to me on high-numbered ports? Should I be allowing these connections somehow?
The remote server probably thinks that it's still supposed to be making connections back to you -- a couple of the lines you posted showed FIN flags indicating that the TCP connection was being shut down. At that point, the mail message has already been sent.
If you get REJECT messages for all SMTP connections, look at your iptables rules and see if you have a specific rule for smtp that only permits NEW conns.
But these aren't SMTP connections. The source is port 25, but the destination is not. The mail server is running normally. I'm allowing new SMTP connections and traffic for established connections.
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:25
One possibility is that iptables no longer thinks that the connection is active -- possibly the connection tracking database has already pushed that connection out. You can check your conntrack max value with the command
cat /proc/sys/net/ipv4/ip_conntrack_max
# cat /proc/sys/net/ipv4/ip_conntrack_max 63480
Yet another possibility is that these are duplicated packets (for whatever reason) and the connection has already been closed out.
Possible, I guess, but I don't know what would be duplicating them.
But these aren't SMTP connections. The source is port 25, but the destination is not. The mail server is running normally. I'm allowing new SMTP connections and traffic for established connections.
They are SMTP connections -- your server initiates a connection to port 25 on the remote server. Thus, when the connection is set up the remote server will be responding with source port 25 and destination port = source port of the initiated connection.
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:25
I think the ACCEPT all line should catch these, but you might try adding RELATED,ESTABLISHED specifically to the dpt:25 line.
# cat /proc/sys/net/ipv4/ip_conntrack_max 63480
Unless you're passing a lot of traffic, the conntrack_max looks okay.
Yet another possibility is that these are duplicated packets (for whatever reason) and the connection has already been closed out.
Possible, I guess, but I don't know what would be duplicating them.
This isn't as likely, but the remote sites could be duplicating them -- the only way to determine if that's the case would be to sniff the traffic and see if the remote site sends the same packet more than one.
M
Meenoo Shivdasani wrote:
But these aren't SMTP connections. The source is port 25, but the destination is not. The mail server is running normally. I'm allowing new SMTP connections and traffic for established connections.
They are SMTP connections -- your server initiates a connection to port 25 on the remote server. Thus, when the connection is set up the remote server will be responding with source port 25 and destination port = source port of the initiated connection.
I understand that. What I meant was that iptables will not see them as SMTP connections since the destination is not port 25.
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:25
I think the ACCEPT all line should catch these, but you might try adding RELATED,ESTABLISHED specifically to the dpt:25 line.
Which will not match these connections since the dest port is not 25. I could put a RELATED, ESTABLISHED line in for source port 25, but as you said, the "ACCEPT all" line should catch them anyway.
On Monday 19 October 2009 17:18, Bowie Bailey wrote:
The logs on my mail server are filling up with this kind of thing:
Oct 19 17:03:51 bnofmail kernel: REJECT: IN=eth0 OUT= MAC=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX SRC=195.140.240.6 DST=XX.XX.XX.XX LEN=189 TOS=0x00 PREC=0x00 TTL=52 ID=6284 DF PROTO=TCP SPT=25 DPT=32776 WINDOW=65535 RES=0x00 ACK PSH URGP=0
The source port is always 25 and the destination is a high-numbered port. The destination address is the private IP of the server. These seem to be related to outgoing email connections based on the source IPs, but I don't know why they are not part of an established connection. The mail server seems to be running just fine regardless of these blocked connections.
Any ideas?
Are you running a mixed firewall rule set? Stateful and Connection or just one or the other? Since you state a private address, I'm going to assume you mean something in the 192.168 or similar space, is NATting an issue?
-
Bowie Bailey -
Kai Schaetzl -
Meenoo Shivdasani -
Robert Spangler