We here have no access to the mainframe by choice (security department's choice), based on the data that we keep here. Would we (as software developers)like a secured FTP access...probably...but probably won't happen in my lifetime.
Kevin -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Thursday, November 30, 2006 9:57 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: CMSDDR-format Linux files. Was: SLES10 Install kernelpanic > [snip argument about firewalls] You're missing the point I'm trying to make here. It's not the provider of the FTP or HTTP service that has the issue, it's the potential consumer of the service having policies that say "no external access from this machine". Whether FTP is secure or not is a symptom of the problem, not the problem itself. > note, I don't accept that "no security exposure" is possible unless one > does not connect to the Internet. A valid technical argument that doesn't matter a whit against the emotional arguments used to validate the "no external access" policies. > > There probably is. That doesn't change the basic fact of the argument > > one iota. If the company's policy says "no", you're not going to change > > that for something like this. > SUSE does allow incoming ftp (I just tested), so in this case, the > company policy does not say "no." See above. I was discussing the potential clients, who clearly *do* have policies about such things. > The immediate question I responded to was the question of ftp through > firewalls. If I, a Big Corporate, decide not to do that, that is one > matter. My point exactly. > A firewall vendor imposing its rules on me, for any reason it > might think of, is not acceptable. The point is not the firewalls, but how they are used and managed. I originally said that it's hard to set up FTP proxying properly. If it's hard, then J Random Admin *will* make mistakes, or just leave the defaults in place, and some commercial vendors have poor defaults. It's not an issue of whether FTP can be made to work with firewall X -- any firewall can be properly configured if used and configured by a competent admin -- but whether the default settings are such that it works reasonably in all cases when managed by a bozo. The design of FTP is such that it's hard to make a piece of firewall software have reasonable behavior in the default case. This leads security auditors to simply order FTP disabled or mandate policy that effectively does the same. But, again, this is just an example of the discussion of "no access from this machine" policy statements. Regardless of the technologies involved, if the policy says "no access", then whether a technology would work or not, you don't care because it can't be applied *in that customer*. Clearer? -- db ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
