I just looked at my blog. I can't believe it's been so long since I've posted. I suppose it's hard when you see so many smart people posting stuff, I'm not really sure I ever have anything new or creative to add. I guess I'll have to force myself to post something on a regular schedule, maybe something useful will come of it.
I'm currently reading Mastering Regular Expression and I'm still in the first third, I can't post a complete summary yet but so far so good. I've worked with regular expression a lot in the past since I've done a lot of Logstash work, but I've only picked up bits and pieces as I've needed to so it's nice to get a more well rounded view of using regex.
I'm also reading Christopher Hibbert's Days of the French Revolution, which is also pretty interesting. My interest in the french revolution was spurred on by the Michael Duncan's excellent podcast, Revolutions, which I can't recommend highly enough. I always hated history in school, but now I can't get enough.
There's more, but that's all for now.
Saturday, May 30, 2015
Saturday, November 12, 2011
The long overdue online banking & security post
I've been meaning to post this for some time.
Recently (or ... not so recently) I was asked by a family member what the best/most secure way to conduct online banking is. This is kind of a tricky question, there's no quick or easy answer. The more secure you want to be while managing finances (banking, credit card accounts, etc.) the more work you have to put in it. There's no "secure/insecure" state, it's more about balancing the risk and convenience. I believe the biggest threat to accessing your financial accounts with your browser, at least the threat that you can do anything about, is the spread of malware designed to surreptitiously collect your bank credentials, or actually conduct transactions against your account without your knowledge.
I'll list a few options and spell out the associated risk as I see it.
There are some rules of the road for being safe online. The typical ones still apply: Keep your A/V updated, scan your system once in a while, etc. I will say that the folks writing and deploying malware are ahead of the A/V venders right now, so this isn't a silver bullet. some other things apply:
Related:
Recently (or ... not so recently) I was asked by a family member what the best/most secure way to conduct online banking is. This is kind of a tricky question, there's no quick or easy answer. The more secure you want to be while managing finances (banking, credit card accounts, etc.) the more work you have to put in it. There's no "secure/insecure" state, it's more about balancing the risk and convenience. I believe the biggest threat to accessing your financial accounts with your browser, at least the threat that you can do anything about, is the spread of malware designed to surreptitiously collect your bank credentials, or actually conduct transactions against your account without your knowledge.
I'll list a few options and spell out the associated risk as I see it.
- Most secure: Don't do online banking or shop online. I guess this is obvious? But if you manage accounts or buy things online you're accepting some risk.
- Pretty secure: Use any of the widely available linux live boot CD's out there to access your online accounts. You can even further reduce the risk of hardware-based threats by having a purpose built system for accessing online accounts - and ONLY online accounts. Home users who boot a live CD (link) (link) to access their accounts are pretty well protected, but business users should consider a purpose built system for accessing online bank accounts (again - only online bank accounts, not email/browsing) that has very strictly controlled physical access due to the increased risk of hardware keystroke loggers being placed on their system. Business accounts in the U.S. don't have the same legal protections as personal accounts, so greater care should be taken to secure these accounts. There are plenty of examples of why you should exercise more caution when dealing with business accounts online: link
- Modestly secure: Using a custom user profile for online banking. Creating a user account specifically for online banking can be a fairly safe option, but only given a few conditions. Make sure your system is clean of all viruses and malware on a regular basis. Make sure the banking profile is highly customized so that it can't/won't be inadvertently used to start browsing random web sites. Most importantly, ALL accounts used for normal access (web, email, etc.) on this system must be limited accounts. The risk of malware planting itself on a system and escalating from a limited user context to an administrative user context is pretty low if you are smart about your browsing. More on this later.
- Not so secure: Using a web browser that allows you to have multiple profiles, add a custom profile for just online banking. Having a unique profile just for banking can mitigate some threats, but this won't stop a lot of the malware that's loaded through phishing or other social engineering exploits; these will often run outside of the Browser and will still be active regardless of what profile is running on the browser.
There are some rules of the road for being safe online. The typical ones still apply: Keep your A/V updated, scan your system once in a while, etc. I will say that the folks writing and deploying malware are ahead of the A/V venders right now, so this isn't a silver bullet. some other things apply:
- Keep your software updated. Windows patches, Adobe updates, Java updates, Flash updates, etc. Sometimes this can be a bit daunting - free for personal use, Secunia's PSI (link) software can help.
- Don't use an admin account for everyday use. All of your general purpose accounts should run under a limited user context. I can't understate how important this is; Admin credentials should only be used for very specific tasks.
- Keep an eye on your financial transactions. Some banks will let you set up alerts, etc. for types of activity on your account. Check this out.
- Don't use debit cards. Debit cards are evil. Use a credit card for all of your online transactions, and pay that off monthly. If you can't wrap your head around that, at least set up an account specifically for using a debit card and keep a low balance in it. Don't have it automatically draw from other accounts in an overdraft situation. But really - don't use debit cards. If you're a U.S. citizen you have some good protections against credit card fraud. These protections aren't as strong for debit card transactions, so if you do use a debit card you should know what your banks policy is on disputed transactions and what the process is to dispute a transaction, it's tough to work this out when you've just discovered that your bank account has been emptied.
- Firefox + noscript + adblock plus = good. This is a major hassle to set up and adjust to, but once you do it's going to protect you pretty well.
- Add another layer to protect your browser - check out Sandboxie. (link). Sandbox your browser, and make an individual sandboxed browser session just for doing your online banking.
- DO NOT REUSE PASSWORDS. Keep your passwords unique. There have been multiple examples of password reuse getting folks in trouble on social media sites (Gawker) - it isn't a huge leap to assume that these credentials from a blog/social media site/etc. could be used to access an online account or online commerce site such as amazon. To help keep track of all those passwords, don't be afraid to use a password manager like lastpass or keepass. If you're using an online service like lastpass you shouldn't have your most sensitive accounts in there, and don't put the email you sign up for the service with in there.
- Use passphrases. Don't worry a bunch about complexity - that's old school thinking. Use 15+ character passphrases. Anything else you read is wrong. I can't make it any more clear than this: XKCD
- Don't trust sites that mail you your password. Passwords should be salted (link) and stored as a hash value (link). If a site mails you your password, it's stored in plain text. bad.
- Be wary sites that limit your password length, or prevent you from using certain characters such as + = ` ", etc. A password hash can be generated from any length password using of these characters. I do believe some limits may be used by sites to prevent attacks like SQL injection (link if you're really interested), so I won't say avoid these sites - but if it's a site that holds or processes sensitive information you may want to get more details about the security of the system before using it.
- Don't answer security questions with normal answers that show up on google searches (Mothers maiden name, etc.) or any social networking sites, or anything else that's easy for somebody to work out.
- NEVER click on banking/finance, email, etc. links in your email. Crafting an HTML email with something that looks dead on like what your bank would send you is pretty trivial. Even the sites that you can be directed to can be pretty convincing.
- If you get a call from your bank about some issue with your account, get a ticket number (if applicable) and call them back on a number listed on their web site.
- Don't access your accounts when connected to a public wifi service, untrusted network, etc.
Related:
Thursday, December 16, 2010
snort's flow-ip-file perfmonitor output ....
I've been spending a lot of time profiling snort performance lately as we try to wrench every last bit of performance out of our busier snort sensors. We have submitted a request for updated hardware, but the current environment has to be kept limping along as the refresh request winds its way through the byzantine maze of a typical government budgeting process.
One thing I've learned during this process is that there's not one real definitive source for tuning Snort. Information is found from a variety of sources, and experience is essential to really understanding the numbers that Snort spits out. This is probably easy for somebody who's really spent a lot of time smashing Snort, but as somebody without much experience dealing with sensors that are being pushed to their meager limits I have to honestly admit that there's times I'm scrambling to figure out exactly what all the performance data is telling me (is broken).
I was looking at ways to reduce the amount of known benign traffic a particularly busy sensor was examining, so I enabled the flow-ip and flow-ip-file options in the perfmonitor preprocessor section of snort.conf and restarted the Snort service. After a few hours I disabled the option, restarted snort, then imported the resulting file into excel and thought ... "now what". The Snort Users Manual was sort of vague (and a bit misleading), ultimately the source code provided the answer. Without further delay ...
(using the excel column headers as they map to field 1,2,3, etc. of the snort flow stats cvs file)
A - Host A
B - Host B
C - TCP Packets A->B
D - TCP Bytes A->B
E - TCP Packets A<-B
F - TCP Bytes A<-B
G - UDP Packets A->B
H - UDP Bytes A->B
I - UDP Packets A<-B
J - UDP Bytes A<-B
K - Other Packets A->B
L - Other Bytes A->B
M - Other Packet A<-B
N - Other Bytes A<-B
O - TCP Sessions established
P - TCP Sessions closed
Q - UDP Sessions created
Armed with this knowledge it was easy to identify chatty hosts that were safe to whitest, which will hopefully reduce the number of mbit/s Snort was having to process. I'll know for sure tomorrow when I dump the snort perfmonitor stats and check how mbit/s (app) is trending.
Happy tuning ...
One thing I've learned during this process is that there's not one real definitive source for tuning Snort. Information is found from a variety of sources, and experience is essential to really understanding the numbers that Snort spits out. This is probably easy for somebody who's really spent a lot of time smashing Snort, but as somebody without much experience dealing with sensors that are being pushed to their meager limits I have to honestly admit that there's times I'm scrambling to figure out exactly what all the performance data is telling me (is broken).
I was looking at ways to reduce the amount of known benign traffic a particularly busy sensor was examining, so I enabled the flow-ip and flow-ip-file options in the perfmonitor preprocessor section of snort.conf and restarted the Snort service. After a few hours I disabled the option, restarted snort, then imported the resulting file into excel and thought ... "now what". The Snort Users Manual was sort of vague (and a bit misleading), ultimately the source code provided the answer. Without further delay ...
(using the excel column headers as they map to field 1,2,3, etc. of the snort flow stats cvs file)
A - Host A
B - Host B
C - TCP Packets A->B
D - TCP Bytes A->B
E - TCP Packets A<-B
F - TCP Bytes A<-B
G - UDP Packets A->B
H - UDP Bytes A->B
I - UDP Packets A<-B
J - UDP Bytes A<-B
K - Other Packets A->B
L - Other Bytes A->B
M - Other Packet A<-B
N - Other Bytes A<-B
O - TCP Sessions established
P - TCP Sessions closed
Q - UDP Sessions created
Armed with this knowledge it was easy to identify chatty hosts that were safe to whitest, which will hopefully reduce the number of mbit/s Snort was having to process. I'll know for sure tomorrow when I dump the snort perfmonitor stats and check how mbit/s (app) is trending.
Happy tuning ...
Wednesday, December 1, 2010
a fresh start ... and Kippo's ssh honeypot.
Well it's been a while. A lot has changed since my last update. I scored a job doing some security engineering on a small team with a big workload, which makes me happy.
Enough about that nonsense ...
I have a home server that I've run linux on for remote access using ssh. I had locked it down pretty well. I did leave it on the default port because I did marvel at the number of brute force attempts people would slam against it daily, but I never went beyond reviewing the logs.
Lately I've been setting up a lab to do some analysis on drive by downloads and one of the things I wanted to see in greater detail were the brute force ssh logins. This is where Kippo comes in. PaulDotCom has a great video on how to use Kippo as part of a pentest, but my requirements are a bit more simple; I just want to harvest some of the target user/password pairs.
The honeypot box i've set up is an Ubuntu 10.04 VM running behind a iptables based firewall box with NAT forwarding traffic to internal hosts. This was a cinch to set up with Firewall Builder.
Before running Kippo you might want to read the instructions on how to get it running on your OS / distro. Since I am using Ubuntu, I ran the command:
sudo apt-get install python-dev openssl python-openssl python-pyasn1 python-twisted
If you haven't already figured it out, Kippo was written in Python. after you unpack it go into the kippo-0.5 folder and edit the kippo.cfg file to check over the settings.
Since I've already got NAT set up I just created a rule to forward from port 22 inbound to port 2222 on the honeypot, this also allowed me to run kippo under a normal user context. There are details on configuring your system for different scenarios on the Kippo page.
The kippo.log file should make for some entertaining reading tomorrow. Granted, "entertaining" is subjective.
Enough about that nonsense ...
I have a home server that I've run linux on for remote access using ssh. I had locked it down pretty well. I did leave it on the default port because I did marvel at the number of brute force attempts people would slam against it daily, but I never went beyond reviewing the logs.
Lately I've been setting up a lab to do some analysis on drive by downloads and one of the things I wanted to see in greater detail were the brute force ssh logins. This is where Kippo comes in. PaulDotCom has a great video on how to use Kippo as part of a pentest, but my requirements are a bit more simple; I just want to harvest some of the target user/password pairs.
The honeypot box i've set up is an Ubuntu 10.04 VM running behind a iptables based firewall box with NAT forwarding traffic to internal hosts. This was a cinch to set up with Firewall Builder.
Before running Kippo you might want to read the instructions on how to get it running on your OS / distro. Since I am using Ubuntu, I ran the command:
sudo apt-get install python-dev openssl python-openssl python-pyasn1 python-twisted
If you haven't already figured it out, Kippo was written in Python. after you unpack it go into the kippo-0.5 folder and edit the kippo.cfg file to check over the settings.
Since I've already got NAT set up I just created a rule to forward from port 22 inbound to port 2222 on the honeypot, this also allowed me to run kippo under a normal user context. There are details on configuring your system for different scenarios on the Kippo page.
The kippo.log file should make for some entertaining reading tomorrow. Granted, "entertaining" is subjective.
Friday, May 15, 2009
How not to back up servers....
from the BBC:
While I feel terrible for what the avsim owners/admins/users must be going through, the truth is there was an obvious flaw in their backup plan. Either they did not take the threat of destruction by hacker seriously or they hadn't even considered it. We don't know if the two servers were in the same room or not, which would have been another major flaw in their backup plan.
They obviously were backing up in response to the most obvious threat - a server failure - but the lack of a comprehensive plan means that avsim might be closed for good. Desigining a good protection plan requires analysis of all potential risk, failure to do so could be costly.
Flight simulator site Avsim has been "destroyed" by malicious hackers.
The site, which launched in 1996, covered all aspects of flight simulation, although its main focus was on Microsoft's Flight Simulator.
The attack took down the site's two servers and the owners had not established an external backup system.
While I feel terrible for what the avsim owners/admins/users must be going through, the truth is there was an obvious flaw in their backup plan. Either they did not take the threat of destruction by hacker seriously or they hadn't even considered it. We don't know if the two servers were in the same room or not, which would have been another major flaw in their backup plan.
They obviously were backing up in response to the most obvious threat - a server failure - but the lack of a comprehensive plan means that avsim might be closed for good. Desigining a good protection plan requires analysis of all potential risk, failure to do so could be costly.
Tuesday, May 12, 2009
FAA web apps contain more than ... what?
According to DarkReading:
Security isn't an add-on product or something you worry about later. Security is inordinately expensive and marginally effective unless it's part of the entire process, aka "baked-in". I wonder what the cost will ultimately be.
A government audit (PDF) has pinpointed more than 3,800 vulnerabilities -- 763 of which are high-risk -- in the Federal Aviation Administration's Web-based air traffic control system applications, including some that could potentially put air travel at risk.3,800? That is amazing. There must be something very wrong with their processes. The FAA has a lot of data and I get the impression they are struggling to interconnect their systems securely but 3,800? 763 high risk? I wonder how FAA/DOT's leadership will respond.
Security isn't an add-on product or something you worry about later. Security is inordinately expensive and marginally effective unless it's part of the entire process, aka "baked-in". I wonder what the cost will ultimately be.
Monday, May 4, 2009
Subscribe to:
Posts (Atom)
