Its that time of year again..As you make your turkey and make plans with the family, We have done our part.  We have exposed the frauds and the leaches. Only one group of all we have asked has actually answered the questions.  So we leave it up to you to decide. By all the hate mail that we receive it seems the other groups are upset, not sure why? all we did was ask them to answer some questions.

We have thought long and hard on this one  and decided to tell you who we favor and support as the leading group of today.

KEYSTONE UNITED
Very simply put, They are a positive organization doing what they can for the interest of our people. They are on the streets making it happen.
The are not afraid to answer questions by friend or foe.
The other “groups” should take a cue from keystone.

From their site.

Is K.S.S. Pro American?
Yes, very much so.

What does the K.S.S. wish to accomplish?
We have set up goals in which we wish to break the stereotypes of skinheads being alcoholic thugs and violent drug addicted criminals. We wish to create a safe environment in which to raise our families in. We hope to help change the downward spiral today’s youth and much of America is faced with.

So you guys have families?
Yes, we have families. Just like anyone else we work hard to support our loved ones and only wish to provide the best for them. This includes a safe place for them to live. Children are very important to us. We encourage all our members to have stable home lives and provide for their family.

What does K.S.S. see as the problems facing the country?
In today’s current state America, and many other once great European nations, are former shadows of themselves. Crime, drug abuse, greed, careless attitudes and general disregard towards family values, have overtaken society. In reality there are too many to list but these are some of the ones we try and focus on.

What does K.S.S. do to correct these problems?
We try to lead by example, by being active in our communities, public awareness, contacting local politicians, or just simply showing people we are not ashamed of who we are. The media has made us out to be villains, a stereotype we must fight everyday.

What kind of events do you hold?
We have picnics, hikes, paintball, self defense training, parties, rallies and concerts. Most all of our events have had great response.

Can only members attend you functions?
No, our public functions are always welcome to anyone wishing to attend. We announce our public events so that you may attend.

Do I have to be a member to hang out?
No, you don’t. How else would we expect you to get to know us?

How do I join?
Only after some time of getting to know you, you will be asked by a member if you would like to become a member. If you agree you will then be asked to be a probationary member. The period is a time in which we get to know you, and allow you to get to know us.

Do I have to live in Pennsylvania?
Yes. All of our members are residents of this state. The club was founded on the idea that members within a certain boundary are more able to have regular contact then those on a national scale.

How long is the probation and why do I have to do that?
The probation is no less than six months. We feel everyone must probate to ensure that you wish to have the club be a part of your life. We want our members to have us into their lives.

What do I have to do while I am on probation?
Probation is not hazing. We respect you and wish for you to become a member. We may ask you to help out when needed, but by no means are you someone’s personal errand boy.

How old do I have to be to join?
You must be eighteen years of age to become a probationary member. However you are welcome to hang out and attend our functions if you are underage. If you are not eighteen yet, does not mean you can not be our friend or supporter.

Is it true women cannot join?
Yes, unfortunately women are not permitted to join. This rule was made under much consideration and we feel this solution prevents any member from having to choose a spouse versus the club, if the situation would ever arise. However, we love and cherish our partners of the opposite sex. They give us a lot of support and stand beside us in our actions. We encourage them to be politically active as well.

What you have just read is written by an organization that knows what they want and has direction is focused and driven. All others seem to pale in comparison. It is easy to state what you are about when you are passionate about it.

Unlike ScreenOS, adding EX-Switch running JUNOS procedure is different.

Following steps I took to successfully add the switches:

Before you can add a JUNOS device to NSM, the device must be installed and configured, and logon credentials for an NSM administrator must be configured for it. Perform the following steps:

1. Connect the device to the network and configure one of the interfaces so that the device can reach the NSM device server.
2. Add a user for NSM that has full administrative rights.

For complete details on installing and configuring JUNOS devices, see the
documentation for the specific device,

Add the Device in NSM
To add the device in the NSM UI, follow these steps:
1. From the domain menu, select the domain in which you want to import the device.
2. In Device Manager, select Devices.
3. Click the Add icon and select Device to open the Add Device wizard.
4. Select Device Is Not Reachable, and then click Next.
5. On the Specify Name, Color, OS Name, Version, and Platform screen:
¦ Enter a name and select a color to represent the device in the UI.
¦ From the OS Name list, select JUNOS.

The JUNOS OS Type list appears.
¦ Select the JUNOS OS type for the device you want to add:
¦ To add a J-series or SRX-series device, select J-series from the list.
¦ To add an EX-series device or virtual chassis, select EX-series.
¦ To add an M-series or MX-series device, select M/MX-series.
¦ From the Platform list, select the device platform name.
¦ Check the Virtual Chassis box if you are adding an EX-series virtual chassis made up of several EX-series switches (EX-4200 series only).
¦ From the Managed OS Version list, select the version of the operating system that runs on the device.

set system services outbound-ssh client nsm device-id F79821 (auto-generated)
set system services outbound-ssh client nsm secret
set system services outbound-ssh client nsm 10x.xxx.xxx.xxx port 7804
set system services outbound-ssh client nsm services netconf
commit

