Threat Level: green Handler on Duty: John Bambenek

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

SQL Slammer Clean-up: Picking up the Phone

Published: 2010-10-19
Last Updated: 2010-10-19 17:59:48 UTC
by Kevin Liston (Version: 1)
5 comment(s)

Last time, we took the reporting up a level (http://isc.sans.edu/diary.html?storyid=9712) this time we need to take it up a notch. We’ve been using scripts and email to limit the impact of abuse reporting on your time, and you’ve seen the results: it’s not having much of an effect on the number of attacks hitting your perimeter. This is not unexpected, since the normal abuse-reporting process hasn’t cleaned these systems up already. It’s time to roll up our sleeves and pick up the phone.

I know it is scary to pick up the phone and talk to human beings-- I don’t like it myself. If we were people-people, most of us wouldn’t be into computers.

I’d like to split you up into two groups: people who are reporting attacks on your perimeter, and people who are carrying traffic from infected machines (in other words, the ISPs.)

If you’re responding to attacks I’d like you to identify the attacker that’s closest to you. Most of the IPs hitting my perimeter are China and the US, so in my case, I’d pick a US source. Look for IPs that have businesses or organizations identified in the contact information instead of large ISPs (we’ll deal with them below.) Next, do a little detective work, and research the contact information for that business. Give them a call, and ask for the computer or security person. Introduce yourself and the program. Try not to scare them too much; you’re trying to build community here. Be helpful, because they really need it.

For the ISPs, I understand the common-carrier issue, but that shouldn’t keep you from informing your customer that they have a pretty significant security issue. I’m not asking that you roll out a full-blow user-notification process. With the volumes that I’m seeing this is definitely a one-off process. You’re probably sitting in a pretty good position to not only contact the affected user, but also know their IT staff contacts already. Give them a friendly call and help them out. You might even get more business out of it.

Keep up the effort.

Keywords: slammercleanup
5 comment(s)

Cyber Security Awareness Month - Day 19 - VPN and Remote Access Tools

Published: 2010-10-19
Last Updated: 2010-10-19 13:51:06 UTC
by Rob VandenBrink (Version: 1)
2 comment(s)

Today we have a few diaries on VPN and Remote Access Tools.  We invite your comments on any or all of these diaries. 

 

=============== Rob VandenBrink Metafore ===============

2 comment(s)

Cyber Security Awareness Month - Day 19 - Remote User VPN Access ? Are things getting too easy, or too hard?

Published: 2010-10-19
Last Updated: 2010-10-19 13:50:56 UTC
by Rob VandenBrink (Version: 1)
11 comment(s)

It seems lately to me that in IT  we no longer seem to have downtime, even in traditional "9 to 5" companies.  Laptops, smartphones, iPads and every other gadget out there all are internet connected, and more and more people seem to be online every waking moment.  And if they’re online, chances are they’re VPN’d in to keep tabs on things at work while they’re surfing social sites, playing flash games or whatever.  This is especially true now that VPN access is so easy, in fact it's now included in a number of smart phones and tablets.

Which brings us to the poor folks in IT.  Since everyone is online 24-7, and we’re seeing business sales offices or business partners from 12 timezones over with VPN connections in, this brings up a whole raft of problems:

When exactly can we do system maintenance?   I’m tired of waking up at oh-dark-early, only to find 6 users logged that you need to track down before you can start an upgrade.  You can’t seem to pick any time as a maintenance window without causing someone a problem. Who gets access to what.  All too often people have skipped over the data classification and server zoning steps.  Without those done, just exactly what is that business partner allowed to have when they’re VPN’d in?


The prevalence of cheap laptops, tablets, phones and electronic doo-dads, all with internet access and VPN access (especially now that we have SSL VPNs) seriously starts to blur the line as to what the corporate desktop is.  Worse yet, it blurs the line over who has bought and paid for that corporate desktop.  No matter what our policies say, we have way too many personally owned devices out there that have VPN access to corporate resources, but don’t have corporate security tools, logging or, well, anything else.  But you can bet they’ve got malware on them from the kids in the family ! (or the grown-up kids).  And just exactly how do you enforce a VPN policy and deny access to someone who wants to work after hours for free?  It’s a real challenge to make that point to a senior manager.


We’d really like to hear about any challenges you have faced on the topic of VPN access, and how you have solved them.  Even if in your view you lost the battle on one issue or another, please share – someone else may have a different approach that might help you out.   As always – our comment form stands ready to field any and all comments, questions and answers !

 

=============== Rob VandenBrink Metafore

11 comment(s)

Cyber Security Awareness Month - Day 19 - Remote Access Tools

Published: 2010-10-19
Last Updated: 2010-10-19 13:50:47 UTC
by Rob VandenBrink (Version: 1)
0 comment(s)


With all the changes in remote access via VPN, other Remote Access technologies tend to get lost a  little bit.  Things like reverse SSL proxy access to terminal servers for instance.  We still see lots of these out there, and they have a lot of technical advantages. For instance, depending on the architecture, often the station that is providing the screen and keyboard to the end user never has access to the internal network at all - this gets around a lot of the issues people have about non-corporate computers accessing corporate networks.

We're also seeing more and more functions that used to be delivered by remote access VPN, but are now offered up on the public internet for all and sundry as web applications, protected only by a userid and password.  The fact that these apps are quite often not tested for secure coding as they are built is often completely overlooked.  What is also overlooked is that the userids to these sites can usually be harvested from the company website or linkedin, and the passwords can often be harvested from the company website or from any of the standard (language specific) wordlists.  Mind you, after taking SEC542, I'm starting to think that passwords are over-rated - in many cases on these applications you can simply bypass authentication completely !

=============== Rob VandenBrink Metafore ===============

0 comment(s)

Cyber Security Awareness Month - Day 19 - VPN Architectures ? SSL or IPSec?

Published: 2010-10-19
Last Updated: 2010-10-19 13:50:27 UTC
by Rob VandenBrink (Version: 1)
7 comment(s)

There’s been a recent shift in VPN architectures over the last few years –we’re seeing new solutions being built that use SSL encryption rather than the traditional IPSEC for a VPN protocol.
The “traditional” VPN architecture involves a VPN concentrator (often located on the firewall, but in some cases it’s a dedictated box), which uses IPSEC protocols to authenticate, authorize and then encrypt all traffic between the end user and the corporate systems.  What this normally means in practice is ISA (udp/500 and/or udp/4500) is used for authentication and authorization, and ESP (ip protocol 50) is used to encrypt the traffic.  In most cases, NAT Transparency (NAT-T for short) is implemented, so that ESP is encapsulated within upd/500 to better deal with home firewalls (or hotel firewalls, coffee shop firewalls etc).  IPSEC VPN tunnels generally need VPN client software installed, and often a file-based VPN profile to connect up.

SSL seems to be where everyone wants to go.  The initial session establishment, authentication and authorization is done via the browser, and the VPN session itself is then done by downloading a VPN client in the browser (often java based), and running that.  This has a few major attractions – all the firewall issues go away, almost every firewall known is configured to pass SSL (tcp/443).  SSL is also well known and is “known to be secure” of protocol – in fact it is often configured to use more or less the same encryption protocols as the IPSEC VPN solutions (AES256 these days). 

Finally, most SSL VPN solutions don’t require a client to be installed in advance.  Any home PC, kiosk or whatever can connect up to the VPN, do some business, then disconnect.
I bet you can see where I’m going on this, and it’s all about policy.  Many corporations have “you can only connect with our hardware” policy.  Using home PC’s, kiosks or whatever allows whatever malware is on those units to access your inside network (or whatever your VPN authorization allows them to access that is.)

Perisistence is strike 2 against SSL VPNs.  Most SSL VPNs have a “zero footprint” option, that is supposed to delete all traces of the client after the session.  But periodically, every vendor has trouble with this.  We see problems where cached credentials or cached hashes allowing access are not properly deleted on exit, they’re left waiting on disk for a determined researcher (or their malware) to find.


A third strike is the fact that SSL, and SSL weaknesses, are well understood.  There are loads of SSL Man in the Middle tools out there.  Coupled with improper implementation, this can be a big problem.  Don’t forget that certificates server two functions – encryption and trust.  If you use a self-signed certificate, you’ve just defeated the “trust” side of things.  If users see a “I don’t trust this certificate” error every time they connect because the VPN Gateway was configured with a self-signed cert, they’ll see that exact same error if they’ve been compromised by a MITM attack.  Not only that, but you’ve trained your user base to press OK on certificate errors, so now they’re all at risk every time they see such an error on a banking or online retail site.

Is it “three strikes and you’re out” for SSL VPNs?  Don’t believe that for a second.  Every vendor is pushing us in this direction, all the new client improvements seem to be coming for the SSL versions only – IPSEC seems doomed to be the “legacy protocol” for remote access VPNs.

Do you use IPSEC or SSL VPNs in your environment?  Are you transitioning to SSL, or are you staying with IPSEC for the short term (or long term)?  Please, share you experience using our comment form.
 

=============== Rob VandenBrink Metafore ===============

7 comment(s)

Cyber Security Awareness Month - Day 19 - Remote User VPN Tunnels - to Split or not to Split?

Published: 2010-10-19
Last Updated: 2010-10-19 13:50:18 UTC
by Rob VandenBrink (Version: 1)
3 comment(s)

In remote access VPN solutions, one of the long standing discussions is around split tunnelling.  When a remote access VPN solution is built, there are two methods of routing traffic.  A dedicated
tunnel is, in english "when you are VPN'd in, all of your traffic goes through the VPN".  A split tunnel, also in normal speak, is "when you VPN in, your corporate traffic goes through the VPN tunnel, and your internet traffic goes the way it would go without any VPN at all”.

 


Both approaches have pros and cons, with IT pro’s lining up on either side.

If you split tunnel, then your internet traffic does not go to head office then back out again.  This should result in a faster internet session, especially if you are a few timezones over from the VPN gateway.  The problem with this is that their direct internet access bypasses all the corporate controls on internet security.  They are able to browse to any site, with no corporate firewall or IPS between them and the internet.   In the worst case, your remote user might be directly attached to the internet with no firewall at all.

If you have a dedicated tunnel, you very likely have a proxy server on the inside network as well.  This is because many firewalls will not take inbound VPN traffic and turn it around to send it back to the internet.  In many cases, having a dedicated tunnel may mean that your users are forced to use a proxy for their browser.  This means that they do not have internet access for their browser at all until they establish a VPN tunnel.  This may seem great to a security expert, but if your user is at a hotel, trying to use the hotel’s web portal to get internet access in preparation for getting internet access, that poor user is in a catch 22.  They won’t get internet access for the browser until the vpn tunnel is established, but they need a general purpose browser session in order to authenticate to the hotel’s system before they have enough internet access to start a VPN session.  To get around this, you’ll inevitably have to give some users “at home” and “at work” desktop icons, which will point to scripts that turn the proxy settings on and off.  Microsoft Group Policy has some nifty features in this area, where if you are at work (ie on a corporate subnet), you can have one set of workstation firewall rules and proxy settings, and if you are away (on any other network), you can have a different set of firewall and proxy settings.


As in all things, the final approach that is taken is a trade-off between security requirements and usability for the users (aka the business requirement).  What I’ve laid out above is by no means the whole story – I’ve seen other problems and solutions, and I’m sure you have as well.  We’d be very interested in the approaches you’ve taken, challenges you’ve seen, and what your final solution ended up being.  Please use our comment form to share.

=============== Rob VandenBrink Metafore

3 comment(s)
Diary Archives