Slashdot Mirror


Changes in the Network Security Model?

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."

11 of 261 comments (clear)

  1. Keep it simple. by SatanicPuppy · · Score: 3, Insightful

    The beauty of the traditional firewall is it's simplicity. IPTables hasn't been exploited in forever, except through user error. It's reliable and secure, and easy to understand/debug.

    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 .NET commercials "1 Degree of seperation between you and your customer!" 1 degree? In what fairyland? Do they WANT to be hacked?

    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.

    --
    ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
  2. bad advice, son... by vt0asta · · Score: 3, Insightful

    He already has the standard generally accepted rule of thumb answer... "Never!". What he wanted to know was, if these newer fancy schmancy firewalls are changing these rules, where it might be acceptable. The answer ofcourse is it depends...not go study up and give back the same answer he already knows to some professor or cert authority. Long and short of it, you have the wrong answer.

    --
    No.
  3. vpn is NOT a magic word by smitty45 · · Score: 5, Insightful

    VPNs are great until you realize that they provide only *temporary* access to your office network. What happens to those road warrior's machines when they're not vpn'd but still on the internet ?

    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.

  4. ideal vs practical by vt0asta · · Score: 4, Insightful

    You're going to get a lot of answers on how in the perfect world there will be DMZ this, several layers of routers that, firewalls in between them all, VPNs, NIDs,and a whole bunch of other things that may not be applicable.

    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.

    --
    No.
  5. Encapsulating protocols is a "bad thing" by Lurgen · · Score: 3, Insightful

    The minute we started encapsulating protocols within other protocols, we made it absolutely necessary to have application-layer firewalls.

    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... :(

    1. Re:Encapsulating protocols is a "bad thing" by oniony · · Score: 4, Insightful

      Layering came about because of the inflexibility of systems administrators to react to the need for new services to be accessible. HTTP is one of the few protocols that are allowed through firewalls because of over-zealous blocking. Because of the need for applications to work, people have realised that the only way forward is to get their protocol to run over HTTP, hence SOAP and the rise of XML. I've experienced this need to layer first-hand on many occasions.

      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.

      --

      Powered by onion juice.

  6. Lesson number 1: by suso · · Score: 3, Insightful

    Don't implicitly trust what you read on slashdot.org.

  7. Re:Try a three-tiered approach by dhammabum · · Score: 3, Insightful
    Um... a vpn is a hole in the firewall.

    There really is nothing magic about vpns, they are quite dangerous - they can provide clear access to your internal network.

    --
    I am not a robot. I am a unicorn.
  8. Are you NUTS?! by TheDarkener · · Score: 5, Insightful

    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)?

    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.

    --
    It is pitch black. You are likely to be eaten by a grue.
  9. The problem is firewall admins by 0x0d0a · · Score: 3, Insightful

    You're right. Application firewalls are a terrible, unsolvable hack. Of course, firewall vendors love 'em, because you'll be paying them for updates until kingdom come, like antivirus vendors.

    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.

  10. How you will get r00ted by btg · · Score: 4, Insightful

    I have been involved with lots of different bits of security for a few years now, and quite a few people seem to think I know what I'm doing.

    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."