syncache_timer: errors; What do they mean?

[David Southwell]

> David Southwell wrote:
> > Here are some example entries in /var/log/messages (server ip address
> > removed and replaced by [xxx.xxx.xxx.xxx] :
> >
> > Can anyone please tell me what thses messages mean and what action (if
> > any) I should be taking.
> > Thanks in advance for any replies
> > Jan 11 10:41:57 dns1 kernel: TCP: [113.53.173.247]:63584 to
> > [xxx.xxx.xxx.xxx]:25; syncache_timer: Response timeout, retransmitting
> > (1) SYN|ACK
> > Jan 11 10:42:01 dns1 kernel: TCP: [113.53.173.247]:63429 to
> > [xxx.xxx.xxx.xxx]:25; syncache_timer: Response timeout, retransmitting
> > (2) SYN|ACK
> > Jan 11 10:42:03 dns1 kernel: TCP: [113.53.173.247]:63584 to
> > [xxx.xxx.xxx.xxx]:25; syncache_timer: Response timeout, retransmitting
> > (2) SYN|ACK
> > Jan 11 10:42:13 dns1 kernel: TCP: [113.53.173.247]:63429 to
> > [xxx.xxx.xxx.xxx]:25; syncache_timer: Response timeout, retransmitting
> > (3) SYN|ACK
> > Jan 11 10:42:16 dns1 kernel: TCP: [113.53.173.247]:63584 to
> > [xxx.xxx.xxx.xxx]:25; syncache_timer: Response timeout, retransmitting
> > (3) SYN|ACK
> 
> What is happening is this: host 113.53.173.247 (which appears to be
> somewhere in Thailand) is trying to connect to port 25 on your machine.
> [I guess it's probably trying to spam you.]
> 
> Now, the very first packet sent to establish a TCP connection is known
> as the 'SYN' packet -- that's because it has the Syn bit set in the
> options bitmap.  That comes from the remote system (as  it is trying to
> connect to you.) Your machine is receiving that OK.
> 
> The next step is for your machine to respond, sending a SYNACK packet
> back to the remote machine (Yes: you guessed it: this has both the Syn
> and the Ack bits set in the packet options).  Your machine is sending
> these packets off OK, but here is where it is all going horribly wrong.
> 
> Your machine never receives the 3rd packet back from the originating
> machine -- which is just an ACK packet -- to say it received the response.
> So it logs the message you've seen and tries again.  After a certain
> number of retries, it will give up on the attempted connection, clear
> out any allocated memory and go back to a quiescent state just listening
> for new incoming connections.
> 
> Unless all three of these packets make it to and fro, the TCP connection
> has not been properly set up.  This process is described as the "Three
> way handshake" -- unless that succeeds do data can flow across the
>  connection, so if this is an attempt to spam you, it's going to be
>  singularly ineffective.
> 
> Chances are, you've run into a badly configured firewall, or a broken
> spam-bot, which is causing packets to disappear from the wire. It /might/
> possibly be an attempt to DoS you by filling up various kernel memory
> structures allocated to managing TCP connection state, but judging by the
> time chops on the log extract you've shown, the other side would need to
> be sending orders of magnitude more traffic in order to beeffective.
> 
> Given this is too low intensity to have much effect on your machine, you
> can simply do nothing and ignore the log messages: it will clear itself up
> given enough time.  Otherwise, a firewall rule to drop traffic from the
> offending source will help reduce the noise level.
> 
> On the vanishingly remote chance that this really is a valid SMTP peer of
> yours, you'ld need to contact them out of band and try and work out where
> the traffic is being blocked and what to do about it.
> 
> 	Cheers,
> 
> 	Matthew
Thanks Mathew -- very well described..even I can understand it <chuckles>

I did not mention I am running freebsd 7.2 p3. I use sshguard and denyhosts 
and  blackhole. I have the:

sshd : PARANOID : deny

set in /etc/hosts.allow
and wonder if the above combination could somehow be connected with the 
messages.

I get some interesting messages sequences like this:

Jan 11 12:40:09 dns1 kernel: TCP: [200.199.44.147]:22093 to 
[xxx.xxx.xxx.xxx]:139 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1: 
Received 76 bytes of data after socket was closed, sending RST and removing 
tcpcb
Jan 11 12:40:11 dns1 kernel: TCP: [200.199.44.147]:22093 to 
[xxx.xxx.xxx.xxx]:139 tcpflags 0x10<ACK>; syncache_expand: Segment failed 
SYNCOOKIE authentication, segment rejected (probably spoofed)
Jan 11 12:40:11 dns1 kernel: TCP: [200.199.44.147]:22093 to 
[xxx.xxx.xxx.xxx]:139 tcpflags 0x4<RST>; syncache_chkrst: Spurious RST without 
matching syncache entry (possibly syncookie only), segment ignored
Jan 11 12:40:14 dns1 kernel: TCP: [200.199.44.147]:22229 to 
[xxx.xxx.xxx.xxx]:445 tcpflags 0x2<SYN>; tcp_input: Connection attempt to 
closed port

From what are clear spoofing "initiatives"

Thanks again

David