From owner-freebsd-security Sun Sep 2 9: 2: 3 2001 Delivered-To: freebsd-security@freebsd.org Received: from mailer.progressive-comp.com (marc1.theaimsgroup.com [63.238.77.171]) by hub.freebsd.org (Postfix) with ESMTP id 8D60837B401 for ; Sun, 2 Sep 2001 09:01:58 -0700 (PDT) Received: (from docs@localhost) by mailer.progressive-comp.com with id MAA30005; Sun, 2 Sep 2001 12:01:53 -0400 Date: Sun, 2 Sep 2001 12:01:53 -0400 Message-Id: <200109021601.MAA30005@mailer.progressive-comp.com> From: Hank Leininger Reply-To: Hank Leininger To: freebsd-security@FreeBSD.ORG Subject: Re: Possible New Security Tool For FreeBSD, Need Your Help. X-Shameless-Plug: Check out http://marc.theaimsgroup.com/ X-Warning: This mail posted via a web gateway at marc.theaimsgroup.com X-Warning: Report any violation of list policy to abuse@progressive-comp.com X-Posted-By: Hank Leininger Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2001-08-31, "Not Going to Tell You" wrote: > I could close all the ports on my box except those needed to provide a > service (i.e. port 80), however, how can I remote manage it? So then I > would have to open a sshd port also. But this leads to a potential > security problem when scanned by a hacker. So, what if I had a program > that sent a type of "Key" to the box and the box recognized that the > key sequence order was from me, then opened the sshd port. After I was > finished with the sshd session, I would run another program to close > the port behind me? If you were to do this, "listen for a few packets that look like in order" would be a bad way to do it--completely open to sniffing, replay attacks, race conditions, etc. Perhaps you could generate a gpg-signed "open" request, where the signed payload included the incoming IP to allow, and a timestamp (encrypting this all with the server's public key would be a good idea, but not essential). Then whack this data into IP and TCP options fields of some set of packets you throw at the box. The server would listen for the right sequence of packets, reconstruct the payload stuffed in the options, check the signature, and open a temporary hole which would allow a single 3WHS (not just a single inbound SYN, which could be spoofed to DoS you) to complete before closing the hole again. But really, it hardly seems worth the bother. A whole lot of complexity (==places for your implementation to be buggy and open new security holes) and resource-consumption (==DoS opportunity) for little gain other than security through obscurity. Now, if there were a CGI that was POSTed to with this signed/encrypted request... or the box also received mail, and one mailbox was watched for a properly signed/encrypted email... -- Hank Leininger We could build a large, wooden badger... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message