The device will immediately attempt to connect to NSM.

Como anterior mente les posteamos un video donde la gente de Mexclas y Rockafellas preparaban una secuela del Terremoto dj’s donde estuvieron Camilo Lara (I.M.S) Toy Selectah y Mexclass.

Ahora aquí les dejamos esta segunda parte de la fiesta en la cual vienen con todo para celebrar el casi centenario de nuestra Revolución Mexicana, donde harán toda una revolución en conjunto con Pepe Mogt – Fussible Nortec Collective (Dj Set) Pato Watson – NSM (Dj Set) y Mex Class.

Pronto estaremos regalando cortesías para este show.

Past : How did it started

NSM expands to NordSecMob, which is an Erasmus Mundus masters course coordinated by TKK. NSM programme is one of high quality masters course which attracts quite many international students every year. I also happen to be a recent graduate of NSM.

The idea to make this service germinated probably in heads of NSM planning officer/ NSM coordinating professor. The vision was to make a service, which acts as a knowledge sharing platform for incoming international students in NSM program. Also, OtaSizzle platform presented an amazing opportunity.

Three students from the current NSM final year took this challenge as their summer job. They were guided by Jani Heikkinen, Olli Mäkinen and myself. Our focus with the developers was to  come up with a service, which serves a need and can be finished within the set time constraints.

We spent quite a bit of time focusing on listing the problems faced by the NSM students. One of the commonly identified problem was lack of information for new moving students to a foreign country(Scandinavia: NSM runs in Finland, Sweden, Norway, Denmark and Estonia) . No doubt about the scandinavian hospitality but still students have challenges with information about everyday things like : shopping stores, course information etc.

Once we were able to identify the problem we want to address, we started to see the solution in form of a service, which acts as one stop shop for information needed by an international student coming to study in NSM program. We had a consensus to build a framework to categorize the information and tap into collective intelligence of NSM students. The developers did a great job in making service which is not only working but also has good amount of seed content.

Also, I would like to mention here some of the lessons we learnt from the development process.

1. OtaSizzle platform works : (Kassi as an example service, which rocks!)

I have no doubt in saying this that with strict limits of time constraints and learning curve for developers (to learn ruby on rails), it would have been nearly impossible to develop such a feature rich service without a reference service like Kassi (and OtaSizzle platform). So, credit not only goes to developers and initiators but to Kassi and OtaSizzle platform.

2. Sharing to the outer world/lowering barriers for using the service

When we have to compete for attention from existing service platforms like Facebook etc, which is not that easy. We realized that using small javascript snippets from existing platforms makes life easy, like Facebook Share. We hope that this approach will be copied in future OtaSizzle services too.

Also, at the same time how a user can start using the service with least effort is critical. The first step towards that is using Single Sign On or similar authentication technologies.

However, all this is just a beginning, we still have lot to learn (how to bring the content in from other platforms and how to take it out) for making our service co-exist (not compete) in this fight where everybody is seeking attention of users.

Present: a continous struggle

One of the main challenge with NSM service is low user base which is due to the handful number of students we have in the NSM program. There are 10-20 students at any time in TKK studying in NSM masters(first and second year students combined). This challenge can be also seen as an opportunity that we can have a really cohesive group because the number is small.

I see two main challenges in making such a service successful.

1. We solved the technology problem but not the culture problem!

To have a vibrant community ( any posting forum) to have sufficient online activity, we must have offline activity as well. The NSM course staff is quite generous and provides opportunity for students to have some offline activity. But, still most of us who come from different cultures to a foreign country and to make a cohesive group we need to have more of offline activities together to help each other with collective intelligence of the group.

2. What is user’s incentive to post (everyone might want to read)?

Majority of the collective intelligence have to come from people who have passed out of NSM program. The current students are seekers of information. We are still in process of figuring out the incentives.

Future: Where do we go from here….

It all started to address the small group of NSM students but it was very soon clear to us that TKK runs many international masters and others might find similar problems. ( there are infact few hundred students coming to TKK every year)

So, in the true Aalto spirit , the NSM service can mature and grow as something which can be used by a wider group of international students and help them bring closer. However, in the process we might have to change quite a few features in the service.

Last, but not least, I request the readers of this post to share to us if they have any ideas to make the community active . Also, thanks a lot for reading the post

please check out the service if you have not yet and let us know your valuable feedback.

The inner title page of MI5’s authorised history shows one of the Service’s past logos, bearing the motto: “Securitas Vigilantiae
Instantis Praemium”, intended to mean “Security is the reward of unceasing vigilance”. This seems to me to be as good a motto now as it was seventy years ago.

An enterprise has numerous tools at its disposal to control what happens on its infrastructure. Some examples are technical controls (such as port filtering, or blocking access to certain types of website) and non-technical controls (such as Acceptable Use Policies, violation of which could lead to disciplinary action).

Controls like these describe what you hope should be happening on your network, which isn’t necessarily what is happening. Controls may have been:

• Intended, but not actually implemented at all
• Improperly implemented
• Removed
• Changed
• Circumvented (intentionally or otherwise)
• Or they may not be as effective as you’d have hoped (anti-virus is a good example).

