From owner-freebsd-security Sun Jul 30 11:12:56 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id LAA17408 for security-outgoing; Sun, 30 Jul 1995 11:12:56 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id LAA17402 for ; Sun, 30 Jul 1995 11:12:51 -0700 Received: by sequent.kiae.su id AA07562 (5.65.kiae-2 ); Sun, 30 Jul 1995 22:10:30 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Sun, 30 Jul 95 22:10:29 +0400 Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id WAA00674; Sun, 30 Jul 1995 22:03:31 +0400 To: Paul Traina , security@freebsd.org References: <199507300543.WAA01343@precipice.shockwave.com> In-Reply-To: <199507300543.WAA01343@precipice.shockwave.com>; from Paul Traina at Sat, 29 Jul 1995 22:43:10 -0700 Message-Id: Organization: Olahm Ha-Yetzirah Date: Sun, 30 Jul 1995 22:03:31 +0400 (MSD) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= aka "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: Re: correction on last message... Lines: 18 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 768 Sender: security-owner@freebsd.org Precedence: bulk In message <199507300543.WAA01343@precipice.shockwave.com> Paul Traina writes: >actually, the string to key and pcbc_encrypt routines are there, just the first >three are missing. Paul, I already discover this thing fixing Makefiles about week ago. It seems your connection was lost those days? Currently Mark have newest libdes fro Eric Young and I ask Eric to implement those functions too. Mark waits for Rod's question about legal importing in USA will be solved. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-security Sun Jul 30 12:22:25 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id MAA20420 for security-outgoing; Sun, 30 Jul 1995 12:22:25 -0700 Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id MAA20395 for ; Sun, 30 Jul 1995 12:21:16 -0700 Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.11/8.6.11) with SMTP id UAA01482 for ; Sun, 30 Jul 1995 20:17:52 +0100 To: security@freebsd.org Subject: Firewall report generator Date: Sun, 30 Jul 1995 20:17:51 +0100 Message-ID: <1480.807131871@palmer.demon.co.uk> From: Gary Palmer Sender: security-owner@freebsd.org Precedence: bulk Hi Due to getting quite a few requests and the relatively small size of the program (despite the 1.5k copyright message :-( ), I've decided to post this here for all to see :-) This relies on perl4 - I dunno what'll happen if you feed this to perl5, and I don't particularly want to try, so I've specified that it must be run by /usr/bin/perl, which under FreeBSD should be perl4. Just after the BSD-style copyright, there are a few variables you can tweek, and a breif explanation of what they do. They are supplied set to something vaguely resembling global defaults. If you find this useful, all donations of cash or hardware (or pizza at a push) are gratefully received :-) Gary -- SNIP -- #!/usr/bin/perl # $Id$ # # Copyright (c) 1995 # Gary J. Palmer. All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer, # verbatim and that no modifications are made prior to this # point in the file. # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # 3. All advertising materials mentioning features or use of this software # must display the following acknowledgement: # This product includes software developed by Gary J. Palmer # for the FreeBSD Project. # 4. The name of Gary J. Palmer or the FreeBSD Project may not be used # to endorse or promote products derived from this software # without specific prior written permission. # # THIS SOFTWARE IS PROVIDED BY GARY J PALMER ``AS IS'' AND ANY EXPRESS OR # IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES # OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. # IN NO EVENT SHALL GARY J PALMER BE LIABLE FOR ANY DIRECT, INDIRECT, # INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, # BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS # OF USE, DATA, LIFE OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED # AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR # TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. # Where the kernel messages are recorded by syslog $LOGFILE="/var/log/messages"; # How to read the log (e.g. if it has been compressed) # if it has been compressed, use something like: # $READLOG="/usr/bin/zcat $LOGFILE |" $READLOG="$LOGFILE"; # A scratch file for recording the output before mailing it off # You may want to move it to somewhere with a lot of disk space if you # have a lot of data for the report $REPORT="/var/tmp/.report"; # Who to e-mail the report to $MAILTO="root"; # Who the e-mail should look like it's come from # NB - This may not work right, depending on what userid runs this script # and how your sendmail.cf is setup $MAILFROM="root"; # The mailer to feed the e-mail to - sendmail by default $MAILER="/usr/sbin/sendmail" # The regex pattern used for matching logfile entries (jeeze - this is # nasty :-( ) $PATTERN="([^\/]+)\/([a-zA-Z_0-9]+): Deny ([A-Z0-9a-z]+) ([0-9\.]+):([0-9]+) ([0-9\.]+):([0-9]+)"; ############################################################################### # In theory, you shouldn't have to touch below here # ############################################################################### open(FILE, "$READLOG"); open(OUTFILE, "> $REPORT"); print OUTFILE "From: $MAILFROM\n"; print OUTFILE "Reply-To: $MAILFROM\n"; print OUTFILE "To: $MAILTO\n"; print OUTFILE "Subject: Firewall Packets Denied Report\n"; print OUTFILE "\n"; while () { if (m/$PATTERN/i) { ($date, $kernel, $proto, $fromaddr, $fromport, $toaddr, $toport) = ($1, $2, $3, $4, $5, $6, $7); $a = $proto; $a =~ tr/A-Z/a-z/; $fromhost = gethostbyaddr(&inet_aton($fromaddr), 2); ($fromportn) = getservbyport(&htons($fromport), $a); $tohost = gethostbyaddr(&inet_aton($toaddr), 2); ($toportn) = getservbyport(&htons($toport), $a); print OUTFILE "$date$proto "; print OUTFILE "$fromhost:" if $fromhost ne ""; print OUTFILE "$fromaddr:" if $fromhost eq ""; print OUTFILE "$fromportn " if $fromportn ne ""; print OUTFILE "$fromport " if $fromportn eq ""; print OUTFILE "$tohost:" if $tohost ne ""; print OUTFILE "$toaddr:" if $tohost eq ""; print OUTFILE "$toportn\n" if $toportn ne ""; print OUTFILE "$toport\n" if $toportn eq ""; } } close(OUTFILE); `cat $REPORT | $MAILER $MAILTO ; rm $REPORT`; sub inet_aton { local($addr) = @_; local($in_addr, $foo); $_=$addr; $foo = /([0-9]+).([0-9]+).([0-9]+).([0-9]+)/i; $in_addr = pack('C4', $1, $2, $3, $4); return $in_addr; } sub htons { local($in) = @_; local($out, $a, $b); $out = unpack('S', pack('n', int($in))); return $out; } From owner-freebsd-security Sun Jul 30 12:48:34 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id MAA21011 for security-outgoing; Sun, 30 Jul 1995 12:48:34 -0700 Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id MAA21003 for ; Sun, 30 Jul 1995 12:48:29 -0700 Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.11/8.6.11) with SMTP id UAA01612 for ; Sun, 30 Jul 1995 20:47:41 +0100 To: security@freebsd.org Subject: Re: Firewall report generator In-reply-to: Your message of "Sun, 30 Jul 1995 20:17:51 BST." <1480.807131871@palmer.demon.co.uk> Date: Sun, 30 Jul 1995 20:47:40 +0100 Message-ID: <1610.807133660@palmer.demon.co.uk> From: Gary Palmer Sender: security-owner@freebsd.org Precedence: bulk In message <1480.807131871@palmer.demon.co.uk>, I wrote in haste: ># The mailer to feed the e-mail to - sendmail by default >$MAILER="/usr/sbin/sendmail" ^; Gary From owner-freebsd-security Mon Jul 31 09:41:24 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id JAA09930 for security-outgoing; Mon, 31 Jul 1995 09:41:24 -0700 Received: from elf.kendall.mdcc.edu (elf.kendall.mdcc.edu [147.70.150.122]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id JAA09922 for ; Mon, 31 Jul 1995 09:41:22 -0700 Received: (from freelist@localhost) by elf.kendall.mdcc.edu (8.6.11/8.6.9) id MAA10729; Mon, 31 Jul 1995 12:32:21 -0400 Date: Mon, 31 Jul 1995 12:32:20 -0400 (EDT) From: "Don's FList drop" To: Sean Eric Fagan cc: rgrimes@gndrsh.aac.dev.com, security@freebsd.org Subject: Re: secure/ changes... In-Reply-To: <199507260318.UAA20861@kithrup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: security-owner@freebsd.org Precedence: bulk On Tue, 25 Jul 1995, Sean Eric Fagan wrote: > In article <199507260200.TAA23061.kithrup.freebsd.security@gndrsh.aac.dev.com> you write: > You're a bright guy, Rod, and it's hard for me to say this, but: almost > everything in your message was WRONG. > > >PGP is a one way hash function, it is not encryption software, thus it > >does not fall on the munitions lists, thus it is not restricted. > > PGP is encryption software. It uses RSA. It is a munition. This is why > Zimmerman is currently facing a possible Grand Jury indictment, for ITAR > violations -- exporting munitions. To be overly anal, PGP in fact uses IDEA _and_ RSA. Data is encryped with an IDEA key, which is then included in the outgoing packet which is encrypted with the RSA key. This makes the body of the message more resistant to brute force attacks, blah blah blah. From owner-freebsd-security Fri Aug 4 06:10:37 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id GAA10272 for security-outgoing; Fri, 4 Aug 1995 06:10:37 -0700 Received: (from pst@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id GAA10264 for security; Fri, 4 Aug 1995 06:10:37 -0700 Date: Fri, 4 Aug 1995 06:10:37 -0700 From: Paul Traina Message-Id: <199508041310.GAA10264@freefall.cdrom.com> To: security Subject: FTP data port restrictions Sender: security-owner@FreeBSD.org Precedence: bulk While looking at Nick Sayer's home page, I caught his reference to FTP data port quarantines, and after thinking about it a bit, decided that this is a good idea, and by default, FreeBSD's FTP client and daemon programs should try to always use a restricted range of data ports (40000-44999) for transfers. If you have a FTP server, you would like your FTP server to restrict its port range to a safe area when clients ask for a passive FTP connection, so you don't have to expose all of your >1023 ports on this machine. If you have a FTP client, you would like to be able to restrict the ports you request to a given "safe" range in case you're talking to some mean old nasty FTP server that doesn't support passive mode (because THEIR sysadmins are as paranoid as OUR sysadmins). The basic idea here is that we leave 40000-44999 open, since no known sane services reside there (yeah, sure...) at the firewalls, and can therefore button down everything else. This in no way precludes passive mode transfers, rather it extends the usablity of FTP clients and FTP servers in light of passive and non-passive mode transfers. Would someone care to check over my diffs for any glaring errors? They're freefall: ~pst/ftp-diffs Still TODO: ncftp version and documentation From owner-freebsd-security Fri Aug 4 07:18:16 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id HAA13343 for security-outgoing; Fri, 4 Aug 1995 07:18:16 -0700 Received: from gateway.fedex.com (gateway.fedex.com [198.80.10.2]) by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id HAA13334 ; Fri, 4 Aug 1995 07:18:13 -0700 Received: by gateway.fedex.com id AA05932 (InterLock SMTP Gateway 3.0); Fri, 4 Aug 1995 09:18:09 -0500 Message-Id: <199508041418.AA05932@gateway.fedex.com> Received: by gateway.fedex.com (Internal Mail Agent-2); Fri, 4 Aug 1995 09:18:09 -0500 Received: by gateway.fedex.com (Internal Mail Agent-1); Fri, 4 Aug 1995 09:18:09 -0500 To: Paul Traina Cc: security@freefall.cdrom.com Subject: Re: FTP data port restrictions Date: Fri, 04 Aug 1995 09:19:37 -0500 From: William McVey - wam Sender: security-owner@FreeBSD.org Precedence: bulk Paul Traina wrote: >The basic idea here is that we leave 40000-44999 open, since no known >sane services reside there (yeah, sure...) at the firewalls, and can >therefore button down everything else. It's important for people to realize that allowing arbitrary connections into your inside network even if they are destined for these ranges is still not a safe thing to do. The problem is that although no *sane* services are running in this block of ports, we still have the problem of RPC dynamic port allocation, so for as far as we know nfsd or mountd could be running in this range. The feature of resticting port ranges may still be usefull for proxy services (since you know you aren't running any rpc services on your proxy host), but if a site's security depends on a screening router, I'd hate for people to get the idea that these ports are deemed "safe". -- William From owner-freebsd-security Fri Aug 4 07:34:45 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id HAA14037 for security-outgoing; Fri, 4 Aug 1995 07:34:45 -0700 Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id HAA14031 for ; Fri, 4 Aug 1995 07:34:39 -0700 Received: from localhost (localhost [127.0.0.1]) by precipice.shockwave.com (8.6.11/8.6.9) with SMTP id HAA02273; Fri, 4 Aug 1995 07:33:31 -0700 Message-Id: <199508041433.HAA02273@precipice.shockwave.com> To: William McVey - wam cc: security@freefall.cdrom.com Subject: Re: FTP data port restrictions In-reply-to: Your message of "Fri, 04 Aug 1995 09:19:37 CDT." <199508041418.AA05932@gateway.fedex.com> Date: Fri, 04 Aug 1995 07:33:31 -0700 From: Paul Traina Sender: security-owner@FreeBSD.org Precedence: bulk From: William McVey - wam Subject: Re: FTP data port restrictions Paul Traina wrote: >The basic idea here is that we leave 40000-44999 open, since no known >sane services reside there (yeah, sure...) at the firewalls, and can >therefore button down everything else. It's important for people to realize that allowing arbitrary connections into your inside network even if they are destined for these ranges is still not a safe thing to do. The problem is that although no *sane* services are running in this block of ports, we still have the problem of RPC dynamic port allocation, so for as far as we know nfsd or mountd could be running in this range. We can only go so far as to fix our own software. Services that don't -specificly- bind themselves to a port (i.e. anyone who calls bind with a 0 port, get assigned a range from 1024 to 5000), which is why you will never see floating RPC daemons in ports greater than 5000. Other RPC daemons, such as NFS, which do lock themselves down to a particular port can fall outside that range, but if they're locked down, you can block them. The feature of resticting port ranges may still be usefull for proxy services (since you know you aren't running any rpc services on your proxy host), but if a site's security depends on a screening router, I'd hate for people to get the idea that these ports are deemed "safe". I agree, and the documentation will say something to that effect, but given the unfortunate situation we currently have, where bloody daemons and user stuff share the same range of ports, we're seriously SOL. If we had it to do over again, we should have reserved the bottom 8k for privileged daemons, then next 8k for unprivileged services, then next 16k for floating services, and the top 32k for client sourced ports. Oh well..