From owner-freebsd-security Sun Mar 19 13:24:07 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA27754 for security-outgoing; Sun, 19 Mar 1995 13:24:07 -0800 Received: from violet.berkeley.edu (violet.Berkeley.EDU [128.32.155.22]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA27745 for ; Sun, 19 Mar 1995 13:24:04 -0800 Received: by violet.berkeley.edu (8.6.10/1.33r) id NAA23182; Sun, 19 Mar 1995 13:23:51 -0800 Date: Sun, 19 Mar 1995 13:23:51 -0800 From: jkh@violet.berkeley.edu (Jordan K. Hubbard) Message-Id: <199503192123.NAA23182@violet.berkeley.edu> To: Nik.Clayton@brunel.ac.uk Subject: Re: FreeBSD and security Newsgroups: comp.unix.bsd.freebsd.misc In-Reply-To: <3k9iei$g3a@beable.brunel.ac.uk> Organization: University of California, Berkeley Cc: security@FreeBSD.org Sender: security-owner@FreeBSD.org Precedence: bulk What really needs to happen is that somebody needs to go write a daemon program that just sits listening for requests and fully authenticates users (admins) that want to schedule things for execution and/or pick up the results of previous "security" runs, and the like. I would base such a daemon VERY strongly on TCL. It's actually all pretty simple. You implement the daemon as 3 separate subsystems: Authentication Script engine Database The authentication system is responsible for establishing connections with clients and authenticating requests for information (or controlling the daemon). If you feel the need, you can even encrypt connections to avoid anyone spying on your security procedures (since you're going to be throwing raw tcl code at this thing at the higher priv levels, it's not such a bad idea!). The script engine is your specially configured tcl interpreter, e.g. some variant on secure-tcl where you have a LARGE body of nice canned commands that also have level classifications in a privilege ring scheme so that you've at least some ability to classify security tasks at different levels for administrative personnel with different levels of privilege. You also add a couple of extra features like checkpointed interruption and loop detection and you've got a pretty able little security language that is also reasonably hard to break (this is important unless you also plan on making this baby multi-threaded!). TCLs basic looping and conditional constructs are more than able enough that you can build a pretty reasonably little library of primitives for checking user attributes, file permissions, network states, filesystem statuses and whatnot and string 'em together for pretty much any kind of system administration task. Your primitives emit database log records as appropriate, and you can come back and query the system later to see what the "state" of it was on a given time and date (the very best of security typically being that which is exercised *after* a break-in, utilising good log information). The final part, the database, would collect log records and associated other information produced by the various primitives in the script engine (or individual scripts themselves - I'd expose the database API into TCL too, of course! :-) for later collection. You'd do the database API such that the database(s) could reside on some other machine, of course, allowing you to keep multiple copies of the log information on one or more remote central servers. I saw a database at CeBIT (db++ or some such name) which looked like it might be quite capable for something like this - it's even got the call-from-TCL ability already included. Anyway, yeah, so.. You could do a pretty nice central security management system this way.. Write a GUI management station based on TK or something and really go to town! :) Jordan From owner-freebsd-security Sun Mar 19 13:27:18 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA28493 for security-outgoing; Sun, 19 Mar 1995 13:27:18 -0800 Received: from violet.berkeley.edu (violet.Berkeley.EDU [128.32.155.22]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA28467 for ; Sun, 19 Mar 1995 13:27:16 -0800 Received: by violet.berkeley.edu (8.6.10/1.33r) id NAA23420; Sun, 19 Mar 1995 13:27:12 -0800 Date: Sun, 19 Mar 1995 13:27:12 -0800 From: jkh@violet.berkeley.edu (Jordan K. Hubbard) Message-Id: <199503192127.NAA23420@violet.berkeley.edu> To: security@FreeBSD.org Sender: security-owner@FreeBSD.org Precedence: bulk Newsgroups: comp.sys.sun.admin,comp.sys.sun.misc,comp.security.unix,comp.unix.bsd.freebsd.misc,comp.unix.bsd.netbsd.misc Path: agate!howland.reston.ans.net!swrinde!ihnp4.ucsd.edu!munnari.oz.au!cs.mu.OZ.AU!darrenr From: darrenr@arbld.unimelb.edu.au (Darren Reed) Subject: Internet Packet Filter for SunOS 4.1.x/xBSD Message-ID: Sender: news@cs.mu.OZ.AU (CS-Usenet) Organization: Computer Science, University of Melbourne, Australia X-Newsreader: NN version 6.5.0 #13 Date: Fri, 17 Mar 1995 04:08:02 GMT Lines: 53 Xref: agate comp.sys.sun.admin:53334 comp.sys.sun.misc:21223 comp.security.unix:13702 comp.unix.bsd.freebsd.misc:178 comp.unix.bsd.netbsd.misc:79 Internet Packet Filter for SunOS 4.1.x/NetBSD/FreeBSD ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I'd like to announce the most recent results of my efforts in writing an IP packet filter for Unix servers/workstations. Why would you need it ? * Allows you to protect your subnets against IP spoofing (the most recent `attack' against as used by Kevin Mitnick) where you have Unix doing IP routing; * Allows you to build a firewall using your existing SunOS/*BSD setup without needing to purchase expensive software/hardware. Recent featurisms added include: * optional returning ICMP error packets for "blocked" packets (a per-rule option, allowing some rules to block packets silently and others with a returned ICMP packet); * "short" TCP packets (which can be deficient in various TCP header details) can be filtered out - short UDP/ICMP packets are just dropped and logged as a matter of course - by default "short" packets are NOT checked against port values/TCP flags; * fragmented IP packets can be selectively filtered; * TCP/UDP packets can be grouped together for filtering on ports; * ipftest (largely as yet undocumented :/) will read in either tcpdump/ etherfind output (text) or snoop binary output (see recent RFC) and apply a ruleset against each IP packet found therein; (good for testing your rules before you "commit" yourself) * The "log reader", which reads the log "output device", has been updated to show which rule and the result (block/pass/log) of the filtering at the stage it was logged. Also, ICMP headers are now expanded out properly. How do I get it to work ? * Follow the instructions on installing the kernel patches, rebuild your kernel and use "modload" to load the packet filter. From there on, it is upto you and what you want to do with it. Where can I get it to check out ? coombs.anu.edu.au:/pub/net/kernel/ip_fil2.5.tar.Z coombs.anu.edu.au:/pub/net/kernel/ip_fil2.5.tar.gz Cheers, Darren From owner-freebsd-security Mon Mar 20 00:43:59 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA13632 for security-outgoing; Mon, 20 Mar 1995 00:43:59 -0800 Received: from dns.netvision.net.il (root@dns.NetVision.net.il [194.90.1.5]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA13610 for ; Mon, 20 Mar 1995 00:43:48 -0800 Received: from ugen.NetManage.co.il (ugen.netmanage.co.il [192.114.78.165]) by dns.netvision.net.il (8.6.10/8.6.9) with SMTP id KAA01074; Mon, 20 Mar 1995 10:42:43 +0200 Date: Mon, 20 Mar 95 10:45:04 IST From: "Ugen J.S.Antsilevich" Subject: Re: To: security@FreeBSD.org, "Jordan K. Hubbard" X-Mailer: Chameleon 4.00-Arm-25, TCP/IP for Windows, NetManage Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: security-owner@FreeBSD.org Precedence: bulk >Internet Packet Filter for SunOS 4.1.x/NetBSD/FreeBSD >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >I'd like to announce the most recent results of my efforts in writing >an IP packet filter for Unix servers/workstations. My IpFW does all of it..hmm.may be i really should port it somehow to Sun also? -- -=Ugen J.S.Antsilevich=- NetVision - Israeli Commercial Internet | Learning E-mail: ugen@NetVision.net.il | To Fly. [c] Phone : +972-4-550330 |