On 04/22/2014 06:38 PM, John Andersen wrote:
The security violation you postulate was letting a connection happen BEFORE you launched your firewall.
NO! The security violation I postulated involved the firewall being down FOR ANY REASON. Lets leave aside misconfiguration ... In Patrick's case we have an example of the generic Something isn't working... I wonder if the firewall is in the way.... Lets take it down for a while and experiment... Patrick remembered to put it back up PROMPTLY, but we don't know what the critical aperture is. I've read that newly installed Windows machines on the 'Net can be hacked in a couple of minutes between being connected and firewall software being installed/configured. My POV is that security rule is a security rule. If the firewall rules prohibit a connection then they should ensure that connection does not exist as opposed to merely 'cannot be initiated'. I understand the explanation you give and don't disagree with it. Yes you have explained what is going on. I think you are quite correct.
You can ssh into a remote server, dick around with the firewall settings and stop/restart it without worrying about killing your own ssh connection, and potentially leaving your remote machine in a broken and vulnerable state. That original connection will persist.
I don't see the problem. The rules permit a ssh connection. My 'proposed' idea about tearing down connections that violate the rules would allow this connection because the rules permit it. I'm NOT saying that starting the firewall should tear down all connections. I'm talking about connections that the firewall would otherwise prohibit. A few years ago, not long after AIX was released, I had an argument with a senior executive at IBM. My attitude towards security configuration lies on the side of "everything that is not explicitly allowed is prohibited". I held that all the services that inetd, for example, supported should be default off. He insisted that the way AIX was then shipped with most of them default on was correct, and that it was the sysadmins responsibility to determine what needed to be turned off for security purposes. I had seen too many novice admins who didn't know enough about security, never mind fringes of security that hackers exploit, which is why I had come to adopt the 'everything off' stance. If the users needed it they would demand it and it could be turned on. There are services such as tftp that are fringe/specialized yet offer entrances to hackers, and I can see no reason to ship them default on. In the long run I feel justified; most of the systems I deal with now - Linux, AIX and other non-Windows systems - are shipped 'default off' for many facilities, especially inetd and xinetd. We can't expect sysadmins to be aware of every security hole that might be generated. We need to have aggressive defaults. Yes, I realise that many of these will require, no will DEMAND more vigilance on the part of the people building the isntllation kits. We've recently had a discussion of Apparmor and Dovecot and I think that's a good posterboy. Installing Dovecot _should_ include installing the Apparmor rules that allow it to be run. Heck, installing it bring in the relevant PAM entries, doesn't it? -- "Realizing the importance of the case, my men are rounding up twice the number of usual suspects" -- Cpt Renault to Major Strasser, Cassablanaca -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org