Implementing a control and then leaving it to its own devices doesn’t seem like a viable tactic. Rather than believing it to be effective, we need to make sure it is effective through strategies like the collection of information and the (unceasing) vigilance to detail required to extract the greatest meaning from it.

By doing this, you can verify the effectiveness of your controls. When things go wrong, you can use what you’ve collected to help you understand what happened and how you can modify your controls to help prevent it from happening again.

Without vigilance, we have our head in the sand, hoping for the best. If our vigilance is not unceasing, Murphy’s Law dictates that something Bad will happen the moment we take our eye off the ball.

“Securitas Vigilantiae Instantis Praemium” hardly ranks as catchy, but it certainly hits the nail on the head. Well, one of the nails, anyway.

Never was a cause-oriented project this exciting!

Just a few weeks ago, our Orcom152 teacher gave us our tasks and assignments for our final project; it was either an employee-concerned issue of a very popular food chain or a fund-raising/ volunteer-related issue of a specific government hospital.   We were fortunate enough to land on the latter.  The main objective of this class requirement was actually to produce a communication plan, which detailed the traditional and/or new social media (NSM) tools that we deem were important in achieving our objectives.

In approaching this issue, we started out by asking ourselves questions revolving the following aspects: brand differentiation, tradition and/or new social media mix, goals and objectives, measures and activities that we deem will be essential in reaching our team’s goal of providing our client the optimum benefits with the least number of costs and drawbacks.

Due to the nature of the hospital, we rationalized the use of a combination of the traditional and the new social media tools, such as brochures, posters, invitation letters, PSAs, and the website.

There were two main highlights of the project, and coincidentally, these two highlights also seem to be the most crucial stages of the project construction:

1. identifying (and segmenting) our specific target, and

2. deciding which from the wide array of traditional and NSM tools will serve the most benefits (in terms of cash donations and volunteer turn-out).

Although the original concern of the organization was on fund-raising events, our team took a broader perspective, and saw that a more pressing problem of the foundation was there very low volunteer turn-out.  Hence, the birth of our campaign, the Passion. Action. This very cool, unique project seeks to address the previously mentioned dilemma of the foundation by heightening awareness (especially among the youth), driving attention to the foundation and their events, and encouraging more volunteers to share their time, effort and/or money to this very humble act of harmony, charity and generosity.

We actually just recently defended our project in front of our professors and the guest panelist, and it was a bit nerve-wrecking.  Nonetheless, I was fortunate enough to work with very fun-loving yet hardworking individuals. And so to my co-team mates, the Pixie Chicks, kudos to all of us! We did great! (“,)

Well unfortunately the most well known white rights group today in this multiracial cesspool called America is, you guessed it, the ‘NSM’. Well if I had the time to post all the ridiculous photos of these clowns in their uniforms saluting I would.

I actually feel sorry for the poor bastards that get suckered into this nonsense with good intentions, but never the less you still look ridiculous.

Unfortunately currently there are no ‘real’ groups for white independence out  there so save your time and money. Not to mention sending your personal info to some complete stranger in a Nazi uniform will only get you put on the FBI list as soon as the informant opens their mail. Don’t believe me?

Well meet former Indiana leader for the NSM convicted rapist John Snyder:

This douchbag became a leader in the NSM ‘AFTER’ his conviction.

Failing Marriage Takes Ugly Turn

John Snyder’s marriage was rocky from the start. His wife was the primary breadwinner in the relationship, forced to hold down two jobs in order to keep the couple afloat, as Snyder was unemployed.
As time went on, Snyder changed for the worse, becoming both obsessive and controlling towards his wife. Their marriage ultimately ended, but not before she gave birth to their son.
After the boy’s birth and the couple’s divorce, Snyder became verbally abusive to his wife and refused to pay any sort of child support. She was torn. She felt that it was important for their son to know his father, but she was also afraid of Snyder’s quickly deteriorating behavior.

In one particular incident, the boy witnessed Snyder tell his wife exactly how he was going to kill himself. In another instance, Snyder begged her to let their son stay with him for his birthday. But she told Snyder he couldn’t see the child until he got a job, cleaned his apartment and sought out a therapist’s help.

When Snyder claimed he had done what she requested, she brought their son to over to see Snyder. The boy immediately started screaming and begging his mother not to leave. After staying for awhile, she started to pack up her things.

It was then that her life would change forever.

There sat two sets of handcuffs, a roll of duct tape and a pair of scissors.
A Vicious All-Night Attack

Cops say that without provocation, Snyder pulled out a stun gun and shot his ex-wife once in the arm.  Though physically shaken, she managed to stay alert, despite losing her balance.

As if that wasn’t enough, however, cops say Snyder then shot her a second time, leaving her in a daze.  Once incapacitated, police say Snyder led the woman into his bedroom and pulled back the covers on his bed.

There sat two sets of handcuffs, a roll of duct tape and a pair of scissors.

The victim tells AMW that she thought to herself, “Oh, I’m dead.”

