Changes in the Network Security Model? 261
Kaliban asks: "As a Sysadmin, understanding network security is clearly an important part of my skillsets so I wanted to get thoughts on a few things that I've seen recently after some discussions with co-workers. Are network services becoming so complicated that application level firewalls (such as ISA Server) are absolutely necessary? Is the simple concept of opening and closing ports insufficient for networking services that require the client and server to open multiple simultaneous connections (both incoming and outgoing)?This leads me to my next question: has the paradigm of 'if you offer external services to the Internet then place those machines onto a perimeter network' been eroded? Are application level firewalls sophisticated enough to allow machines on your internal network to advertise services to the Internet? When is it alright to 'poke a hole in the firewall' to allow this? Personally, I think the answer is 'Never!' but perhaps I'm out of touch with current network security models."
Keep it simple. (Score:4, Insightful)
Application firewalls and filters are complex. To me that means more can go wrong, more holes can be found. And they have to be super effective, if they're a line of defense. Sounds nasty, like those stupid
For my money, leave the perimiter boxes. Defense in depth is a great strategy. They will get some, but they won't get them all.
bad advice, son... (Score:4, Insightful)
Troll! (Score:2, Insightful)
Maybe what you're saying is "why ask on slashdot instead of asking people who know?" That would be a different question
vpn is NOT a magic word (Score:5, Insightful)
are they firewalled properly ?
are their virus definitions updated ?
if no or "don't know" to either of those, then having a VPN will compromise any amount of safety it could bring. in other words, it's possible that the lastest and greatest worm that wasn't able to penetrate your office network until you patch is now vulnerable due to the work-at-home employee who VPNs in, and is now infecting everyone.
a bottom line is to have a well thought out security policy and PROCESS....and that only comes with training, more training, and training. Some education would help, too. Even people like Mudge and Dan Greer don't stop learning.
and for those who would call your questions stupid...they are the folks who are afraid to ask the stupid questions.
Re:Try a three-tiered approach (Score:2, Insightful)
In all seriousness, he should be looking at a system that minimizes any potential damage, not some fance firewall solution that costs a bundle. Close down the ports and keep users from loading spyware or opening email with executable attachments.
Firewall is mainly a buzzword (Score:2, Insightful)
Gee, even RedHat jumped into the firewall bandwagon. At install-time instead of selecting which services I want to run, it runs God knows what and asks me which *ports* I want to open. Now if I want to run some new network service I have to waste time learning how to fiddle with this "firewall" so that the new service will work, while making sure that those services I don't use are still protected from the outside. Fuuuuun.
Just say no to firewalls. Ask your vendor which services are running, and how to disable the services that you don't use. That's it.
ideal vs practical (Score:5, Insightful)
The answer really depends on what you are protecting and whether or not the security required to protect it is worth the cost.
The only way application aware firewalls CHANGE the paradigm of network security models is for a certain class of protection. Usually that line of protection is or train of thought is "we would like something slightly better than nothing".
If you need protection more than that, it sounds like you already know what is best practice. That hasn't changed, and you are not wrong to suggest to your co-workers otherwise.
Think of it along the lines of what the military would do. Just because there is some new whiz bang motion tracking CCTV x10 ninja thing that shoots lazers. You better believe they are still going to have soldiers with rifles in watch towers, soldiers walking the perimeter, and 20ft of dead man zone and razor wire fences surrounding, along with the whiz bang consolidating gadget.
Encapsulating protocols is a "bad thing" (Score:4, Insightful)
RPC over HTTP is a good example of this, as are the many other protocols people see fit to encapsulate in HTTP (RDP / Terminal Services, instant messaging, etc).
Originally, the rules were dead simple. One port == one protocol. Some protocols used multiple ports, but even then it was kept nice and simple. But no, not everybody liked this situation. In the interests of making IM available to more people, clients started using HTTP so that even office staff (behind firewalls and proxies) could use it. Sure, this was blatantly circumventing the firewalls that were put up for this very reason, but that didn't stop anybody.
Application layer firewalls are a must-have. Of course, that will just force people to start using SSL...
Lesson number 1: (Score:4, Insightful)
Re:How Do I Compare then? (Score:2, Insightful)
how do you know whether to trust the XP updates? did MS break anything in the newest update? it's been known to happen
your linksys is probably pretty secure, I don't know of any exploits. doesn't mean there aren't any!
but you can do some proactive things:
- keep watch on CERT & other security sites.
- get some of the professional and hacker intrusion tools and run them on your network. do some research, find out what exploits are "hot" these days.
get paid for doing this a few hours a week - nothing like learning Fast and getting paid for it!!
go Coasties!!
Re:Try a three-tiered approach (Score:3, Insightful)
There really is nothing magic about vpns, they are quite dangerous - they can provide clear access to your internal network.
Are you NUTS?! (Score:5, Insightful)
I am the head sysadmin for a company that has many Linux, Windows, and Solaris servers, and other specialty systems such as Cobalt Raqs, proprietary satellite equipment like IP enabled RF Modems, MUXes, IPEs and a shitload of high-bandwidth routers in multiple POPs around the world. If you think that a firewall to protect your network is insufficient, especially for a network with mixed OSes and such, you are terribly wrong. Imagine working in an ISP. You have your private workstations, then your servers (DNS, MXes, etc.), then your colocation equipment. Put it all on the same network? Suuuuure!! WHOOPS! Someone hacked into a colo box and then used his r3wt account on that box to scan your internal network for other vulnerable boxes (all at the same time, using your T1/T3/OC-192 for hosting the world's biggest movie IRC bot). You didn't have a firewall and/or IDS to detect the initial portscan on the colo box, and now you don't know that he/she is sucking up your bandwidth and scanning your entire internal (well, to you it's internal, external, whatever) network for more boxes to royally *$#! up. Trust me. Once a box is rooted, you take it of as SOON AS POSSIBLE and reinstall. It's a shitty feeling knowing that someone owned YOUR network and now you have a shitload of crappy work to do over the weekend. Not to mention downtime, customer/employee complaints, fielding the hundreds of "I CAN'T CHECK MY E-MAIL!!! BOO HOO!" calls, and general feeling that maybe...just maybe there's a box that got 0wnz0r3d that you might not know about.
The moral of this story, boys and girls, is that FIREWALLS ARE GOOD. Intrusion detection systems are GOOD. NAT is GOOD. TCP syncookies are GOOD. Everything on the Internet is vulnerable by default unless YOU TAKE THE TIME TO SECURE IT YOURSELF. Keep the colo systems on their own subnet. Shit, keep each SYSTEM on it's own 2 port VLAN with the uplink. Keep your servers on a DMZ. Keep your internal workstations on a TRUSTED, PRIVATE, NATted network. Close every damn port besides the ones that are used by servers. Do not open ANY ports to your trusted, internal network. If someone roots a box, at least they can't load an SSH trojan on port 2000 with no password and automatic root access to get back in later.
Users (Score:3, Insightful)
The problem is firewall admins (Score:4, Insightful)
Take a look at this part of the original post:
Are network services becoming so complicated that application level firewalls (such as ISA Server) are absolutely necessary?
Yes. They are. You know why? Because jackasses thought it would be a great idea to slap firewalls on everything. It's an easy, one-off fix that's centralized. Does jack for actual security, but it's easy to sell to management, so IT people constantly claim that everyone needs firewalls all over the damn place.
So now we have a ton of firewalls inhibiting functionality all over the place. Do application vendors simply say "Gee, I guess we'll give up on doing interesting things with the network", due the best efforts of short-sighted sysadmins? No. They do ugly, slower, less reliable and harder-to-monitor things like rebuild everything and ram it through SOAP. And then sell the same stupid product right back to the "firewall-enabled" company. Now, everyone loses. The security is just as bad as before. The user gets a slower, less reliable experience. The sysadmin has a harder time monitoring usage and troubleshooting (since everything is obscured by the layer being used to bypass his firewall).
Firewalls are the singly most-oversold computer product ever, having displaced antiviral tools in the last year or so. Nothing ticks me off more than some sysadmin shoving another firewall in front of users.
Loads of badly designed services (Score:2, Insightful)
These are services that are using an end-to-end protocol approach without provisions for a concentrator and filtering server within your company, requiring connections from desktop to desktop across corporate firewalls. There are services that hide their payload in normal http or https requests, requiring you to parse HTTP and XML in order to select which requests you pass on and which you don't. There are services that require backward connects on variable port numbers.
Don't let your security model be eroded by these. Tempting as it may be to have them, these services simply have no place within the enterprise. Their design is simply not fit for such an environment, despite all the advantages that service may be offering - the risk your corporation is taking by deploying it is simply to high. Talk to the vendor, tell them you'd really like their service and you'd like to deploy it, but they aren't offering a security model that is up to it. Stare your requirements and see if they have ideas to match them. If they don't, they do not understand enterprise. Avoid them.
On another note, application level firewalls are funny things. They parse and understand the application protocol. That makes them pretty sophisticated as firewalls go. It also makes them vulnerable to many of the same types of attacks can hit the applications that they are protecting.
Think about it: An application level firewall parsing POP, IMAP or HTTP not only can block or allow the protocol as a whole, but deny or allow individual commands, or users, or directories or whatever. That's nifty. In order for the FW to do this, it must parse folder names, user names, or commands. It must manage buffers for that. It must decode character sets. It must deal with strings with illegal characters in them. It must do all the same stuff that your applications often fails to do properly.
Use what application level firewalls offer to you, if you need it. If you don't, don't use them. They are to complex internally to be really secure.
Kristian
It depends... (Score:2, Insightful)
At the moment, for my "day job" (which is really at night, but never mind that), I do sysadmin and networking stuff for an international investment bank. The information on our computers is worth on the order of tens of billions of dollars on the market, not to mention the very serious privacy implications if there were a compromise (which have specific legal consequences in some of the jurisdictions where we operate, and serious PR consequences everywhere). As you would expect, the order of the day here is totally-closed firewalls with proxy servers to handle the specific traffic that's been determined to be appropriate. The internet-accessible machines owned by the bank are hosted in offsite colo facilities that have no direct connection to our network. Short of saying "no, you can't access the internet at all for any purpose no matter what", that's about as tightly secured as it's possible to get...and that's appropriate for the security needs of this environment.
On the other hand, I also run a small community ISP. It's a not-for-profit cooperative association, but in terms of security it'd be managed pretty much the same way if it were being run as a for-profit enterprise. Its security configuration is pretty much wide open...the machines with sensitive member information on them are hidden behind a proxying firewall, but the rest of the network is only firewalled to the extent necessary to prevent serious DoS attacks. That's also appropriate for the security needs of the environment.
Good security practice starts with a risk model and a threat model. Anyone who says "this is the level of security you need to implement" without understanding the risks and threats you face is somebody you should ignore.
Re:Try a three-tiered approach (Score:3, Insightful)
How you will get r00ted (Score:4, Insightful)
Playing the "security component Lego" game is great fun, and a little intelligent thought will soon see you set up with a nice, best-practice architecture. This is how it will then fail.
1. You will have unpatched machines which will be trivially rooted with a script-kiddie exploit. You will know that you should have patched, but you won't have the time, manpower, or authority to ensure the patches are in place.
2. You will misconfigure something, and then miss the problem in reviews because you didn't get peer or professional verification of all your configs.
3. You will get owned by an internal employee who has exactly the level of trust that you planned for, but abused it.
4. Someone will walk in with a clipboard, bamboozle the secretary and walk out with your fileserver.
5. You will create a whole bunch of really cool procedures, but the CIO / CTO won't back them when the first departments complain about lost productivity - this will undermine the whole thing and you will be back at square one.
6. You will give someone VPN access, and they will connect their virus and worm ridden home machine. It will infect your network, and their kids will surf pr0n and share mp3s on your dime.
7. Your backups will have some unforseen problem, your restore procedures won't work right because they aren't tested, and you will lose much company data (and your job).
8. Your users will deliberately download trojan-ridden, virus infected, IE Object Overflow infested garbage, despite clear, explicit orders to the contrary being sent to them twice a day. They will do this because dancing rabbits are somehow more compelling than 'all those emails from the grumpy tech guys'.
When we talk about the 'current paradigms', I don't even think about fancy technology, I think about these obvious threats that always apparently only happen to other people, because some wiseguy always knows better. "IF you do blah blah, like we do..."
Your "paradigm" wish might be: "I want a network where every single part is doing as best it can to defend itself against the threat at the keyboard as well as the threat from external attack - not a perimeter, not 'tiers', but every part."
Small nit (Score:3, Insightful)
One problem with this is that simply reinstalling a r00ted machine is no guarantee that it won't immediately be r00ted again.
While being hacked sucks, it is the worst time to panic. Remember, when you suddenly notice something strange on the machine and realise you've been owned, it could have been compromised for weeks or even months.
While you should immediately prevent it from doing further harm, you should also attempt to do a bit of forensics. See what kind of traffic it's sending, and to where. Make sure it hasn't compromised other boxes on your network (or elsewhere). When you take it off-line, get a disk image so you can try to understand how the machine was entered in a safer, contained, environment.
OTOH, if you know you the person who set the box up was lazy and didn't patch appropriately, and you are reasonably sure you know which exploit got you, then just reinstalling can make sense. As can firing the pinhead who put your organisation at risk.
Lesson number 2: (Score:2, Insightful)
Re:Encapsulating protocols is a "bad thing" (Score:4, Insightful)
Developers tend to do the least work necessary to achieve the result they desire. The fact that so many protocols run over HTTP now indicates that the developers of the applications that use these protocols have been unable to persuade the systems administrators to open ports so that they could their necessary applications to work. Instead they resorted to the harder task of layering to avoid the blocks.
The sysadmin that said "I like people to do some work to convince me" says it all. The attitude is that of a power-monger. A pragrmatic sysadmin would work with the applications developers to find a solution. Maybe they frown upon opening ports for applications, but they should at least put the effort in to explore the options otherwise we'll always end up with this layering effect for every networked application. I wonder how long it takes before we end up with protocols running over HTML/HTTP to avoid the application firewalls that start blockting non-HTML HTTP traffic.
Re:What about a small company? (Score:2, Insightful)
It is prudent to assume that something 'bad' will happen; it's just a matter of time. With that assumption, start figuring a monetary value next to the loss of each kind of data you have. How much would it cost you to rebuild your customer database, weather legal action from customers, etc. in the event that the customer database is broken into and details leaked?
Don't be worried if you don't have this expertise in-house. There are many businesses out there that can work with you and share the responsibility. Think of it as outsourcing your IT security (and possibly more) to a trusted company. This doesn't have to cost the Earth, just make sure that whomever you work with starts by asking the value of what you are trying to protect!