A watering hole attack is an indirect attack on a victim. Rather than directly attacking the victim’s network, the attacker attacks a web site that the victim’s employees are likely to visit. Then the attacker attacks the victim’s network, via its own workstations, from that web site. A former colleague asked me how you protect against watering hole attacks, and I thought this was a good exercise. So here are some strategies for watering hole attack prevention.
As a security professional, I talk to a lot of people about common security attacks and countermeasures. I’m not always certain the people I’m talking to know what these things mean. I am almost certain they aren’t willing to ask.
I know it’s more complicated than it was when I took my Security+ exam a decade ago. The stakes are much higher now. The attacks I had to identify caused inconvenience, but someone conducting a successful smurf attack on your printer won’t get you in the headlines. Today’s attacks will.
I’ve seen a lot of gimmicky hacks to speed up Firefox, and you probably have too. But chances are Firefox ran just fine when you started, then it slowed down over time. Here’s my collection of tips to restore Firefox’s performance if Firefox is slow.
There’ve been some stories floating around about how to make your IT department spy on you. The advice is good. The question you may be asking is how much does your IT department really know? Or, more directly, is my IT department spying on me?
I can’t answer the second question with certainty. But the first question is a lot. I’ll tell you a story.
Last week at work, I noticed some odd events in an event log, and when I investigated them, I found they were part of a failed ransomware attack. This got me thinking about how to prevent ransomware at home.
Ransomware, if you aren’t familiar, is an attack that encrypts your data and demands a ransom, usually around $300, in bitcoins, and you get a short deadline until it destroys your files. More often than not, paying the ransom is the only way to get the files back, so it’s much better to prevent it.
I had a Java app pointing at a Forcepoint (formerly known as Websense) proxy server. The proxy server wasn’t working, and the app was giving me a 407 error.
We had Websense set to require NTLM authorization, but it turns out Java won’t do NTLM, so the Java traffic wasn’t even showing up in the monitor.
My workaround was to have users open a browser, then go to any web page immediately before opening the app. By letting the browser authenticate for it, the Java app worked thanks to Websense having the credentials cached.
If you want, you can launch the applet with a batch file that uses IEcapt to hit any web page, then starts the applet.
One of the best things you can do to improve your security in a corporate environment is to limit the use of Java, or whitelist Java. Undoubtedly there will be one or more legacy web applications your company uses that require Java, and it’s almost inevitable that at least two of them will be certified for one and only one version of the JRE, and it won’t be the same one.
Believe it or not there’s a solution to the problem of conflicting JREs, but it took me years to find it, because I had no idea that Oracle called it “Deployment Rule Set.” The secret’s out now. If you run Java, and you want security, you need Deployment Rule Set.
Last week Apple released a bunch of patches up and down its product line. One of the vulnerabilities it fixed in OS X was a vulnerability in its font parser.
In the past you could mitigate vulnerabilities like this by only installing fonts from trusted sources, but since it’s now possible for web pages to transmit fonts along with other content, there’s a limitless number of untrusted fonts out there in the world.
Since it may take a while for all of the major operating systems to shake out all of the problems in their font subsystems, that’s the reason I’ve recommended filtering fonts at the proxy.