Snyder then handcuffed his ex’s arms behind her back, handcuffed her ankles together and put duct tape over her mouth.

After tying her up against her will, she says Snyder raped her for hours.

As if that wasn’t horrible enough, Snyder used their son during the attack, telling his victim that if she didn’t comply with his wants, he would run away with the boy.

She says Snyder also forced her to calm their son down before the heinous attack, refusing to take the handcuffs off of her.

Cops: Fugitive Takes On Hate-Filled Cause

When morning came, Snyder let his wife and son go free, but that was not the end the torture.

Until Snyder was arrested for the rape, cops say he continued to stalk his ex: he punctured her tires with nails, and tried to seal her into her apartment by caulking up the door frames. He wrote messages scrawled in chalk on the sidewalk outside of her apartment, and left threatening notes for her.

She was so worried about her safety she wouldn’t keep her son with her and she constantly rented cars, changing them out to try and confuse her ex-husband and throw him off her track.

Eventually, Snyder was arrested and sentenced to 20 years in prison. He served four years before his release. His ex thought she had seen the last of Snyder, until one fateful evening in 2003, she saw him on the local news.

After his release from prison, cops say Snyder became the head of the Indiana chapter of the Pro-Nazi Nationalist Socialist Movement (NSM). The NSM is known for recruiting children into their “Viking Youth Corp.” organization.

It had been several years since the attack, but she saw on the news broadcast that Snyder was at a hate rally in downtown Indianapolis.

Snyder has been on the run since 2004 for violating the terms of his probation, in addition to three counts of failing to register as a sex offender. He is not supposed to have any contact with children.

If you know where John Snyder is, you’ve got to bring justice to a brave survivor and her son. Call our hotline right away at 1-800-CRIME-TV.

Go here: http://www.fox.com/fod/play.php?sh=amw#

And start the video at about 33.50 to see the original airing of the story on AMW.

The story so far:

• Detecting encrypted traffic with frequency analysis
• Detecting encrypted traffic with net-entropy, part one
• Detecting encrypted traffic with net-entropy, part two

I’ve written a basic Sguil agent that will upload net-entropy’s RISING ALARM messages into Sguil. You can download the agent here, and the config file here.

On a Sguil sensor that has net-entropy installed, copy the agent to wherever your other agents live (/usr/local/bin on my system), and the config file to where your other config files live (/etc/nsm/sensor1/ on my system). Then fire it up:

net-entropy_agent.tcl
   -c /etc/nsm/sensor1/net-entropy_agent.conf

With a bit of luck, you’ll see the agent register in the Sguil client:

And we’ll start to see net-entropy messages appear, too:

The bottom right pane of the Sguil client will behave as it does for the PADS agent, and will show you the event detail:

Sguil will correlate these events in the usual fashion, and allow you to right-click and say “Transcript” or “Wireshark”. It all seems to work pretty well!

Finally, the net-entropy project has a new wiki – it’s here. This is the place to go for the latest source code, which now includes a Paninski entropy estimator in addition to the original Shannon estimator. Have fun!

Back here I described my setup of a modified version of net-entropy, which I was going to use in my quest to detect encrypted traffic. Well, it’s been running for a week or so now, and I’ve got some results.

• Did it detect encrypted traffic? Yes!
• Did it detect stuff that wasn’t encrypted? Yes!
• Did it fail to detect traffic that definitely was encrypted? Yes!
• Was the experiment a total failure and a complete waste of time? No! Far from it, in fact.

The theory I was testing was that traffic with sufficient entropy might be encrypted, since high entropy is a property of decent encryption algorithms. net-entropy was set to trigger an alert if it saw any connections whose entropy crossed an arbitrarily chosen threshold of 7.9 (8.0 is the maximum), and protocols that were expected to be encrypted (HTTPS, etc.) were filtered out.

Here’s a summary of what I’ve found so far:

• Encrypted traffic that crossed the 7.9 threshold included Windows Remote Desktop (RDP), Skype (both calls and signalling traffic), SSH-2, and Google Talk.
• Unencrypted traffic that crossed the threshold was mainly RTMP (streaming Flash audio/video), and possibly Spotify (I don’t know for sure if Spotify uses encryption or not, but high entropy was observed both on the inbound media from port 4070 and the outbound media on random ports). Media protocols like this are usually highly compressed – high entropy is a side effect of compression as well as encryption.
• Encrypted traffic that was not detected included SSH-1 (1.5, to be exact). SSH-2 was detected as one would hope, provided that the session was long enough.

Clearly my blunt approach of a single threshold isn’t the most effective one, as we have both false positives and false negatives. But after applying some visualisations to my results, an intriguing possibility presents itself.

net-entropy was installed in this instance on a Sguil box mainly so that it was in a position where it could see a large volume of real-world traffic. A happy side effect of this is that it’s quite simple to extract the raw traffic captures that each net-entropy alert is referring to. If we’ve built net-entropy with the –enable-statistics option, we are then in a position to draw graphs of the entropy of an individual TCP stream:

