Centralizing Check Point data into Splunk allows the user to expand their knowledge of their own environment by easily analyzing the data. Through the Splunk Dashboard, the app provides a general overview of the Check Point environment, Check Point IPS, and Check Point VPN information. The user has the ability to narrow down the data by specific firewall, performance impact level, and confidence level. Users also have access to a map showing what IPs have been dropped or accepted and where.
With the number of attacks increasing per year it’s important to stay up-to-date on current trends in the industry. Splunk allows you to index, monitor, and analyze data with a security mind frame. Managing Check Point data in Splunk will allow users to view trends in the firewall data and analyze why attacks happen to mitigate the chances of them happening again.
Version 1.1.1 of ‘Hurricane Labs Firewall App’ can be found at (http://apps.splunk.com/app/1727/). Splunk users can utilize the app through installing and configuring the Splunk Add-on for Check Point OPSEC LEA Linux (http://apps.splunk.com/app/1454/).
About Hurricane Labs and Splunk
An industry leader in Splunk Managed Services, Hurricane Labs assists your team in maximizing the value of Splunk. Hurricane Labs is the only official Splunk partner in North America that can provide licensing, implementation, on-site training, and managed services around Splunk. These key skills allow Hurricane Labs to provide a focused and unique offering all built around Splunk.
I couldn’t even begin to explain the thoughts that pour through my head with that scenario in place. Just to touch on it a bit, 99% of security attacks are directed at the user, and with that in mind I’d have so many changes that would aggravate so many people. Every host, not user, not server.. every host would be it’s own /30 network with a network/application firewall as it’s default gateway. Every host would be it’s own “trusted” IDS variable as far as network is concerned and be connected to an incredibly well thought out OS security and control model that is centrally managed by a team of people I could only describe as something Hollywood would portray as a group of 8-10 people working 24×7 to solve some unsolvable mystery. I could literally go on about the resources I would put in place. Cloud based web filtering, full disk encryption, multiple layers of public facing asset protections, not even to mention that I would probably take care of 5% of the nation’s unemployment rate just to make sure there was enough physical coverage to respond to every event that came about. You all know you could use more people help. Right? Security won’t work itself, right?
Just think about that idea momentarily, cognitive security. Not the product/company Cisco acquired(we all know how manual anything Cisco related can be), but the true idea of information working to your advantage with minimal administrative interaction.
I’ve been doing it the hard way for customers as a security vendor for the past 5 years of my career. Multiple products in place; ISA/TMG, Qualys, mod-security, TrendMicro, <insert firewall vendor name here>, Barracuda, Sourcefire, port-security, etc. That’s a lot of effort for administration to work with in a very disconnected format that requires significant attention for them to function with the purpose they were intended. I’m not going to bash any one product, they all control what they were meant to control. It’s just that many companies/organizations don’t have the manpower or time to give these products the proper attention they require to be as completely up to date as possible. That’s why we moved to Splunk. It puts all of this information in one place. Don’t stop there. You still need to do something with it.
That’s where we put Splunk to work. You can tell Splunk to do things with your log data/security alerts based upon the information provided by your network and security infrastructure, the systems and infrastructure you already have in place. Just by sending Splunk your log data. A simple example would be something along the lines of automatically opening up a help-desk ticket because Splunk was able to tell from your IDS alert data that a host at your Chicago office has tripped. A less simple example would be that the same help-desk ticket was opened only if that alert triggered a certain amount of times within a specific time frame. An even more complex example would be that the same alert threshold would correlate with your Websense and firewall data to verify that the traffic passed successfully to properly prioritize the ticket it opens with your help-desk team, to help communicate how quickly action needs to be taken. A simple example of an outside security threat would be parsing the IDS alert data against internal Qualys scan results to determine if that threat requires a help-desk/security ticket internally because it’s running the affected software, on top of running a script that will kill the connection at the network or host based firewall. It can even go as far as to detect a DDoS or Reflection attack from your firewall logs and execute a script that automatically drops the traffic for a certain time period without any human interaction at all.
Honestly, that’s as perfect as you can get in today’s security world. We call it HDSI, because we’re Hurricane Defense and it’s our Security Intelligence. I call it being as proactive as you possibly can with the information and infrastructure you have in place. Sure, nothing is perfect and things change, but if you put in the effort to be as proactive as you can with what you have, you can sit back and say you are doing everything in your power to be as proactive as possible. I’m not going to lie either. This is all security based Splunk use case discussions. You can easily sell Splunk to other departments and their budgets based upon it’s incredible operational strength. You know, spread the wealth if you will.
For more information go to Splunk Managed Services
This jump in popularity has driven me to better understand how this technology is deployed, as well as common vulnerabilities and configuration issues that exist in many environments.
Like any security technology, full disk encryption systems are not foolproof. I have successfully gained access to fully encrypted laptops that are completely powered off, without any information other than what is present on the system itself. In some cases, a machine was completely compromised in minutes. Several of these tests involve actual deployments that were analyzed as part of forensic penetration tests that I performed. I suspect that many other actual deployments of full disk encryption systems are vulnerable to the same types of attacks I have used in the past.
I hope that this blog post will shed some light on the common attack vectors and risks associated within a full disk encryption environment. I will begin with an overview of full disk encryption technologies as well as some common deployment scenarios. I will then describe the methodologies I have used to successfully gain access to several of these systems. I will conclude with some recommendations on how you can assess and improve the security of your FDE deployment.
Overview of Full Disk Encryption
Encryption technologies are designed to protect data. Full disk encryption is used to secure data at rest. Increasingly, companies are turning to FDE as a solution for protecting mobile data. Perhaps the most common use case for FDE is protecting an organization’s laptop fleet.
From what I’ve seen, many companies have requirements that at least some systems be encrypted – especially those that are used by individuals that might have access to sensitive and/or proprietary information. Taking things a step further, an increasing number of organizations are moving towards a model where all of their corporate owned laptops are encrypted by default. Some organizations will also deploy FDE on desktops, but this application is far less common. Due to the ease at which a hard drive can be removed from a standard business desktop and the lack of physical security that would prevent a drive from being removed from a facility, there are certainly strong arguments for deploying FDE on a wider scale.
When full disk encryption is deployed, it is assumed to be a black-box panacea for all data security issues. All too often, the simple presence of FDE is considered protection enough to secure a system. Like any tool or system designed for security, FDE is by no means bulletproof. Unfortunately, FDE is often implemented, but rarely verified or tested. The vulnerabilities, configuration oversights, and potential weaknesses of different FDE technologies and implementations are only infrequently discussed and even less well understood.
Attacking Full Disk Encryption
At its core, the actual encryption technology used in most commercial products is some variation of AES, a system that is currently considered to be very secure. At the time of this article’s writing, it is not practical or possible to break the encryption algorithm used in most FDE systems itself. When evaluating the security of an encrypted system, this fact alone is often considered adequate to consider the deployment to be secure.
The security oversights I have seen on many full disk encryption penetration tests do not involve the actual encryption technology being used “under the hood”. Encryption is one of those technologies where it makes sense to simply use the best current standard available. I would be concerned to see a product in this market that was using a custom encryption algorithm – these are not only typically significantly less secure than the accepted standards, but sometimes even contain major programming or implementation oversights that render the algorithm trivial.
Full disk encryption is better attacked by considering possible weaknesses in the configuration and deployment of the system. Generally, the most successful method for attacking a fully encrypted system is to attack the operating system directly. When the operating system is running, decryption is taking place. While the data on the hard drive is still stored in an encrypted manner, this data must be decrypted to be loaded into memory. The CPU also must work with unencrypted data.
There are several methods that are often used for FDE authentication. Many products offer an integrated authentication scheme that ties the FDE authentication into the authentication for the operating system. This is often deployed as a convenience for users, since they only need to log in once to use the system. The problem with this authentication method is directly related to when the user is prompted for his or her credentials. If the operating system is allowed to load, it can be compromised. Configurations that require authentication prior to booting the operating system prevent a hacker from immediately attacking the operating system.
I have also found various loopholes with pre-boot authentication schemes, such as a grace period where a system does not require authentication before booting within a limited time of last contacting an authentication server. Prior to testing any fully encrypted system, I will first make a full image of the system in question using a forensics writeblocker. If such a window exists where pre-boot authentication is not required, I have been able to locate this through trial and error while repeatedly reimaging a scratch disk from my master copy. Since the hard drive has no sense of time, the system clock is considered absolute for determining the timeframe for such a window. Once the system is powered on, any timestamps on the disk are updated and the working drive will need to be reimaged in order to run another test. This is certainly a time consuming process, but it can be effective if the system being tested has such a feature. Ultimately, I will want to get the system to a point where the operating system is loaded to proceed. In some cases, this is not possible.
The most effective method for attacking a running operating system on a fully encrypted machine is through memory manipulation. Modern computers offer several interfaces that feature direct memory access (DMA) – a technology that permits access to the lower 4 GB of system memory independently of the CPU. Interfaces that offer DMA include FireWire (one of my favorites for these sorts of tests), PCMCIA, ExpressCard, and Thunderbolt. Since most operating systems support plug and play and will install device drivers, a system running software designed to copy the contents of and manipulate memory can be connected to such a system. I have found that a tool called Inception can be very useful for dumping the contents of memory (which may contain the decryption key) or manipulating the password validation code in the currently running operating system to allow any password to be accepted as valid for the administrator account. At this point, the system is generally completely accessible.
Protecting Your Environment
As an industry, there is room for improvement in the deployment of FDE. The following recommendations can be used to better protect your fully encrypted machines. Like any security recommendations, some of these are easier to implement than others and some may not be practical in your environment. You must consider the risks involved and pick the best options for your particular situation.
TO SECURITY ADMINISTRATORS:
Pre-boot authentication is absolutely mandatory – on every boot. As I demonstrated, if there’s any window where pre-boot authentication is not required, that window can be discovered. Once the operating system loads, the presence of encryption is often a non-issue. By far, this is the most important step towards protecting your encrypted systems and data.
Disable DMA interfaces: Laptops come with many DMA capable interfaces which are typically enabled. In many of my tests, the DMA interface used is Firewire, but other interfaces such as PCMCIA and ExpressCard can be used as well. All modern operating systems support plug and play and will allow device drivers to be loaded automatically when a system running a memory acquisition tool is connected. More often than not, these interfaces are not typically used and can be disabled in the BIOS with minimal to no impact. Disabling these interfaces prevents an attacker from accessing the memory of a powered on system that is left unattended.
Understand the ramifications of standby and hibernation modes. Both standby and hibernation allow a system to be powered on without pre-boot authentication being required. In most cases, both should be disabled to prevent a system from being stolen in a state where pre-boot authentication will not be required. Some products can be configured to force pre-boot authentication for both standby and hibernation. If available, this should be enforced.
Establish a policy where powered on machines shall never be left unattended – even locked systems are vulnerable.
Trust but verify: testing and verification is the best option for securing FDE. Do not assume a given solution is secure out of the box and that the default settings are optimal. Whenever possible, have your implementation verified by an independent third party. This type of assessment should be performed by someone who is both familiar with full disk encryption security concerns and not associated with the vendor whose solution you are deploying.
TO FDE VENDORS:
Finally, vendors are trusted by their customers to provide a data protection solution. Vendors need to be aware of the vulnerabilities in their products and any configuration options that may put their customers’ data at risk. When possible, settings that reduce the security of an implementation should have clear warnings of the risks associated with these selections. I would like to offer the following suggestions to those tasked with developing the tools we must rely on to manage and safeguard our data:
Perform all authentication prior to loading the operating system.
Never store or cache any authentication tokens locally.
Develop methods to better tie the encryption to the hardware it is installed on. Recognize changes in physical drives (resulting from imaging) using serial numbers or SMART data.
TO OS VENDORS:
Disable plug-and-play while the system is locked and before initial log in.
Log the presence of any unauthorized devices, offer the option of alerting the user if a device was connected when the machine was locked.
I hope that you found this article to be both interesting and informative. If you have any questions, comments, or additional research on this topic you would like to share, please let me know. Most of the information in this blog post is also available through a slide presentation, “Attacking and Defending Full Disk Encryption”. This topic was originally presented in July 2013 at the Bsides Las Vegas Security Conference.
Let’s start with some good news – When I originally wrote this post back in 2012, Apple was really behind in the area of automatic software security updates. At the time they hadn’t even released automatic security updates for OSX, let alone iOS. Since then, some things have changed, and dare I say it, gotten better? I like to think so – at least a little better. Now that we have the automatic updates across their entire ecosystem right down to the apps we download. It’s a nice convenience (not always). I think for users who don’t want to be bothered with updating their apps, the auto-update option is a nice feature. Does that mean that Apple has a perfect security record now?
Not quite, and now it’s time for the bad news (and these are just a few examples) – Back in 2012, Apple was involved in the hacking of a prominent tech journalist who had all of his accounts targeted. 2013 was a fresh start, but oh not quite a great year either – In March of 2013, there was the vulnerability that allowed for malicious individuals to reset someones Apple ID and password with just their email. At the end of 2013, with everyone screaming about the NSA, it was discovered that there was a major flaw in webcams on MacBooks (creepy). In July of 2013, their developer portal was compromised. Oh boy, that doesn’t sound like such a great track record. Will 2014 be any better – only time will tell.
Another part of my complaint in the original post had to do not only with Apple’s security practices from a software and hardware perspective, but also from the marketing perspective. I’m honestly not sure if things have changed with the way Apple products are sold to consumers. In the past, I’ve had Apple employees always tout the safety and security of their beloved products. The problem with this is the illusion that it sets up in the mind of consumers. ‘This product is so safe, that I never ever have to worry about it.’ The correct way to approach this would be to explain that this product is a machine, and like any machine is vulnerable to potential security flaws. Then, and only then, should an Apple employee go on to explain HOW the consumer can best secure their system while emphasizing that no system is 100% secure – ever.
I said this two years ago and I will say it again – my point is that companies need to be more upfront about the security of their products. Apple has gotten a little better about it, but only because they’ve had to. They’ve been put in some uncomfortable positions over the past couple of years. I really hope that more pressure is put on them to better secure their ecosystem. Otherwise, another one bites the dust.
This entry was posted by Ian Gillespie from Hurricane Labs
Like clockwork I expect there will be calls for “new controls” and “better detection methods”. You probably predicted this, but I say that’s all nonsense. We should actually use the methods we currently have. Go on, give them a chance, you know you want to. “But AV failed to detect the malware” you say and that’s correct, it seems to have and that will happen, but why was any device on Target’s POS network able to FTP to Russia? Do they have locations there or do any data processing there? Probably not. They are not the victim of a huge, advanced, vast, APT-laden conspiracy, they are a victim of loose firewall rules, pure and simple. If you cannot stop an attack, you should at least be able to contain it, that’s why we should have layers protecting important data. Those layers should be specific and monitored.
I am a huge advocate of egress filtering and I get beaten up for it a lot but you know what? I can take it, I’m a big boy and I can take it because it works. I’m sure there are hundreds of magical scenarios where it won’t work, maybe you’ll say “DNS tunneling!” and that’s probably accurate, but if you limit egress traffic you can definitely make a dent in what you have to look for, you will know your weak spots. The other one I get a lot is “but its hard and applications need lots of ports and its really hard”. The only response I have for that is, to quote an old colleague of mine, why they call it work. Yes its hard but its not impossible and if the data is important enough it should be done and done well.
I am also a huge advocate of reducing your threat landscape in common sense ways. Don’t do business in Russia? Block Russian IP addresses. Of course that won’t stop them from proxying through another channel, but again it reduces the stuff you’re looking for, making those needles in haystacks a bit easier to find. I’m not proposing rocket science here, this is all stuff you should already be doing so ask yourself, am I avoiding work because its “too hard” or am I just another target?
Take the recent retail breach for example. Every expert on Earth (before any details were out of course) said it had to be the work of a super complex, advanced ring of international hackers who were way more advance than our paltry defenses could stand. Turns out, it was originally reported to be a 17 year old Russian kid that actually wrote the software. I’m sure there was probably some more involved “criminal” types, but that super advanced piece of malware was written by a 17 year old. Experts could not fathom a world where a PCI compliant, big time company with all the “right” consultants and all the “right” protections could be breached by a kid.Now the same folks are saying that someone else was indeed involved and that the 17 year old kid had not acted alone so, experts get a lot of things wrong too. That, to paraphrase Yoda, is why experts fail.
Expertise is a disease of the mind. It basically reinforces the fact that you can’t move higher or further in your field. It limits you, greatly. It starts innocently enough “hey that guy is really good with computers” or “hey she’s a pretty talented programmer” and then progresses to “just ask Steve, he knows everything, he’s an expert.” If you were Steve, would you bother to pick up a book again? Probably not, not if that sort of thing persists. All of this ends up with the attitude that you can’t be wrong, you’re an expert. Expertise forces you to start accepting your own theories as proof, your word becomes all you need. This is why in academia there’s a general rule against providing yourself a source in a paper, not only is it self-serving, but it’s very bad form, “this is true because I say it is true.” Does that sound like someone who would take advice from a novice in the field even if that novice has a genuinely better idea? No, because few if any experts can recognize a better idea because that sort of thing doesn’t exist in their bubble.
Of course there are exceptions to every rule so you can save me the commentary that you’re an expert that doesn’t act like that because, really, we all do it in some way. Whether in our personal lives or professional lives we all have something we feel expert in and we’ve just stopped trying to get better at. It is a curse that afflicts all of us at one time or another but in IT, especially in IT security, if you’re not taking into account anything but your own limited worldview, you will fail and you will fail big. Basically this was a very long-winded way of saying, don’t be an expert, strive only to be a student, that way you will know you don’t know enough just yet.
This entry was posted in by Bill Mathews from Hurricane Labs
Many of the mid to high-end Check Point appliances feature a built in LCD display and control panel. When an appliance is booted up, the display will show the appliance model and the Check Point logo, as pictured.
The LCD and control panel buttons allow a user with physical access to an appliance to perform basic configuration tasks, such as changing the management interface IP address and default gateway, or reboot the appliance. In many cases, this may not be desirable. To restrict this access on an appliance running Check Point’s GAiA operating system, run the following command from the clish shell:
my-firewall> set lcd access none
This will prevent any configuration changes from the LCD screen. There is also an option available which requires a numeric passcode to unlock the LCD display.
Check Point also offers various screensaver options for the LCD display. I’ve found that the most useful option is to display the time and hostname of the appliance on the LCD. This can be accomplished with the following command:
my-firewall> set lcd screensaver mode hostname
The screensaver change will not be displayed until the screensaver is reloaded or the appliance is rebooted. To allow this change to take effect quickly, you may adjust the screensaver timeout to a shorter timeframe, specified in seconds.
my-firewall> set lcd screensaver timeout 15
Then, press any button on the front panel (assuming LCD access is allowed), and then wait for the timeout to complete. Your Check Point appliance will now display the hostname and time as pictured:
his entry was posted by Tom Kopchak from Hurricane Labs
It’s a pretty simple and not terribly technical concept. Encryption is really just a masquerading technology, an illusion meant to provide temporary privacy for moving data. When data is at rest, given enough time, it is even less of a security technology (but we’ll save that for a different post). I know what you’re thinking, “I know that, of course encryption only protects privacy and in some cases integrity.” Awesome, I think it is a great that you know that, would you mind helping me spread the word to marketing departments and management folks? Here’s why:
LinkedIn’s response to their recent breach was to add some encryption to their passwords. A really good move to be certain, why it wasn’t there already I don’t know. However I have seen no mention of actually proving these security measures. How did the attacker get the data in the first place? LinkedIn seems certain that, aside from passwords, no other data has been leaked out. But how do they know? They’re certainly not talking (which is a whole separate problem in handling an incident). Having conducted and/or run quite a number of penetration tests I can tell you if we get a SQL Injection and dump out the passwords table, it usually doesn’t take much to get the usernames too. So what is the real story? Again, they’re not talking but they’ve “added some encryption” so in case it leaks out again, it’ll be better.
You see it on websites all the time, “We use bank level encryption to secure your data” and my response to that is always, “so what?” My wife is probably quite sick of hearing about it and since no one else would listen I figured I’d write a blog post. When I read this, it is usually in reference to their website’s use of SSL and that’s great, everyone should use “bank level encryption” for their SSL connections. But what really matters is the meat of their protections, what are the other layers? If you’re just encrypting the traffic and nothing else then all you’ve done is insure that no one can snoop on the bad guys while they’re breaking into your stuff. That’s it (and these days even that it isn’t a certainty). We have to be smarter about the messages we send to customers. You are not protecting them because you’re encrypting their traffic – a slogan is simply not enough. You have to provide layers of protection and you should go into some detail about them so customers can really understand your precautions. This is much better than lying to them.
The bigger problem I have with encryption is that on a long enough timeline (shorter with more computers doing it) ALL encryption is breakable. Don’t believe me? Fujitsu Labs just broke 923-bit encryption which was thought to take thousands of years. With 21 computers (252 cores) they broke it in 148.2 days. That probably sounds like a long time if you’re only passingly familiar with cryptography, but really it was a land speed record. With computers getting faster, cheaper, and cloudier (couldn’t resist) cracking “bank level encryption” will become trivial within a few years. What does this mean? It means start getting serious and stop relying on encrypted voodoo and soothing marketing “power” words like “bank level encryption.” It is meaningless and makes me wonder what else you’re hiding.
UPDATED CONTENT
I wrote this article a while ago, before all the NSA problems emerged so you might be thinking, “well Bill, I bet you regret that article don’t you?” Short answer is no, no I do not. Simply encrypting something does make it more or less secure. A lot of the NSA stuff is about compromising endpoints or links that aren’t encrypted at all anyway, if I control the endpoint then encryption is meaningless anyway. Encryption still does not equal security.
You’ve probably read about Snapchat’s recent fiasco concerning user data, would encryption have helped there? Sure it would’ve contained the leaked info and limited damage but no it would not have stopped the breach from occurring. Once the data is out of your control, encrypted or not, it can no longer be considered safe.
There is nothing magical or earth shattering about this but despite all of this you still see websites saying they are secure because they are encrypting everything and it is still simply not true.
This entry was posted in General Cyber Security and tagged Encryption by Bill Mathews.
Hurricane Labs, founded in 2003 by Bill Mathews and Glenn Brzuziewski, has seen exponential growth from its beginning. Starting off with only a few employees, Hurricane Labs has grown into a mid-sized business, continuing to employ IT professionals. Today, the company is a leader in the industry offering Splunk managed services, vulnerability management, training and more.
Throughout the years, Hurricane Labs has evolved itself to keep up with the ever-changing IT Security field. Through its vendors of Splunk, Checkpoint, and Qualys, the company has a solution at hand for any IT business plan. The thing that sets Hurricane Labs apart is the teamwork and passion of the engineering team. With a unique combination of technological expertise, educational resources, and 24/7 customer support, Hurricane Labs is able to create a personalized set of security solutions that work to monitor and protect clients.
Having collected several awards, Hurricane Labs has been recognized for excellence and growth. In 2004, Glenn Brzuziewski, co-owner, was presented the Distinguished Service Award for outstanding leadership and service in support of the mission of the Infragard program. Glenn was also presented the Linda Franklin Award in 2005 for contributions to the growth and development of the Northern, Ohio chapter of Infragard. Also in 2005, Hurricane Labs was presented a reward from Check Point for Fastest Growing Partner. In the years 2009, 2011, and 2012, the company won the Weatherhead 100 Outstanding Growth Award. 2010, 2012, 2013 brought recognition from NEO Success, recognizing the most successful companies in North East Ohio. Lastly, In 2012, Bill Mathews, Chief Technical Officer, won Crain’s 40 Under 40 Award.
Hurricane Labs continues to work on growing sales by expanding into new markets and looks forward to new opportunities in the future.
This entry was posted in General Cyber Security, Network Security by Nicole Haefke.
That said, I’m really growing tired of reading articles about “Malware discovered in Google Play”, “First Malware ever in the App Store”, “Malware went undiscovered for weeks in Google Play”. It’s not really news – People write malware, people distribute malware, people install malware – It happens. I shake my head at people who run Windows computers and don’t have good anti-virus software installed. I have 3 Windows computers at home (well, my girlfriend does, I really only use my Mac). They all have AV on them (ESET NOD32 if you’re curious). And you know what? I’ve got an AV-type malware detector on my phone, too (Lookout Security).
The thing about malware is that it’s out there and its not going to go away. If the fact that it got past Apple (granted, after however many years) says anything, it’s that you can try and try and try and you’ll still get it. There will always be security flaws in software, there will always be hackers, there will always be viruses/malware/etc. The fact that the news outlets on the Internet feel the need to report each and every time malware is found is indicative of something…but I’m not sure what. It’s like the news reporting on every time someone gets a parking ticket. There’s no need to inform the public about it. At best, you’re going to annoy the readers. At worst, there could be a lot of people getting parking tickets and you’re going to make people think the local police are getting overbearing with parking tickets.
The fact of the matter is, Google/Android, Apple/iOS, Microsoft/Windows Phone, ALL need to be more upfront with their users about the fact that some sort of virus or malware protection needs to be installed. They could even take the route Microsoft ALREADY took with Windows on the desktop and include a pretty basic version in the OS. Google could easily pick up someone like Lookout and integrate the malware scanning into the base OS. Sure, Apple tends to fight that stuff at the App Store level, but having something integrated into the OS wouldn’t be a bad idea either. And at that point, why not integrate the scanning into app submissions? If you can detect the Malware before it gets accepted to the app store then you eliminate a huge chunk of the problem. My guess is that there ARE scanners checking apps before they get submitted to the store, but obviously things are getting through. So, are the scanners that bad that so many things are getting through, or do we not have the details about how many ARE getting stopped?
What it comes down to is this: Owning a smarter phone is great, it lets you carry the Internet in your pocket, stay connected, etc, etc. But you have to remember something important. YOU’RE CARRYING THE INTERNET IN YOUR POCKET. Your phone is now just as connected to the Internet as your computer. And if you’re affording your computer some sort of protection because its connected to the Internet, why wouldn’t you do the same for your phone? Assuming something is safe just because its not running Windows has been proven to be a bad security tactic (I’m looking at you, Apple). Do yourself, your data, and the poor people who are tired of reading articles about malware in the app stores a favor – just be smarter about your phone.
This entry was posted in Mobile Security and tagged Antivirus, Malware by Steve McMaster.
I still see it every day on my own Facebook account. Parents willfully and without warning posting countless picture of their kids – at the park, at home, with mom and dad, eating some ice cream – the list goes on and on. All very innocent and wonderful memories for the families involved, I’m sure. But this brings to mind the fact that there is a huge amount of responsibility on us as parents to be mindful of not only how we teach our kids to behave socially on a day to day level, but also how we utilize their information within the online world.
It is up to us, as responsible parents, to decide whether or not it is appropriate for us to post information about our children. It is our duty, I believe, to act in their best interest. I simply mean that the very act of posting images, videos or anything else of our kid’s lives (no matter how seemingly innocent) onto a social networking site carries with it a possible price.
Imagine, if you will, being a teenager of the future and you start searching the internet and decide to look yourself up on Google. Suddenly you stumble across countless pictures and videos of yourself as a kid that your parents posted of you on a social networking site. These images and videos are publicly available for all to see. They are now owned by some faceless organization that owns the right to every image of you as a child (remember your parents no longer own those images once they posted them to Facebook). How would you feel about this?
This is an open ended question and there is no absolute right answer. Different individuals will feel very differently about how they would react to this. Nonetheless, I think it’s very important to consider this question. To take a moment and think about the future and the data we willingly provide not only about ourselves, but others around us. I completely understand that I base a lot of this on my own personal feelings. A lot of what I say may have no weight with other individuals. Maybe the times are changing, and the veil of privacy is truly a thing of the past. I cannot and do not speak for everyone. This article is meant simply to act as moment of pause and reflection of what we do as parents. To hopefully consider something we did not consider before.
Let me close with this – we do not and cannot know who will own the information we post to a social network in twenty or fifty years. Because of this fact, we must be Information Guardians for our kids. We must act responsibly on their behalf. Again, posting about ourselves is one thing – we carry with that our own responsibility. On the other hand, when we post about our kids, I believe it becomes something entirely different, something with an even greater amount of responsibility. I think this is something that has not really been considered that much. So please, regardless of your choice on how to handle this, just take a moment and think about your kid(s) before clicking the ‘Post’ button.
My wife and I completely understand we may not have 100% control over every aspect of this, but as parents we are trying to do what we think is in our kid’s best interest. Again, it’s different for every parent out there. Good luck and godspeed with your own parenting
Anyway, cloud security is tough for a lot of reasons, not least of which is because you, like me, probably only understand the basics of what you interface with in the cloud – the controls the cloud provider allows you to see. This lack of depth of management introduces many security related challenges. Having said that, let’s explore:
1) Control Panels
Control panels are simultaneously the best and worst aspect of a given cloud provider’s offerings. They can enable you to do really great things or handicap you by not allowing enough fine-grained control. They can enhance the security of your slice of the cloud infrastructure and then cut it off at the knees, sometimes with both in the same feature. If a control is very granular and allows you to be very custom, you can make spectacular infrastructure decisions while at the same time easily forgetting to make some necessary security adjustments. If the controls aren’t granular enough, i.e. the provider made those decisions for you, then that can limit your abilities. In general, control panels are a double edged sword…and a balancing act…usually done while juggling razor-sharp ninja stars – not necessarily an easy job.
2)Uptime/Downtime
This is a problem, but not necessarily a problem specific to the cloud. It is a problem specific to computers. You will have downtime no matter where you host your services or what you do to prevent it. (Author’s Note: I have spent a large portion of my company’s overall budget to avoid downtime. It still happens, it’s just mitigated better) Some will argue uptime is worse in the cloud than if you hosted it yourself, but depending on who you are this may or may not be true. It just depends on how much trouble you want to go through to deal with the uptime of critical assets – or rather how much you want to spend to achieve a good uptime ratio. In the public cloud, the cost is spread around so it is naturally a bit cheaper. If you are doing it yourself then you are footing the entire cost. Simple equation really: how much downtime can you afford? Be careful here, the cloud is not always cheaper than doing it yourself, check out the Cloud is Cheap section.
Side note: While I was editing this post and getting its accompanying presentation ready Amazon Web Services had their big storm related outage and one of our apps was in the wrong zone at the wrong time, bringing it down for about 30 hours total. Luckily, it was a weekend so no one was using it. But still, there is no greater feeling of helplessness when your service is down and completely out of your control. I’m like this whenever my phone or data center provider have problems too so I’ve gotten used to it. A bottle of pepto and lots of patience is required for any sort of cloud endeavor.
3) Access Control
There is a “myth” that you have no concept of access control in the cloud. In most cases, at least with the reputable providers, you do have a decent ACL system. In Amazon you can set up roles and assign folks to groups, not half bad. The problem comes in when you actually MEAN access control. With very few exceptions you are running on shared resources in the cloud, not dedicated equipment. If you were under the impression it wasn’t shared, perhaps we need to revisit the definitions of cloud computing again (see cheatsheet). In theory, this sharing could cause some problems. All cloud providers use some sort of virtualization – what it is, what vendor, what tech is completely irrelevant – there is at least some risk of someone being able to break out of the virtualized jail and see your data or perform some other malicious activity. This is a very important risk, one to at least mitigate with encryption on both the transport and rest layers. Honestly though you should be doing this in any virtualized environment, it just makes for very good practice. Dare I say, it should be a best practice.
4) API (Good and Evil)
I have a love/hate relationship with APIs (Application Programming Interface). I love them because they can make so many things so easy to do, at least the good ones. I hate them because they can often change without notice (depends on the provider) and they give providers yet another avenue for charging “micro payments”. Micro payments sound good in theory but they do add up. Amazon, for instance, wants you to send email through their messaging API and charge you per-message. I haven’t paid for email per message since…well never. They claim it increases reliability and makes it better than sending directly from your EC2 instance. I find that claim a little suspect but it’s their jail and their rules. Another big issue is if you buy the theory that the cloud is a jail for your apps then APIs are the bars. They can really lock you into a provider. I despise vendor lock-in almost more than anything. There are cloud abstraction layers (such as Delta Cloud) but honestly I’ve never used them and really it is just adding another layer of complexity. Deploying your cloud app is not like dating, it’s more akin to marriage and divorcing it is hard, so remember to do your homework.
Of course there is also the whole security angle of APIs that you have to consider. Is the transport encrypted? Is the data reliable and untainted? Are you sure you are pulling the correct data? These considerations cannot be overlooked, even in a cloud environment where you are encouraged to “trust the system.” Buyer should always beware.
5) Firewalls Are Dead….Well Sorta
Real firewalls in the cloud are a great idea, most reputable providers at least have basic packet filtering available. But wouldn’t it be great to have a full-on firewall up there protecting your data? It is possible! Check Point, Cisco, and probably many others have full firewall instances (some with IPS) available for you to deploy. I think it’s a good idea and all, but I struggle to see how many people will actually use it. I mean, people hate firewalls as it is for some strange reason (I blame willful ignorance). But now not only do you have to pay for the firewall license, but you will have to pay for the CPU time to actually run it. Obviously we’re talking about a public cloud here, if you have your own private cloud already you just need the license. Regardless of where you have your cloud, you should probably have a firewall to give you tighter control.
6) Redundancy
One of the ways the cloud sells itself is on it’s instant super-redundancy and availability. As we’ve learned, even the large cloud providers are susceptible to downtime. As I discussed above in the uptime/downtime section, downtime just happens. The more or less instant redundancy marketing line is somewhat true, you can absolutely load balance your apps across multiple Amazon EC2 instances across multiple availability zones. But this isn’t some magic feature you just get, it costs extra. Don’t be fooled by those sort of marketing tricks.
As I wrote this section I began thinking about the abstraction layers discussed in the API section and started to wonder: is it possible to build an application that was hosted then load balanced across multiple cloud providers. I bet it would be but now brain hurts (and I suspect if I did that my wallet would be hurting too). Anyone doing that out there?
7) Encrypt Early, Encrypt Often
Before Amazon introduced the ability to encrypt in their storage offering (S3) I wrote a tool called logsup that would allow me to automatically rotate (through logrotated), encrypt (through GPG) and upload (to S3) old log files. It takes some metadata and writes it up to Amazon’s SimpleDB service so I can easily search and figure out what data was in the encrypted log files. Of course I thought I was really clever when I wrote it, but then four days later Amazon introduced their encryption feature that has better key management than GPG. Eventually I’ll rewrite logsup to take advantage of that, but until then I will keep stubbornly using it.
There are two primary lessons to take away from my logsup adventure. First, you should always encrypt sensitive data before it leaves your control. Second, you should always write a receipt for that data so you know where it came from and at least abstractly what type of data it contains. This will allow some piece of mind that your data is safe and that you will be able to find it later when you need it most.
Depending on the deployment, encryption also offers some protection against snooping tenants when you’re using cloud storage or other less private storage. It is not a replacement for strong access control or larger security precautions but it can provide a decent layer of protection against basic prying eyes.
Side Note: After coming back to this blog post a few months later, The NSA has become a regular topic of discussion. We are now aware of the NSA eavesdropping on the internet and weakening cryptographic systems. You can protect yourself from NSA snooping by encrypting your data. That way you’re much better protected than if you were communicating plainly.
8) Cloud Is Cheap!
There are a number of different types of cloud service (see cheatsheet) and the whole “cloud is cheap” myth only holds up for a few of them. Cloud can be very cheap when you’re discussing Software As A Service (SaaS), e.g. Google’s Apps for Business is only around $5 per user per month per year or $50 per user per year. You as an independent person or company cannot run a mail server for any amount of users for less than that cost per user. The hardware alone would set you back more, so it makes very good financial sense to run your email in the cloud. Whether it makes good common sense is a different story, but I think it is becoming more generally accepted as a best practice to outsource your email, even if only for the cost benefit.
The story gets a lot murkier when you move away from software into infrastructure or platforms as services. Depending on your needs and usage this can be way more expensive than running your own stuff or much cheaper, again it just depends on the needs. If you want to build a redundant platform or infrastructure with off the shelf hardware and Linux, prepare to pay for the privilege. It really depends though, I’ve seen analyses where it is cheaper to do it yourself, so as with all advice your mileage may vary.
9) Logs In The Cloud
There is a very persistent myth that you can’t get proper logging for your cloud applications and this is patently untrue. An EC2 instance is just an operating system tweaked a little bit to run on Amazon’s infrastructure. There is nothing magical about it, it is the same as if you were running it on a VMWare cluster and you can get your logs from there just fine right? Right? Of course you can, your application and OS will log the same as if you were hosting it locally. You could even put a log collection server in the cloud if you were so inclined or use something like Loggly or Splunk Storm and have your log analysis up there too.
When you start discussing SaaS or IaaS the story gets a little darker as you are not necessarily buying access to the logs – you are outsourcing it completely so the providers simply do provide that same level of visibility. I guess that is their call, you just need to be prepared. As we discussed in the control panels section the type of visibility you get will depend on how well the control panel is architected. A lot of providers will give you access to logs for your specific instance (if only to cut down on support calls), but others do not. It is simply a matter of asking the right questions and, again, doing your homework.
10) Service Level Agreements (SLA)
When you are choosing a cloud provider be sure you actually read their SLA. This is basically the agreement that spells out your interactions and expectations when dealing with your provider. This is the document that will basically tell you how much uptime to expect (they all say 99.999% uptime, they are almost all deceitful) and more importantly what sort of compensation you will get if they violate their SLA. Expect a lot of lawyer-speak here, so if you are putting something really critical in the cloud have your lawyer read it over. You won’t have a lot of negotiation room usually, but at least you’ll be able to plan for the possible risks with a clear head. Typically an SLA will link out to a document describing security precautions taken by the provider to protect your data. This can be crucially important to have so you can effectively add in tech to fill the gaps, though sometimes these documents tend to be a bit vague.
While this list wasn’t entirely security focused, the intent was to help guide folks looking into cloud deployments for their organizations and how to better prepare for the differences in securing those environments. Hopefully it met those goals and more. Please send any feedback on this list to [email protected].
This machine had dropped its wireless connection inexplicably. Wired connections were fine, though. On Windows, there are myriad reasons this can happen. Sometimes proprietary wireless management software (intended to “help” users manage their wireless connectivity) can actually break functions. I’ve seen instances of Dell’s wireless software conflicting with Windows’ native network stack, rendering the card inactive.
Sometimes, there’s a driver problem. An erroneous update, a missing update, an incorrect driver version… Perhaps the machine received a Windows update that interfered with the currently installed drivers.
This wasn’t a rare-form specialty wireless adapter by any stretch, just a run-of-the-mill common chipset USB dongle. Complete removal and reinstallation of the device and its driver software, application of any and all missing Windows updates, still no go.
At this point, the card would connect but would not successfully query for a DHCP address. All other hosts on this network queried and received addresses without issue. No filtering or blocked hosts in the router (also acting as DHCP server), either.
At this point, no reason to not be working, but still not working.
REBUILD THE TCP STACK.
netsh int ip reset C:\resetlog.txt
This effectively reinstalls the TCP stack on the machine, and gives it vanilla settings. For an experienced Windows admin, this whole process is nothing new and it’s by no means a taxing process. It is however annoying, and once you become familiar with OS alternatives, it is revealed as unnecessary.
RELATIVE 2
I installed an Ubuntu system for them two years ago when a hard drive died. After setting up some preferences for email and browsing (and one snafu with a Facebook interface problem), I’ve not had a single support issue on this system since it was installed. As we all like to say, “It Just Works.” (Of course, this is separate from the whole Gnome3/Unity debate, so we’ll talk about that later.)
On this GNU/Linux machine all drivers were included upon installation; try that with a purchased copy of any Windows version. People often claim driver issues as a roadblock issue for Linux, but in my experience that has rarely been the case. Only one machine of mine ever had significant issues, and that was due to an older ATI graphics card and an infamous Broadcom BCM-4318 wireless card. Both of those have now been addressed in later kernel releases.
I use this rather simplistic example to relate my over-arching experience contrasting Windows and Linux usage. Ask yourself how much time you spend up-keeping your machine in order to get work done, vs. how much time you spend actually getting work done.
You know this type, he’s the one that doesn’t talk a lot in meetings because you should just magically know what is on his mind, he also hates to be asked questions. Yes this guy just assumes everyone knows the same things as he does so tagging doesn’t naturally suit him. The problem of course is when the Undertagger is on vacation or not involved in say, the monitoring of whatever systems he is responsible for. I’ve dealt with this type for many years and the only way to deal with him is to ask as many questions as you can and tag for him. Sounds like a horrible solution, and it is, however you can’t change people and they seldom change on their own.
The problem the Undertagger is causing is a big problem throughout all of IT and that is the “silo” mentality and today’s mostly holistic approach to things really confounds the Undertagger and systems like Splunk make their heads explode because they’re really very happy in their bubble. We have to pull the information out of the Undertagger and get it into Splunk using any means we can find. Personally I try taking Undertagger out to lunch and getting information that way when they’re least expecting it, failing that I just badger them until they tell me what I need until I go away. I will then happily do all the tagging for them based on that.
The Midtagger
The Midtagger is a rare beast, most people fall into one of our other two categories. This type though is often “too busy” to do the tagging but always “means to” and just never does. You can usually defeat the Midtagger by offering ways in which tagging would make them less busy. This can usually be done by showing them how adding knowledge to Splunk can save time with support calls and unrelated questions. People who “get” Splunk are generally data driven and this method does work.
The Overtagger
This is probably the most common type, the Overtagger *cue dramatic music* and wow can this one be tricky. They tag EVERYTHING, host, source,sourcetype, destination and on and on and on, usually with overlapping tags or such in depth detail that the tags are bigger than the data itself. On one hand you don’t want to diminish their enthusiasm but they can’t keep tagging everything in sight either and certainly not with so many levels of detail. Tags should be quick hits that help describe groups of things and not just one thing, not usually anyway.
The Strategy
This is where we’ll talk strategy and not just about a specific type, these strategies should prove effective across all of our tagger types. The first part of our strategy is glaringly simple, have a plan. I know, I know, sounds really easy right? An effective tagging plan should answer the basic questions of “what should I tag, how should I tag and where should I tag it?” These questions can be answered with a simple one page tagging cheat sheet that data wranglers can use when they’re getting data into Splunk. Want some examples? I knew you did.
TAG HOST
TAG BY GROUP OR FUNCTION
A host tag should identify the host by its larger group or function. If you have a group of web servers that all do basically the same thing and that is run the corporate website you could tag the hosts with “web_servers, corp_site” or however you choose to designate it.
TAG BY CRITICALITY
Another way to tag hosts is by their criticality and it is not exclusive of the above examples. If a system simply cannot ever go down or have a problem and if something bad happens then everyone should be woken up. A “critical” tag is the way to do this. I find doing this by host is a great way to do this. A more broad example would be a set of tags that say “web_servers, corp_financial_reporting, critical”. We can then construct a Splunk alert that escalates as needed.
TAG SOURCETYPE
TAG BY APPLICATION
This is much simpler, you can tag sourcetype based on whatever application it is. I use this a lot with custom applications. For example, if you have a custom java application, you could tag this sourcetype as the common name for that application so it is instantly identifiable.
TAG BY UNKNOWN
I also like to tag sourcetypes that I don’t fully understand so I come back to them later. I usually use an “unknown” tag for that but whatever your preference is will probably work.
FINAL NOTE
These are just a couple of ways I use Splunk tags and these will hopefully get you thinking about creative ways to use them in your organization, I find them a very powerful element of Splunk but not always an appropriately appreciated one. I might also be categorized as an Overtagger in some cases but that’s okay, I’ve learned to live with it. The important point is to make sure you are using the Splunk knowledge system to its fullest potential and tagging is a huge element of that.
This entry was posted in Code, General Cyber Security, Splunk by Bill Mathews.
That said, one of our head system administrators came up with the idea of a constant display that could render an up-to-date Icinga feed in real time, and this seemed like an appropriate excuse to try out the much lauded “Raspberry Pi” in a work appropriate context. The process was made much easier by way of the “New Out of Box Software” (NOOBS) suite which is a piece of software that can be flashed to the SD card and creates a bootable file system for the device. From that point on all we had to do was pick a distribution and follow the initial setup prompts, but a few issues popped up along the way.
One of the initial problems was the default keyboard selection as the NOOBS system selects the UK layout instead of the US layout on boot. While a seemingly small issue, it did cause a number of problems before we caught onto the setting conflict. The second issue was a lack of mindfulness during the initial configurations. This stemmed from the constant back and forth that arose out of trying various solutions, and really did reinforce the need to keep a clear head during system setups.
After making it through those hurdles we then ran into the issue of over complexity, which arose out of depending upon too many varied sources for assistance. Many others have had their own solution for a Raspberry Pi setup like this, but in each case they all had points of divergence that were not directly applicable to our situation. These tended to skew our setup process and led to a number of unpleasant failures, but as a result we can now present our own iteration of a Raspberry Pi kiosk setup.
Step 1: After the initial setup, you need to update the packages and chosen distribution on your Raspberry Pi. This can be done by entering the following at a terminal session on the Pi in question.
sudo apt-get update
sudo apt-get dist-upgrade
Step 2: You should then install chromium, Xscreensaver, and Xserver utilities with the following command.
There are a number of Raspberry Pi kiosk tutorials out there that recommend the usage of Midori, the default browser on the Raspberry Pi. We had a number of issues with this browser and cannot recommend its usage due to the number of inherent limitations that it has.
Step 3: Also be sure to change the time to the proper settings for your time zone. This is important as some secure sites may enforce the usage of correct time and date stamps. Below is an example of the proper format for the “date” command.
sudo date -s "Thu Aug 9 21:31:26 UTC 2012"
Step 4: Now bring up chromium, click the “store” option on the default page, and search for either “Auto Refresh Plus” or “Easy Auto Refresh.” Either of these free products will allow you to select custom time amounts for the refresh period, and are rather easy to use as well.
Step 5: From this point you have a number of options. You can either save the Icinga address of choice in chromium under “customize → settings → On startup → “Open a specific page or set of pages” → “Set pages,” or edit the LXDE settings for the Raspberry Pi at “/etc/xdg/lxsession/LXDE/autostart” with the following information.
* The kiosk mode for chromium can be somewhat troublesome to use, and has been known to be glitchy depending upon the distribution. An alternative to that would be to boot without kiosk mode using: “@chromium http://dashaddress.domain.tld # Chromium” which should start Chromium up on boot in windowed mode. That said, try them both to see what works best for your situation.
Migrating from Django User Profiles to Custom User Models
I’ve worked up a full solution for migrating from Django <1.5′s User + Profile models to 1.5′s custom User models without destroying all the users on my site. This article will explain how to do the migration while preserving all your users, group memberships, and permissions.
You will first need to create your new model. The get_profile function and user property allow your new model to simulate the old behavior, while logging any function that still uses the old profile code. This assumes that the logger is configured and that your profile model had a user property.
from django.contrib.auth.models import AbstractUser
And here are the forwards and backwards migrations. You’ll need to use replace “myapp” with the real name of your application. If your user model isn’t called myuser, you’ll need to change “myuser_id” as well. This will rename the contenttype model so that existing generic relations will continue to work:
Something like this ought to do you for the data-migration. Be sure to include all fields you want to copy
def forwards(self, orm):
# Write your forwards methods here.
# Note: Remember to use orm['appname.ModelName'] rather than
"from appname.models..."
for u in orm['myapp.MyUser'].objects.all():
p = orm['myapp.Profile'].get(user=u)
u.parrot_count = p.parrot_count
u.save()
def backwards(self, orm):
"Write your backwards methods here."
for u in orm['myapp.MyUser'].objects.all():
p, created = orm['myapp.Profile'].get_or_create(user=u)
p.parrot_count = u.parrot_count
p.save()
Now that we’ve moved the database tables and copied the data, it’s time to throw the switch. In your settings.py you’ll set AUTH_USER_MODEL = 'myapp.MyUser' and remove AUTH_PROFILE_MODEL ='myapp.Profile'.
Watch your logs for calls to get_profile, and grep your code for instances of user.get_profile()so you can update them to just use MyUser.
One last thing, you can remove the Profile class from your code, and do one more schemamigration to drop it from the database.
The check we are going to look at will return memory from a Cisco Switch. We will then make sure that there is sufficient free memory, or it will go into a “warning” or “critical” state. The check itself is written in bash because I like bash. You can write the same thing in python or perl but your milage may vary. The basic steps are:
1. Write a script that checks over SNMP
2. Define a command to run that script
3. Put that command into a service template
4. Apply that template to a host
1. The check script
Create a file called check_cisco_memory
A she bang and a few comments to get started:
# !/bin/bash
# check_cisco_memory
# Description : Check the free memory of a Cisco device
# Version : 2.0
# Author : Dru Streicher
# Licence : GPLv2
# A lot of this code is based off a memory check by Yoann Lamy
We are going to set some global environmental priorities here:
# Commands
CMD_BASENAME="/usr/bin/basename"
CMD_SNMPGET="/usr/bin/snmpget"
CMD_SNMPWALK="/usr/bin/snmpwalk"
CMD_EXPR="/usr/bin/expr"
# Script name
SCRIPTNAME=`$CMD_BASENAME $0`
# Version
VERSION="2.0"
Nagios only returns 4 different status messages. We declare all four here:
# Plugin return codes
STATE_OK=0
STATE_WARNING=1
STATE_CRITICAL=2
STATE_UNKNOWN=3
These are the OIDs that we are going to use. This will return the used memory and the free memory:
# OID's
OID_USED_MEMORY="1.3.6.1.4.1.9.9.48.1.1.1.5.1"
OID_FREE_MEMORY="1.3.6.1.4.1.9.9.48.1.1.1.6.1"
Then we set the default state. Always set it to unknown that way if there are any issues your check will come back as unknown:
Great now we know our check is working and the host has plenty of memory. Now we need to make this into a service check in Icinga.
2. Defining the check command:
The purpose of the checkcommands.cfg is to allow the check scripts we write to be used over and over. The checkcommand.cfg also allows us to pass variables. In our case we want to pass the warning and critical variables. So we need to define a command called check_cisco_memory and pass some variable like this:
Create a file called checkcommands.cfg
By using the $_HOSTSNMP_COMMUNITY we can store the community string somewhere else. The $ARG1$ and $ARG2$ will be variables that we can pass on later by the hostgroup template or on a per host basis.
3. Putting the checkcommand into a hostgroup template:
Say we want all of our ASA firewalls to use this check. We would do something like this…
Create a file called cisco-asa.cfg
###--- HOST GROUP DEFINITION
define hostgroup {
hostgroup_name template_cisco-asa
alias Cisco ASA Firewall
}
###--- SERVICES
define service {
use generic-service
name cisco-asa-memory
hostgroup_name template_cisco-asa
service_description free_memory
display_name FREE MEMORY
check_command check_cisco_memory!10!5
}
The line:
check_command check_cisco_memory!10!5
is where all the magic happens. The ! passes the variable to the checkcommand so in our case the !10!5 will take place of the $ARG1$ and $ARG2$ on this line of the checkcommand.cfg
Now that we have everything setup, we need to actually put the service check onto the host. Before we can do that, we’ll need to do two things: set the community string and add the service check itself.
Create a host.cfg file
###--- HOST DEFINITION
define host {
use generic-host
host_name fireball
hostgroups +template_cisco-asa
alias Cisco ASA
address 198.162.1.1
_snmp_community sw0rdf!sh
}
Now the snmp community string will be passed to the checkcommand very much like the $ARG1$ was passed.
Reload Icinga and behold! There is your shiny new memory check, all done without an agent.
