-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is a new follow up to an old post from Jon (2003-02):
- -------------- cut here ----------------
As previously mentioned, I've been using the following rule to track any
machines that spew packets containg 'cko', which is associated with the
Q backdoor:
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"Possible Q-Backdoor
traffic"; content:"cko"; depth:3; dsize:3;)
I've compiled some information about this traffic in the hopes that it
helps someone. Since my first email (beginning of Februrary), I've
caught 2042 packets coming into my network that tripped this signature.
Common characteristics for all of these packets include:
* all tcp
* low ttl
* ACK and PSH flags set
* sequence # set
* payload is "cko"
...
Traffic leading up to the final 'cko' packets always seems very routine
- -- your average web browse, mail traffic, etc. All source hosts that
were not the server in the connection seem to be random dialup/dsl
machines from around the globe.
Any feedback or information about these (or other similar) "attacks"
would be much appreciated, either publicly on this list or privately via
email.
- -------------- cut here ----------------
I saw the same sort of traffic today, but that traffic is not the result
of a backdoor. There was never a resolution to Jon's post though, so I
thought I'd take a stab at clearing up the mystery.
The pattern is:
1) Normal traffic from a public IP;
2) Connection closed normally (FIN,ACK;ACK)
3) A second or two later, mystery packet with low TTL, ACK/RST, Reset
cause: cko
4) We send an "ACK"
5) RST,ACK from remote with Reset cause: ehnc
This isn't exactly like Jon's traffic was. His had ACK/PSH instead of
ACK/RST. He also didn't mention the "ehnc", but if his system wasn't
generating the "ACK" that mine is you wouldn't see that packet. So this
might not be the same thing he was seeing, but it seems pretty close.
Especially seeing the normal traffic first, followed by the weird
packets with low TTL and "cko" payloads.
My traffic was generated by one of my customers using a SonicWall
firewall. For some reason, after the connection was closed down by our
web server and ack'd by the remote, the firewall itself generated its
own packet to try to shutdown the connection. This packet has the "cko"
payload. Here is the SonicOS description of its reset packets:
http://www.sonicwall.com/services/pdfs/technotes/SonicOS_TCP_RST.pdf
I'm not entirely clear why the firewall felt it needed to close the
connection itself since it had already been properly closed. It doesn't
do that for every connection. We sent e-mail to that customer twice and
neither of those connections was followed by the the firewall "cko"
traffic. However, two HTTP connections made by the customer to us were
both followed by the "cko" packet. I also don't know why the TTL is so
low on the "cko" packets.
- --
Kirby Angell
Get notified anytime your website goes down!
http://www.alertra.com
key: 9004F4C0
fingerprint: DD7E E88D 7F50 2A1E 229D 836A DB5B A751 9004 F4C0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBeTWM21unUZAE9MARAj/hAKCIpL9OX/e1mLQz9wcVocDezBdFkQCcDssy
jOshr37T7Z/h+sWCCl8yV0w=
=oeMX
-----END PGP SIGNATURE-----
-------------------------------------------------------
This Newsletter Sponsored by: Macrovision
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate
today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