• First, use the net-entropy alert to extract the specific TCP stream. The easiest way to do this is to search for it using the Sguil client, and then export the results to Wireshark. Let’s save the capture as session.raw
• Then we run net-entropy over it in statistics mode:

  $ net-entropy -r session.raw -s mystatsdir -F
   -b -c net-entropy.conf

• The output of this is a .dat file whose name is made up of a timestamp and the source and dest IP addresses and ports.
• We can now plot this file in gnuplot:

  plot 'mystatsdir/whateveritwascalled.dat'

By way of a baseline, here is a plot showing the entropy of the first 64KB of an HTTPS and an SSH-2 session. The blue line marks the 7.9 alerting threshold:

Zooming in a little, we can see that HTTPS crossed the threshold after about 2.2KB of data, and SSH-2 took a little longer:

Let’s zoom in a little on a different area of the graph – the little “wobble” on the SSH-2 line:

What we’re looking at here is the part of the conversation where the various parameters of the SSH-2 session are being exchanged (key exchange protocol, encryption/hashing algorithms, etc). These are passed as cleartext, hence the low entropy at this point.

It’s an interesting little pattern, though. Let’s overlay some more SSH sessions onto the one above and see what they look like:

There are three sessions illustrated here:

• The blue line is an SSH-2 session, which in the context of this experiment is a “true positive” since it was encrypted and it did cross the 7.9 threshold
• The red line is another SSH-2 session which was so short in duration it didn’t manage to make it above 7.9. This is a “false negative” because we’ve missed something that definitely was encrypted.
• The green line is an SSH-1 session. At no point during this session’s life did it cross the 7.9 threshold – another false negative.

As far as detecting encrypted traffic goes, this clearly isn’t as useful as I’d have hoped. But look at the red and blue lines – look how tightly they follow one another:

This brings us to the intriguing possibility I alluded to earlier – using entropy analysis not for the detection of encrypted traffic, but for the classification of traffic.

What if the entropy of certain types of traffic is reasonably consistent? What if the patterns above represent “fingerprints” for SSH-1 and SSH-2 traffic? If we could match traffic against a library of fingerprints, we’d have a port-independent classifier of sorts.

I’ve not had time yet to analyse sample sets large enough to be anywhere approaching conclusive, but let’s look at some other kinds of traffic:

The following graph shows four RTMP sessions:

Whilst RTMP isn’t encrypted, all four sessions have a similar visual fingerprint.

Now let’s look at nine RDP sessions (Windows Remote Desktop):

The most obvious outlier here is the black line – this was an RDP session to a server whose encryption level was set to “Low”. If we zoom in a bit, we’ll see another outlier:

The orange line is significantly different to the others. This particular session sent the string “Cookie: mstshash=machinename” in the first data segment sent from the client to the server – the other sessions had mostly zeroes instead, hence the lower entropy at this point. Since this is the very first data segment in the session, we could possibly infer that we’re looking at different client software used to make the connection. Indeed, if we look at RDP sessions from rdesktop (rather than the Windows client), the entropy looks different still:

The entropy is low, relative to the Windows client, and there’s a slightly different signature at the start of the connection:

One might be tempted to think that one could look at graphs like these and infer something about both the server (encryption level in use) and the client (type of software used).

OK. Enough graphs. Summary time.

Detecting encrypted traffic with a straightforward entropy threshold doesn’t seem to be useful. However, we may be able to use entropy analysis as a means to classify traffic in a port-independent manner, but I’ve analysed nowhere near enough traffic to assess whether this could be a viable technique or not (there are bound to be loads of outlying cases that don’t fit the profile). And even if it is a viable technique, are the bases already covered by other port-independent classifiers (l7filter, et al)? That said, I’m not the first person to explore various visualisations of encrypted traffic, so someone somewhere considers the broad concept useful.

Comments welcome!

This blog is dedicated to the OtaSizzle research project – it has been created to make it easier for all of us to communicate to one another what’s sizzling in our project and in the services that form the core of it.

From here, you can read of new features  that have been implemented to our services (Ossi, Kassi, NSM) or of possibly upcoming ones that we’re thinking about. Furthermore, the blog will allow you to stay tuned to our on-going research activities.

Most of all, however, we wish that this blog will be another forum for dialogue between users, developers, researchers and anyone who’s sizzling.

I’ve been pondering the possibility of detecting encrypted traffic crossing a network, and I think I’m getting somewhere (not necessarily closer to the goal, but somewhere nonetheless!). My initial thoughts were to put some kind of frequency analysis to the task, and whilst I was researching this I came across net-entropy.

net-entropy is a clever tool that can learn the expected cumulative packet entropy (“randomness”) for a given protocol, and raise alerts if an observed connection falls out of bounds (there’s a very detailed writeup here). The theory is that if someone is attacking a flaw in some cryptographic software (a SSH server, for example), the observed entropy of the connection will decrease unexpectedly once the attack has been executed and the attacker is delivering shellcode or whatever (figures two and three here illustrate the principle).

net-entropy was designed to focus on its list of pre-learned protocols, each of which is described in a protospec file. Here is the file for SSH:

