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."
There are three disparate levels of security you need to consider, and it is advisable to take a three-tiered approach to the problem.
First, for employees and others who have trusted access to your network, the answer is not to poke holes in your firewall. Rather, the answer is simple, just three letters. VPN. By setting up a secure, encrypted, authenticating channel, you bring your trusted users into your network. From your point of view and theirs, it is as if their machines were physically located on the other side of your firewall--just like having the machines right in your building.
Second, for business partners and contractors who need limited access to a subset of services, but whom you do not trust fully, the answer is quite likely also a VPN, but not directly into your network. For services provided to these people, you want everything from your end first going through application-level firewalls, and then through the VPN, over the Internet, to them.
Using a VPN in these cases prevents random hackers from entering your network on these levels.
Finally, for the general public who simply need access to your web site, the ideal situation is to simply host the web site on a network entirely separate from yours--possibly not even in the same city. Use an application-level firewall to help prevent things like buffer overflows. Then, if your web server needs to retrieve information from other systems on your network, have it communicate over a VPN, just like the second-level users mentioned above--that is, through additional levels of firewalls to machines not directly on your primary network. (Basically, you shouldn't consider your web servers as trusted machines, since they are out there, "in the wild.")
By following this approach, you expose nothing more than is necessary to the world, and greatly mitigate the risk of intrusion.
It's hard for thee to kick against the pricks.
No es solamente usted. Necesito esperar mucho para ver las paginas de Slashdot. El Senor Taco necesita comprar computeradoras mas poderosas para su sitio de web.
Un otra cosa - bustamante es un sinonimo para disastre.
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.
.NET commercials "1 Degree of seperation between you and your customer!" 1 degree? In what fairyland? Do they WANT to be hacked?
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
I can see where the desire for more than one firewall is going to go up. Here's an example. At the boarder, you might have a hardware firewall set up, before data can even get to the machines. Then you might have a per-cluster firewall, so each department or cluster of computers can set their own policies for what gets in and what doesn't. Then there would be the firewall on each machine, which could be set according to the uses of the machine. So there would be three layers of shielding before you even get to the security features of the OS itself. Or you could just go VPN like someone suggested. Another good idea would be to have some kind of username/password setup so that some people could bypass the first firewall, and the issue of 'trust' wouldn't be as big as allowing someone to zip through all the firewalls.
Job? I don't have time to get a job! Who will sit around and bitch about being broke and unemployed then?
Nope. That should never happen.
The problem here is that application-level firewalling is fraught with problems. The lack of intuitive management for this type of firewalling is a problem that quite a few companies are trying to solve -- with limited success, so far. The problem is that as you move up the OSI layers, the variables increase exponentially. If you think that 65,536 is a big number, try writing an application-level script that permits "acceptable" MAPI requests while denying "unacceptable" MAPI requests. How do you determine that this NFS packet is good, and this one is bad? From the same host to the same server? How about X11? SSH? Oh, and don't break anything while you're at it. Lions and tigers and bears, Oh my!
These are the problems of an immature technology. As time passes, these issues might be somewhat mitigated, but there are plenty of "network administrators" that haven't fully grasped the concept of IP, and struggle with L3/L4 firewalling, to say nothing of moving up the stack.
Here's a tip, though; look for Bayesian filters in firewalls in a few years. That will be a trip.
Feh.
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.
Times change, and technology always requires you to keep up to date.
:)
Maybe what you're saying is "why ask on slashdot instead of asking people who know?" That would be a different question
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.
hehehe, reminds me of an old joke:
Why isn't cliff a sysadmin?
Because the only thing he knows about services and holes is getting his hole serviced by cmdr taco and michael.
IPFW
Dunno what Linux guys do, though. I'm sure they have something equally groovy.
--
the strongest word is still the word "free"
People run a firewall to block services that are running but that they don't use. Riiight. Instead they should just *not* run the services that they don't want. Then they wouldn't need a firewall.
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.
Given what I read above, how secure does my setup sound?
First, the company: Small landscape contracter with only 4 computers, all running windows XP. Website is hosted of the computers of our small-business DSL provider.
The computers are networked through a LinkSys Router with built-in firewall, in addition to which each computer has Norton Firewall (and System Works) installed.
I know that deliberate hacking chances are essentially nil for such a small company, but these measures combined with at-least weekly windows updates should pretty much secure us against any type of incidental or random attack, right?
And in case you are wondering, I am essentially the entire IT department, which leaves me working only part time, and even then half my time is spend doing general admin (not sys admin) work. It helps me get through college, gives them the tech help they need. My specialty was Electronics Technician in the Coast Guard, so I know I am not fully up to par for Sys Admin skills, but I am learning Fast!
"It takes a very long time to count to 2 in binary." ~'Fourlegged'
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.
Where have you been? (or are you a troll?) Ipfwd Ipchains Iptables And yes XP includes a firewall.
There are plenty of firewalls for linux. In fact, when I installed Mandrake 9.1, my biggest problem was opening up the default firewall enough to let my server function as a server.
First off, remember - you won't be able to think of everything. No security model is complete without behind-the-wall systems, be they basic monitoring systems up through more sophisticated custom snort or proprietary IDS. It all depends on your paranoia level.
There are a few ways to handle the bane of netadmins - 'I wanna get to my files!' VPN, as suggested, is one solution - but not without problems. Recent issues with X.509, OpenSSH hacks for IP-over-SSH, etc. You can mitigate the danger by using a set of consistent criteria for each of your requirements, like a checklist. For example:
1) Is the service mission-critical? (BOFH them if no!)
2) Can the service be offered through a less-vulnerable channel? NFS mounts moved to SFS, perhaps, or encrypted AFS as mentioned above.
3) Is there a way to move the service into a perimeter network (or outside entirely)? Even if this means synchronizing a set of data to an outside machine via cron, if the data on the machine is less important than the internal network security, this can help.
4) Once the user is connected, authenticated and accessed, *THEN* what can go wrong? What could they do maliciously? What could they do accidentally?
Personally (and this is just me talkin', no creds here) I tend to reflexively say "NO!" until convinced otherwise. I know that there are services which *must* be available through the wall, but I want the requestors to have to work to convince me. Closed systems are more secure.
Also, don't be afraid to investigate low-tech but simple and effective means of circumventing problems. First thing I ask users who want to get an occasional file home - "Can you mail it to yourself?" Second thing: "Would you be able to use a 'public folder' that I have synch to an accessible box, say, every half hour?"
I second the opinion of iptables. It's a sharp tool, so be careful - but correctly applied, it kicks pants off most application or appliance firewalls. Invest the time to learn the sharp tool, and you'll realize that most of what you pay for on big expensive firewalls is manageability (i.e. Java GUIs, wizards, databases, multiple systems preconfigured - IDS, firewall, proxy, etc). Do the work.
Good luck. Don't listen to people who berate you for 'not knowing things.' Attempting to learn them in advance - due diligence - is a sign of a good admin. Be thorough. And above all, find a friend who does the same kind of work, and check each other. Probe each others' networks. Try exploits posted on the net.
Final, and most important - software updates. The boring part, but the most critical.
Cheers.
A general question - bayesian filters are great for email because a user trains them. But do you think it will ever be practical to "train" a firewall as to what is good and bad traffic? I guess to some extent you could use regression tools to generate the sorts of traffic you like... but it seems like such a thing would have to have a pretty high threshold in order not to drop any real traffic. I'm not sure such a device is pratical.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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...
Don't implicitly trust what you read on slashdot.org.
Face it folks. Provisioning security services at network perimeters is just wishful thinking, and this is not a new insight. Traditional packet filtering firewalls are absolutely necessary (do you walk around your neighborhood naked?) but they must become much more widely distributed *inside* large networks in order to be effective. The same applies to application filtering technologies (some of which are very promising) and all the other stuff people think of as perimeter defenses. Any attempt to set up large networks as controlled domains with known security characteristics is a losing battle. The world needs to go to endpoint-driven security. A lot of companies are working on making this manageable and cost-effective. And while we're at it, that's also the place to incorporate highly granular access-control services. As long as you have machines on your network that can hit external web sites or have floppy drives or unauthorized wireless access points, your internal network *is* 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."
Those who don't need to pass traffic inside are afforded that luxury due to the fact that they don't have a job. Anyone can decently secure a network that doesn't interact with anything; the real trick is allowing business to flow as usual and *still* have an acceptable level of Security.
dmiessler.com -- grep understanding knowledge
Right on, mate. Thanks for the sensible, inspirational words. Made my day.
-kgj
The firewalls are there in linux distro's, the question is what are the default setups on distro of choice. Micro$oft has firewalls already in the more recent release's but again the question of defaults comes up. The ultimate issue comes down to what should be default settings and how much should be cut off. Of course the best setting is complete isolation so it becomes a matter of tradeoff's. Do we want features X,Y & Z plus their inherit weakness or do you default to no X,Y & Z giving more security, but the hassle of enabling X,Y or Z as needed. It's been mentioned many time's here on slashdot that security is all about tradeoff's and that's where the ultimate question comes in especialy when looking at it from a commercial point of view. What is acceptable to customers (in convenience, features & ease of use). As far as exploits they will always be there, question is how desirable are they to be found. To error is to be human, and no matter what we do there will always be way to find that error. If your that worried, the best firewall would be to be disconnected (again the tradeoff's).
There is no one answer. If security is your only concern you should have as many layers of security as possible with firewalls between each layer locked down as tight as possible. That said, security is never your only concern. Cost, ease of maintenance, performance, and flexibility are all important in a network design. After all, the purpose of your company is probably to get something accomplished, not to avoid getting hacked. There are times when every different network configuration is appropriate from super secure to a cable modem router to a windows box right on the internet. There is no one answer.
Application layer firewalls are another layer above port filtering. They can increase security and could, in theory, make it worthwhile to share a service hosted on a machine that is inside your network. I would only do that if you trusted the security of your internal network. Most network designs assume that once you get in to the "internal network" there is no more security and all your deepest company secrets are available to anyone browsing around. If this is true, you've probably made some bad decisions somewhere along the way and you should address those before you open any holes. If you are willing to maintain strict security on your internal network then the added simplicity of allowing Internet access to machines on it can be worth the risk. This can be a lot easer than setting up a dmz.
Usually layers do make sense though, even if one of the layers is just a Linux box doing firewalling, routing and serving some services. One thing I like to do is to mix operating systems at different layers. That way if you get a worm of some kind that gets into one layer it won't penetrate to the layer behind. For example, internet facing servers are Linux based, desktops are Windows based.
Another thing I have done when I absolutely needed a Windows based web server is to setup Apache as a reverse-proxy only forwarding requests to a particular subdirectory to the Windows server. This filtered out all the standard buffer overload attacks since none of them referred to that subdirectory name. It also made sure the requests were relatively well behaved and buffered outgoing data for the Windows box, reducing connection counts when it was under high load. This is an easy way to do an application layer firewall and if you are firewalling with a Linux box you can do it right on the firewall.
set softtabstop=4 shiftwidth=4 expandtab nocp worlddomination
When firewalls don't do the job Mike Fratto, Sep 29 2003
Battle lines have been drawn, and volleys are being lobbed between the analyst and vendor camps. In dispute: Whether intrusion prevention is out of commission or the next network security salvation.
On one side, Gartner has cast intrusion detection into its "Trough of Disillusionment", saying the tech has stalled and calling for these functions to be moved into firewalls. Meanwhile, intrusion-prevention product vendor ForeScout Technologies vows to identify and block attackers "with 100% accuracy".
Call us Switzerland, but we say neither group has a lock on the truth.
Network intrusion prevention (NIP) systems probably will not protect your network from the next zero-day exploit or troublesome worm, but they are not a waste of time or money, either.
Our position puts us in the minority: Though we think NIP systems can enhance an existing security infrastructure, we do not consider integrating intrusion prevention and firewalls into a single unit a desirable goal.
Firewalls vs NID Firewalls have a largely static configuration: firewall administrators define what is acceptable traffic and use the features of the firewall to instantiate this policy.
Some firewalls provide better protection features than others. For example, an HTTP application-level proxy is far superior to an HTTP stateful packet-filtering firewall at blocking malicious attacks, but the basic idea is the same: Your firewall administrator can be confident that only allowable traffic will pass through.
If you have doubts about your firewall, get a new one from a different vendor, send your firewall administrator to Firewall Admin 101, or get a new administrator.
Not surprisingly, when we asked you why you are not blocking traffic using network-based intrusion detection (NID) systems, 63% of you said you use a firewall to determine legitimate traffic.
But people make mistakes, so misconfigured firewalls are a common source of network insecurity.
This simple fact has been used as a selling point for both intrusion detection and prevention systems, with vendors claiming their products will alert you to, or block, attacks that do get through.
The answer: Instead of layering on more hardware, solve the fundamental problem of misconfiguration.
Think configuring is easy? Unfortunately, though, it is not that simple. If you are enforcing traffic policy on your network using a stateful packet-filter firewall--such as Cisco Systems' PIX, Check Point Software Technologies' FireWall-1 or NetScreen's eponymous product--without security servers or kernel-mode features enabled, you should know that application-layer exploits, such as server-buffer overflows or directory-traversal attacks, will zoom right through. Stateful packet filters stop at Layer 4.
Application-proxy firewalls can block some attacks that violate specific protocols, but face the facts: protection is limited to a handful of common protocols.
The rest are not supported through a proxy, or are supported through a generic proxy, which is no better than a stateful packet filter.
Still, NIP is not a replacement for firewalls and will not be in the foreseeable future. Why? The fundamental problem is false positives--the potential to block legitimate traffic.
Before you can prevent attacks, you have to detect them, but NIP systems rely on intrusion detection, which is hardly an exact science.
A properly configured firewall will allow in only the traffic you want. We need to feel this same confidence in IDSs before we can believe in NIP systems, but IDS vendors have employed lots of talented brain cells trying to raise detection accuracy, and they are nowhere close to 100%.
Incoming! Despite these caveats, we believe a properly tuned NIP device can be instrumental in warding off most malicious traffic that gets past your firewall.
There are several ways to block malicious traffic: If the NIP device i
I love the smell of Karma in the morning
uh
i don't use linux alot and didn't know xp had built in firewall. docs for my computer didn't say anything about it. Why did i install zonealarm ?
Not a linux expert. The suse linux cd never mentioned firewalls. Thanks for clearing that one up.
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.
If you allow users to select what goes in and out of their computers onto the internet, I guarenty you that within 24 hours of rolling out the system, 95% will have flipped the "allow everything" switch because they got anoyed with being asked every time they fired up a new application.
Space for rent, inquire within
Firewalls are great at slowing down intrusions. However, without proper application security architecture and host-level security hardening, you cannot really protect a network-accessible resource. Often times, the only resource (network, application, host) that we can control 100% of the time so that it can be trusted is the host.
Besides, the bulk of compromise situations occur INTERNALLY. Is that PIX on your WAN router really going to stop disgruntled Gary down in QA from trying out across 5 subnets the latest script kiddie tool that his roommate hooked him up with. If you spend quality time hardening your hosts, chances are you may really not lose more than a few hosts at a time during a significant compromise at the application-layer (e.g., a remote root sendmail hole, a bug in BIND). I think we need to revive the popularity of security "tuning" on the host side - a lot of people forgo it for strong network security but I think that the latter is a much more difficult perimeter to maintain.
I've seen others post about the dangers of VPNs. I totally agree, they are conduits for information loss, but are likely to be mostly self-generated (internal). Example: Disgruntled Gary in QA sucks down the product roadmap details off the Intranet before giving his 2 weeks notice and starting to work for a competitor.
Apologies to Gary's everywhere. ;-)
--rc
I have been a firewall engineer for nearly four years. In that time I have come to the conclusion that you have a major trade off in the ultimate security of a system as compared to the usability of that system. An example is the explosion of VOIP and video conferencing in the last two years.
H.323, SIP, SKINNY etc. all require many ports to be used which is a nightmare to a firewall admin. As a result, firewalls are evolving to include support for these systems, but my fear is that the overly (in my opinion) permissive nature of firewalls which allows these connection, is ripe for exploitation by future crackers/hackers.
While I was supporting firewalls, my mantra was to close every damned thing I could and the users can suffer. But I also realize that in a modern network, usability is a major concern. Companies are deploying VIOP networks in record numbers while saving thousands of dollars each month. Companies need to reduce overhead to remain profitable, so they are looking at new technologies to help them. If the firewall industry cannot keep ahead of these technologies, it will ultimately fail.
I think that the time of using access-lists to controll traffic is nearing an end. This will result in slower overall performance of firewall solutions as application level firewalling becomes mandatory, rather than the past of transport layer firewalling.
I am afraid that I have no easy solutions, but I hope that the industry will be able to remain both secure *and* usable.
Hell, perhaps in the future security will be built into operating systems and network resources, rather than the reacitve nature that we enjoy today.
it is better to light a flame thrower than curse the darkness. -Terry Pratchett Men at Arms
There's a few very sophisticated application-level firewalls available on the market, but they all pertain to a very specific set of protocols. NFS and MAPI are none of them, as these are far too complex and it's too hard to distinguish bad from good traffic; HTTPS, on the other hand, is pretty well suited to full application layer inspection, and this can make it very practical to actually allow access to an application on your INTERNAL network from the outside. However, on the side of the application-level firewall, this requires very sophisticated rulesets that require modification whenever the application changes, and that require a very skilled administrator. Whale Communications makes one such product (e-Gap Application Firewall), which could easily be the most sophisticated application level firewall for HTTPS. There are other vendors though that offer reverse proxies including authentication that will do session management and only forward traffic belonging to live, authenticated sessions, that could possibly as well make it practical to have the application run on your internal network.
Just think about it - in an ideal world, you could connect your database only to the web - no replication to the insecure area (DMZ), no (not in the Windows meaning of the word!) trust relationship with the DMZ, no poking holes in your firewall for DB/RPC/other proprietary communication protocols, no bringing out and maintaining the same set of hardware and software twice...
BUT this comes at a price - secure application layer proxies require skill and money.
Disclaimer: I work for a company that has implemented the Whale solution in Germany for 2 years. However, I chose the Whale solution for its technical merit solely.
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.
May we never see th
Sad to say, but in the future, the only reliable port will be 80. All clients will have all ports except 80 blocked by default (right now this seems like wishful thinking!) and no one will open any other port (it will give them a scary security warning!), and even if they wanted to, they might be blocked from doing so by their ISP.
We're already seeing shades of this, but it hasn't reaced the majority of Internet users yet. Back in late 90's my company rolled out a product for schools that to be retooled when it was realized that many schools were firewalling everything except port 80. (They added a mini proxy server to the product that sent everything over 80.)
I have a friend that's a sysadmin for a medium sized insurance company - and they had all their internal applications break a couple weeks ago when a MS worm started bouncing around the Internet. However, the problem wasn't that they were using Windows machines (I think all their servers were AIX...)- the problem was that their ISP (the regional phone company) had blocked off the port that all their applications used because it was the same port that the worm used to get into systems. Last I heard, the phone company was refusing to ever re-open the port. (The phone compnay made the change without even informing anyone at the insurance company, everything just stopped working and from what I heard it took them a day to figure out why their data wasn't getting through. I believe they were resigned to changing all their programs to work on a different port.)
So, we've already come to the point where connections on other ports seem strongly subject to the winds of fate, and I see no reason the situation won't get worse. In most environments 80 is the only port that people would notice if it was blocked, and there are too many sysadmins out there who don't know any better. Right now, if I was developing an application that needed to communicate on the Internet, I would only trust that it could use port 80, and I wouldn't even bother looking at anything else. You can even see application enviornments starting to spring up now (Flash Central) where it's assumed that most applications will just share a port 80 connection.
It sure is a sub-optimal situation, but I don't know what can be done to stop the trend. Ironically, such a situation makes simple port-blocking firewalls useless because all applications will be running on port 80 anyway.
A lot of network security problems come from microsoft and just laziness. Writing code is more than just putting a bunch of algorithms together. you must think first. imagine that you are a hacker and want to crack through those algorithms.
I do not think that Microsoft has done this. Maybe they think of security as afterthought to the software, but they do not think security first. this is the problem. A firewall thinks security first. A firewall intended to stop everything but what is allowed in. Why you want to poke holes through firewall? Only if completely necessary for use! Be very careful, test everything, think like you are the enemy and your system will be better off.
If system must advertise outside, test test test test test it! Invite grey hat hackers to break system first. Make honepot system and test it where it can not hurt anything. Let everybody hit the system. Keep all microsoft product behind dmz zone so that they are far behind all firewall and do not announce anything.
The varied answers did indicate that there is ambivalence in general about the idea of allowing a machine on the internal network to advertise services even if protected by an application level FW(such as ISA Server protecting an Exchange server). That's good because I thought I missed something in the past 2 years since my last sys admin job(tried my own non-IT business for a while for those who are curious).
For those who did comment, thank you kindly. I appreciate the ideas and just so folks better understand, this question was speared by the fact that my current workplace has determined a need for webmail because apparently our VPN solution is both too complicated and we dont trust our users to have secure machines(I dont make those rules, I just live with them). There is one voice in my organization who wants us to open up an exchange server thats on our internal network because it will be protected by an ISA server and that just seems nuts. I rather just place a frontend Webserver on our DMZ/perimeter network with IMAP access to our exchange server(we only need email, not calendaring and other features) and use secure protocols to transmit authentication information. From this discussion I've concluded that there is no decisive answer and that I rather stick with our current network security model(screened subnet) rather than "poke a hole" in the firewall for the exchange server.
There are badly designed services out there. Loads of them.
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
While this is simple to state, how many companies will follow this rule. Companies are not going to jail their users, so the first one who wants to listen to mp3's or streaming music, up goes Real, or Windows Media. What? You want to see the stock ticker from Bloomberg? Sure now you have multicasting crap. Get real, and that's not including someone who knows about things like datapipe.c
Rather, the answer is simple, just three letters. VPN. By setting up a secure, encrypted, authenticating channel, you bring your trusted users into your network.
You're either blind or too trusting in people. Remember the biggest security hole often comes directly from the inside. For instance, I know someone who has a VPN through IBM for her work. Lo and behold she wanted to take that same machine and hook up DSL to it. Say goodbye to security over VPN.
I won't get too deep into this since I'm tired but a VPN isn't always the answer. The answer is actually education. Instead of spending on a Cisco Pix, or Nokia VPN machine, try holding monthly meetings with employees and make them aware of issues. Doesn't have to be a full blown Harvard presentation, but a quick power point presentation will actually teach them things they could carry on in their home or future place of employment. VPN's are like security through obscurity in a way. If someone wants in a VPN will do nothing to stop them
MoFscker
If you want to do it right you'll always end up with a tiered model. Your basic stance should be not to trust anything or anybody, and open up from there (a bit like getting a mortgage ;-). Second stance is to always try and have two layers of defence in place instead of one (i.e. defence in depth), like NAT + proxy, just an example. Third stance is to NEVER allow direct interaction with internal hosts. This means that inbound services (SMTP, hosting web pages) should be done from a separate interface 'between' the Net and your internal network, called Demilitarised Zone of DMZ (apologies if this is old news, just trying to keep it clear). That's IMO also where VPN users come in, they can be given proxied equivalents of internal services, that keeps a network clear from oinks that have just managed to fiddle their VPN so they end up as routers between the Net and the internal network (yes, I know your policies should prevent them doing this, but see second stance ;-). Any supplier feeds come in on the same type of facility, you could even use a separate interface for it. And last but certainly not least, describe what you're actually trying to protect as that will give you some idea of the value loss if you end up with a breach, much easier to develop some defendable idea about budget requirements. For extra bonus points you can let senior management decide to put a value on those assets (i.e. give them enough rope ;-).
;-). ;-), I prefer Unix based facilities because I end up with less patching downtime as it rarely needs a complete restart. But that's just me. And READ those logs..
But this is not where it ends, because you still haven't dealt with (a) inside abuse and (b) the possibility of failure. Good security design takes failure mode into account. Plan for when somehow your defenses are breached. Tripwire your firewalls and core systems and check them, lob the odd honeypot in the internal network which will give you early alerts that someone is scanning the place or a virus has entered (last year I caught one of them very early because of a rather suspicious Apache log) and make sure you have a patch strategy that has a short cycle time (depends on your risk tolerance, but especially your firewalls will need attention). Where possible, segregate the more critical facilities out so you can more accurately protect them (just consider your users hostile - don't answer the support phone for half a day if you want a more realistic version of that feeling
Oh, and think about what platform you run your security services on. I don't prefer a Unix over Windows because it's more or less safe (that's actually more complex than appears at first glance - donning asbestos jacket
Hope this helps. =C=
Insert
You are out of touch with current network security practices, but that's a good thing. Most security guys these days are just not thinking straight, IMHO. The first order of business is to clearly delineate your real internal network and your semi-publicly-accessible DMZ where public services are hosted. No traffic crosses the DMZ without going through a proxy service or application level gateway of sorts. Secondly only setup simple (and password protected I might add) proxies for outbound connectivity. If a group wants a publicly-accessible service facing the net, don't poke it through onto the private network - make them put a seperate server in the DMZ, and make sure they don't establish any unneccesary trust between that machine and the inside network. And lastly, the simple model of firewalling ports is always a good thing. It's just that beyond that, for the ports which must be open to certain hosts, an application-aware transparent proxy or firewall can go a long ways into making sure the traffic doesn't show signs of attack. Hooking up snort is a good thing too. Once you get the rules tuned such that false positives are somewhat rare - set it up to trigger scripts that cause a firewall blackhole on IPs believed to be attacking you, and even make it smart enough to blackhole networks when enough IPs from that net send an attack. Beware denial of service when implementing this - you'll need to keep an eye on what gets blackholed, and should probably timeout the blackholes after a week or two anyways.
11*43+456^2
Your AIX admins were running a DCE RPC app over the public Internet? Damn -- not even most MCSEs are that stupid.
why don't we put a harddisk into the application firewall and run our mailserver of it?
Maybe I'm of the older though school, but it should be the network daemon verifing the data that your firewall is allowing to pass.
Application firewall my ass, here, buy this donkey, it dosn't eat much, won't carry anything and is possibly dead - but a bargain all the same!
-A
We are a big Checkpoint shop (stateful inspection firewall). With regards to which is better, the issue seems more to be:
.gov.au sites).
;-)
1. What is the industry standard
2. What can we get support for locally.
Application firewalls have really done poorly here in Australia. I speak from experience - used to be a security 'engineer' (read, install Gauntlet), and have since moved on to network security administration.
The main vendors I've seen in the marketplace are (or were) Gauntlet, Sidewinder, and Cyberguard.
NAI dropped the ball with Gauntlet both here and abroad. The technology behind it is excellent, but the support really, really sucked. In addition, the administration was performed via a highly unintuitive java-based application, that everyone I knew *hated* to use. You often ended up simply going back to the command-line to configure the beasts.
Sidewinder I have no formal experience with, but have heard good reviews. Secure Computings presence in Australia was limited to international firms that required its use. There was no "storefront" for quite some time.
Cyberguard I have seen at a handful of places, mainly banks (and apparently also at various
All of these are technically good products. But due to their lack of popularity and market presence, they don't get used.
So it's a glorified packet filter I go to add a rule to now..
Man watching 6 MSCE's around a sun box, looks alot like the opening scene's of 2001:space odyssey...
The simple answer to this question is "Definitely not." The use of a DMZ segment to keep production machines on their own physical network segment is likely to never become obsolete because the benefits of this simple step are so great.
Whether they are or not is irrelevant. Only the barest minimum of your network should be exposed to another network (especially the Internet), and those hosts that _are_ should be unable to initiate connections to the rest of your network to reduce the impact of the loss of confidentiality in the case of an intrusion. While this may seem rather anal-retentive, to implement a proper application level firewall, the firewall can't just casually filter by generic service type. It _has_ to be able to distinguish a kosher query from a malicious one, and this requires a LOT of detailed work in the firewall rules to ensure that only the queries you want passed through can be passed. If you have a lot of custom CGIs with input parsing, this can turn into a nightmare of man-hours to maintain.
I mainly agree with you and feel that the answer is really "Almost never", with "never" requiring some support from the developers maintaining your site. If they're on-board with you on the concept of a DMZ, they'll help you by designing the production system so that connections could be made _to_ it from the intranet to extract information from the production hosts, instead of making the production hosts initiate connections to the intranet and increase the chance an intruder could do the same. If you can't control the access because it's some wacky proprietary protocol, institute a second DMZ (network cable is cheap and so are extra NICs). No other network should ever be allowed to reach inside your intranet.
Serverwatch
Microsoft's own site
ISAServer.org
The best answer is always to have defense in depth - Having a firewall in front of your web servers and email servers is good. Having an application aware firewall in front of your web/email servers is better. Having both and having a secure policy on them with AV software and keeping your machines patched is the best.
A VPN (or most likely multiple VPNs) is an additional service and should be viewed in that way rather than as a level of protection. It opens multiple long-distance holes into your network, creating potential vulnerabilities extending to the homes of your co-workers (and their teenage kids and their teenage kids's friends, etc). Rather than a solution to network security it creates a whole 'nother set of problems.
I don't think security has changed in its basics, rather the demands for services have changed how networks must compromise, as they have always had to, against those basics
The basics are (1) no services not needed on any server-level machine, strip off anything unneeded to the bones. (2) host-based firewall on every server, ideally on every host period. (3) strict default deny both incoming and outgoing perimeter firewalls (4) DMZ for any exposed services (5) monitor and scan both traffic and vulnerabilities (6) I know I'm paranoid... But am I paranoid enough? (7) If you must run Microsoft in any exposed application, isolate and proxy.
Stay away from a soft chewy center.
My company won't let me do it but in my opinion a sane network that wanted security would run nessus in destructive mode against all machines on the subnets continuously, creating a network darwinism that would allow only the correctly configured hosts to stay in place. But that's just me.
...on your specific security needs, and the needs of your user base. As always.
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.
In this case you might be able to solve your problem with pairs of nat boxes.
Let's presume tha the virus talks back on port 1022 and your office servers are at 1.2.3.4, and that's the port that you're using. .. In front of your remote boxes you'd put a firewall that (among other things) would translate outbound connections to 1.2.3.4:1022 into connections to port 1020.
On your local end, set up your firewalls to transalate incomming connections to 1.2.3.4:1020 into connections to 1.2.3.4:1022. At that point, your boxes think that they've got a clean link to each other and you don't have to reprogram the entire application.. You also have a good excuse for putting firewalls on the remote system (if they didn't have one before).
If your system has to use port 80 to get through a PHB run ISP, then so be it. If you absolutely have to, you can always run an effective VPN on port 80 and forward as many ports as you want to through that.
I actually ran into something like that where a client of mine had his machines behind a firewall that only let out a couple of ports including 80 and 20(ftp) let litte more than that back in. Luckily he had a box running Linux, so the solution was for me to run an SSH server on port 20 and havd him go:
ssh -R 12345:localhost:22 -p 20 my.ip.address.com
Once he logged in to my box, I could go:
ssh -p12345 localhost
Voila! I was then able to get into his machines and do the needed diagnostics.
Sometimes an ISP wil get a PHB idea to be 'really useful' but will get it wrong. A couple of weeks ago, mine got the bright idea to put a (simple) IPS system onto the DSL network. If they saw your box 'probe' too many machines, they'd automagically cut you off of the net. Unfortunately they didn't bother to check what port was being probed, and their IPS matched the way that a number of FPS-type games query game servers.
It took about a day of not being able to reach their help line before they puled that 'service'.
Free Software: Like love, it grows best when given away.
If your employees need remote access from home, and you are providing the laptop, consider a Linux-based laptop. No spyware, adware, viruses, email worms, etc. to worry about (assuming you have it properly secured of course...). They may complain they can't run the latest games and so on, but you're calling the shots, so tough - they were hired to do work for you. They'll probably be more productive for this reason alone, which is a second advantage.
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."
Once a box is rooted, you take it of as SOON AS POSSIBLE and reinstall.
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.
ISA is a nice and SECURE tool, if it is used correctly. It is very good for publishing services (HTTP, Exchange-RPC).
You should do a back-to-back two-layer firewall setup, with the outer ISA not being member of your inner domain. The publishable services should be in the DMZ between the two firewalls - webserver, Exchange FRONTEND. You can use the URLScan plugin for ISA FP1 to make sure no illegal HTTP options get through to the webserver.
The internal firewall could also be a non-ISA, preferably HW firewall, but then you loose some strong outgouing proxy authentication integration with AD.
Do not use ISA as a three-homed firewall, you loose all secure application and stateful packet inspection to that kind of DMZ.
What you should do is only use the sftp-server subsystem and give users a fake shell (unfortunately sshd needs it to effectively run -c ). Three lines and you're done. If they try to log into it or run anything else than sftp they get "You have no shell access" or something to that effect.
If you allow them to use scp, yes they need to have a full shell then.
That should be ... effectively run [the_shell] -c [the_subsystem] (and that's after priviledge dropping)
/code)
(original text got eaten by
These system may filter standard attacks (i.e. exploits you find at bugtraq, packetstorm) quite good, but You can image that it's easy to poke such a firewall by varying an attack. They know many standard ways of varying (like "/cgi-bin/../cgi-bin/" instead of "/cgi-bin/", or inserting NOPs into a rootshell), but there are a thousand and one way for doing the same thing, and most won't get detected.
So: Do NOT think Your $XXXXXX application level oversecure paranoia firewall ransoms You from secure network design or patching Your systems! Instead, do the usual:
- use seperated subnets of different security level (like a dmz)
- hold Your systems on recent patchlevel
- tighten Your configs, review them with >2 eyes
- use proxies (maybe with authorization). Build virus-scanner into http- and smtp-proxy
- do NOT consider Your internal network "save", so don't use telnet for administration Your internal *NIX servers
The last point is due to the fact that it's too easy to inject hostile code into a browser. Most scripting attackts get NOT detected by state-of-the-art virusscanners if they are slightly modified. So consider the desktop workstations in Your network as a bunch of trojans.To summarize: You have a excellent chance of averting 99% of all attacks (as those are known attacks of script-kiddies/zombies/...) with standard techniques like the above mentioned. You have a good chance of making a random hacker to move away to an easier target. You have almost no chance of averting a skilled hacker with time who wants to get into YOUR machines.
Hi all,
It's been very edifying listening to you guys talk about your DMZ servers and your application level firewalls and your apparently infinite budgets for admin time and hardware, but what about the real world of small (<10 employees) businesses with a single server running Windows 2000 Server and Exchange 2000 on a single network segment. No ISA, No Checkpoint, no time, no money, no dedicated admin, no understanding of why it might be a good idea. Mostly what we've got for these folks is a Linksys router portforwarding 25, 80, and 1723 for SMTP, OWA and PPTP direct to the server, and teaching somebody onsite to keep an eye out for the critical update notifier. Where does this fit in to the grand scheme of things?
When protecting a system, designing network configuration, firewall rule sets etc. The sysadmin/security specialist needs to think of how will he as a hacker from the outside compromise the system security. But when designing the system we wish to protect ourselves also from the attacks we ourselves can not think of.
We can attack this problem in several methods:
We may assume a single components can fail, for example We may wish to assume that our HTTP server may be insecure and exploitable, if this is the case we must place it in a DMZ.
We also may try and place multiple failesafes, When we think of how a hacker would try to get in we want his attack to fail in one then more place along the way. We think This attack will fail at this stage, but even if he passes this(which we can't see how he could) it will fail on a second
level, such levels might be.
Obviously the level of security must be adapted to the threat level. My home network is protected by a single firewall which allows dome incoming connetctions, yet I feel safe. I would never recommend such a setup to a large orgenization.
Dryice
Don't implicitly trust what you read on *
Luck favors the prepared, darling.
Want to attack a httpd behind a mature NIDS? Establish an SSL-session to port 443 and send Your "GET /cgi-bin/dummy.pl?AAAAAAAA..."! NIDS blinded.
To avoid this, You have to terminate the SSL-tunnel in front of Your IDS, i.e. by setting up a transparent http-proxy holding the X.509-certificate and the key-pair on Your "application layer firewall". Most products do not offer this possibility.
-Practical Unix and Internet Security, 3rd edition
Building Internet Firewalls, 2nd edition.
Securing Windows NT/2000 Servers for the Internet
Skillset, paradigm? Aren't those just buzzwords that dumb people use to sound important?
Please don't mention ISA Server and network security in the same context!
Is smoothwall secure enough for securing a small hospital ?
And I'm getting fed up with people who seem to think infection vectors are a good way to classify malicious mobile code. Personally, I don't see much of a difference between viruses, worms, malware, spyware, etc. It's all basically "bad stuff running on your computer". Some are network aware, some hide in executables, all do bad things and are pretty pernicious.
Oh and by the way, you are wrong about there being no Linux viruses found in the wild. There are several: Staog, Bliss, and Etap (aka Metaphor).
I'm proud of my Northern Tibetian Heritage
Niggers are totally a meatspace problem. Sure, they'll steal your computer, but they'll sell it right back to some other white dude. As far as I know, not a single nigger has made it onto the Internet.
Here, you worry about slopes (mostly chinks and dog-eaters) and Soviets, because their countries have no laws.
This is an arms race, and as soon as you give ground at all, you've lost.
The reason people are implementing things like 'Web Services', overloading port 80 to provide potentially insecure services on a port previously thought reasonably safe, is that they don't understand the need for security and firewalls, they're frustrated by the restrictions you - rightly - put on them, and they want to shortcut around the firewall. If you allow them to, they will. Furthermore, they will employ half trained code-monkeys to point-and-drool together some Visual BASIC abortion with no concept of security or defensive programming. At that point you've basically lost the battle. The temptation is to advance the arms race another twist, by implementing 'application layer' firewalls which can inspect traffic going through. This takes far more computational resources and is far more prone to both false positives and false negatives than simply blocking services deemed to be unsafe, so you've not only spent more money on hardware, you've given yourself a huge and ongoing security headache.
You are right: the only sensible answer is NEVER, and you need to stick to your guns. Otherwise the firewall might as well not exist at all.
I'm old enough to remember when discussions on Slashdot were well informed.
I have a few thoughts on security:
Every computer inside a firewall should be as secure as possible. One compromised computer should not necessarily compromise your network.
Web service responses shoudl be document centric - SOAP is best used not as RPC but as a rich document (XML payload) request. Make requestors sign their requests.
Use SOAP over HTTPS.
Avoid using Windows :-) (Hey, this is /.)
-Mark
Many years ago I ran across a listing of many corollaries to Murphy's law: Many of them apply to security admin (some directly), like:
One of the first rules of security admin is 'presume that any given layer will fail'. This is why you have a DMZ (with or without application-layer firewalls). It's not that you expect your firewall to fail, it's just that you don't bet your company on it not failing.
Similarly: allowing VPN users unfettered access to the internal network is allowing any of the bugs they catch on the outside in. This is why VPN's should go into their own DMZ that allows access to only necessary ports/services into the local network.
Application level firewalls aren't bad but they ARE more complicated than simpler firewalls. As such they're more prone to complicated failures.
IDSs (intrusion detection Systems) are a nice last resort. They don't (usually) stop attacks but they do look for signs of anomalous activity and warn you -- allowing you to take corrective action faster. IPSs are essentially IDSs with the ability to block suspicious actions almost in real time -- Unfortunately, the cost of a false positive with an IPS is far higher than with an IDS (i.e. Denial of service).
One problem with IPSs is that they open you up to a denial of Service attack of feigning a real attack == thus causing the IPS to lock down the 'attacked' service or machine.
Application level firewalls have some nice things about them -- they make it harder to do things like buffer overflows on your system, but that doesn't mean that the 100% prevent someone from breaking into your system. As a worst case, their complexity is their Achilles heel. an attacker may find a way to hack the firewall itself then you're just a Owned as if they'd hacked your web server to start with.
any salesman who tels you that an Application level firewall is so good that you no longer need a DMZ is just that -- a salesman who doesn't understand the principles of security and is spouting blather put together by their PR group to sound really good to a C[EFT]O who also doesn't understand the principles of security.
To understand the principle of things like DMZs, consider the history of WW2 resistance cells. Having the resistance be one big group would have made administration much easier, but it would have made them vulnerable to infiltration by one or two German agents, or the capture of one or two leaders who knew who everybody was.
Instead, The Resistance compartmentalized into small cells. Thus capture of even central leaders would only lead to the compromise of one or two cells, instead of an entire region.
Similarly, DMZs and other functional groupings of your network mean that 'capture' of one section means that you don't have to worry about having your ENTIRE company to clean up. It also means that you (hopefully) have a bastion of (hopefully) clean systems from which to start your cleanup campaign.
Depending on how big your network is, there are various ways of grouping things. For me, the minimal grouping would be:
Free Software: Like love, it grows best when given away.
I think the single most common point of "failure" is usually overlooked in IT security as it is in many security practices (asset, facilities, etc.). Security professionals tend to focus on the target and neglect the threat. With that in mind, it is important to realize that not only is the black-hat outside your network a threat, but so is the happless user who makes a poor judgement call and unintentionally opens up a window of opportunity for threat and vulnerability to come together into that lovely crescendo of "incident". Not to overstate it, but the "Human Factor" has to be the second place we look (do you trust the people in your house after you've gone in and locked the doors?). Over the years I have found the vast majority of "incidents" to be unintentional either in whole or at least in creation (but not exploitation). The ONLY way to overcome this is:
1. Have a written security policy that EVERYONE is required to read, understand and sign.
2. Enforce the aforementioned. Make specific people accountable for specific actions. Make bringing in your own Linksys WAP11 and dropping it on the LAN a terminable offense.
3. Educate the end-users for God's sake. They have the power to make a mess of things. They don't have to be experts but they have to undertand that which they bear responsibility for.
You are responsible for the hard core security (perimter, IDS, etc.) but the end-users are responsible for their part as well. If either party fails, everyone suffers.
Just my two cents.
ER
Companies are not going to jail their users, so the first one who wants to listen to mp3's or streaming music, up goes Real, or Windows Media.
The problem with your reasoning here is that letting employees listen to most of the audio files available on various Internet services may result in the employees and the board members being tried for copyright infringement and going to a real prison[1]. Besides, there exist many purportedly-lawful[2] streaming audio services, such as MP3.com radio, that use HTTP on port 80 outgoing.
You want to see the stock ticker from Bloomberg? Sure now you have multicasting crap.
There exist stock tickers that retrieve data by pull, often via HTTP, rather than by push. If they need up-to-the-minute quotes, they shouldn't be day trading on company time.
[1] Please do not respond along the lines of "copyright infringement is a tort not a crime" without having read 17 USC 506.
[2] Some of these are Internet radio stations authorized by the recording artists. However, can these artists prove in court that they actually wrote the songs they claim to have written, as opposed to having some copyrighted earworm from 30 years ago pop into their heads?
Will I retire or break 10K?
In order to secure a SOHO, it rarely takes more than IPCop has to offer. This is probably the best solution, having a restrictive firewall with an properly configured snort IDS behind...all accessible via a simple webbrowser. DMZs, Graphical Logs, included proxy, dial on demand...hell, even patching works via browser!
I'm satisfied. Application Level Firewalls are useful when there's enough differentiated/sophisticated traffic to justify the ressources spent - and enough money to pay for them. For SOHOs it's just overkill.
We were unable to compromise or otherwise DoS either of the two NT servers with readily available exploit code for IIS or otherwise on either operating system.
Couldn't DoS it? Have you tried posting the public URL of a page on the NT4 box to Slashdot? That will DoS it by simple network congestion.
Will I retire or break 10K?
Check out FortiNet. They do seven layers, NIDS and antivirus all in ASIC (also BSD/OS based, I think). Very f'n cool.
Can I bum a sig? I left mine at the office.
might it be possible to train a firewall that certain types of DDOS attacks might be "bad traffic", such as repeated requests on certain ports, opening large numbers of http connections without continuing the transaction, etc?
It would be perfectly easy for somebody to coordinate a DDoS attack on an HTTP server and still continuing the transaction. A 13-year-old could coordinate it (through his l33t n3tw0rk of Z0mBi3z), and so could Mr. Malda (the Slashdot effect). What firewall protects against simple congestion on the connection to the ISP from many outside sources whose IPv4 addresses show no distinguishable pattern?
Will I retire or break 10K?
These "internet-accessible machines owned by the bank ... hosted in offsite colo facilities that have no direct connection to [y]our network" -- do they have sensitive/valuable data on them thet they publish to the world? If so, all you're saying is your megabucks employer trusts the colo's sysadmin more than he does you when it comes to securing his sensitive data.
Colo's have DMZs and internal nets too, y'know. I have heard the argument far too many times: "I know how to secure it... we'll host it totally offsite and pay someone else to handle it!" While that may in fact mitigate the threat to your internal servers, very little is available to you regarding access to the servers in question.
I personally like having all my servers located where I can physically touch them (and disconnect their cables physically if need be). Also, my IDSes and monitors get more of a sense of the rise and fall in the "noise floor" when they're all at home. Hearing this chatter is especially useful when the bottom's about to fall out on the next mega-worm, or even sooner when the real threats are probing for the exploits they have now and you don't get a patch for till two weeks hence.
Can I bum a sig? I left mine at the office.
As other replies have pointed out, defenses must be layered. As I've said before, the presence of a wall around your city is not an excuse for not locking your front door. And even within our own homes, we have doors, sometimes with locks, between rooms.
Kinda like Tripwire , Symantec Anti-Virus, RedHat Enterprise Linux's dymanic relocatable address to fight worms, OpenBSD StackGhost and ZoneAlarm Firewall all rolled in one.
Once implemented, we should see a dramatic change in the network security world; less IDS/IPS/IDPS business model.
The last frontier would then be the social hacking engineering prevention.
Mark Mah Words
A firewall doesn't have to be restricted to simply blocking/allowing certain ports. It can do rate limiting, logging, and other things that your network services may be unable to do themselves. Instead of re-inventing the wheel for every program, many authors choose to include tcpwrappers support. A packet filter can be viewed in a similar manner, except that your application doesn't even have to support it.
Generally, I want it all: only enable those services which I need, lock them down as far as their own settings will allow, and then put a packet filter in front of them. Maybe they don't have the ability to restrict which networks/hosts can connect to them; the packet filter adds that ability. Or maybe they're badly written commercial software that can't turn off/restrict services on their own. Hopefully not, but there's some awfully crusty niche software out there, and some of it runs on NT4 to boot.
That's not even addressing the needs of a location where you may not have control over your end-users' machines, such as an ISP or a college campus.
WMBC freeform/independent online radio.
... most of this information is available via google. Since it is scattered and very inconsistent, I will help you anyway.
>As a Sysadmin, understanding network security is clearly an important part of my skillsets
Absolutely. It is arguably the most important part of your skillset, especially if you don't have a network security director, and/or are involved in buying decisions.
>Are network services becoming so complicated that application level firewalls (such as ISA Server) are absolutely necessary?
It's not that the services themselves are becoming complex. The point you need to understand is that the type and variety of services available, some running on each other's ports, necessitates more than just port management. You need to be able to detect, for example, that kazaa is running and kill that traffic. Since kazaa uses port 80(or is it 8080?), and so do your internet browsers, you can't simply allow access to 80.
You need to keep the AIM users from simply switching to port 21(ftp) and circumventing that rule you have about the OSCAR port.
>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)?
Absolutely insufficient.
>has the paradigm of 'if you offer external services to the Internet then place those machines onto a perimeter network' been eroded?
Not if you know what is good for you.
>Are application level firewalls sophisticated enough to allow machines on your internal network to advertise services to the Internet?
There hasn't been a piece of software written yet, that can't be comprimised. Advertising services from internal machines exposes software which may be vulnerable, to everyone in the world to run scripts against it.
If they comprimise the software, they can oftentimes control the machine. If they control the internal machine, they are that much closer to either wrecking or stealing your information.
Newer firewalls are smart enough to detect some of these attacks and drop the packets into bit bucket, but some things aren't necessarily detectable as an attack. Where there is a will, there is usually a way.
>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.
I will undoubtably be flamed for this, but your instinct is correct. There is almost always another way and if there is another way, you should not be exposing internal machines. If your software can't do without this two way internet firewall hole, you should find something to replace it.
Where I work we have a one way trust. Internal machines can go out to DMZ and pick up messages, files, whatever. The DMZ machines cannot initiate contact with internal machines.
This is accomplished through the magic of message queues. Explaining how this works is a bit much for this thread.
To all of you exposing your databases on the internet and think I am full of it... I work at a bank. I think in banking terms when it comes to security. If you flame me as being paranoid, I will take it as a complement.
When you get comprimised, and your customer's identitys (or yours from the HR database) get stolen, you will understand: )
l8,
AC
Software Engineer/Software Security analyst.
(yes I wear two hats. I work closely with our security director)
Although there are some excellent points raised here by some extremely knowledgeable people, I think the status quo is too complex. The average sysadmin/security tech today is dealing with: numerous security applications, which may or may not be compatible with each other and ultimately may compromise the actual business model of the enterprise in the name of security; careless and reckless human behavior; and what I call the patching polka and the intrusion detection dance, just to keep their heads above water in an imperfect system that can't be guaranteed 100% foolproof. No wonder security people/admins are overwhelmed! I'm helping a small startup that has come up with a new approach to Security. The developer has found a way to convert any stock Linux system into a manageable trusted operating system, complete with mandatory access controls and fine-grain auditing of all system users, in literally minutes. This advanced security system, called Praetor, protects against external and internal threats, and uses pre loaded templates and an interactive GUI, so is a real time saver. It seems to me that this system could act as a last line of defense, as it protects the core of the system, and augment any other security system. The more I learn, the more I am thinking of getting even more involved. Can anyone tell me if there is potential in a product like this? Check it out at www.googgun.com. (Warning, the system is commercial and only works with Linux)
Granted, it's better than nothing, but it can be broken quite easily (I'm sure you already know of some of the open source WEP cracking tools, heck even on a 486 in reasonable time now). I'd use WEP, sure, but I feel better in starting with a default deny policy, good rules for keeping state of each connection, and then only allowing access by MAC. Once more, NOTHING is a panacea, this is all just part of a process....but if we're giving advice, let's not pretend WEP is really that good on its own.
You have to consider each piece individually. Trusted users are one component, Untrusted users that still need access to internal resources are a component, Untrusted users that need access to public (Internet) resources, and third party connections (VPN or hardline).
In reality, you should have very few trusted users, mostly sysadmin types that need all access, and these folks should be authenticating to something everytime they need to use an all access connection. Most users should be untrusted, and as such I would consider using something like an SSL VPN/Reverse Application proxy cluster.
The untrusted user's connection would terminate on the SSL device and the SSL device would initiate the internal connection. This would help remove the risk of infection, among other things. This SSL device would be located in a DMZ network (between two firewalls) so that only the SSL device had access to the internal network, and only on ports that you specifiy based on applications you publish. There are some devices on the market that will allow you to initiate a Windows Terminal Services session, or even an X session with an internal host, adding another layer of security (also complexity, latency, etc).
Third Party connections should have a DMZ of their own. VPN connections should be terminated on devices between two firewalls (consider it a b2b dmz) to allow access only to resources absolutely critical to that partner.
And of course, for "Public Resources", or those generally accepted to be accessible by anyone from the Internet, you need to construct a dmz arraingement. Allow from the Internet the ports required to provide the service being published (http/https only, for example), and only to hosts in the dmz. Generally, try to construct applications on a push/pull basis so that all connections between dmz hosts and internal hosts are initiated by the internal hosts.
If you do this, use a general attitude of deny any any unless there's a damn good business case, and pay attention to patches, updates, etc. you should be ok.
Sig??? I don't need no stinkin Sig!
... is a "bad thing."
For Chrissake, lighten the hell up. Work is boring. There's a lot of people out there who are extremely overqualified for their jobs who could do them in their sleep, but cannot find anything more challenging because the market sucks.
Can you blame them for wanting to IM/surf? As long as this behavior doesn't expose the organization to network security holes (sorry, but exchange of text doesn't cut it), what is the BFD?
Rather than make blanket statements of "if it isn't absolutely NECESSARY to be on, it's off," why don't we actually do our jobs as sysadmins and actually investigate whether or not a given service will cause problems when being used?
+++ATH0
I used Google to try to learn what "mandatory access control" means, and unless I'm reading this result wrong, it seems to have something to do with digital restrictions management.
Will I retire or break 10K?
I haven't seen many people touch on a Recovery Plan.
Not every solution is going to be water tight, and even then you can be compromised. True, protect your network the best to your abilities. If you over-kill, you'll have the users mad at you for killing bandwidth, but you'll sleep better at night. However, What if something devestating does get through? Do you have a good backup plan, is the CEO's and other VIPs PST files for Outlook backed up? If you walk into the office tomorrow to find that someone physically stole all of your computers, the place burned to the ground, etc., can you safely say that you can recover all that data? My 2 cents anyway.
I read about people saying that ssh, firewalls, ids, etc.. are an absolute must for any serious setup. I agree sort of.
:/
Many of you probably dont hack. You dont audit source code for your own unique hole. Dont consider finding a local linux bug on redhat like a chess game. (sudo).
So say you setup this secure crazy lan that no one can hack. That is with publically known bugs.
So you just stopped 99.99999% of people from a remote hack. Now, for true remote, there are a handful of ppl left world wide who can find bugs in serious open source software and code the sploit for them.
You are not going to stop them anyway. So you just spent $$$ to stop children. When patching your damn daemons would have done it too.
Oh yea, i want a firewall upstream of my lan. fuck having it at the tail end of the t3. now that would be something. no calling for ddos on my dialup
m
vayase a barrapunto, por favor
The issue is that treating the problem of security at 2 levels (network and application) is flawed - each specialist area thinks the other is doing everything.
The real goal OMHO is to dumb down the need to network security (i.e. stick to firewalls, routing controls and simple protocol checks) and boost security at the application messaging layer.
The 3As (authentication, authorisation, accountability), confideentility, integrity and content inspection/management are a must.
SSL, SSH and VPNs et al don't enable any of these attributes at the application layer.
For those wishing to transform themselves into viable internet entities ffrom the early adopter mmodels, look for application level security tools.
There were some very smart guys about 30 years ago who "knew" security.
They had it figured out. It came down to a secure kernel, and from that secure kernel they developed a reference monitor model and successfully tested this model in Multix.
Another good read, google for "What is there to worry about? An introduction to the computer security problem?" -- by Brinkley & Schnell
Some of the guys who knew what this game we call security is all about are:
Willis Ware
Donald Brinkley
Roger Schnell
Ross Anderson
Now this does not directly answer your question...but these guys say that a firewall SHOULD NOT run at the application level. Certainly the material changes the way we as Info Sec, Info Assurance, Info Tech. professionals THINK about security...
Only application level firewall I have had to work with is Microsoft ISA Server. And from experience I can say that it is too "easy" to use and doesnt offer the features of a real firewall. By using ISA you are expected to use NAT and you cant even do one-to-one IP mappings. MS can do a lot of "nice" things with ISA, but really ISA is Microsoft's first try at firewalling and you can see it lacks many features a real firewall would have. Dont be fooled by all the gizmos of ISA Server. Yes it's easy to use, but that doesnt mean everyone and their mother should setup one cause it looks like friendly Windows UI program and is easy.