Slashdot Mirror
Ask Slashdot: Is Running Mission-Critical Servers Without a Firewall Common?
An anonymous reader writes: I do some contract work on the side, and am helping a client set up a new point-of-sale system. For the time being, it's pretty simple: selling products, keeping track of employee time, managing inventory and the like. However, it requires a small network because there are two clients, and one of the clients feeds off of a small SQL Express database from the first. During the setup, the vendor disabled the local firewall, and in a number of emails back and forth since (with me getting more and more aggravated) they went from suggesting that there's no need for a firewall, to outright telling me that's just how they do it and the contract dictates that's how we need to run it. This isn't a tremendous deal today, but with how things are going, odds are there will be e-Commerce worked into it, and probably credit card transactions... which worries the bejesus out of me.
So my question to the Slashdot masses: is this common? In my admittedly limited networking experience, it's been drilled into my head fairly well that not running a firewall is lazy (if not simply negligent), and to open the appropriate ports and call it a day. However, I've seen forum posts here and there with people admitting they run their clients without firewalls, believing that the firewall on their incoming internet connection is good enough, and that their client security will pick up the pieces. I'm curious how many real professionals do this, or if the forum posts I'm seeing (along with the vendor in question) are just a bunch of clowns.
So my question to the Slashdot masses: is this common? In my admittedly limited networking experience, it's been drilled into my head fairly well that not running a firewall is lazy (if not simply negligent), and to open the appropriate ports and call it a day. However, I've seen forum posts here and there with people admitting they run their clients without firewalls, believing that the firewall on their incoming internet connection is good enough, and that their client security will pick up the pieces. I'm curious how many real professionals do this, or if the forum posts I'm seeing (along with the vendor in question) are just a bunch of clowns.
Everything is Fine.
Is stupidity common? Yes. Yes it is.
In my experience, the stupid people tend to get fired eventually. But the mess they leave behind can be tremendous.
Not just because plenty of things are run by stupid people, but also because otherwise smart people can have pretty damned important blind spots. And other IT people have been talked out of it by their clients just like you're letting happen.
Whether it's common or not has no bearing on whether it's a good idea.
The only question you need to ask them is weather they're willing to accept the quantified risks from having exposed systems.
Is there a reverse proxy and a DMZ to the outside world and transparent VPN on the internal network between the database and the clients?
Apparently only if you possess data that someone else might want... ;)
It sounds a little like you're trying to just fling a firewall at the system and improve some sort of objective security metric.
What threats are you risks to mitigate with the firewall? What threats will it help guard against?
They don't come for free, and configuring them don't come for free.
If it's a Windows box, the firewall for the local subnet is down if the "Network Location" is a "Domain Network" anyway, so it really doesn't matter.
--fatboy
When I came here, the AD server (2003) where the Oracle Sales DB and the ERP were installed were in the called "DMZ" (at router level) because "Somebody in the European HQ wanted to browse some tables".
Yes, that's in a home router, DMZ, where it means "route everyhing that doesn't match a rule to that server".
Aaaaaaand it had cornflicker. The DC. The DB server. The ERP server. All-in-one and out of our control.
The reality is that there are a lot of enterprisey guys who don't have a clue of what they're doing.
=/
I've set up networks where the server infrastructure itself is on its own segment, so there's no need for firewalls between the servers themselves, but the whole subnet is firewalled by a border router.
A lot depends on how tightly you can lock down a server. On my *nix boxes, I tend to only run daemons with listening ports to the extent absolutely necessary. I have a LAMP server that basically has ports 22, 80 and 443 open, and everything else either shut down or set to listen only on 127.0.0.1. Do I really need to configure iptables?
The world's burning. Moped Jesus spotted on I50. Details at 11.
As soon as they start handling credit card transactions, they will need to conform with PCI standards, which will mandate much much higher levels of protections. There are significant fines associated with non-compliance so you may want to forward them over information about this.
The key is to only ever run the services that are absolutely needed, carefully configure these and keep them up to date. If you follow that advice a firewall is an added level of security but not necessarily needed.
Is there a reverse proxy and DMZ to the outside world and a VPN between the clients and database server on the internal network? This will mitigate some of the risk.
Could you repeat the ip address of this server, you know, for research and the children... :)
They don't prevent attacks, nor do they keep your data in. If you correctly secure your infrastructure, ie by using point to point, white listed communication pathways, you have done more than a firewall will ever do.
Firewalls are just like the TSA. They sure say they do their job, but do you really believe them?
Is a POS vendor used by most Australian newsagents. Their contract not only mandates the lack of a firewall, but a writeable share of the C: drive on the Windows machine acting as a server - with no authentication.
While this is incredibly negligent, the support contract makes the vendor completely liable for any security breach that occurs while honouring their contract requirements.
The problem with this battle is that you're a contract worker. So if reasoning/persuasion doesn't work, then you're only options are to end the contract, or fulfill your obligation.
Keep documentation that shows that you brought up the problem, and were rejected. Bake in language on subsequent contracts that give you an out under these types of scenarios, and move on.
If someone is unwilling to listen to reason, is in a position of power, and there's no laws that they are breaking, then that pretty much gives you all of the information you need to know about your options! Just learn to stop worrying and love the bomb.
I don't run a local firewall on my work system, for reference. As a developer, it's common to need to have "random" ports open for various things for testing, and having to deal with a firewall is one more nuisance I don't want to account for. A local (on system) firewall won't prevent most attacks anyway, so I don't feel I'm giving up much real security.
I do run a local firewall at home, but only because it has not annoyed me enough to be disabled yet.
I don't know how useful that information is; consider it a data point.
PCI v3 compliance *REQUIRES* a firewall. End of story. Do not pass go, do not collect $200.
If your database is in a trusted network zone, it's fine.
If you have a bunch of assets outside the corporate firewall, you're doing it wrong. These belong behind a DMZ firewall, blocking any ports not strictly necessary, possibly with PNAT and coalescence (i.e. an FTP, Web, and Mail server, natted to the same address, ports 80, 443, 25, 21, and FTP PASV going to different addresses behind that).
Within that DMZ, servers provide whatever services they're going to. MySQL on port 3306 will provide MySQL on port 3306; if you add a local firewall, you will have a firewall that blocks all non-listening ports and leaves port 3306 open, so no difference. If you're worried about ssh, use an IP console card (DRAC, etc.) on a separate subnet, or put the database servers behind another firewall. It is, in fact, common to create trust zones for front-end, application, and database, such that i.e. your Web servers connect through WSGI to a CherryPy application, which connects back to a Database, through a firewall in each step. You can do this with vlans and broken-down subnets, one switch, and one firewall.
You have to consider everything when you design secure network architecture.
Support my political activism on Patreon.
The 3 machines are presumably firewalled from the broader internet?
The server isn't offering services beyond those needed by the clients?
If these are both true, I'm not convinced a local firewall on the server offers much security benefit, and is yet another thing to configure/troubleshoot.
What is the gain from running a local firewall? There are significant downsides in maintenance and troubleshooting time (not always, but not infrequently in my experience).
Depend if you have ports open? Some OSes install a lot of extra crap that you cant remove and should firewall off, but its not always the case.
Usually a firewall is a good thing, as it can drop packets that would otherwise use your programs, but it is possible that the only ports they have open are the ones they are meant to access, in which case it doesn't really do anything for you unless you set up access rules.
In some way every third party vendor does this. Anything that can potentially complicate their installation or support gets eliminated, rather than configured in a way that is appropriate or best practices. It reduces their support cost and increases their profits. Overspecing hardware and network resources for their app is another area where this is done.
Well, whether this practice is common or not is probably irrelevant, it is still not a prudent thing to do.
I build and supply retail chain management software to a number of chains, there are dozens of stores that use it, we switch at least one computer in a store to a Linux machine that runs the store management software (the chain management software is a central system and it doesn't run in a store, but all stores talk to it.)
Store management system is on the Linux machine that faces the Internet, it has 2 network cards, one is the Internet and the other is LAN (the same machine controls the LAN). Since this is Linux, iptables is used to filter out any unnecessary traffic.
I think there should be some sort of packet filter on Internet facing equipment, POS or anything else.
You can't handle the truth.
From the sounds of it, you're discussing disabling a software firewall, not an actual hardware firewall. There's a lot of applications which require local firewalls to be disabled - for instance, we disable local firewalls when we're deploying telephony application servers because of vendor requirements. Likewise, some applications require SELinux to be disabled as well. All of our servers are still collectively behind a firewall, and beyond that we have a number of ACLs and centralized authentication controlling them. As for not running a firewall being lazy - firewalls are tools. Sometimes they're the right one, and sometimes they aren't. The only way to tell is experience on when to use each tool (and budget too). The more time you spend with networking, the more you'll come to realize that. But since you're learning, stick to what you've been told until you master it. As Picasso said, "learn the rules like a pro, so you can break them like an artist."
Plenty of companies do. This is standard Operating procedure for ISP's and online services. Google, Facebook, Ebay all do. If your server needs to be accessible from the public Internet then yes. Firewalls are overrated as a protection measure. If you can run them from behind a firewall then I see no reason not to unless you have to open a bunch of ports to allow access to the server in which case the firewall won't help much. This is usually port 80 and it's where most of your attacks will come from anyway.
If only a select group of people will be accessing this server from the Internet then the safest way may be to make it accessible only via VPN. Users would have to log into the VPN first. Much stronger protection than a server behind a firewall with ports open.
They can write whatever they want in their contract, but that means jack and shit when it comes to complying with federal regulations. They're required to run a firewall, and if they can't code to comply with that, then you should alert the appropriate regulators.
A zoned security architecture is always best and implementing intra-zonal firewalls is likewise a best practice however there's always pragmatic considerations because of cost or risk of the information being protected. If any of the servers are Internet facing or face an internal desktop network, that should be firewalled off at a minimum.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
... to run mission critical servers on Windows?
It's the only OS on which "to firewall or not to firewall" is actually a question.
On a proper OS you would only have the minimum services necessary open... and a firewall would add nothing.
http://blogs.technet.com/b/exchange/archive/2013/07/17/life-in-a-post-tmg-world-is-it-as-scary-as-you-think.aspx
Microsoft seem to indicate that they do NOT use a firewall in front of their Exchange and SharePoint systems; no UAG, TMG, nothing. BUT, they admit that to do this requires a very different way of managing security. The Application Development and Support people MUST take FULL responsibility for keeping their applications secure, and CANNOT just leave security to the Network/Security teams. The days of securing buggy software by sticking a security appliance in front of it are gone, but many IT departments have NOT caught up with this yet. Networks and Security people still don’t trust Microsoft applications to be secure, while Application people think Security is something Networks or Security people should look after. The perimeter collapsed and nobody noticed....
Bob G.
The OP makes it sound like their environment is not running a firewall at all. Do they have a hardware firewall that sits between the outside and inside? Do they have a DMZ?
If they have a hardware firewall and other security appliances, there's not really a benefit to a firewall on an internal server, and it can get in the way of specific services or necessary apps needlessly.
If they have nothing between the server and the outside, however, then yes, a firewall is necessary.
Is your firewall "mission-critical"? I meant if your mission involves being accessed from the outside then the firewall is as critical as whatever stuff behind it that you are trying to access.
If the POS (point of sale... although if the vendor are as lax about their quality assurance as they are about network security, that might just also stand for "piece of shit") and the back office PC are completely isolated from the internet, then I would agree there is no need for a firewall. However, retail POS systems almost always now come with a built-in credit card payment system instead of having separate terminals for that... so the POS cannot be guaranteed an airgap out to the internet unless the POS vendor is also supplying a separate credit card payment system with separate hardware that will reside on a completely separate network from the POS and back office system.
My advice to the OP would be to register their extreme dis-satisfaction with the setup verbally with the client, and in writing/email to the client and vendor, detailing the concerns about data security. That way, it at least limits OPs liability for the inevitable fuck-up and loss of customer credit card data to the time and effort involved in hiring a lawyer and producing said documentation when the shit hits the fan and law suits alleging incompetence start flying.
From experience, I know that as the 3rd party implementation consultant, you are nothing more than an annoying buzzing sound to the vendor unless you get the client on board, and even then it will still not work unless there are break clauses around client satisfaction built into the vendor-client contract. All OP can really do is cover his/her own ass, do their best to educate the client about the dangers involved, and leave it at that.
No firewall is probably because the vendor is too lazy to figure out how to configure the POS firewall so that they can still connect to it for remote support/maintenance tasks.
Back in my consulting days I would throw in an openbsd firewall running on a customer provided machine as part of my services to them. The customer would get the documentation and passwords for it as part of the deal for whomever followed me. It was the ounce of prevention vs the pound of cure. Customer's who wanted wanted to just hang their gear on the internet without it were customers I declined to deal with.
Its true the customer is aways right. But they can be right with someone else. I had a reputation of providing a quality service. Not going to sacrifice my good name and reputation with reports of shoddy work.
we run firewalls on the hypervisor a'la vGW. But a firewall won't stop people from doing stupid things, but it sure makes day to day annoying as shit.
For incredibly inept companies that really know nothing at all about security to run without firewalling.
Make sure you have a clause written in that without a firewall your client is fully responsible for any and all damages their unsecured server will cause.
Do not look at laser with remaining good eye.
I do a ton of infrastructure builds. From a few boxes to 1000's of VM's. There is no excuse for no firewalls.
If a vendor is disabling the firewall then they should absolutely be approached. If the clown you are talking to says that's the way it's done then go over his head. Tell your boss.
Be gently of course. Doing the run around my hair is on fire dance is not going to win any one over.
You can even help the vendor. There are a ton of tools for all OS's that will help you determine the port that need to be open. Simply run up the software and scan the open ports. Tada you have a simple set of fire wall rules at least. Are they perfect? Of course not they can be improved on. But it's something at the very least. I'm not overly a fan of point to point rules in firewalls as they are self defeating in the long run. ( This is a longer story )
So yes host firewalls should always be enabled. And the rules you use better be documented.
There are plenty of mission-critical servers run without a firewall. That's because they provide services (web hosting, DNS, and the like) to the internet at large, and the firewall functionality is built into the server.
This is called a "bastion host". It runs a severely stripped-down system (for both security and performance reasons), and is usually reimaged periodically from a secure master copy.
So yeah, I do it all the time. There's no need for a separate firewall. But the server is configured from the ground up with a heavy emphasis on security.
Now, did this vendor provide a highly secure OS image and a process for reimaging it if there's a problem? Or did he just give you a binary to install on a generic MS-Windows install?
In the latter case, the vendor is a fucking idiot.
The most recent one I'm dealing with is an IE-specific browser-based EMR (electronic medical records) package that apparently has some issues with newer Flash versions, and by "newer" I mean "released within the past 3 years." They want us to roll back to some version of Flash 10.x (the product mostly works with newer, but has some very annoying delays).
My basic take on this is to go to the practice manager and say "According to the EMR vendor, their requirements are that we run an incredibly insecure configuration. I can do that, but my recommendation is that if we do so, no computer should be able to use both the EMR and other parts of the Internet." It makes me wish we were a Citrix shop; I'd set up a terminal server/app server running that insecure configuration, then just share direct app access via desktop icons for the end users.
fencepost
just a little off
But it's a terrible idea.
If this is what your vendor is telling you, they're either lazy or incompetent when it comes to security.
My advise, you need to get management to sign off on it to do a little CYA, otherwise someone is going to blame you for this when you get hacked (assume there is no 'if' in this situation).
If they've signed a contract with this vendor saying it "needs" to be ran without a firewall, then the person who signed that contract wasn't reading carefully, or didn't understand what they were signing.
Telling you that you don't need a firewall is like telling you that your car doesn't need brakes -- it should be a giant warning that someone is either lying to you, clueless, or doesn't give a damn.
"Real professionals" are paranoid about security, and don't take stupid risks. Me, I'd go with your assessment of "bunch of clowns".
Yes, this might be a small shop, and with a limited budget -- but hanging your production database outside of a firewall is just asking to get pwned. You can safely assume someone is trying to hack into you right now, because there's a good chance they are.
Lost at C:>. Found at C.
Your post is not clear on what you mean by "without a firewall". There are so many places in a typical setup where a firewall could be placed, and yes, it is safe to leave them out in some situations.
For example, your store has a firewall at the internet connection and everything inside is a private ip address. The cash registers run on their own network, firewall'd away from the other computers in the store, with rules to allow for outgoing credit card authorizations and that sort of thing. Does each cash register need a firewall? Probably not, and it might even be a significant expense to maintain updated rules every time the network needs to be reconfigured.
So yeah, it depends on the entire configuration. The tone of your post suggests that the situation is not good though, and of course, it's a lot easier to argue for a firewall these days than against one.
You need to look at the PCI-DSS requirements because this is what dictates the security standards of your network if you are storing credit card information. Specifically PCI-DSS dictates (not your contract) that there needs to be multiple levels of firewalls. Ergo you will need a firewall in front of the web server. You will then need a separate firewall in front of the DB servers. And the preferred setup is a three or more tiered system. Web server with firewall connects to the Application (WCF / web service server) which also has a firewall, which connects to your database server which also has a firewall. Also note that I am referencing hardware firewalls such as a Cisco ASA or a Dell Sonicwall. The servers should also have their own software firewalls enabled whether it's Windows Firewall or Linux IPTables. With that said we are "supposed" to be PCI-DSS compliant and should be for the sake of liability (and doing it the right way). Unfortunately I know many vendors who don't want to spend money on proper setups and run very insecure systems. If you can avoid it don't work for these people and go find a client that has the budget to do things right. PCI-DSS: https://www.pcisecuritystandar... A better option for a cheap client is to not store any customer data and use a tokenized system. Authorize.Net will store all sensitive data for an extra $10/mo and allow you to skirt PCI-DSS regulations. You should still run a firewall though and be as close to PCI-DSS as possible though. http://www.authorize.net/solut...
Some industries do make it a standard to disable firewalls on everything except perimeter devices. Networking talent is rare in these industries so it makes a certain amount of economic sense. You might be surprised to hear that SCADA and industrial control are one of the industries where this is common.
It's not totally crazy, either. If you know that if anything were to ever get on your internal network, you're going to be more diligent than usual about letting things on it. If you put all your eggs in the perimeter firewall basket and it's pretty good, then what's the problem?
Well, here's a big difference: the guy running your water plant is way different than the minimum wage guy you have running the till. The cashier has more incentive to attack the system, especially if he can get away with running a skimmer without getting caught. But the cashier has physical access to the system for several hours per day! What's the firewall going to do to stop him? He can just reboot the machine into an OS he controls, then turn off the firewall by writing to the disk directly.
There's another more important problem: if SQL Server Express is involved then I'll bet the PoS app is doing cleartext database writes, which might include credit card transactions in the future. If that's the case, the firewall has to be configured to allow these writes in cleartext. Mr. skimmer guy just needs to put a tap inline with the register's network port to get all this data, firewall or not. The app is the problem here.
Security is a people problem. Think about your staff and your vendors and choose them wisely. Until that's done pontificating about firewall best practices probably shouldn't be your first priority.
-- thalakan
A firewall between you and the outside world, yes, absolutely. If you have to open ports to your network, that is expected, and you should make every effort to minimize those ports and encrypt when possible. If you can establish a DMZ even better.
Internally you should be maintaining a secure environment anyhow, so there is no need. Between users and vulnerabilities, I can understand why people would want to turn on internal server firewalls, but generally no I don't see that happen. And that's from small to very large corporate entities. Mostly what I see is people who don't know how to manage their networks, or don't understand security, saying 'well I'm going to turn on the firewalls and now everything is Secure'. Most applications on internal networks expect wide ranges of ports to be open, and yes that is normal. If you have the time to manage every server at the port level, go ahead and enable them, but most administrators do not have enough time to handle normal day to day activities, let alone micromanaging networks like that.
I will shred my adversaries. Pull their eyes out just enough to turn them towards their mewing, mutilated faces. Illyria
Seriously. Don't do it.
I had a smallish consulting client from 6-7 years ago that ran their Oracle server on a system that had no firewall protection, because it made it easier for the application server to get to it. It also simplified remote access by a contract developer. As the remote DBA, it was also easier for me, although I advised against it from the beginning.
Sure enough, an intrusion happened (whether my script kiddies or someone more serious I don't remember). The intruders left behind a lobotomized database and who knows how much rootkit. The latter was the bigger issue, as a big part of my job was to ensure that reliable database backups were being taken. I knew I could recover with what I had, but the admins had to know the system was uncompromised.
So...a good day or two of downtime resulted as a new system was built and deployed. (It wasn't a mission critical system, which is why contract offsite DBAs and developers were used.) I restored the database, AND a firewall was put in place to limit all but the most sophisticated of intruders. I also configured CMAN (Communication Manager) to restrict database access itself to known systems only, even though the database wasn't the intrusion vector.
If the system is valuable, or could serve as a gateway to the rest of an internal network, it must have a firewall. MUST have a firewall.
...you mean the windows firewall, the answer is yes - a thousand times yes.
To start with a pedantic nitpick: Strictly speaking most firewalls are packet filters, as they don't look further than TCP (or UDP) port numbers. We'll call 'em firewalls here anyway. That said:
The reason it's been drilled into people to "use a firewall" is that *cough* certain systems *cough* are rather notorious for running all sorts of services, and so opening all sorts of ports to the world, with basically no way to turn them off. On top of that they historically have shaky network stacks that could use a little help filtering out "weird" packets.
If you know what you're doing and use (other) more robust systems where services only get enabled when the administrator says so, then it's not a requirement to run a firewall. If either is not the case then the traditional chicken waving with "enabling the firewall" is likely a better idea than having no firewall.
Above assumes a public network connection. If not, well, the need isn't nearly as pressing. Though we all know eg. SCADA systems are rather notorious for assuming a "safe" network and ending up connected to the public internet anyway. Sounds a bit like your situation is one of these: Assumptions of secure network so insecure configurations (on shoddy systems) are permissible, only not so much in reality. Nothing much you can do except swap suppliers, or hire someone who does know what they're doing and drill better practice adherence into the supplier. Or have them pick a better supplier to swap to.
Yes, there should be firewalls (Not sure if client side is needed, depends on the AV used on the devices. There is AV, right?). However, with you being a contractor who is not responsible for this aspect of the design, and you notfied your client of the issue, and they told you to back off, its no longer your problem. Depending on how involved you are with the project, you may want a written document specifying that you mentioned your concerns about this, and they decided to not follow your suggestions, simply as a CYA manuver.
tl;dr: Make your professional opinion known politely to the client in writing, with your advice, them let the client decide, and have records of this decision.
While I agree with you that security should be paramount, in reality, it is often trumped by adhoc business needs and costs. The owner/C-level want this or that to be able to happen, even tho you know it's bad security. You explain it, recommend alternative, then go with what they decide, no matter how asinine, provided you like receiving money. Document the decision so that when the inevitable happens, you've covered your posterior.
From the outset, it doesn't seem like the client is taking things too seriously when it comes to data, they are using sql express after all. The client typically doesn't want to be bothered with our techno babble of how they are doing it wrong, they want it to just work and on budget. They purchase service contracts and warranties so that when something does go wrong, they pick up the phone to get it fixed or point fingers of blame towards when legal gets involved. It's all about passing responsibility. That's why you document and get signed off that the client is aware of these shortfalls and that you work doesn't cover any breach due to the shortfalls. The client sure as hell doesn't need or want a pissing match between you and another vendor, even if you are correct.
Don't piss off the client. Call it a day, cash your check, have some beer.
When there is only one listener on your server, and only one port permitted inbound or outbound on the firewall, you should ask yourself:
Why am I putting a high latency, trivially DoS'd additional hop in front of my service?
In other words, yes, there are online configurations where no firewall is necessary, and adds no value. Personally, I've run several public facing (as in, a single Interface, public IP) hosts since 1996 and have never suffered a breach, because I actually read my logs and maintain my systems.
Hell, most "firewalls" are nothing but low performance, poorly configured routers, in many environments. If that's the case, put ACL's on your router and remove the firewall.
However, I will say one thing.. I would -never- do this with Windows. Linux? Sure. BSD? Sure. Solaris? Sure. Windows? Nope.
Assuming the servers are correctly configured and hardened, then a firewall is an additional layer - ie the ports allowed by the firewall will be those ports that you have explicitly opened on the server, nothing else should be present irrespective of what the firewall allows. Wether you then need one depends on your budget, your risk profile, wether you need to comply with any external requirements (like pci-dss) etc.
Personally i have many servers with no firewalls, because having a firewall would add additional hosting cost, additional point of failure, additional attack surface, additional latency, and the servers themselves don't run any services that aren't intended to be open to the internet (and thus everything thats running would be allowed by the firewall anyway).
The benefits of having a firewall in my case - an extra place for logs incase my host is compromised, and the ability to control outbound access if the host is compromised, are outweighed by the downsides. The chance of the host actually becoming compromised in the first place wouldn't be decreased by the addition of a firewall, but you'd have the additional risk that the firewall itself could be compromised.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
eg. offline - no internet connection - then I wouldnt worry about not having an operating system/software firewall enabled on the 2 systems. Heck, even if you had a linksys giving them shared internet access it could even prevent the RPC worms and stuff from getting in. The day you start surfing on them or otherwise let the internet in then its horrible practice to go without a good edge firewall on that connection; but if the network is entirely offline I wouldnt worry about it. In the larger networks firewalls are independent devices; we no use software firewalls. Oh no..
will work for dragon quest localization
Sorry to barge in like this.
Oracle does not have issues with firewall. A proper firewall will allow a specific program to monitor a range of ports.
Ex.
Open port 80 system wide.
Open ports 40000-65000 for sqlserver.exe TCP and UDP.
You may have multiple listener processes, it takes a few moments and some research but in the end, you ensure the door is opened only for the ports and processes you want. This blocks the door for ports and processes that may be vulnerable thru bugs.
It's not perfect, nothing is. But it's better than staying opened.
Will you get hit if you don't, not necessarily but what if you do??? How much is your data worth? Restore time and data lost since that last restorable backup? What? You don't have a backup or have not tested your restore recently... (excuse me while I rotfl).
Sorry for the nasty punts, but let's face it, the day you get hit. I will say the same thing as today. Rather you hear it today, it's cheaper for you and if I helped in anyway, I'll be glad to not laugh later. I do go see humour shows, I don't need this for entertainment.
Good luck, and best of chances either way you go.
If a vendor is telling you that a contract dictates to not use a firewall, get it in writing, and then bring this to your customer's attention detailing why this is unwise. While bringing this to your customer's attention, do it in a way that gets them to think about their risk tolerance. E.g. How do they want to handle:
a) Security compromises (machine trojaned, etc, but no evidence of other issues)
b) Demonstrated data loss (hackers steals data, maybe posts it to public forum)
c) Demonstrated public web site defacement (brand damage)
Once you get them to start thinking about these risk, THEN you can start talking about what tools and processes they want to use to mitigate these risks.
Recognize that firewalls do NOTHING to protect against poorly written services. If a vendor has custom code in play, and is talking as you indicate they are talking, I would personally RUN from them as fast as I could. Because even if the firewall is in place, it's a safe bet that an experienced individual could breach the service in short order. The only secure server is an airgapped one (and even not then). Realize that firewalls are only one tool, will not protect exposed services, and need to be one tool of many to be considered in any security process.
In my experience, many smaller companies, especially ones who offer a specific one-off product, this is a common attitude. This means they've done no real security testing on their product, or how their product is deployed and managed in a customers environment. I think it stems from a couple of things: 1) They aren't security literate. They know how to code or deploy, but they can't be bothered to learn and implement security. They have enough to worry about as it is, and security isn't one of them. It's nothing less than willful ignorance. 2) Sometimes it's more nefarious. They don't want anything impacting their customer experience. Two factor authentication? Firewalls? Application white-listing? Those things get in the way of a customer using their code they paid for. They will not endorse or support it. More over, if YOU implement, it could violate your warranty and null any SLA's. Read the fine print. Ultimately, the (real professionals) answer is this: Defense in depth. For a small business (assuming 1-2 workstations as you've described), a premise (ISP) router based firewall will suffice, and then host based firewalls for each individual client/server/workstation. Keep AV installed, and signatures up to date. Implement a basic change management procedure, and ensure everything stays patched and up to date. All of those things can be done for relatively low cost and high yield for security return. Heck, just doing those basic things puts you head and shoulders above many peers.
I bring nothing to the table.
There are lots of different risks that must be considered when securing a network or system. In my many years of securiy architecture, I've found it make the most sense to create a risk assessment.
Threat x Vulnerability x Impact = Risk
Once you have defined the risks, you can define the best protection method to reduce each risk.
Application firewalls may not be the best protection method depending on the rest of your network security controls. If you have strong network firewalls and every device that connects to the network must be authenticated (and scanned for viruses) before its given an IP address, an application firewall may not reduce much risk. If it doesn't reduce much risk, it may not be necessary.
In business, security is like insurance. You have to justify how much to spend, based on how it will protect us if something bad happens. Further, you have to make sure that whatever the security control is, it doesn't interfere with what the business needs to function. If the database cannot function with a firewall, a firewall is not the best protection method and other options should be considered (Network Intrusion Prevention systems, Data Protection [encryption/tokenization/hashing], Anti-Virus, File Integrity Monitoring, etc). There are many tools available to security professionals today. A firewall is a good tool, but not the only tool... depending on the situation, it may not even be the right tool.
Get a life, not a lifestyle. - Hikem Bey
After 4 weeks of oracle training, the advice from the oracle trainer was that oracle simply doesn't play well with firewalls. I'm not a DBA (thankfully), but that's from their actual instruction.
I've seen firewalls that simply allow any port on any protocol right on through.
Many PHBs seem to think that merely having a firewall is a panacea for all security issues.
If I hear "but it's behind the firewall!" one more time...
Depends on the network design for high security networks yes it is common to have sensitive machines on a physically separate network with firewalls between.
If you are going to be working with credit cards then read NOW and not later the PCI-DSS (Payment Card Industry - Data Security Standard) standards and follow them, or the company could be liable to penalties from your financial institution. Firewalls are indeed mandatory, as is proper documentation, management and review of the firewall rules.
Download PCI-DSS v3.0 here: https://www.pcisecuritystandar...
Oolite: Elite-like game. For Mac, Linux and Windows
In my humble experience, POS systems are those most forgotten, and least protected once you get on to the network. Few patches if any, and the vendors often squawk about only supporting ancient versions of Windows XP. Yes, the POS systems are probably Windows. Probably no AV either, and quite likely all administered with shared accounts that everybody knows. A firewall is by far the least they should be doing.
Some large (internet scale) services run without a firewall, although typically ACLs on the router serve a similar function. The issue is that firewalls have a hard time scaling to internet scale volumes. (source: I have served as the lead systems architect on very large scale internet infrastructure).
KK4SFV
You simply don't know the future security bugs that will affect your infrastructure. Just look at http://www.cve.mitre.org/ or any distribution security announcement like https://www.debian.org/securit... . Security bugs are discovered all the time. With this fact in mind you realize that you need more than a single protection layer to get a chance to detect and drop a harmful traffic. The bug could be deep into the kernel, making almost any magic possible from the application point of view. Having only a few ports open is not enough to protect against this, as the kernel structure and notion of port could be corrupted.
Honestly, determining whether you need a firewall isn't as simple as "yes, always, all the time" or "no you don't need one." You have to know what the firewall is doing, and what security is required. You can set up a firewall, allow all ports to be forwarded through without inspection, and while you have a firewall, it's not helping you. Or you could have a server running a secure OS with only the vital ports opened, without access to anything other than the Internet, in which case a firewall probably isn't doing you a lot of good.
Also, it seems you're talking about a software firewall installed on the server? I wouldn't trust it. If I'm running Internet accessible servers, I generally want separate hardware firewall, and I want to put those servers into a separate DMZ if I can. I might leave the built-in Windows firewall turned on if it's not causing any problems, but if I have to disable it, I don't worry too much about it because I have the hardware firewall.
A properly secured Linux/Unix server should be able to sit directly on the Internet without issues, but you may as well put it behind the hardware firewall if you have the option.
But are we talking about disabling the built-in software firewall on a machine that's only accessible by other computers on the LAN? That's probably fine. You should have some security preventing unauthorized personnel from accessing the LAN, and I would assume the SQL databse it password protected, right?
I guess my bottom line here is this: Since you can't trust a the built-in Windows firewall to actually protect from very much, you shouldn't worry too much about disabling it. Make sure your network is secure without it.
Your trainer was an idiot, not a network admin. Oracle database and the various Oracle apps I've used have no silly issues with firewalls. They may have some apps with issues, but not the main product which uses a single consistent TCP port for connections.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
A firewall will not stop most attacks. A firewall has to allow traffic to the services that are permitted (duh), and so that open channel, attacking and exploiting the service is what will allow the attack.
A firewall could not stop that by design.
If an internet facing server is secure correctly, there is no need for a firewall in front of it.
There is however a need for a firewall between the DMZ (which is where this server should be) and the internal network, to prevent access to the internal network in the event the server in the DMZ is compromised.
If you ignore ACs because they are anonymous - you're an idiot.
alternatively, have the vendor sign a waiver accepting full responsibility for any damages and liability that could be attributed to not using a firewall
I am sure that the company lawyers would be very eager to have something like this in place.
After all, this is the vendor's recommendation, which should be in writing anyhow.
Their actual instruction isn't wanting to "get into" all the possible firewall configuration problems that exist, no doubt...
Oracle training is just that. It's not custom Oracle expert deployment contracting. You "can" use a firewall, done right.
I'd make every effort to inform them of this security violation, then make every effort to explain it, and then highlight that POS systems are now being considered for hacking. Once you've done that, and the customer still refuses, keep the documentation and GTFO because they're as dense as lead.
After all, this is the vendor's recommendation, which should be in writing anyhow. Have the vendor sign a waiver accepting full responsibility for any damages and liability that could be attributed to not using a firewall I am sure that the company lawyers would be very eager to have something like this in place.
"It is a greater offense to steal men's labor, than their clothes"
I have seen this so called "requirement" on occasion and think the company that requires it needs to go though a security audit of their own. I also think that anyone that requires Domain Admin/Root access for their software to run doesn't know a thing about security (I get this commonly too). The problem you may face will be through regulatory compliance for various things (as some here mentioned PCI already) There are other regulations you should probably try to discover if you are required to comply with especially if you will be hosting PII (Personally Identifiable Information). Not just talking HIPAA, but some e-commerce sites require a little more security for their data.
That being said, as long as there is a firewall to the internet and your server does not have critical internal only ports open, in most cases you would at least pass basic security requirements, albeit not optimally. Make sure you run a test using something like NMap! As for alternative ideas, you could set rules in the local firewall to allow unrestricted traffic between the servers involved while limiting access from all others to the default rules. You could also set up IPsec tunnels between machines to encrypt that traffic. I would at least make sure you have a path to separate as many features that require higher security as possible. For instance, PCI will require more strict rules and if that is a problem for this vendor, budget a separate server for transaction processing.
Some of those options may help find some middle ground between your requirements and theirs (after all, you are not limiting traffic of interest to them). I would push to have a Business Associates agreement signed by them saying that by not following your configuration requirements, they will hold some or all of the responsibility for a breach involving their solution. It would still hurt you in the case of a breach, but at least it puts them on edge to make sure they do everything they can to secure their solution since they now have a financial consequence for a breach.
Last but not least, make sure you put the POS system in it's own VLAN separate from all other systems. Lock down that network to only POS traffic and put no other device unrelated to the POS system on that network. This is part of the reason for recent breaches from some of the major retailers.
The Vendor will have issues with their product running if you do not configure the firewall correctly and will cost the Vendor support time.
If you get hacked because you let malware onto your POS systems or put a compromised machine on the network it is your problem.
A firewall will just prevent an exploit of a service. So only run the services you need. The real issue for this POS would be an exploit that gains access to the SQL server and a firewall is probably not going to stop that.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Don't be a muppet. Limit the spread of malware on your network as much as possible by only opening things that need to be open, to places they need to be open to. There is ZERO reason, for example (plucked at random to illustrate a point), for your end user PC network being able to directly connect to SMB on your SQL server, for example.
Yes, in theory they need credentials to do that. But why leave it open to anyone who obtains credentials when you can be more pro-active about defending the box?
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
You said they disabled the local firewall. That's how I'd run most Windows servers on a network of any size, because the local firewall just eats up resources on the server that could be better used for the server's actual job. The firewalls should be proper hardware firewalls built into the networking infrastructure located a) between the outside world and the client networks to control access to the network in general, b) between the POS terminal segment and the server segment to control what access the terminals have to the servers and to block the servers from unnecessary access back to the POS terminals, and c) between the two client networks you mention to control what access each client has to the other's network.
The Windows Firewall itself is fairly useless in a large network because as far as incoming connections go it can't control things any better than a hardware firewall can, and for outgoing connections it's pointless because any malware that might try making unwanted outbound connections has to be assumed to have enough access to disable or bypass the Windows Firewall.
That design tells me that you need to put a PCI-compliant hardware firewall between the POS and its associated DB server, and the rest of the internal network. And you also need to have a firewall logger that is actually looked at daily, plus you need to do vulnerability scans both internally and externally. A Windows firewall is not sufficient and won't meet PCI DSS requirements in any event, ever, and isn't going to provide any benefit if the firewall between the POS network and the rest of the store/enterprise is in place.
Any device that processes, carries, or stores ANY credit/debit card data that isn't encrypted *must* be behind a firewall that only permits it to send traffic to specific hosts that are necessary for the functioning of the system, and even then only on the bare minimum number of ports, and almost all inbound traffic is denied as well.
If you don't run a firewall and you and your clients are the only one trying to connect to your server, then people see that running a firewall only interferes with things working. Meetings with management are really fun when they run along the lines of "We turned security on and things started breaking.", "Then turn off the security". So if no one is attacking you, you might make it to market faster with less resources than your competitors when only dealing with security after an incident.
My job requires that I deal with a lot of, to put it politely, vertical market software companies. As in, they're the only game in town for that particular function in the industry I work in. It's extremely common to see stuff like this, and it's usually justified by saying "firewalls won't protect you anyway, so why bother?" I only slightly agree -- in my mind the most important thing is to severely limit the use of admin/root accounts and protect their passwords, since you can shut off any security measures once you're through the door.
Usually, it's just laziness on the part of the vendor. The software is assumed to be running on a closed network with no external access in many cases, and a lot of people don't get that even closed networks aren't really closed anymore. I'm completely platform-agnostic, but I've noticed this a lot with typical Windows DCOM fat client / SQL Server (or worse, Jet/Access DB) pairings. As soon as you try to run these securely on a general purpose desktop, you find that port-based firewalling is very difficult to do without opening a huge range of ports due to the way RPC works. Yes, there are workarounds, but in general the protocol is not firewall-friendly. And, the golden rule of vertical market software is "thou shall not upgrade thy technology stack, ever." I do desktop systems integration -- OMG, getting poorly coded VB6 applications working on Windows 8 is a nightmare even with the compatibility toolkit, etc. Not sure what it is with the market segment I'm in, but I see lots of VB6 married to a Jet database, and lots of craptastic fat Java applications. Both can be killers to fix and get working without access to the code/programmer.
To be fair, just because the network is properly setup and allows for certain behavior etc. does not mean the application will play well with that setup. I've seen it happen before (and have been able to demonstrate it with proprietary software) that sometimes the network will not react correctly with certain network setups. At my company we have had to implement special protocols and features in our software just to overcome some inherent network limitations that our IT group pretty much said, "we have no way around this issue, sorry."
I only have limited experience with Oracle though, so take that statement as what you will. I have seen other software exhibit this kind of behavior though.
they went from suggesting that there's no need for a firewall, to outright telling me that's just how they do it and the contract dictates that's how we need to run it. This isn't a tremendous deal today, but with how things are going, odds are there will be e-Commerce worked into it, and probably credit card transactions... which worries the bejesus out of me.
I suggest you relegate the 'is this common' question to a discussion after hours over a beer.
Your real issue is security. I would want to schedule 2 different meetings, preferably with everyone attending in person. The first is a prep meeting with your client and their legal counsel to discuss your concerns, review the contract language that is being referenced by the vendor, and what liability the vendor has if the machine is compromised due to the vendor required there be no software firewall.
The second meeting would be with your client, their legal counsel, and the vendor.
FYI, oracle requires ports from 1024-65535 to be open for any client. 1521 is only used for initial setup dialog. This also forks a new oracle process, which gets its own socket. Afterwards, as stated above, this information is sent back to the client which reconnects on the new socket. This oracle doc explains what I am talking about: https://asktom.oracle.com/pls/...
The actual training did "get into" why it works that way. See the above referenced article explaining how SQL*NET works. 1521 doesn't handle the actual sql query, it forks a new oracle process for that particular request which has a new socket associated with it.
Yup, this is our case. There's also a common misconception that with oracle you can just open port 1521 and everything works, but per oracle, that's only part of it. SQL*NET is weird software.
You drive your car quite fast on roads with on-coming traffic separated by nothing more than a stripe of paint.
There's no limit to the amount of security that you can add to a network. But in the end, the odds are fairly good that fixing the few problems likely to occur is far simpler and more cost-effective than preventing them in the first place.
Obviously, we're talking about a small business, that isn't subject to large and persistent attacks. And should the day come when it is, that's when increased security can come around.
Regarding the ecommerce side of things, most small companies use ecommerce to receive money. So the worst thing that can happen is that they receive more money. That'll be noticed. Providing they aren't storing credit cards, then there's nothing to lose.
Safety third: first the job needs to actually get done, otherwise there was no point in starting it. second, the job needs to be worth doing, or there was no benefit to having done it. third it needs to be done safely. think of all of the great achievements that came from numbers one and two without any degree of reasonable safety. think the discovery of new worlds, exploration, animals, major construction, and every dangerous job out there. the line of what's considered "safe" moves quite freely to accomodate the other two priorities.
Safety Third.
First and foremost, the most common reason I see to have poor network traffic controls (on network or system level firewalls) is that defining the traffic ACLs is to skill/labor intensive. You need to have the skills and patience (read: time) to make sure that everything works and you're blocking everything else.
That being said, I tend to design systems to rely primarily on the network level when I can for traffic controls because I reduce the number of possible points of configuration which helps configuration management, auditing, and troubleshooting. If I do want focus on the host I am more likely to use host level firewalls on Linux systems for 2 reasons, 1) the services to be permitted are easier to isolate, and 2) iptables configurations are much easier to archive, manage, and audit (at least for me, I really haven't had much success with any kind of task automation with the windows firewall or ForeFront).
Cloud IaaS can make this complicated, because it's much more involved to employ network or "soft" VM based firewalls, and creating traffic isolation in elastic environments is tricky. The times I've designed for Amazon AWS, I pushed the systems design to Linux, rather than windows (Drupal/MySQL system that was being migrated from a Windows implementation to cloud hosting) partially because of the network traffic controls.
Network security design is not about firewalling everything, it's not that simple and the more things you have manipulating traffic, the more trouble you're buying down the road. It's about defining your security zones (how needs access to what, and how are they getting there), and then determining what controls to use. If, in the OP's instance, it's a web server and DB server in a DMZ that has ingress of HTTPS (443/TCP) and no egress, then I'm not sure that an additional control between the 2 servers buys you too much. The main advantage I see is limiting the depth of exploit if either of the 2 servers is compromised, but given that they are windows servers, and it's likely that they are using SMB/CIFS (137/TCP, 139/TCP, 445/TCP) rather than SQL server authentication, you have to allow all the ports you'd want to block anyway.
Spyder
My current company has a firewall for the incoming internet connection. (What sane company doesn't?) We also have individual firewalls on each PC but no individual firewall on any server. I'm not a network administrator -- it's a black box from my viewpoint, but I can rattle it and guess what's inside. The servers, I believe, are protected in two ways -- (1) to get out on the internet, you must go through a proxy, and the servers do not know how to do that. (2) traffic on the server subnets are blocked by the internet firewall, except for a few in a designated DMZ. We run into this all the time when applications have features that report back to vendor tech support, but are always blocked by the firewall. (In one case we had an application that would hang when it couldn't make an ftps connection with the vendor's tech support site -- who the heck uses ftps anymore? We stopped using that app.)
So to answer your question, a well designed network will have clients that can get to the outside through a proxy server, and servers that can't get to the outside at all, and servers that can cautiously get to the outside from the DMZ. The servers that are blocked from getting to the outside by the network don't necessarily have to have individual firewalls, and in fact, local firewalls can cause problems with some applications.
Now, if you're running the back end part of the system on a local PC that can also get out on the internet... whoo boy... that sounds dangerous.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
Is it common, yes. But does common = good? no.
If common sense really was (common), the world would be a much better place.
Unfortunately, lots of (even smart) people to very stupid things, and all too often people focus on "getting it to work" more than "making it safe to operate" (which is, in effect, "being lazy"). So you should keep on arguing for good security practices. The results of not doing so speak for themselves (i.e. Target, etc)
Also, firewalls are one piece of an overall security plan, but an important part. But to talk only about firewalls is kind of missing the boat.
And all this discussion about databases not working well with firewalls - I think people are missing the point. Generally, I would expect "customers" to have a well defined path to this POS - i.e. a web site/api, etc, and that this would communicate to the DB, so all the communication between your POS app and the DB are together behind a firewall, so communication to the DB wouldn't be affected by said firewall. To have the DB directly open to something outside... seems like a recipe for a security disaster...
Having said all that, since we don't know much about your environment, the two clients, how they are connected (the implication is over the Internet, but you don't really say), requirements, design, other security measures in place, etc, we can't really give specific advice for such a general case - it's possible a firewall is unnecessary, but we can't say for sure given the info we have.
Unless *all* datafiles on your client's system are encrypted, also, and I don't think even that's enough.
ObDisclosure: I worked for about 4 months on a contract at Trustwave, a root CA.
Leaving that huge hole in your defenses... I suggest you look, if you don't already know, at .
From the 1.2 std: "Firewalls are a key protection mechanism for any computer network. Other system components may provide Firewall functionality, provided they meet the minimum requirements for Firewalls as provided in Requirement"
Even all data between two systems *MUST* be encrypted, for full compliance, if you're doing your own.
So, what this vendor is doing... I'd say you and your client need to reread the contract *VERY* closely, and if they say they're adhering to stds, they're in violation of the contract.
mark
"A firewall is a MUST".... However
1.) If you are a contractor (or an employee for that matter), and you're explicitly told not to do something, document your concerns, in writing and either do what they tell you or quit. This covers your butt when thing blow up. Note I said, when, not if. You don't get to dictate the business objectives in either case (contractor or employee).
2.) The networks/firewalls are only one part of the picture. I've noted other posts asking questions concerning the surrounding environment. These are good, even if they don't address point (1.) If a "best practice" for an element in the environment breaks the environment, then the "best practice" is invalid and MAY be ignored. It may also be that the app in question is brain dead, but that's a whole 'nother topic.
I've seen way too many "best practices" that do not account for the specific environment and even more "checklist" jockeys who can't figure out how to make things work without them. Learn to do more than to follow a flowchart/checklist.
honestly you could not be more wrong/trolling...
you completely avoided the question
**of course** the objective of any firewall is to do as you say, but stating that fact is not an answer to GP's question
I really want to hear a good answer to GP's question....I used to have my CCNA, but mostly did database and research query stuff...I'd really like to see a specific answer to the question
You really are trolling more than just GP...you're trolling all of us, everyone on here who is an industry professional should have a decent ***specific*** answer to GP's question.
To top it off, you accuse GP of acting like a typical "bureaucrat"
No.
Just dead wrong.
bureaucratic functionaries don't ask analytical questions that demand real world, specific answers...and they use manipulative language to justify **getting a bigger budget** as well
Thank you Dave Raggett
My guess is they are too lazy to determine which ports they actually need. So tell them you need their configuration policy document which states 'firewall is not allowed' for your company records for when you get audited (or hacked and audited)
That still leaves a fairly large number of fairly *important* ports that you may as well firewall off. Not to mention you can also firewall off entire IP ranges from reaching any of your ports, or even better, limit to specific IP's to reach any ports. Why not secure it down as much as possible ? It's simply cleaner. The "open all" approach is bad administration, imo. Maybe not in a particular case, but it indicates there will be bad management across the environment.
Sometimes sloppiness is on purpose, and a good idea, but make sure that's what it is.
I just started reading the Microsoft CompTIA Security+ certification book. A sidebar story mentioned that a data center kept no firewall on the network because it had other forms of network security in place. The tradeoff was a faster thoroughput performance versus an increase possibility of a network attack.
For us, we control everything else using both hard firewalls and ACLs. Everything in those subnets purposefully needs to be able to talk to everything else. Plus, as mentioned elsewhere, we're beholden to the vendor whose application is running on those boxes, and their config requires iptables and selinux to be disabled on individual hosts. So, we control everything with network equipment above them. I think the only thing we are using IPTABLES for is mangling dscp markings.
I always disable it on internal networks. Causes problems for the most part and serves no purpose behind a NAT or even a properly firewalled network. Why have two firewalls? (with one of them being a buggy microsoft one)
I used to work with a guy who firewalled everything off from everything else. I am pretty sure he did it for job security, because no one else could figure out the russian doll sequence of firewalls in order to fix any of "his" machines. Luckily he was fired for incompetence after losing the backups for an entire department.
As a potential lottery winner, I totally support tax cuts for the wealthy
Well, it seems this only applies to Windows only, and, BTW, this behaviour can be quickly modified (and it is the default in Oracle >= 10):
From the article you linked:
"If you are on Oracle 8, you can use a WINSOCK V2 API feature called Shared Sockets .
This allows a socket to be shared (or passed) between multiple processes. To use this
functionality in a single Oracle Home enviroment, set USE_SHARED_SOCKET = TRUE in the
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE section of the registry. If you are using Multiple
Oracle Homes, change to the desired Oracle 8 Home and view the oracle.key file in
ORACLE_HOME\BIN to find which registry key to add USE_SHARED_SOCKET to."
Yes. Foolish? Sometimes. From your description PCI DSS is going to apply. That means the server and the network it runs on are "in scope". Defending a no-firewall "policy" is going to be a tall order.
Why would you need a firewall when the attack is going to come from that disgruntled employee you fired last month and YOU never changed the password for the single user in the system that everyone shared.
Thanks for the ip addresses and/or domain data.
f it does no harm in day to day operations and offers protection when your assumptions fail, why *not* run a software firewall?
Connection tracking can be expensive. If you need that, it's going to cut into the performance of your server, so it can be beneficial to do that on a separate box.
Security through obscurity is not secure at all.
Do you run your home computer without a firewall? Of course a firewall is useful keeping things out but they also let things out from within.
I am Bennett Haselton! I am Bennett Haselton!
That's no problem; the firewall on windows can be configured to allow traffic to and from certain services and executables while blocking the same ports for other services and executables. Just find the oracle binaries that need to be allowed and you are almost done.
PCI compliance.
I hate these crappy 3rd party vendors who don't know how to write software. I just dealt with this with some 3rd party products here. We were finally 'Get it to work with the firewall or we'll send you your crap back'
Magically, the "impossible to do" was done in a week.
The Kruger Dunning explains most post on
So...
If you had a Server with one port open inbound (port 22).
Would you still need to put up a firewall? I don't see why.
For a high traffic carefully managed and locked down internet server that does nothing else a firewall is dangerous single point of failure. Not using firewalls on very high traffic webservers is common.
At the same time at lower load with less active supervision where you the hardware is bored with your workload a firewall can be a useful impediment to enabling services you didn't mean to enable.
Sorry if this is a stupid question - I may just be out of touch with what firewalls can do nowadays. How would the firewall know whether it is dealing with sqlserver.exe on port 40264 or some other program? If it's not running on the same computer? I can imagine that some expensive solutions can do this, but I would be surprised to learn that a stock OpenBSD, say, can do it.
The article talks about this being a small local area network. No discussion about it being connected to the Internet. This is the best firewall of all - a physical air gap between you and the rest of the universe. In many respects this is the best security. So what do local firewalls on each box achieve? In this context virtually nothing except CPU overhead. The database server shouldn't be exposing anything but the database port anyway. The client need not expose any endpoint at all. Configure it this way and there is little opportunity for compromise.
Now as a way to protect your internal lan from the evils of the Internet a firewall is a great idea on the edge, but again they provide very little protection running on the internal servers. You can't just sprinkle firewalls over your network and assume security. They are a tool to limit a specific kinds of attack; to insulate your internal network from external bad actors. If you have a office and servers put the servers behind their own firewall.
We're using Oracle Grid Infrastructure/Data guard on linux. Windows firewall doesn't apply.
This whole "network security" meme is a failed experiment needing to be called out as the ridiculous farce that it is. Firewalls are the equivalent of mounting castle defense against an airforce. It does not work and never has. The opportunity cost of squandering resources on castle building vs standing up an opposing airforce is both high and sad.
Host-based firewalls are even more amusing. They come enabled by default. High probability any application installed needing to listen() is going to automatically punch a hole to do so as vendors have zero interest in dealing with firewall support nightmares. This begs the obvious.. what is the effective difference between listen() and firewalled-listen() ?
If you really want a secure internal system then lock down services/listeners and configure each system to use only secure communication protocols. If this is not possible set IPsec = required and secure the transport E2E only.
The further away from application domain you apply security the increasingly worthless that security is.
Also, hosts.deny all:all and then adding the hosts you want to allow in hosts.allow works just as well as a firewall, without having an extra process running on your systems.
How about this: If you find yourself needing a firewall, your system design has already failed. Every single system should assume actively hostile environment.
I can only repeat your original subject.
This applies to all oracle installations, and from training, this is still the default (at least as late as 11g, I haven't tried 12 yet - again, that is per oracle training). We're running oracle grid with dataguard (4 separate 2-node clusters with failover sites) on RHEL5. It functions the exact same way. Shared socket works so long as you don't mind the bottleneck it creates. It's far easier to remove iptables from the picture, let oracle function as it is supposed to. Any sort of access control can be handled by using hosts.allow/hosts.deny and letting tcpd handle it instead of having a whole extra process in the picture.
FYI, I looked at the 11g docs and you are correct, the default is now to use a shared instance. We are still using dedicated instances on our end. Section 3.4 covers it here: http://docs.oracle.com/cd/B283...
There are firewalls and firewalls. If you have a box with port 80 listening and nothing else listening, and you install a firewall that blocks connections to ports that are not port 80, you haven't really added a whole heap of useful. If you have a firewall that allows port 80 from anywhere and ssh connections only from a particular subnet, then maybe the firewall is earning it's keep. If you have a firewall that warns you about outgoing connections from your server that might be to command and control botnet servers if it gets compromised, then maybe it is worth doing. If you have a stateful firewall that is doing traffic analysis and shutting down particular attacks on your server then great. Shutting closed doors just for the sake of buzzword compliance is not a useful function.
it starts with the vendor accepting client firewall software. Then supporting every firewall software becomes unmanageable, so there may be a list of approved firewall software. Then, the number or support requests for firewall-related issues still rises due to the amateur nature of inexperienced end-users setting them up and the firewall software itself changing over time causing the approved firewall list to dwindle down to something like OS native firewalls only. Then the OS native firewall changes with the OS version becoming more complex and problems continue. Eventually, no firewalls are supported because the software engineers and support staff is lazy, understaffed, or just has a directive to not support firewalls.
Deny all, allow minimal that is needed. ie. FTP should only have port 21 open. Why open your whole server subnet, if someone compromises one box they have network level access to all.
The "open all" approach is bad administration, imo.
I concur with your opinion.
Or say the data is responsible for multiple national electrical grids, meaning that if it gets out people can shut them down in a non fixable manner. The Vaxxen used to run much of our grid offer a challenge to someone who wants to be entirely digital, but give me a drill and a stick of dynamite and I could plunge a major city into darkness for up to a year(details omitted for safety). I've got this data because it's my job, so don't worry, only disgruntled contractors at a fairly high level could do this too easily. You think peoples credit cards are a big deal? Try being able to plunge them back to the iron age because of a badly configured(or missing) firewall.
1) They should read up on PCII compliance since these are POS systems. Perimeter defense is not good enough these days... (was it ever?)
2) What's the difficulty in setting up a local DAPE policy? punch a hole through for SQL/SQLBROWSER (TCP/UDP) for the other system to connect..
3) When I have systems that absolutely require a local "SQL Express" install, I usually change the method the software is installed. Rather than binding to the dotted quad 0.0.0.0 to allow anything to connect to the SQL services, I change the binding to only bind with the loopback 127.0.0.1. Instant DAPE whether or not the firewall is on/off or even installed. This works great, but the Information Assurance idiots get pissed because they can't scan my SQL instance remotely for vulnerabilities. Neither can anyone else that is trying to exploit them remotely! It's called hardening, or reducing the threat surface. Get off your lazy ass and run some SQL queries locally if you want to confirm everything else is STIG'd properly.
I think you are pretty confused. If you need to use enterprise level tools you use enterprise level hardware and network configurations. This means that, if you are going to use it you have a separate NIC for each node and an "Oracle Only" subnet. If you don't / can't do that, you are most likely using a tool for which there is no actual need. In other words, you're doing it wrong. Even in this case, you should certainly be blocking the unneeded ports in the 0 - 1000 range.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
See subject.
Yes. Often times in less critical systems, it happens. If it's critical, though, or has any privileged accounts that can access critical stuff, it definitely keeps it. Let me tell you, as nice as the Windows Firewall interface is in Server 2008 and above, it can be a painstaking endeavor to find all the exceptions you need. Then there's always the support guy asking "Umm... why come... why come I can't ping this? It's broke. Fix it."
Firewalls in the servers are useless.
They aren't manageable. If you manage 40/60 servers, it is impossible to manage 40/firewalls. At the end you don't now what you allow/forbirds (you will need to open 40/60 machines with different OS and different firewalls: it would be a nightmare).
The only case for a firewall in a server, if the server isn't behind a firewall. It is the case of personal firewalls at your home.
The purpose of have a network firewall is to have centralized management. If every server has a firewall, the usefulness of a network firewall is near to zero.
We ran a Windows server for many years with no firewall. We took credit card info (which was immediately encrypted). We had spent over a month hardening the server by shutting down all but the services that we truly needed. We never had a problem with that arrangement. We added a firewall when PCI required it but I'm still not convinced that it mattered.
Posting anonymously so I don't identify my employer, but I work at a large university, and it is common practice to turn off the OS firewall and allow the network firewall to do the job of blocking unwanted ports. The network firewalls ARE very tightly controlled, so, for instance, servers are firewalled from clients.
I don't see the harm with doing something like this, because if you think about it, if you have a subnet that is completely firewalled from the outside world is effectively the same as having each machine in that subnet firewalled from the outside world.
The only threat would come from other machines on the same subnet, and in order for something like that to happen, the threat would have had to get through that subnet's firewall in the first place.
Application support always says to turn off everything that might possibly interfere with their precious application. They would have you shut down the operating system if they didn't need it. Application support lives in a fairy land where the only thing they have to worry about is their application. They don't have to fix anything if the application isn't broken. They have no interest in anything else. A good vendor will program their application to work with the system standards. Most ISVs are not good vendors.
As a system or network admin, you have to protect the application from the rest of the network and protect the rest of the network from the application and protect everything from the users and the Internet. Part of doing that is firewalling the crap out of your core network, and if you can't do that you should be looking at adding more VLANs and controlling traffic that way.
The road to tyranny has always been paved with claims of necessity.
Take a good look at your exposed host. Install only the software that the clients will need and make sure only the essential ports have services listening on them.
Now there is no traffic left for your firewall to filter (except connections to your internal network going through a different interface).
and we don't keep logfiles, so we don't have to worry about checking for breakins and cooptions. hey, we don't comment or document our code, either, it's just us two guys. that way, we get to keep all the millions.
hang on, the phone just started melting and my screens went blue...
if this is supposed to be a new economy, how come they still want my old fashioned money?
Facebook puts F5 load balancers on the edge, which function as firewalls in some sense, but aren't actually dedicated firewalls. The goal you should have is perimeter security, lots of ways to skin that cat.
There are two kinds of people who run servers without firewalls: Nitwits and professionals.
Nitwits do it because they think they don't need a firewall and it gives them a bit more performance or whatever.
Professionals do it when they know the conditions are right to justify it and they've made a risk assessment that confirms they are right. For example you run a high-traffic server that does exactly one thing on one port and the server software is robust - a firewall wouldn't do you any good, it's just additional security in case you open a port you didn't want to or such.
Assorted stuff I do sometimes: Lemuria.org
Their argument probably revolves around the fact that this will be a small network and nothing will hook up to it that could present a threat to an unprotected box. My argument is that the guy who works on that POS 2 years from now may not know that assumption was made, and be asked by management to hook a WiFi AP up to it so that they can have POS terminals w/o wires. Now all the sudden you have unfirewalled boxes on WiFi. Then the guy who replaces him will be asked to set up an data circuit off-site so that folks at the warehouse can do data entry. Now you have off-site access to the unfirewalled box. Then the contractor who replaced the guy who replaced the guy will set up a web server application to interact with the stuff at the warehouse, not realizing it is on the same network as the unfirewalled POS server. And so on and on. They will claim that doing any of the above invalidates the contract, and the result won't be their problem. Fine. Add a small firewall appliance to the project cost and configure it on deployment so that traffic is not forwarded to unauthorized machines. Management won't understand firewalls and network segmentation, but they understand a cost line-item for something which already comes in Windows for free. When management sees the actual security cost front-loaded (rather than tacked onto a later project), they will be more willing to take up that battle.
I think you are using a strange model for rating risk. I'd suggest you look up a copy of AS/NZS 31000 or other recognised standards on risk management.
I run a couple of realtime servers and over the years we have had to turn of all aspects of the windows firewall on the server and on some cases on the clients. (don't forget to turn it of in domain level, it sort of hidden).
The windows firewall creates terrible delays and jitter, so the impact on for instance sip telephony is terrible.
So I totally agree that server should be protected, but software firewalls for windows are simply not fit for the work.
The real problem is that we usually have to let the problem get problem and then ask them to turn of the firewall. If we ask the to do it first they won't do it as they think it's a good product.
Trainer was wrong! If possible (without leaving yourself wide open), set a temporary firewall rule allowing any:any between the Oracle client, the Oracle DB server(s), and DNS(s). _Run_ _a_ _sniffer_ (wireshark) while testing the Oracle app. Note _every_ communication logged on the sniffer for this test. Write an "allow" rule which includes _all_ of the communications logged in the sniffer. Disable the temporary "any:any" rule. Test with your new "allow" rule enabled. DONE!
Partition the network into groups of logical units. You don't need firewalls, but smaller groups enable you to pinpoint the originating machine. Then again, if you have an idea about the destination target's ports, monitor the ones that try to hit non specific ports, aka scans. There's an optimum point of how large this group is, the provider organisation will have a clue. However, if it's not in the vendor requirements, do it to spec. Large vendors seem to have a vested interest in snafus that pump up the bottom line in the long run. They also have an incentive to make things seem as complicated as they can, while delivering as few as possible. It's a business after all and their incentive is large margins. If you have liability, then approach the client. If you have to maintain a maintenance contract, consider liability and support dollars. They'll pay you if something screws up, but you'll have to find out how much the affected areas are. Depending once again on your stance to cleanup, you'll either recommend complete overhaul ( kaching for you, show you delivered and to spec ), or if it's a business you have an interest in (i.e. you are the business owner), do a root cause analysis as fast as possible to minimize the areas affected.
Once again, as vendors they have an incentive to fluff up the bottom line as much as possible, while the customer wants it as low as they can get. Do you see a conflict of interest when the consultants are the same people that provide the machines?
It's much better to assume that a server may be or is exposed to malicious traffic than it is to assume not. Even if there's only ever a direct ethernet connection between two machines, assume someone may compromise one of the machines and protect the other. Using a username and password is one thing; if you can filter based on IP address, use software firewall rules to only allow connections on certain interfaces and from certain addresses (or, better yet, localhost), et cetera, you're always better off.
Hope for the best, plan for the worst.
Next question?
---- Booth was a patriot ----
Your servers are already pwned.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I setup all our Oracle databases.. (Many, many of them). Only port 1521 is open in iptables. (actually, for some, I have secondary listeners).. The Junipers also ONLY allow access on port 1521, (and a secondary, if specified)
I have never had issues connecting to the database.
What are we going to do tonight Brain?
People can work out a vast complex network exists. All that national spread of small factory complexes with just in time delivery and payment.
Add in a tail end network thats waiting on international parts delivery.
So they find their way onto trusted systems and go for the main complex.
Finding a way in they use skill and poor design to transfer out 'plans'.
Some time later they spend big trying to make the plans work. Their own well funded lab comes back empty. Something is wrong, missing or it was never a real project.
To make the above work you need a vast amount of tame press telling the world about sloppy code, successful intrusions, countries getting away with decades of digital design over a few short years.
At a lower level its all about vendor lock in, ensuring the sale of that next version and then chasing the intrusion clean up work.
Systems are open to the net for a reason - as bait or to rent seek clean up contracts.
Domestic spying is now "Benign Information Gathering"
The case for not having a firewall is a lot like the case for unprotected sex:
> The horror stories only happen do dumb people who should have known better (I'm different).
> I know exactly what's coming in and out of my systems
> It adds an extra layer of complexity i don't want to deal with.
> She's taken contraceptive measures anyway.
> It'll probably be fine.
Run away from this client. Do not walk.
If credit cards are involved, then PCI-DSS guidelines are almost certianly mandated by merchant agreements.
PCI-DSS guidelines say, among other things that firewals are required, and that they have to be in their most restrictive ("DENY ALL") configuration, with only the specific connectivity required being permitted.
Therefore, by extension, if this is a point of sale system, and credit card processing is happening on the same network, then by extension, the firewall is required by the merchant agreement, and not only required to be present, but also required to be locked down.
Most places I have worked, developers and their management think they know everything about computers, the OS, the network, the backups, and just about everything related to IT and networks. Network engineers are a hindrance and cannot design anything, tech support is stupid, and system administrators are there just for you so your stuff works, and the VM and SAN guys? Yeah. They are totally useless and have no idea what is going on.
In the long run, the other teams do not make many of the decisions but yet are held responsible for the decisions that are being made. To be accountable for something, you have to have the power to make decisions. When the power is not there to make the decision, you should not be accountable for that decision. Unless your organization is committed to security, support, administration, backups etc, decisions you make that others may not like because it may reduce their productivity will be seen as an obstruction. People will work around obstructions and circumvent your decisions but still hold you accountable in the end.
A company gets hacked through an unsecured DB. The group of people that worked around your security or complained they could not do their job done with your restrictions in place are probably not going to get the blame in the early investigations or possibly never get blamed. The security guy will.
Escalate the situation up the tree until it reaches someone with a clue, or who can take advice from someone with a clue.
I had some phone system idiot that wanted to be able to telnet directly in without needing a password. The problem was almost self corrected forever when he took a open can of drink into the server room and put it down on a 5kW UPS. He muttered something about earth leakage circuit breakers upon being informed about how suicidal that was, totally unaware that 5kW of DC shorting directly through him would not have gone anywhere near such a thing.
Similarly the vendor mentioned here is expressing a view beyond their skill level.
Ever wondered why there is the phrase "stateful firewall"? It's as if that wasn't the only kind of firewall isn't it :)
The way you are using a list of allowed ports and hosts is a non-stateful firewall, just like very simple ipchains/iptables/ipfilter rules.
The actual training did "get into" why it works that way. See the above referenced article explaining how SQL*NET works. 1521 doesn't handle the actual sql query, it forks a new oracle process for that particular request which has a new socket associated with it.
I think you have misunderstood a lot of things and I guarantee you that establishing a connection to an Oracle database does not require 2 TCP handshakes. It is also the reason that you can do a "netstat -an | grep 1521" on the server or client and see the open database connections.
If it is e-commerce and they will in some manner take credit cards, pull the PCI regs on the vendor. Firewall = required, no wiggle room on that.
Second, tell the customer if they do not back you that you will walk. It is not worth risking your reputation for a vendor with blind ignorance.
Close but not quite. PCI-DSS does not say that you have to have separate firewalls nor does it say anywhere that you need multiple levels of firewalls.
1.1.4 Requirements for a firewall at
each Internet connection and between
any demilitarized zone (DMZ) and the
internal network zone
Do they need isolation from each other by a firewall? Yes.
Does it say anything about separate firewalls? No.
1.2.3 is only applicable if you have a wireless network and still does not say a separate firewall.
Maybe you are thinking about a WAF? Section 6.6 touches this and would be applicable here once e-commerce comes into play.
6.6 For public-facing web applications,
address new threats and vulnerabilities on an
ongoing basis and ensure these applications
are protected against known attacks by either
of the following methods:
And for heavens sake, you cannot skirt PCI-DSS. In most cases if you are a business owner and take credit cards on your e-commerce site, even if you transfer ALL risk (outsourced your payments), you still fall under PCI. The only possible exceptions are items like Paypal. I'm not certain where payment systems like that fall but I am guessing that they are assuming all the risk for the fee you pay them. It is worth it for a small company.
To make sure I am clear, I am not saying to only have a single firewall. Have at least one. I am saying that nowhere in the DSS does it state you must. Try not to read anything into any compliance regulations. You'll end up doing more and spending more for marginally better gains. I'd rather have one firewall and have all of the systems kept up with patches and scanning than have multiple firewalls and everything else ignored.
Thank you for up selling for the appliance vendors.
Why not try Sandboxie?
I've had similar experiences with EHR vendors requiring old, old versions. The lag time and impracticality of their limitations can be frustrating. One product I've worked on shares a parent company that was part of the Obamacare website roll-out (they wrote middleware). After spending some time working with the database on that product, I began to believe in the Infinite Monkey Theorem.
My ISP gives me the gateway. It feeds to the router, and that goes to the switch. Everything else connects to either the router (wireless) or the switch (wired). I run nmap and wireshark against the network regularly, and change passwords regularly too. Its not perfect security even though I only keep 3 ports open, but its not bad.
If you didn't need the operating system, running without one would increase your security, performance and reliability.
-puddingpimp
"The cheapest, fastest, and most reliable components are those that aren’t there." -Gordon Bell
Highly uninformative post as it doesn't mention this situation is only for NT. On UNIXes, port 1521 (or whatever port is selected in installer) is enough.
Oracle's emphasis is rarely on Microsoft's operating systems. Not only in RDBMS, but many other products support UNIXes primarily, and Microsoft's operating systems secondarily.
Bingo Dictionary - Pragmatist, n. A myopic idealist.
I'm using an Oracle 10g RAC cluster and have been since 2008, and we also have multiple 11c clusters and single machines. They are ALL firewalled and they are all operating fine. Financial Institution regulated by the FSA, so people pay attention to this kind of thing around here.
Your instructor gave you poor/bad info - Oracle plays perfectly well with firewalls.
The database had to be in a certain mode though (Don't know if it was shared or dedicated), and some changed to the ORA file or other were necessary too to specify the port.
Oh yes, and in good Oracle fashion, this was only possible from Oracle9i, or before Oracle10 or something like that
And why it pays to be an Oracle consultants, folks
Next lesson: try installing Oracle on a linux platform...I hope you guys know something about library linking, compiler options and make files
This mythical box that only listens on port 80. How do you monitor it's health when you are not sitting in front of it manually tailing logs? How do you get content on that box that only listens on port 80 or is it all static content that NEVER changes? How do you patch it and maintain it? Manually? That would suck unless you only have a few servers you are responsible for. What about outgoing ports? Can it spew outbound mail? Can it get to the internet? When a person installs something else on that machine either on purpose or by accident that listens on other ports? Do you want to only rely on individual local firewall rules on multiple machines? If you are willing to do that and see the advantages, how do you not see the advantage of a firewall at your gateway?
Leave the network and security to those responsible, not the DBA. Just as a network engineer should not be setting policy or giving advice to the DBA or the web site designer on how to do things.
The post sounds to me like it is asking about host based firewall on the server. If you have a firewall on the internet connection then not running firewalls on the hosts themselves is exceedingly common. Historically the hard crunchy outside and soft chewy center model is all anyone ever expected. Now it is considered more important to have additional security in the interior. If all it takes to completely compromise internal security is for one user to wander in with an infected laptop, that isn't good. The need for, benefits of and headaches attached to host based firewalls on servers vary depending on the environment. It isn't something I insist upon.
Mechanic: Somebody set up us the firewall. Operator: Main firewall turn off. CATS: All your [data]base are belong to us. CATS: You have no chance to survive make your time.
In most companies of any size that I have been involved with an application portfolio would need to list the ports and services that it would use.
You could also turn off the firewall, run nmap against the system and see what ports are open. Ask the developers what their application uses from the ports discovered and then turn the firewall on again. Then block what you don't need and open what you do. Yeah, it's a pain in the ass, but not every machine inside your network is always going to play nice with everyone else, so firewalls on important systems are needed.
How come Slashdot never gets Slashdotted?
It's perfectly fine for Unix based system, since open ports and services are few enough for you to disable/configure properly, and nothing you can't recognize anyway.
But very unsafe for windows because networking is enabled and required for everything including registry, WMI, etc, etc. Even if you know about all of them, you can't just turn them off or change the listening address to localhost.
To be fair, just because the network is properly setup and allows for certain behavior etc. does not mean the application will play well with that setup.
This means your application is shit. DON'T fix a properly set up network FIX THE APPLICATION or get rid of it and find an application that does play well with the network. Never give up security for a buggy app. If your application does not play well with a firewall it isn't to proper TCP/IP Internet Standards.
Yes this means you Oracle and Microsoft!
I think most firewalls handle that dynamic re-assignment of connections to higher ports automatically. None of the oracle server's I have access to show firewalls open to wide ranges of ports.
Maybe it is a windows firewall issue? (I'm all linux solaris)