Port: 22
Direction: both
Cumulative: yes
RangeUnit: bytes
# Range: start    end      min_ent        max_ent
Range:   1        63       0              4.38105154
Range:   64       127      4.22877741     4.64838314
Range:   128      255      4.95194340     5.02499151
Range:   256      511      4.86894369     7.28671360
Range:   512      1023     4.86310673     7.59574795
Range:   1024     1535     4.94409609     7.74570751
Range:   1536     2047     5.77497149     7.81915951
Range:   2048     3071     6.44314718     7.85139179
Range:   3072     4095     7.17234325     7.92034960
Range:   4096     8191     7.46498394     7.96606302
Range:   8192     65536    7.82608652     7.99687433

Each range is defined in terms of start byte and end byte, and minimum and maximum entropy. For example, for the first 63 bytes, the entropy is expected to be between 0 and 4.38105154 – an alert is raised if the entropy at this point is either too high or too low.

We could have a go at detecting encrypted traffic (rather than profiling its properties) with a very simple protospec file. What I’m interested in seeing is anything with an observed entropy that’s greater than some defined threshold – this will be my indicator that what we’re looking at could possibly be encrypted. So, we could have a protospec file that looks like this:

Port: "whatever"
Direction: both
Cumulative: yes
RangeUnit: bytes
# Range: start    end      min_ent        max_ent
Range:   1        65536    0              7.9

This file will cause net-entropy to raise an alert if the entropy for a connection on port “whatever” exceeds my arbitrarily chosen threshold of 7.9 in the first 64KB of its life; the problem here is that I’d have to write thousands of these files to cover the complete set of all TCP ports. I spoke to net-entropy’s author, Julien Olivain, about this and he very kindly implemented me an “all” feature, whereby a single protospec file can be applied to the complete range of TCP ports (updated source code is available here).

Now we can start to experiment! net-entropy will accept the usual variety of capture filter, so we can use this to exclude:

• The protocols that we expect to be encrypted (SSH, HTTPS, etc.)
• High volume protocols that are scrutinised by other means (SMTP, HTTP, etc.)
• Non-TCP protocols (net-entropy only works for TCP at the moment)

So, our net-entropy.conf file looks like this:

Interface: eth1
RuntimeUser: nobody
MemoryLimit: 131072
MaxTrackSize: 65536
PcapFilter: tcp and not port 80 and not port 25 and not port 22 and
            not port 443 and not port 993 and not port 995
ProtoSpec: /usr/local/share/net-entropy/protospec/proto-tcp-all.nes

I installed the software on a Sguil box and fired it up; pretty soon, things like this were popping up in /var/log/messages:

Sep 17 11:15:03 morpheus net-entropy[2689]: RISING ALARM on 212.7x.aaa.bbb:1708 -> 82.4x.aaa.bbb:60970 offset=2406 packets=7 entropy=7.90993547 range=0 (1 65536 0.000000 7.900000)

Woohoo! Data! Now all we have to do is work out if it’s useful or not. I’m not one for leaving logs lying idly on the server that generated them so I send the messages to a remote syslog collector, in this case a Cisco CS-MARS. The MARS certainly has its flaws and niggles, but it does let you write custom parsers for devices it doesn’t know about. Once the MARS has been educated in the ways of net-entropy, you can use its querying mechanism to start exploring the data.

I’ve written the required custom parsers, and exported them as a Device Support Package that you can import into your own MARS, if you happen to have one and want to play along (download it here). The net result is that I can do stuff like:

• Ask about the kinds of messages from net-entropy:
  

  Event Types

• See the details of sessions seen:
  

  Sessions

• Drill down onto a single session:
  

  A single session

  Note that the MARS has noticed that there are two events talking about the same session (based on the IP addresses and ports), and has been able to correlate them together into a single session.

• Get the raw messages as raised by net-entropy:
  

  Raw messages from net-entropy

So, here’s where we’re at:

• net-entropy has been enhanced to support a protospec file that applies to all ports
• This allows us to do “generic” entropy detection
• Events from net-entropy are being exported to my MARS, from which I can run queries and reports

Next steps:

• Work out if the things that net-entropy is alarming on are actually encrypted, or if the reason for their high entropy is something else (effective compression, for example). If I’m not reliably detecting encryption, then I can either tweak my entropy threshold, or give up the whole idea
• If the technique is really yielding useful results, perhaps write an agent for Sguil so that net-entropy’s alerts appear in the client for easy drill-down onto the session transcripts (there’s an agent available for modsec, so it could be feasible to try this)
• In the far future, how about a mod to the Sguil client that lets you right-click and say “Graph session entropy”? This would extract the relevant session from the full-content capture (just like the Wireshark option does at present), run it through net-entropy in statistics mode, and use gnuplot to visualise the result.

This post is most definitely filed under “Crazy Plans”. Comments on my insanity are welcome.

By Tracey Ryniec
September 04, 2009

It’s a relatively quiet week on the earnings front with only 50 companies scheduled to report, including a smattering of retailers and food companies. Only 2 S&P 500 members are on tap to report including Campbell Soup Co. (CPB) and National Semiconductor (NSM).

