syncache_timer: errors; What do they mean?
David Southwell
david at vizion2000.net
Mon Jan 11 12:57:35 UTC 2010
> 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
More information about the freebsd-questions
mailing list