Date: Mon, 11 Jan 2010 12:57:32 +0000 From: David Southwell <david@vizion2000.net> To: freebsd-questions@freebsd.org Subject: Re: syncache_timer: errors; What do they mean? Message-ID: <201001111257.32096.david@vizion2000.net> In-Reply-To: <4B4B1B1F.1010701@infracaninophile.co.uk> References: <201001111051.56331.david@vizion2000.net> <4B4B1B1F.1010701@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 >=20 > 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.] >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Cheers, >=20 > 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= =20 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=20 messages. I get some interesting messages sequences like this: Jan 11 12:40:09 dns1 kernel: TCP: [200.199.44.147]:22093 to=20 [xxx.xxx.xxx.xxx]:139 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1:= =20 Received 76 bytes of data after socket was closed, sending RST and removing= =20 tcpcb Jan 11 12:40:11 dns1 kernel: TCP: [200.199.44.147]:22093 to=20 [xxx.xxx.xxx.xxx]:139 tcpflags 0x10<ACK>; syncache_expand: Segment failed=20 SYNCOOKIE authentication, segment rejected (probably spoofed) Jan 11 12:40:11 dns1 kernel: TCP: [200.199.44.147]:22093 to=20 [xxx.xxx.xxx.xxx]:139 tcpflags 0x4<RST>; syncache_chkrst: Spurious RST with= out=20 matching syncache entry (possibly syncookie only), segment ignored Jan 11 12:40:14 dns1 kernel: TCP: [200.199.44.147]:22229 to=20 [xxx.xxx.xxx.xxx]:445 tcpflags 0x2<SYN>; tcp_input: Connection attempt to=20 closed port =46rom what are clear spoofing "initiatives" Thanks again David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201001111257.32096.david>