The economic calendar is also quiet to start the first “real” trading week in September, as Wall Street comes back from August vacations. It’s a shortened trading week due to the Labor Day holiday on Monday.
* Monday: Markets closed for Labor Day
* Tuesday: ICSC-Goldman Store Sales, Redbook
* Wednesday: Beige Book
* Thursday: International trade, weekly jobless claims, weekly natural gas inventories, weekly crude inventories
* Friday: Import and export prices, University of Michigan consumer sentiment survey for September, Treasury budget

Volume is likely to return to more “normal” levels to start the week. Despite recent weakness in the markets, the bulls remain in charge. Wall Street will also be watching trading in the commodities complex, especially gold and silver, as gold attempts to bust through the $1000 an ounce level for the third time in the last 2 years and silver trades at 13-month highs.

Companies That Could Issue Negative Earnings Surprises
Smithfield Foods (SFD), the largest hog and pork producer in the U.S., is struggling as pork demand falls due to the recession and worries about pork products somehow being connected to the swine flu. According to a Reuters report, the company has cut its hog breeding herd by 13% this year. Higher feed costs are also pressuring the food manufacturer.

While Smithfield has surprised on estimates 3 out of the last 4 quarters, covering analysts have been lowering the estimates going into the fiscal 2010 first quarter earnings release. In the last month, the Zacks Consensus Estimate has fallen 4 cents to a loss of 55 cents. It is scheduled to report before the market opens on Sep 8.

Keep an eye on the Aerovironment Inc. (AVAV), the maker of unmanned aircraft systems, as it reports its fiscal 2010 first quarter earnings. The Zacks Consensus Estimate has fallen by nearly 50% to 13 cents in the past 90 days. The most accurate estimate is even more bearish at 6 cents per share. The company is scheduled to report on Sep 8 after the market close.

I recently wrote about a plan for detecting encrypted traffic, where I mentioned in the comments that I’d come across a package called net-entropy (very detailed writeup here). I’ve been in touch with Julien Olivain, one of the authors, and he’s kindly given me the sources to experiment with.

And experiment I shall – I’ll post my findings when I’ve got some!

A while ago, I bemoaned the ease with which Cisco’s inline URL filtering can be bypassed. There were two main gripes:

• Only HTTP GETs were processed – POSTs etc were not inspected
• You have to manually nominate the ports that the inspection will take place on (although this point can be mitigated with egress filtering)

I have since discovered a third bypass, whereby HTTPS traffic is not inspected at all, even if you manually alter the port-map settings so that port 443 is listed as plain HTTP.

I’m pleased to report that I’ve successfully raised a product enhancement request to remedy some of this (big thanks to Herbert at Cisco TAC for getting the ball rolling here!) – the inspection of POSTs and of HTTPS is on the development roadmap for a future version of IOS.

Timescales? I have no idea. Best estimate is a one-year timeframe, but better late than never!

Aguarde

Não Somos Máquinas

Tack http://putmeonit.blogspot.com

1. Soundspecies – Can We Call It Love (with Ahu) [BB4]
2. Simbad feat. Steelo – Soul Fever [BB1]
3. Bullion – Get Familiar [BB3]
4. NSM – The Hype [BB2]
5. Katalyst feat. Steve Spacek – How Bout Us [BB3]
6. Cornish Waters feat. Duchess – Walking [BB2]
7. Ayak & First Man – Can We Go Back? [BB1]
8. DJ Day – A Place To Go [BB3]
9. Mayer Hawthorne – Maybe So, Maybe No [BB4]
10. Iman – Who Was I Trying To Fool [BB1]
11. Flying Lotus – Tea Leaf Dancers [BB2]
12. New Look – Everything [BB4]

It’s not always possible or feasible to collect the four types of information useful for conducting NSM, for the usual reasons (“cost of software/hardware/people/time” being near the top of the list). However, this doesn’t mean that the game is lost before it’s even begun – Sguil, for example, doesn’t have any facility for statistical alerts, but that doesn’t mean that it’s not a powerful tool.

The following tale took place where only session and alert data were available. Despite this apparent lack of information, we were able to solve the mystery without the intervention of Scooby and the gang, and we were able to dodge the temptation to take an IPS alert at face value (a clear case of defensive avoidance!)

The network in question was purely a client site; there were no public servers to worry about. Network security was pretty formulaic:

There’s a PIX doing the standard firewall/NAT job, and an inline IPS scrutinising everything that goes in or out. The logging level on the PIX is turned all the way up to “debugging”, so we get an export of session data in the form of messages like PIX-6-302013/PIX-6-302014 etc. Both the IPS and the PIX are reporting to a central log collector, a Cisco CS-MARS in this case.

The trigger for this investigation was an alert from the IPS. Lots of them, in fact. The signature that fired was one we’d never seen before, which either means another class of false positive to tune out or that something interesting is actually happening.

Even more interesting was the fact that the signature wasn’t just your typical brute-force pattern matching job – it was one of Cisco’s “anomaly detection” signatures that fires on behaviour observed over time. The signature denotes a TCP scanner hard at work scanning external IP addresses. The signature writeup is frustratingly lacking in detail; what it means when it says “scanning” would be a useful thing to know, for starters.

