Conflicker detector?

[Carter Bullard]

Gentle people,
Anyone interested in doing a Conflicker detection program?

I don't have any argus records of a successful Conflicker session.
I only have Conflicker scan attempts.  No one I know seems to be
having Conflicker problems, so I haven't seen any good data yet.

If you are capturing user data in your argus data records, you
may find this interesting.

So, just looking for external to internal TCP -> port 445 will give you
some Conflicker scan activity if you have any, and the list of src IP  
addresses
involved in those types of scans can be used to seed searches in your  
argus
archives to see if any of those addresses have done anything
interesting with your network.

 From what I know, Conflicker, once it has done its thing, uses HTTP
over a peer-to-peer "callback" channel to check for things, and we can
test for that really easily.

With the list of IP addresses that used port 445, we can look for any  
flow
that has HTTP protocol key words on a session not using a traditional
HTTP port.

So, by hand you can do something like this, with the data from an
argus looking at your border interfaces:
    ../bin/racluster -L0 -m saddr -s saddr -R /Volumes/Data/argus/ 
prim*/207*/2009/03 - tcp and port 445

This will print out the IP addresses of port 445 scanners.  You can  
refine that with a filter to say give
you only addresses that are outside of your network.  For the month of  
March,
here is the output from QoSient world headquarters:
             41.209.130.202
             41.209.130.205
               58.222.22.41
              69.57.239.251
               74.11.29.171
              85.109.156.27
             85.189.237.214
                 86.8.99.27
             94.241.252.150
              123.169.76.30
             189.26.118.117
             207.40.251.189
            207.160.119.252
             207.164.177.50
             207.182.133.26
             207.188.73.161
            207.188.248.132
            207.199.245.133
             207.212.177.34
             207.212.177.36
              207.213.99.57
            207.218.175.231
            207.224.112.169
               207.225.1.47
            207.225.186.157
             207.237.36.130
             207.237.37.194
             207.237.37.198
             207.237.152.49
             207.237.152.98
            207.237.152.243
              207.248.38.10
             210.193.47.160
               216.12.74.84

So "../bin/racluster ...... port 445 > /tmp/ips.using.port.445"

OK, so put that in a file, and use it as config for rafilteraddr() to  
grab all the argus
records from/to  those addresses, and check to see if you see any HTTP  
like
protocol keywords on a non "port 80" tcp connection.

Remember, all ra* programs in argus-clients-3.0.x can 'grep' for  
patterns
in the user data buffers.  Just use the "-e 'regex'" option.

    rafilteraddr -f /tmp/ips.using.port.445 -R /path/to/your/archive/ 
2009/03 -e "GET | PUT" - port not  \(80 or 8008 or 8080\)

The "GET | PUT" is the regular expression "'GET' or 'PUT'" so be sure  
and use the (bar)
character.   OK, if you get any hits that look suspicious (like the  
contents are all encrypted, or
it just doesn't look right), then what would be cool is to capture all  
the argus records to and
from the local IP address over the time period where the Conflicker  
activity was seen
to see if you can figure out what is going on.

Or, you can just go through your entire archive looking for this:

    ra -R /path/to/your/archive/2009/03 -e "GET | PUT" - port not \(80  
or 8008 or 8080\)

But you'll get some false positives.

When I do that, I found a single HTTP session using port 10080, and  
that was it.

That TCP connection was interspersed with other port 80 HTTP  
connections to the
same server, and you could see that it was preceeded by a loading of a
"jquery_pack.jsr" file, so it was some java script grabbing off of a  
weird port.  The
commands were all "GET"'s and they were just images (a few gifs, pngs,  
jpgs),
so not interesting.

I validated that they were pretty boring by doing a radump() of the  
domain requests
over the same period, looking for the IP addresses in the output, so I  
could see
that I had actually done something that made sense.  Let's say that  
the IP address
was x.y.z.w, then I would type:

    radump -R /path/to/your/archive/2009/03/12/ -s +suser:128 +duser: 
129 - port domain | fgrep x.y.z.w

And got the DNS session that actually returned the IP address of  
interest.  So everything
was pretty boring on that 10080 port HTTP session.

Anyone have any interest in thinking about this kind of stuff?

Carter