The media is full of security horror stories of company after company being breached by attackers, but very little information is actual forthcoming on the real details. I hope that those who unfortunate to suffer future breaches are equally generous enough to share their logs and lessons learnt for the rest of us to understand and adapt for our own systems. The attackers share their tips and tricks, as anyone looking at the uploaded chat logs to public sites like pastebin can attest to this. We need the very smart folks looking after the security at theses attacked companies, that can step up, to take time to write up what really happened is going to make it accessible for the rest of us to learn from. Seeing the events of an attack in recorded in log files is a terrible, yet beautiful thing. To me it means we, as defenders, did one thing right since detection is always a must. If the attack couldn't or wasn't blocked, then being able to replay how a system was compromised is the only way forward to stopping it from occurring again. As always, if you have any suggestions, insights or tips please feel free to comment. Chris Mohan --- Internet Storm Center Handler on Duty |
Chris 105 Posts ISC Handler Jun 20th 2011 |
Thread locked Subscribe |
Jun 20th 2011 1 decade ago |
The key mistake made at Barracuda is someone switched their web app firewall into non-blocking mode during maintenance and never switched it back to blocking mode. Based on their experience, we added an alert to ours to email several people when ours switches mode.
Maybe we could begin compiling some tips as to WHAT to look for in logs, not just "do you look at your logs?" Here are a few to start with: 1. Know what traffic is permitted INTO your network. Set a firewall filter to display all accepted traffic from non-approved sources. This can alert you to someone changing a rule and not letting you know to a rule having unintended side effects. 2. Have a very restrictive outbound rule and then monitor all traffic trying to exit the network and getting dropped. This usually will be some misconfigured Windows system but occasionally can be a malware-infected system. 3. Make sure all of your systems sync to an internal time server. Then restrict access to Internet time servers. Monitor for attempts to sync time via the Internet from unknown sources. We've detected unauthorized consumer wireless access points this way. Those home routers usually try to time sync to the Internet, so that can be an indirect way of detecting them. More likely it's another misconfigured Windows system, though. |
Anonymous |
Quote |
Jun 20th 2011 1 decade ago |
I'd just like to mention that log file monitoring doesn't have to cost an arm and a leg. One excellent freebie is OSSEC (http://www.ossec.net/), which monitors a large variety of logs and can be configured to report on "interesting" things in a GUI interface or via email.
|
Anonymous |
Quote |
Jun 20th 2011 1 decade ago |
I would recommend a Log Correlation application like LCE by Tenable. This application along with SecurityCenter provide highly configurable alerting and log monitoring across multiple platforms. www.tenable.com
|
Hugh 1 Posts |
Quote |
Jun 20th 2011 1 decade ago |
I would hesitate to recommend Tenable's Seucirty Center. For an enterprise of any size and/or complexity it is a very costly solution. Further, I know of a particular government deployment that is experiencing quite a bit of trouble conducting routine vulnerability scanning; granted, with a less than desireable deployment architecture - but the Security Center product is not living up to the hype.
|
Kilroy 4 Posts |
Quote |
Jun 20th 2011 1 decade ago |
one word: Splunk
There's a "free" limited version too. |
Kilroy 4 Posts |
Quote |
Jun 20th 2011 1 decade ago |
The problem is a lot of support people have too much on their plates. Being a support person who handles the back end and help desk there is zero time to deal with security If you have 20 servers, 6 satellite offices and a long help desk queue. Plus an administratition that does not understand technology other than the expense. I am sure I am not alone. I also suspect this is the reason many organizations get hacked.
|
Kilroy 1 Posts |
Quote |
Jun 20th 2011 1 decade ago |
@Overwhelmed - I know the feeling, the key is automation/scripting of log checking. Although you'll initially be trawling through screeds of legitimate logs, with a small amount of filtering it's fairly easy to get it down to the point where only significant logs are getting through to you. It's very easy to fall into the trap of filtering too broadly though. In the grand scheme of things 20 servers don't really generate that many logs.
It's time well spent - after "expense", management also understands words like "breach" and "compromised" fairly well and if you get put on the spot after an incident you'll feel like a complete idiot if you try to tell them you didn't have time to implement some rudimentary log checking, and you'll be a lot better armed to come back and say well, we did everything in our power right and we still got owned, but here's what we can do better next time. |
Kilroy 12 Posts |
Quote |
Jun 20th 2011 1 decade ago |
Hi, If anyone is looking for a place to grab Jason Fossen's isascripts.org/scripts.zip file, a copy of this zip file has been posted up at this site with permission:
http://www.jigsolving.com/jigsovling/lost-vb-scripts-jason-fossens-isacripts-org-script-zip-file-can-be-found-here Cheers |
Anonymous |
Quote |
Jun 10th 2017 5 years ago |
Sign Up for Free or Log In to start participating in the conversation!