Never mind. NSM Ninjas don’t need vendor writeups. We can reverse engineer a signature’s firing conditions ourselves.

Looking at the alerts we’d got, we can see:

• There were zillions of alerts over a five-ish minute period.
• The alerts cite five distinct internal IP addresses as being those doing the “scanning”.
• At the end of the five-ish minutes, the alerts stop as abruptly as they started.

Hmm. Let me see if I’ve got this straight. Five of my hosts all start “scanning” at the same time, they carry on scanning for five minutes, and then they all stop at the same time?

Eek.

Maybe we really do have a worm outbreak here. But why only five hosts? Why did they stop at the same time? Is there a command and control element at work here? Are my hosts pwned? Do I trust the IPS alerts and start rebuilding the “compromised” hosts? Questions pour down like rain, and we’re in for some serious flooding unless we wheel out the umbrella-and-wellies combo that is NSM and Vigilance to Detail.

First, let’s see exactly what these hosts were doing during this five minute window. We’ve got no full-content capture here, remember, so we’re going to have to hit the session data from the PIX pretty hard. Using this, we can see that each of the five hosts tried to contact between two and three hundred non-local IP addresses in our five minute material time frame (MTF). This is definite worm behaviour. There’s a small degree of crossover between the pools of target IP addresses, but there’s no one address that they all have in common (i.e., there’s no single command and control channel).

Next, we can check the destination port – if we’re dealing with a worm, this will be a good clue to which one it is. All the ports were TCP, but the port numbers were random. All over the place. This doesn’t seem like worm behaviour to me – random IP addresses I can understand, but random ports makes little sense.

Now we can look at data volumes – how much data did our “scanners” actually send. We get another interesting answer – not a single byte of payload was carried. This could possibly be explained by the random nature of the destination ports – given the utter shotgun nature of the “scanning”, I guess it’s not too likely that we’re going to hit an open port.

So we have a frenzy of totally ineffective scanning, with the attackers apparently synchronised somehow. There’s not too much more we can learn from the session data at this point, so we have to look for other clues. The plan is to see what kinds of events the PIX was splurting out in the thirty seconds before and after the first IPS alarm – we’re after the catalyst for the scanning, if there is one.

All the while, I can’t help but think I’ve seen these five source IP addresses together before, but I can’t quite put my finger on it…

Anyway, back to the catalyst seeking. The ad-hoc query interface on the CS-MARS is pretty reasonable, and it’s really easy to ask it for a list of event types seen from a particular device for a particular MTF. Taking the start of the scanning as the start point and working from T-30 seconds to T+330, we notice a few things:

• There seems to be a big gap in the events output by the PIX – it’s been totally silent during the initial period of scanning.
• During the latter phases of scanning, there were loads of these messages logged: “%PIX-3-305006: outbound portmap translation creation failed”. These are raised when the PIX can’t create a NAT translation, due to lack of resources, or a TCP protocol violation, etc.
• We also see a single instance of this: “%PIX-6-199002: Startup completed. Beginning operation”. This means that the PIX rebooted for some reason.

We can express this as a timeline:

Finally, I remember where I’ve seen the five IP addresses before, and all the pieces fall into place.

The five IP addresses are those of people who use Skype. Whilst it obviously has great merit as a piece of communications software, its use of apparently random destination IP addresses and ports plays merry hell with NSM reports based upon session data. For this reason, I run a daily report of Skype users so that I can exclude them from these reports if I need to (it’s easy to spot a Skype client starting up because it checks to see if it’s running the latest version – I look for which IP addresses are making the check).

After piecing together all the evidence, we come up with this:

• Five Skype clients start up. They connect to many many destination IP addresses on random ports.
• For whatever reason, the PIX crashes and reloads.
• The Skype clients don’t know this, and try to maintain their existing TCP connections (they must do some kind of keepalive).
• After a minute or two, the PIX has finished reloading.
• Whilst this is going on, the Skype clients are still trying their keepalives. Once the PIX is working again, the keepalives still fail because the PIX is a stateful firewall. Each keepalive only has the ACK flag set because it’s part of an existing session as far as Skype is concerned. However, the PIX hasn’t seen the start of the TCP session and therefore has no “state container” for it. This is the reason for all the “outbound portmap translation creation failed” messages, and also the reason why we didn’t see any actual payload transferred – the PIX dropped all of the keepalives.
• Meanwhile, the IPS (sitting in between the Skype clients and the PIX) is seeing all of this and is merrily firing it’s “External Scanner” signature.
• Eventually, the session timeout on all the Skype clients fires, and they all declare their existing sessions dead and re-establish them from scratch with SYN.

So, there we have it. The IPS alerts were false positives in this instance, caused by a tenacious piece of software and a flaky piece of hardware. Our lack of full-content capture wasn’t a problem – we solved the mystery without it, and even if we’d had it there wouldn’t have been anything to see in this case. Another victory for the umbrella-and-wellies combo!

May’09: One of my favourite exhibitions at NSM.

for more images that were taken