heartbleed patterns ?

[Jesse Bowling]

Hi Mike,

You would need to have this section in your argus.conf/command line in
order to be generating application byte metrics (which pcr is based on):

# Argus can be configured to generate metrics that include
# the application byte counts as well as the packet count
# and byte counters.
#
# Commandline equivalent   -A
#

ARGUS_GENERATE_APPBYTE_METRIC=yes

Cheers,

Jesse


On Thu, Apr 10, 2014 at 4:46 PM, mike tancsa <mike at sentex.ca> wrote:

> Hi Jesse,
>         I didnt know of this filter in Argus, nor this metric to analyze.
> Are there any good references you can point me to on this topic ?
>
> I guess this is only available in the dev version of the clients ? If the
> data I have is saved from an older version of argus/radium, am I able to
> safely use the newer clients on older archives and get valid info ?
>
>         ---Mike
>
>
> On 4/9/2014 6:24 PM, Jesse Bowling wrote:
>
>> A friend of mine observed a pcr of -.99 in cases of known heartbleed
>> attacks; hence my earlier question regarding filters. :)
>>
>> I'm also interested in seeing how this plays out!
>>
>> Cheers,
>>
>> Jesse
>>
>>  On Apr 9, 2014, at 5:57 PM, Carter Bullard <carter at qosient.com> wrote:
>>>
>>> Hey Mike,
>>> I was going to do something about that today, since its a hot topic.
>>>
>>> I’m thinking that there are a number of strategies for mining server
>>> memory using TLS heartbeat attacks, and using argus to discover them
>>> should be pretty successful.  I haven’t found any incidents of this in
>>> any of my data, so these strategies need to be tested to be real.
>>>
>>> The big give away is that the TLS heartbeats are unencrypted (?), so
>>> if you are collecting user data, you will see strings in your TLS
>>> buffers.  If the attackers are aggressive, you should see long lived
>>> TLS connections, that started with the HELLO exchange to negotiate the
>>> heartbeat extension, but not proceeding with any other part of the TLS
>>> handshake.  This is valid TLS protocol and attackers will be pretty
>>> efficient, so as not to identify themselves for the system logs.
>>> The memory miner, I suspect, would connect, and then just sit there
>>> asking for large heartbeat responses, to farm as many server memory
>>> buffers as they are willing to grab.  All of which which should be
>>> unencrypted on the wire.
>>>
>>> This scenario would be the most zero false positive zero false
>>> negative case to detect, that I can think of.  Unambiguous intent,
>>> not even trying to negotiate a full TLS, and getting the goods.
>>>
>>> The heartbeat request can be pretty small, 20 bytes ?? And the response
>>> would be very large, so the PCR for a buffer miner, connecting
>>> to a vulnerable server, would be approaching -1.0. (I’ll have to fix
>>> the filter to find some of these).
>>>
>>> So, long lived connections, low source load values, after the
>>> TLS handshake, and large dst byte counts for the memory dumps,
>>> all in the clear.
>>>
>>> If that jives with your understanding, we can come up with a
>>> decent set of filters to find those types of connections.
>>>
>>> There are others that are not so obvious.  Lets continue this.
>>> Gotta run, but will be back later tonight.
>>>
>>> Carter
>>>
>>>  On Apr 9, 2014, at 5:02 PM, mike tancsa <mike at sentex.ca> wrote:
>>>>
>>>> Has anyone come up with or seen any flow patterns indicative of someone
>>>> trying to exploit the OpenSSL heartbleed vulnerability ? I would like to go
>>>> through my old logs to see if anyone was poking about prior to the general
>>>> announcement.
>>>>
>>>>     ---Mike
>>>>
>>>
>>>
>>
>>
>


-- 
Jesse Bowling
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20140410/7a91135f/attachment.html>