Re: [leaf-devel] Mike Noyes
Phil: Please pass along my wishes to Mike for a speedy recovery! -Scott On Mon, 12 Apr 2004, Phil Noyes wrote: Everyone, Mike was in a accident. He is in the hospital. He asked me to let you know that he would not be working on the WEB page for a while. He hit his head while riding his bicycle. He was in surgery for 3.5 hours. It looks good for a full recovery. I do not expect him to start work on the WEB page before next month. Phil Noyes --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New use for firewalls?
David: Heya. In my experience, wireless-access points are always placed on the outside of a corporate LAN's firewall, on a specific interface. And that interface is setup to deny all traffic not of type IPSec or PPTP. A VPN server is then setup behind the firewall, and all wireless members are then required to authenticate with a VPN client to the VPN server. Without this authentication, any wireless member can still access the WAN connection...which turns out to be a big feature, as contractors/partners/customers who come to visit the facility can still VPN back into their own corporate LAN. Otherwise...regarding firewall-authentication for wireless users, I *think* that's what NoCat's all about. Along those lines, I started a project called Radiance once that was a lot like you described. I can dig up some details if you're interested... -Scott On Tue, 25 Mar 2003, David Douthitt wrote: I've been working with this new Airport (Apple's 802.11b wireless) and finding out just how insecure America's wireless networks are. Seems like a good purpose for a 486 or Pentium with two network cards would be to act as a firewall and proxy between wireless clients and the rest of the network. Each base station or access point could then be isolated from the rest of the network, and only authorized clients could be allowed in. Authorization could be done over SSL, and all access could be controlled via web proxy and ftp proxy. SSH could be used for terminal access (through the firewall). Are people using these wireless solutions that way? Is there one out there already? -- David Douthitt [EMAIL PROTECTED] UNIX SysAdmin - HP/UX, UnixWare, Linux LPIC-1, Linux + --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New use for firewalls?
Charles: Heya. Don't even need a rogue WAP: LinkSys (now Cisco) has a driverless wired-to-wired bridge, the WET11. Attach that to any secure wired socket and a whole world of problems comes down. Partly, this has been a motivational driver behind the Kaboodle project which conumes most of my cycles (www.Kaboodle.org). It manages a visual LAN poulation GUI, updated automatically, so you can see everything that's on the network at all times. As soon as something joins, Kaboodle will sniff its ARP who has requests, and present it into the GUI. It's not perfect (eg, it uses MAC address for long-term identifiers) but I've cuaght my neighbors using my WLAN more than once. :) -Scott On Tue, 25 Mar 2003, Charles Steinkuehler wrote: David Douthitt wrote: I've been working with this new Airport (Apple's 802.11b wireless) and finding out just how insecure America's wireless networks are. Seems like a good purpose for a 486 or Pentium with two network cards would be to act as a firewall and proxy between wireless clients and the rest of the network. Each base station or access point could then be isolated from the rest of the network, and only authorized clients could be allowed in. Authorization could be done over SSL, and all access could be controlled via web proxy and ftp proxy. SSH could be used for terminal access (through the firewall). Are people using these wireless solutions that way? Is there one out there already? Lots of folks are doing this with their wireless networks, and using linux based boxes to provide the firewalling. Off the top of my head, check out the NoCatNet folks (mainly geared towards publicly available wireless lans, but requiring login/auth before use): http://nocat.net/ There are, however, major problems with *ANY* access-point firewall type solution. While your wired networks are protected from rogue wireless clients, what protects valid wireless devices from attack or sniffing by other wireless clients? Going a step further, given the ease of installing a $50 WAP, exactly how secure are your internal networks that rely on a physical access security model? Are you sure some bozo in sales didn't install a WAP just so he could browse the 'net from his laptop while on a smoke break? If he did, how would you know, and how could you protect your network from this in advance? I think we're heading to a point where *ALL* communication across a network, whether internal or external, wired or wireless, will need to be encrypted, and/or authenticated for any reasonable expectation of security. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Java on Bering
Heyaz. Been a while since I posted. :) Another Java-on-Linux is Blackdown: http://www.blackdown.org Size requirements are: JDK 1.02: 28M RAM, 10M Disk 1.1.8 35M RAM, 40M Disk 1.2.2 100M RAM, 61M Disk So if your app runs with a 1.02 JDK, it doesn't look impossible for LEAF... -Scott On Thursday 13 March 2003 05:17 am, S Mohan wrote: I want to run a Java App on Bering and build a dedicated, robust embedded box for a specific purpose. How do I do this? Is java available as an lrp on Bering? snip --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Dave Cinege
Mike: I was just wondering about this last night. You're right about the network trouble: none of the DNS servers in the WHOIS record for linuxrouter.org are responding to pings (four machines in the Linkscape.net domain). -Scott On Thu, 8 Aug 2002, Mike Sensney wrote: News Flash for what it is worth... I tried to get through to www.linuxrouter.org and couldn't. Further checking shows that DNS is not working on the following domain names, all of which are owned by Dave Cinege. linuxrouter.org, Linkscape.net, psychosis.com I'm subscribed to the LRP list (still.) The last message I got from that list is dated 7/24/2002. -- Mike Sensney --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: Re[2]: [Leaf-devel] Dave Cinege
Charles: Heya. I still haunt the LRP list, and Dave flipped the no spam switch back in April or so. It was a fairly busy list before he did that, mostly with some peculiar firewall/router concerns regarding penis size and mortgage rates... -Scott On Thu, 8 Aug 2002, Charles Steinkuehler wrote: I suppose it's possible... One odd thing now that linuxrouter.org is back up...there seems to be a lot of traffic listed in the list archives that doesn't make it to the Geocrawler archive, including a lot of SPAM. Mike: Since it sounds like you're still subscribed, do you get all this SPAM traffic from the linuxrouter list, just the stuff that's listed at geocrawler, or something in-between? IIRC, when I was subscribed to the linuxrouter list, the geocrawler site wasn't doing a very good job of archiving the list...maybe this is still a problem? Oh...linuxrouter.org wasn't working for me when I initially wrote my reply either, I just thought to check psychosis.com before I clicked send, and lo-and-behold, everything was back online... - Charles Very strange. It is working for me now also. But I had tried accessing the linuxrouter site just before sending my message. And now it is working for me also. Maybe DC reads this list. :-) Thursday, August 8, 2002, 12:47:16 PM, Charles Steinkuehler wrote: CS And the Geocrawler archive of the linuxrouter lists only 11 messgaes for CS all of July, with the last one on 7/24/2002...none yet in August, and CS only 364 messages for the entire year! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] is Bering GNU?
George: I just wanted to point out the obvious: Is Bering GNU? [snip] ...I know asking for doc is a lot, but maintaining a file of command lines used to make the binaries from source would be an excellent first step. While I'm no expert, this is a new definition of GNU for me: requiring a file of command lines used to make [all of] the binaries [in the whole distribution]. The source code for Bering (kernel, modules, patches, packages, etc), and all of the precompiled binaries that come with it, is freely available to anyone who requests it. Further, any modifications to GPL'd code that Jacques and Eric made are also GPL'd. That's GNU. Perhaps you are more accustomed to compiling a standalone binary, most of which utilize a ./configure script (itself a GPL'd item), at the command line of a full *nix distro. However, adhering to such a *convention* (that's all it is) is not mandated within the precepts of the Copyleft. Nothing is more or less GNU for doing it or not doing it in this fashion. Also, obviously, you're quite welcome to take Bering, modify it as you wish, put it on an EEPROM for your own use, and never distribute it. That's GNU too. -Scott PS: Bering being central to LEAF, I've restricted my cross posting to just the LEAF lists. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] How do I request help FAQ
A quick comment: 1. Is incorporating a diagnostics script in into each LEAF distribution a good idea? Probably (as long as it doesn't get so big as to cause problems with fitting on a floppy). This is a good idea. We could ask for users to post *at a minumum* the results of ~root/diagnose, which creates a file called SENDME. That will provide a 90-percent solution, which sometimes is as good as you can get. -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Greetings from the wonderful world of NoCat...
Clarifying... 1. What were your design considerations in regards to putting the authorization info and server on the firewall itself? The alternatives are harder, but strike me as possibly more secure than putting such important stuff on boxes whose physical security cannot be assured. In a typical setup, no sensitive information is stored on the firewall machine (or gateway, as we call it), so I'm afraid I don't understand your question. From the NoCat whitepaper: |-The Client then makes an HTTPS POST request to the Authentication | Service (probably via an SSL enabled browser.) The POST request | includes the member's login, password, and optional MAC address | information. |-The Authentication Service validates the request, and returns an | appropriate response to the Client. My impression was that the NoCatAuth process verified this login-password-MAC thing, and so would need to storesomething? 2. Any thoughts about HereUAre.com? I met with them last year downin Santa Clara, CA., though nothing came of it. Don't know anything about it, but last we heard they were trying to make money on a public radio band, so we weren't especially interested. So radio's and radio silicon is okay to sell, but not radio service? :*) Not trying to bait you here -- I'm a big proponent of public-access 802.11 hotspots. So much so that I wish it could move at the velocity of something driven by capitalism rather than altruism. 3. I was curious if you've looked at LaBrea at all, to tarpit the unused IP's on the WLAN until someone authenticates with your NoCatAuth. Never looked at it before you mentioned it, but I'd say it's basically outside the scope of our project. Other wireless groups have expressed an interest in RIDS, to prevent luser antics on the wireless network, and our attitude is basically the same. We do require transparent port forwarding on the gateway firewall, however. From my perspective, I see 'theft of service' as, well, the point of any authentication scheme. Perhaps my perspective isn't that aligned with NoCat's? Thanks again! -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] New LEAF user Choose version FAQ
Lynn: Heya; some quick feedback on your FAQ. Very qualitative stuff, so take from it what you will. :) Also, should Seattle Firewall, ShoreWall, and OpenWall be covered in this FAQ? It wouldn't be a problem. There's a fair parallel: choosing which firewall package to use is similar to choosing what LEAF distro to use. The LEAF (Linux Embedded Appliance Firewall) project are one of my favorite IT tools. Do you need a small Linux distribution that will scale down to a single floppy disk or is expandable to span several floppies, a flash disk, or a CD? I think you're touting the distro's flexibility here, but I think most Linux distro's can claim to run from a CD. The very small media (floppy, DoC) is really more impressive. Do you want a STRONG home firewall that you can make from old spare parts or find laying out in the trash or a friends garage? Well...it's not as if you build it from paint cans and nerf footballs. :) It does turn the doorstop of an old PC into something that becomes one of the most important pieces of a broadband network, though. Do you need a cheap VPN gateway solution without the thousands of dollars in licensing fees? Akshally, the low-end LinkSys and Sonicwall stuff do VPN passthru and one-notch up they do VPN endpoint, without the licensing that (say) Cisco or Watchguard would charge. Some old versions of LEAF can run on a 386SX, but for the more recent versions/branches a 486DX33 with 16Meg's of RAM is suggested for a floppy versions (24 Meg's for the cdrom versions) for cable modem users and an old Pentium 133 with suggested 24Meg's of RAM should saturate a T1 WAN connection unless you running an encrypted VPN gateway. That's a busy sentence. :) Content wise, the old versions of LEAF were actually called LRP: LEAF didn't start until Eigerstein really. Also, cable-modem users could fairly be called cable/dsl modem users. Lastly, the saturation capability is primarily a function of whether the NIC is an ISA card or a PCI card, not so much the processor speed. Any Pentium-1 class PCI-based machine with 24MB RAM could saturate a T1, even with being a VPN endpoint. The coolest part is run on a write-protected floppy or a cdrom, if the machine is compromised, you can just restart it and it is back to the original setup...not even Cisco can guarantee that. A very good point. However (based on recent experience), the downside to a floppy system is the reliability: the disk will die after a while, long before a HD would. So be careful of celebrating the floppy part too much. All parts are common PC hardware typically, so you can always find and buy hardware for it if something goes bad. I'd say a system suitable for LEAF costs about $50 to $100. You may want to spell it out: 486 66MHz, 16MB RAM, no HD, 2 ethernet NICs...maybe even a URL to a good site for used stuff cheap. Another major difference between LEAF distributions and your regular Linux distributions is that LEAF is embedded Linux. This means that the system runs in a virtual disk in RAM, which is the fastest once booted, and safe from system crashes if they may occur because there is no data loss of the boot/configuration disk(s). I'd move this to near the top of the description. It is fundamental to how LEAF works, really, and describes why the system is primarily constrained by RAM siz. Dachstein I'd point out here, or maybe above, that LEAF s primarily used as a *masquerading* firewall, also called a NAT'ing firewall, or a firewall/router. it can be just a firewall too, sure, but most people used it to masq. Also, I'd emphasize that Dachstien's target user is the new-to-LEAF user, as it's optimized to get working quickly by focusing 90-percent of the required configuration into a single file: network.conf. It comes with no development tools, but it packs all of the essential packages in: SSHd, VPN passthru, DHCP client and server, DNS cache, a web-based monitor. Not sure what you meant with SSL. Lastly, the stock firewall is good, but it requires a fair amount of TCP/IP know-how to customize, and it tends to, IMO, log too many unimportant packet events which can be disconcerting to a novice user. Oxygen Oxygen is definitely for those who want more than a Linux network appliance, but rather want a box that doubles as a full fledged Linux system, complete with development tools. LRP-the Original It's hard to know what to say about LRP. It's certainly true that LEAF branched (pun!) out of LRP, in an effort to make LRP systems more accessible and better supported. Dachstein is really what Dave Cinege would have called an idiot image meaning, if your a Linux idiot (aka, new user), use this. Dave did some great work to get LRP started, but he's not exactly known for playing well with others, and he ignored the contributions of too many people for too long, and so LEAF had
Re: [Leaf-devel] New LEAF user Choose version FAQ
Jack: That's a really good point: the biggest advantage that a LEAF system has over a low-end LinkSys/Sonicwall/Netscreen appliance is that LEAF *really is* a Linux system. A user can add software to it almost as easily as adding software to a RedHat desktop; just find the package.lrp file and lrpkg -i it. Install ssh/scp clients, perl, IPSec endpoints, nmap, even FTP servers. Can't do that to PIX nevermind a LinkSys box. -Scott On Tue, 8 Jan 2002, Jack Coates wrote: On Tue, 8 Jan 2002, Scott C. Best wrote: that you can make from old spare parts or find laying out in the trash or a friends garage? Well...it's not as if you build it from paint cans and nerf footballs. :) It does turn the doorstop of an old PC into something that becomes one of the most important pieces of a broadband network, though. Do you need a cheap VPN gateway solution without the thousands of dollars in licensing fees? Akshally, the low-end LinkSys and Sonicwall stuff do VPN passthru and one-notch up they do VPN endpoint, without the licensing that (say) Cisco or Watchguard would charge. these days, the opportunity cost of building a LEAF system instead of buying an OTS unit for $100 is getting to be arguable... I'd focus on flexibility rather than cheapness. -- Jack Coates Monkeynoodle: A Scientific Venture... ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] cryptographically signed .LRPs
Thought I'd contribute my brief understanding of package signing using openssl. I believe this package can be customized on install so that it only provides the tools you need. Package signing only needs (I believe) 4: md5, rsautl, genrsa, and rsa. First, you need the md5 hash of the package you're going to distribute: % openssl md5 package.lrp package.md5 Then use an RSA or DSA private key to sign the hash value. I'll use RSA here cuz the docs at www.openssl.org refere to rsautl a lot more than dsautl: % openssl rsautl -sign -in package.md5 -inkey priv.key -out package.sig Note that 'rsautl' requires version 0.9.6 or above. I'm pretty sure all of this is doable without it, but it'd take more poking around to be sure. Anyhow...the signature file is written to package.sig. This presumes you have a RSA private key in the priv.key file. To generate one, do this: % openssl genrsa -rand /dev/random -out priv.key That generates a private key into priv.key. To get the public key you should distribute along with package.sig, do this: % openssl rsa -in priv.key -out pub.key -pubout Now you got package.sig and pub.key which you can send out to anyone. The remote user verifies everything's cool with: % openssl rsautl -in package.sig -verify -inkey pub.key -pubin I think all the details are there. Hope this helps... -Scott And Jack Coats pointed out gpgv that might fit on a CD (283932 bytes), to which Jeff Newmiller reminded all that gpg will take that much ramdisk + RAM to run in... gpgv is the verification only part, and looking through the source code, most of it is gpg stubbed out (to be as small as possible.) From the looks of it, it is pretty close to what you were describing: gnupg 1.0.6 (gpgv), stripped and upx'ed down to 113522 bytes That's still pretty big. Or do you think that would be small enough? I don't see any way to get a pgp-like app smaller than that. I'm not looking for something general purpose. The code has to do one thing, and one thing only: Given a file, a signature, and a public key, verify the signature (and hence the file's) authenticity. The public key and signature can be in a pre-defined format, if desired, although it might be nice to support varying key lengths. No pass-phrase encryptions of files, no complex code trying to keep secrets from other users of the system (that all belongs on the development side, when the package creator signs the package in the first place), no webs of trust, just a simple public-key signature verification. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] gatping 0.3 ALPHA released
BTW...if anyone could compile this package for a libc 2.0.x ES/Dachstein system, setting the DEFAULT in the first line of the Makefile to the default internal interface IP for ES/Dachstein (192.168.1.1, I think), I'd greatly appreciate it! -Scott On Sat, 1 Dec 2001, Ray Olszewski wrote: For anyone who is interested, we just finished up the latest iteration of the gatping utility, a small program that rapid-fire pings a /24 network range, then list all the hosts that show up in the pinging host's arp table. It's a quick way of determining what machines are actually connected to a LAN at any moment. The program is still rough, which is why it has a low version number and the ALPHA label. It is also, by design, limited in scope -- it does just one thing, but it does that very fast, its size is small, and it needs only libc6. (People wanting a more general-purpose replacement for standard ping might want to consider fping or arping instead.) A complete tarfile of gatping -- binary (against glibc-2.1.x), source, License, Makefile, and notes -- can be picked up at URL ftp://ftp.echogent.com/gatping/gatping_0.3f.tgz -- Never tell me the odds!--- Ray Olszewski-- Han Solo Palo Alto, CA [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] pfw.lrp v.0.94 - A Packet Firewall using ipchains
Matt: Heya. Some quick comments inline: Sounds good! I haven't checked echoWall on Oxygen yet, so good going. Thanks Scott, but they don't make it easy. There's no /etc/version or convenient uname switch so a script can determine what OS it's running on. Gah. I was wondering about that. The only thing preventing echoWall from running on Oxygen is that it needs a different gatping binary. Which we have, sure. Trick is to install the right one, either when the package is first installed via lrpkg -i or when it detects that it's being run for the first time. That I know I can detect. But now I need to consider how to detect the glibc version... Well I wasn't sure what you were going to release. I took a look at your website and it seems like you're making good progress at echogent.com from the looks of things. Heh. :) Our major release is on target for the end of the year. It's a personal VPN application called Kaboodle. It's designed to let average Internet users (ZDNet called them the clueless in a recent article; Dave Cinege's sobriquet for them was idiots) create a peer-to-peer VPN connection without needing to know anything about IP address, nevermind what their own is. The intent is to allow any TCP/IP app to tunnel across that connection, and so become point-to-point secure. Am starting with VNC, a personal favorite. It's a Windoze app, it's built in VC++, it's open source, and I'm working on the sourceforge website in my spare time (whatever that expression means, I cannot recall). It's a BSD license, and gawd knows I learned most of the basics from your rc.pf to begin with. :) Shucks. I don't know much from licenses, though. That's my brothers side of the family. Here's how I keep them straight: there are basically two things an open-source license speaks towards: can the code be combined with non-open code; can modifications be taken private into closed apps. The GPL says no to both. The LGPL says yes to the first, no to the second. The BSD license says yes to both. Playing fast and loose here, but AFAIK that's a good rule of thumb(s). Honestly I'm flattered that anyone's using it all besides me... I'm not. You made it very well. It's was cool of you to analyze all those inbound services and script them in the rules file. That's looks like a neat hobby. Have you announced if for any other os or just for LEAF users? If you haven't, that's an awful lot of succinct data on inbound services to hide at LEAF. Thanks! I should give it some more thought, perhaps release a more conventional tarball with a more conventional INSTALL script. Once I get the which-gatping-to-use issue settled, I should go for this. Quick question: when you start it up, does it blow away what was there by default, or will there be conflict? Yes it runs a global flush and clobbers any of the good work that Charles runs by default. Funny thing is, I always thought it was just called Dachstein, not Dachstein Firewall. Once I ran it, though, I realized that Charles had gone past a general router, hardened it, and added a lot of nice touches like dnscache, and load balancing. As I was near completion, I rolled it out for Dachstein, anyway. The ram-disk log partition is my favorite. I've had to reboot my ES2B router once a month because of the firewall log filling the ramdisk... Got to code some Java now for a break. Btw, do you have any idea why a Nessus scan of my firewall would say that port 0 is open to udp and tcp in the form a bonk attack? I have those ports blocked the usual way, so I'm thinking they're spurious report items. I didn't know there was a usual way to block those. That is, I didn't think the stock ES2B firewall rules addresses the non-standard port-0. I should check ipchains -ln the next time I boot sans echoWall... cheers, Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] pfw.lrp v.0.94 - A Packet Firewall using ipchains
David:
Hey, thanks for the script idea. I'll try that:
GLIBC_VERSION=$(basename /lib/libc-*.so .so)
GLIBC_VERSION=${GLIBC_VERSION##*-}
...or better yet, follow that with:
GLIBC_MAJOR_VERSION=${GLIBC_VERSION%%.?}
Regarding the GPL, you make a good point. Not only can
GPL'd code not be combined (and then released) with non-open code,
it can only be combined (and then released) with *any* other code
if that code itself inherits the GPL license. Many other GPL
compatible open-source licenses, such as the Sleepycat license,
don't specify *which* license the new source code must be released
under, only that it must be open-source.
Again...I'm playing fast loose with the word combine
up there. The GPL FAQ (www.gnu.org/licenses/gpl-faq.html) dedicates
more than a few lines to what is the difference between mere
aggregation and combinining two modules into one program,
addressing details as low-level as the means one portion invokes
the other (fork, exec, pipes, rpc) and the semantics of the
communication.
Which, I don't believe, has hit the courts yet. It's
a question of legality that will eventually be presented to
judge. And that'll be an interesting event...
-Scott
Here's how I keep them straight: there are basically
two things an open-source license speaks towards: can the code
be combined with non-open code; can modifications be taken
private into closed apps. The GPL says no to both. The LGPL
says yes to the first, no to the second. The BSD license says
yes to both.
Playing fast and loose here, but AFAIK that's a good
rule of thumb(s).
Of course, there are MORE things than that. One of the most important:
GPL is viral in that any code that uses GPL-licensed code MUST be GPL
licensed; BSD licenses don't have that. The X Consortium caused quite a
stir when they tried to take X into the commercial realm as a
proprietary private product - which they could do under their license.
Under a GPL license, they couldn't do that.
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] netmeeting.o module
Am CC'ing this to Jeff Pierce; am not sure if he's on the leave-devel list or not. His post to the LEAF list (CC'd below) got me thinking Could you kernel-owners post a netmeeting.o module for Dachstein and Oxygen? Jeff seems to have been able to get Netmeeting to work, which is nothing to sneeze at. AFAIK, Netmeeting uses H-323 for host calling, *along with* a buncha other protocols which also embed IP address information in the data payload (which breaks masq'ing...grrr). Since this netmeeting.o module appears to address all of them, it seems to me a worthwhile replacement for the more limited ip_masq_h232 one. Thoughts? -Scott -- Message: 2 Date: Thu, 08 Nov 2001 13:03:19 -0500 From: Jeff Pierce [EMAIL PROTECTED] To: Blanton Lewis [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Leaf-user] netmeeting I am using the following script on Eigerstien2 after starting module netmeeting.o #!/bin/sh IPMASQADM=/usr/sbin/ipmasqadm EXTERN_IP=`ip addr list label ppp0 | grep inet | sed '1!d'| sed 's/^[^.0-9]*\([.0-9]*\).*$/\1/'` echo Extern IP: $EXTERN_IP $IPMASQADM portfw -a -P tcp -L $EXTERN_IP 389 -R 192.168.2.205 389 $IPMASQADM portfw -a -P tcp -L $EXTERN_IP 522 -R 192.168.2.205 522 $IPMASQADM portfw -a -P tcp -L $EXTERN_IP 1503 -R 192.168.2.205 1503 $IPMASQADM portfw -a -P tcp -L $EXTERN_IP 1720 -R 192.168.2.205 1720 $IPMASQADM portfw -a -P tcp -L $EXTERN_IP 1731 -R 192.168.2.205 1731 I don't really want it running all of the time. And this seems to work fine. Also, goto: http://support.microsoft.com/support/kb/ARTICLES/Q158/6/23.asp It explains what is needed to get netmeeting through a firewall. Now, I have a question, I use netmeeting.o for netmeeting from: http://netmeetingmasq.sourceforge.net/ However I see mention of ip_masq_h323.o, what are the differences and which is the better to use? ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] gatping with debugging symbols
Jacques Nilo wrote: - Original Message - From: arne @ loopback . org [EMAIL PROTECTED] I would go a step further. make a minimal busybox only containing very few applets(tar,msh as shell,mount,ls,cat,...) And link it statically with uClibc. This will result in a quite small binary and you don't need to include a big libc... I do not [understand] the interest of doing that in an LRP distro. You will need libc and ld-linux libraries anyway so why not putting them in initrd.gz ? If you compile statically even with uClibc you would loose disk space at the end... Oxygen development had busybox compiled with uClibc and this is very useful, actually. It permits the removal of glibc from root.lrp, which means that glibc can be updated just by adding the appropriate glibc package - with appropriate room, of course. My thought, too, is that all packages EXCEPT root.lrp could be put on the network on an FTP host or such like - and thus, not only could the system be updated on the fly, but if you had multiple hosts they would all have their sources updated at the same time, and so on. From a development standpoint, it is also nice because it shrinks root.lrp down by about half, and also means that loading root.lrp goes faster. Only thing is, MY compiled busybox is contains dozens and dozens of applications - not the minimalist version envisioned by Arne. The Problem with your previous post is, that you can not load the loadmod.lrp from the boot medium cause you need the modules from there to access your boot medium. I do not understand that. If you need to mount a special driver to read your boot medium, obviously you cannot have either the original root.lrp nor my boomod.lrp package on this boot medium. The bootable CDROM is a perfect example of this quandry. Syslinux can boot the CDROM, and load the Linux kernel, and so on - but the floppy image is not accessible by Linux (only by syslinux). So once the kernel is loaded and running, all packages must come from the CDROM itself, not from the bootable image. Well I guess we will have to move to glibc 2.1 or 2.2 at some point. But we all know that will lead to a somewhat bigger LRP distro... Oxygen is using glibc 2.1 on floppy in its development versions - and it works well. Converting to glibc 2.2 is a little scary - just how much space would I lose THEN? At least the upgrade is easy: # rm libc6.lrp # cp /tmp/new/libc6.lrp /mnt/floppy :-) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] gatping with debugging symbols
Matt: Perhaps David's using the patched version he posted to the list last week? -Scott Ok. I don't think I can help much. I don't have the right gatping.c apparently. I just used the one Scott sent. Matt ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Echowall on Oxygen needs ipmasqadm and ipfwd
David: Not ipfwadm, but ipfwd. Different beast; it's used to forward other IP protocols besdies just 6 (tcp) and 17 (udp). So it's needed for IPSec and PPTP forwarding... -Scott On Tue, 30 Oct 2001, David Douthitt wrote: Matthew Schalit wrote: I found ipmasqadm, but not ipfwd. I couldn't even find ipfwadm as a .lrp package any more. If I had that, I could continue running rc.pf, and not have to deploy echowall or seawall. I thought with Linux 2.2 ipfwadm was no longer used, and instead ipchains was used. Thus ipfwadm is gone and replaced by ipchain. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] gatping segfault in Oxygen
David: Heya. Actually, yea, gatping is a play on Gatling. :) It essentially sends out 256 minimum-sized icmp echo requests, ignoring the responses, so as to get a freshened-up ARP table. I emailed the source tarball out to the list a couple of days ago; it's also availble on ftp.echogent.com in the EchoWare directory. cheers, Scott On Thu, 25 Oct 2001, David Douthitt wrote: Matthew Schalit wrote: Not so big a deal as that, David, but still, gatping was compiled against 2.0.7. Shouldn't matter. glibc 2.0.7 binaries run against glibc 2.1.3 all the time. Could you compile if for me agains 2.1.3? Sure. Where do I find it? Is it related to Gatling Guns? :-) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] gatping segfault in Oxygen
Matt: Heya. I just used gcc -o gatping gatping.c. Didn't seem to warrant a Makefile. :) -Scott On Tue, 23 Oct 2001, Matthew Schalit wrote: Scott C. Best wrote: Matt: Heya. Source code attached. If you could send back to me a compiled working versionI'd be thankin ya. :) BTW, yes, echoWall has gatping built for ES2B only, glibc-2.0 (I believe). -Scott Hi Scott, Thanks I got the archive. It has gatping gatping.c in it. I don't have the setup to compile it, though. Do you? How was the gatping in the archive you sent compiled? Thanks, Matt ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] Framebuffer vnc
Hmmm. I think I see the idea: a lotta folks use VNC as their remote-admin tool of choice, as it's OS independant. To that end, it'd be interesting to port a VNC server for use in LEAF. Unlike other VNC servers, though, it wouldn't be very graphical at all, rather it's just present a VT100/xterm'ish interface like SSH does. Then the same remote VNC viewer could be used to connect with a Win2k box, a Mac, and the LEAF router which gateways them to the Internet. Groovy. I wonder how lean it can be built? -Scott On Wed, 26 Sep 2001, Jeff Newmiller wrote: On Wed, 26 Sep 2001, Luis.F.Correia wrote: Let me explain it better: A router/firewall LEAF box running a framebuffer-enabled kernel, has a vncserver that we as admins could connect to using a very normal vncviewer with any platform to perform our remote administration. Is this possible, or the overhead is huge and sshd is better? Isn't a framebuffer used for graphics modes? What LEAF runs a windowing environment? If one did, why would it do so? Sshd is quite effective. -Original Message- From: David Douthitt [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 26, 2001 2:55 PM To: LEAF Devel Subject: Re: [Leaf-devel] Framebuffer vnc Luis.F.Correia wrote: I read some time ago, that someone was triyng to make a Framebuffer vnc combination for remote administration. Is there something that I can test? The kernel, distro does not mind, I just want to see the results I created a vnc client package which uses SVGAlib, not Frame Buffers. I don't know if this is relevant to what you want to do, but I thought I'd mention it. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] ipchains redirect
Leaf'rs: Heyaz. Saw this on security-basics this AM. Never saw it mentioned on LRP/LEAF before; anyone ever try it? Alternatively, is IP Transparent Proxy enabled in any LEAF kernels? Seems terribly powerful to me. TIA! -Scott -- Forwarded message -- Date: Wed, 19 Sep 2001 20:19:19 +0200 (CEST) From: Bosko Radivojevic [EMAIL PROTECTED] To: Daniel Chojecki [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: ipchains, ipmasqadm On Tue, 18 Sep 2001, Daniel Chojecki wrote: Is it posible to redirect all traffic comming for 0.0/0 80 to local squid proxy using ipchains and ipmasqadm. Using ipchains - yes. I'm not sure for ipmasqadm (I've never used it) I'm using those lines for that. Of course, you have to enable 'IP Transparent Proxy' in your kernel. ipchains -A input -p TCP -d YOUR_IP/32 www -j ACCEPT (in case you have your own web server) ipchains -A input -p TCP -d 0/0 www -j REDIRECT 8080 Conf: 2.2.19 ipchains It works for me: 2.2.18 ipchains 1.3.9, 17-Mar-1999 Greetings ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] ipchains redirect
David: Yeah, a transparent web-proxy or web-cache gets handled pretty nicely by this. If the proxy could http forward you could even redirect the packets to an external, remote proxy. That'd be useful for apps which used a LEAF router to gateway a wireless-LAN into wide-area access, where you want to restrict user access, requiring them to login on a remote https server before access is granted. So when a new DHCP lease is granted, you tie-in a hook to insert a REDIRECT rule for that IP-address. The proxy gets it, and passes it along. Time to read-up on LEAF proxies... -Scott On Mon, 24 Sep 2001, David Douthitt wrote: Scott C. Best wrote: Heyaz. Saw this on security-basics this AM. Never saw it mentioned on LRP/LEAF before; anyone ever try it? Alternatively, is IP Transparent Proxy enabled in any LEAF kernels? Seems terribly powerful to me. I've done this before, I think; it can be nice, especially for things such as web cache. However, for a router with no hard disk it isn't all that useful. The basic idea is that ALL web traffic going out is passed through the proxy itself; helps if you want to add a web cache but don't want any client reconfiguration to be needed. Its also good for proxies such as JunkBuster or filtering proxies. -- Forwarded message -- Date: Wed, 19 Sep 2001 20:19:19 +0200 (CEST) From: Bosko Radivojevic [EMAIL PROTECTED] To: Daniel Chojecki [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: ipchains, ipmasqadm On Tue, 18 Sep 2001, Daniel Chojecki wrote: Is it posible to redirect all traffic comming for 0.0/0 80 to local squid proxy using ipchains and ipmasqadm. Using ipchains - yes. I'm not sure for ipmasqadm (I've never used it) I'm using those lines for that. Of course, you have to enable 'IP Transparent Proxy' in your kernel. ipchains -A input -p TCP -d YOUR_IP/32 www -j ACCEPT (in case you have your own web server) ipchains -A input -p TCP -d 0/0 www -j REDIRECT 8080 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Is this a CodeRed scan?
Luis: Heya. I think the page you're asking about is this one: www.echogent.com/cgi-bin/fwlog.pl I sent Mike the code to get that running on the LEAF site, I suspect he's been way too busy though. Also, you may want to visit SecurityFocus.com. Tina Bird has started a new email list all about log analysis: [EMAIL PROTECTED] Regarding the packets your seeingif you're seeing 3 attempts in a row, from the same IP source, then it's likely CodeRed. That's its signature. If you're seeing different ports probed from the same IP source, I'd suspect Nimda. Hard to say without seeing the data payload, of course. Though...if you're running Apache anywhere on your LAN, it's much easier to tell. The error.log file would be filled with: [Thu Sep 20 23:28:15 2001] [error] [client 193.13.81.201] File does not exist: /home/www/http_docroot/default.ida The default.ida is a CodeRed certainty. I got tons of those on my server. cheers, Scott On Fri, 21 Sep 2001, Luis.F.Correia wrote: Last night, while browsing around I started to get entries like this on my logs. I'm using an ES2B modified version (PPP) Is this a CodeRed scan? Sorry that it is not properly formatted. Also I lost the link to that page on where we could put lines like this to get extra info. Could someone post it again? Thanks! - Sep 20 23:28:15 porteiro kernel: Packet log: input DENY ppp0 PROTO=6 193.13.81.201:1201 193.126.171.3:80 L=48 S=0x00 I=46155 F=0x4000 T=112 SYN (#37) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] YATALWI
Etienne: Heya. Over the last year, I pitched my company's 'echoWare' solution to a number of OEMs, including heavy-iron OEMS, SOHO-router OEMs, and garage-mode last-mile broadband wireless gateway startups. Everyone I've spoke with agrees it's a strong model for the future, but faces an enormous adoption problem: a Fortune-500 OEM simply *cannot* put anything into the box unless it's an industry standard. Put another way...even if a sh!tty, insecure, bloatware protocol becomes an industry standard, they don't just feel compelled to support it, they are *proud* to support it. It can be very frustrating: talk to them about a novel, lean, SSH-based remote-management architecture, and they ask for SNMP, UPnP, Passport, or 802.1X. Not that this surprises me. :) But the doubly frustrating part is that this resistance affects my ability to raise funds to support a development staff to actually release some code that could, who knows, someday actually become pervasive. Perhaps it's a Peter-principle of mass market products: they are forced into this awful state of standardized mediocrity. /rant off Anyhow. The idea behind echoWare is that you run an SSH service on the machine you want to administer, and exchange simple ascii directives to that machine to affect its configuration. You can make these directives as machine friendly as you want: importantly, the actual *user interfaces* is filtered by a remote web-server. So, the end user connects to this website, and that server opens an SSH connection back to the end-user's gateway, pulling out ascii config info, and turning it into an HTML picture. Only takes a second or two in our demo. End-user can now point and click to make configuration changes, which go up to the server over SSL, and back down to the gateway over SSH. The primary benefit is the cost of the software. The gateway only needs to run an SSH daemon (which usually comes from free), and an ascii parser, which bash and sudo handle well enough. Might be worthwhile to customize the shell, too, so that only a limited set of commands is available to the ASP server. Given this...you can load up all the heavy lifting (graphics, os-specific ifdef's, etc) on the server, which has the CPU, memory, and storage to spare. Anyhow, we call it echoWare here, and someday it'll actually move beyond the demo phase: I'm hoping to attach EchoWall 2.0 to this service. So instead of editing the echowall.conf file by hand, you'd connect to a website, tell it what services to enable, and it sends the sed commands into the box, and updates the echowall.rules file if needed. Very visual for the end-user, but very ascii for the gateway. Anyhow...hope this helps, somehow. Got something of a demo running if you'd like to kick the tires around. Got another meeting this week with a major vendor to talk about it some more. :) cheers, Scott On Sun, 16 Sep 2001, Etienne Charlier wrote: Hi, Since last year ( when I discovered LRP), I think that there was at least 3 or 4 threads about a web interface to a LEAF derivative. I would like to start a brainstorming on the feasability/usefullness of a Web interface for the LEAF project. what people think about - usefullness - would it be secure enough - technologies to use ( scripting languages ,..) - is there some exsiting project that could be reused ( I've heard about Webmin) - other secrets wishes that you have about LRP/LEAF happy brainstorming Etienne Charlier - Original Message - From: Eric Wolzak [EMAIL PROTECTED] To: Etienne Charlier [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, September 16, 2001 10:37 PM Subject: Re: [Leaf-user] thttpd CGI Forms for administrating Firewall through browser Hi Etienne, Sandro and the rest of the list I'd be happy to contribute to a web interface for LEAF If there are more people interested, we could join our efforts :=) Here are some ideas First of all, the combinaison LRP/Kernel 2.4/Shorewall is not yet very common in the LRP world and I can understand the lack of feedback Eric got about his web interface. I think you ve got a point there. I think that allowing editing existing files through the web interface is a lot of work with a very small ROI, an applet java allowing ssh access could do the job This is what i normally use myself, but I thought that there is some interest to do it with a webinterface. ( a concurrent product fli4l.de uses a windows programm as a frontend) IMHO, What we need is a higher level interface ( Like seawall, you have a few simple configuration files and a lot of work done with the data in those files) That was exactly what I liked about shorewall I think we could design the web interface as an editor modifying a big file ( config.web) containing shell variables definitions and a few scripts which process configuration files
Re: [Leaf-devel] Interesting potential LEAF application
A further problem that this solution fails to address is that the Access-Point itself is allowing a rogue user to associate *at all*. Sure, the firewall may prevent the user from connecting to the Internet, but it doesn't prevent them for sitting by passively and sniffing for MAC/IP address pairs that are valid. Combine that with Airsnort or WEPCrack (both on Soureforge) and that WLAN could be in trouble. Most of the know-it-mosts I've seen on the isp-wireless list insist that authentication in the access-point itself (usually RADIUS) cannot be worked around. That combined with all LAN members using a VPN client with a SecureID card is about the only thing agreed as secure. cheers, Scott On Sun, 2 Sep 2001, Ray Olszewski wrote: At 03:30 AM 9/2/01 -0400, George Metz wrote: Hey guys, For those of you that saw and skipped, or don't read Slashdot, check out the following: http://www.nas.nasa.gov/Groups/Networks/Projects/Wireless/index.html It's actually a pretty ingenious solution to the wired encryption setup. I don't see any mention of actual VPN/Encryption for traffic from the wireless device to the firewall, though, so I wonder if you could still sniff data. It mostly seems geared towards preventing unauthorized usage of netaccess, rather than denying information access. Any thoughts? I've seen several variants on this idea over the paast 6 months (even worked on a related prototype project, for a client that ended up not seeing any moneymaking opportunity with it ... at least I think that's why the project never went ahead). This White Paper covers most of the basics. You can improve security a bit by checking the arp table regularly (every minute or so) to make sure the (claimed) arp address of the system using an IP address has not changed. This forces an attacket to use link-level spoofing, not IP-level spoofing. You can further improve security by using some sort of active tool in the client ... say something able to authenticate itself using client Certificates. This makes spoofing very tough, perhaps impossible (if the Cert uses a safe key length). Even a system with these added features isn't foolproof, but it does limit breakins to a higher class of fool. Bottom line -- as far as I've been able to figure out, wireless cannot be completely secure without using high-quality link-level encryption. Without it, the vulnerabilities are akin to those that you get if you leave a LAN port on a hub unprotected (that is, in a location where a stranger can plug in a workstation). ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Have you guys seen this?
Luis: Yikes. I wonder what sort of proprietary functionality VA will be adding to SF that'd they'll start charging for? -Scott On Fri, 24 Aug 2001, Luis.F.Correia wrote: http://www.theregister.co.uk/content/4/21253.html Luis Correia ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Lost disk space problem resolved
Andrew: Heya. I've got some time in the next 2 weeks, and I thought I'd finally tackle the iptables/netfilter add-on to echoWall. Your post motivates me to ask: where's the latest/greatest 2.4.x LEAF disk image I should use as a qualification platform? Thanks! -Scott On Fri, 27 Jul 2001, Andrew Hoying wrote: Hello, For those of you who are interested, I believe I found out why I was losing disk space on my /var/log partition. It turns out that there was a bug in the grsecurity patch that I use on my kernels that caused this. I'm building a new 2.4.7 kernel with the newest grsecurity patch which corrects this issue. Andrew Hoying ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Wireless PPP - was NoCat.net
David: Hee. It's a fair question: the 2.4GHz band isn't unlicensed because the FCC was feeling generous. It's unlicensed cuz it's filled with microwave (as in food and as in non-terrestrial) garbage. People talk about having a Bluetooth enabled ear-piece for the cell-phone, seem to skip the fact that some skeptics *may* not want to put a little oven in their ear. Cell-phones, at 2.3GHz, don't absorb into water nearly as well as a 2.4GHz transmitter does. -Scott On Thu, 26 Jul 2001, David Douthitt wrote: Mike Sensney wrote: The 2.4 GHz radios use 50 ohm cable. You can use the RG 58 cable that tends to be readily available. You will loose about 3Db, or half your power, for every 16 feet of cable. A lot of the RG 58 cable on the market has poor UV protection so that can be a problem in direct sun. If you need a better cable the LMR series seems to be popular with the wISP crowd. As a ham operator myself, I've a question for you wireless wizards. I've heard that newer cell phones operate somewhere in 2GHz, and now you mention this. Seems to me I remember that standing next to a 1+ GHz antenna is likely to have SERIOUS consequences... like burning a hole in your head ;-) Or was that 12GHz? You all can probably tell I don't do any work in the GHz bands :-) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] NoCat Net
Mike: Heya. You may want to look into this project, if you haven't already. They've built a floppy-based firewall called WRP to support their 802.11 hotspot community network: http://nocat.net/download/wrp.img I'm willing to be we could talk to them about building on the LEAF platform instead. Lets them focus on the whole system rather than on the firewall. cheers, Scott From: Charles Steinkuehler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 25 Jul 2001 09:06:08 -0500 Subject: [Leaf-user] Wireless link Reply-To: [EMAIL PROTECTED] Someone sent me this link, related to wireless networking. Thought it might interest a few folks on the list... http://nocat.net/ Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Going to glibc-2.1 (or glibc 2.2)
David: Just wanted to add uLibC as an option too for ES3/Dachstein. :) IMHO, picking one seems, in a way, like more work than simply re-compiling the packages. -Scott On Fri, 20 Jul 2001, David Douthitt wrote: This is interesting... I've not heard whether Eigerstein is going to go to a new glibc (2.1 or 2.2). glibc 2.0 is obsolete, and 2.1 is already deprecated and obsolete. As a packager, I'm not interested in trying to shoehorn a glibc-2.2 binary into a glibc 2.0 system, especially when the program wasn't designed to compile under glibc 2.0. These days, my compiles (for packages) go like this: 1. Compile against glibc 2.0 2. If errors encountered, compile against glibc 2.1 There's just not enough time in the day to haggle over every little error... Here are my questions (direct and to the point :-) 1. Is Eigerstein (or Dachstein) going to upgrade to a new version of glibc? 2. Is LRP likely to upgrade to a new version of glibc? 3. What is your opinion: is compiling against glibc 2.0 worth the trouble? Or should everyone migrate their packages to glibc 2.1 or 2.2? ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Licensing (specifically, djb)
David: Ug. DJB is a bright guy, and I'm a big fan of qmail, but...he's apparently at war with RedHat (and other major distro's) who I guess have slighted him by not incorporating his stuff into their releases under his terms. From what I could pull out of his FAQ page for distributors, I do not believe that tcpserver and tcprules can be re-packaged into a .LRP and re-released. Quoting: All installations must work the same way; any variation is a bug. If there's something about a system (compiler, libraries, kernel, hardware, whatever) that changes the behavior of my package, then that platform is not supported, and you are not permitted to distribute binaries for it. Again, he writes good stuff. But he seems to be looking for a fight, and I'm not willing to sign LEAF up for one. -Scott On Tue, 17 Jul 2001, David Douthitt wrote: With the addition of tcpserver and tcprules to the ever growing list of packages, I went and looked at their licensing (always of interest). I was dismayed to find out it was under the same licensing as the other djb tools (I didn't realize that these were one of them). According to his page http://cr.yp.to/distributors.html the licenses to distribute daemontools and ucspi-tcp expires on December 31, 2001 - so after that date we can no longer distribute the packages or programs from them. He also quotes Red Hat's Bernard Rosenkraenzer as saying (on April 16, 2001): qmail and djbdns are not open source, so we aren't going to ship them unless the license changes. I'm not comfortable with his license, and I don't expect that any of these tools are contained in Debian either, what I consider to be the purest of OpenSource Linux distributions on the planet. Thoughts from you all? Jacques? Andrew? ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] bridge filter patch
Heyaz. Anyone ever build a LEAF/LRP kernel with this patch: http://ac2i.tzo.com/bridge_filter/ Am noodling on a zero insertion cost filter based on LEAF: old:LAN = LAN's Gateway new:LAN = New Filter Box = LAN's Gateway I think if setup specifically to bridge, I won't have to proxy-arp. And AFIAK bridging removes ipchains' ability to filter the packets. Hence the question about the patch. Thanks! -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Site Updates
Mike: Nice update to that page. Me, though, I'd go one step further and put a Mailing List header right there on the main page above the Affiliates section. In that new Mailing List section I'd invite the visitor to Get your network or firewall config questions answered here on the newbie-friendly LEAF-user email list, where LEAF-user is a link to http://lists.sourceforge.net/lists/listinfo/leaf-user. Thanks for all your work on this! -Scott Everyone, I've done my best with our new Mailing Lists page. I need some feedback to improve it further. Suggestions and comments are welcome. http://leaf.sourceforge.net/content.php?menu=14page_id=20 Charles and Mike, I apologize for not seeing the wisdom in your suggestion earlier. I hope this new page is what you had in mind. Thanks for convincing me of the need for this page. -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: [Leaf-user] echowall 1.1 released
Chris: DOH. :) Can't believe I forgot IRC. Sigh. Okay, forget 1.1, version 1.2 is now up in all the same places. :) It adds IRC support, and I've gone and alphabetized the list of services so it's easier to navigate (and support). see the README for the full list of 30 services. Also, it is an ipchains-based script. I plan on adding iptables/netfilter support, but I hadn't planned on going backwards to the 2.0 kernels. Perhaps you could be convinced to upgrade? Echowall was built for the Eigerstein releases, installing itself over the default rulesets with that distro with zero conflicts. It de-installs itself nicely too (see echowall install and echowall deinstall). It also works with both DHCP and PPPoE IP address renewals from your ISP, automagically re-init'ing itself. For two-NIC, non-DMZ, LRP/LEAF usage, it's not half bad. Hope it works well for you! cheers, Scott Thinking about trying your echowall and was wondering if it is possible to forward a generic services, or, rather ones that you dont include in your setup. I have an IRC server sitting behind my LRP box that I forward traffic to on port 6667 (using ipfwadm). Is it possible to do this under echowall? Thanks for your attention! Chris Kulish Heyaz. Just posted version 1.1 of echowall.lrp in all the usual places. Some bug fixes to the now-tested PPTP and IPSec pieces, as well as added support for Battlenet and Firewall-1 VPN'ing. Hope it proves useful! cheers, Scott http://leaf.sourceforge.net/devel/sbest/echowall ftp://ftp.echogent.com/EchoWall ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] New Project
David: This, now, is a great idea. Go fer it. Suggestion: A new user comes along (with or without UNIX/network tech), boots with two disks (yes two), and then goes through this initial setup step by step, with a boot disk to be configured in hand. Once this is all done, then the disk is backed up to another, the configuration saved, and the user reboots with this ONE disk for a router. If packages chosen for setup could be apt-like gotten, from a LEAF apt server, that'd be very slick. My favorite thing about Debian, no CDROM needed. :) -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Suggestion for improvement
Heyaz. So, I went to the LEAF site today trying to imagine myself as a new LRP user who's going there for the first time. And it strikes me...where's the distro? IMO, frontcenter links to both ES2B and Oxygen be a would be a great help. Sure, there's a little releases in the upper left, which leads to a page that has no clickable links on it -- gotta click again in the left banner, though, to actually get to the page. Doing it that way, with the left-banner, makes me feel like I had to mine for something, and may have no gotten the good stuff. So, I guess I'm suggesting a here's the good stuff link, right there on the homepage. Thoughts? -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] Suggestion for improvement
Steven: Good point, I shouldn't be so dark. :) Lets release Son of Eigerstein officially this week. It's in great shape, arguably better than any other LRP distro you could download... -Scott On Wed, 13 Jun 2001, Steven Peck wrote: Geez Scott, Do you have to concentrate on the negatives? :) j/k That was actually why I was hesitant about advertising until we got some focus on what directions LEAF is going in. I hope it continues to travel in a varity of directions, but some helpfully prominent sign posts to direct fols appropriately will do wonders. Now, I'm going to be a little selfish and will not be doing much work in the next 2-4 weeks. After that I should be moved and if a long shot pays off, I MAY even have static IP DSL! Yippee! Otherwise, I have to wait for an indeterminate amout of time for cable. Once I get settled, I'll start being more active again, even if it is through a, sigh, dial-up line. :) -- Steven Peck [EMAIL PROTECTED] Sacramento, CA http://leaf.blkmtn.org -Original Message- From: Scott C. Best [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 13, 2001 11:26 PM To: [EMAIL PROTECTED] Subject: [Leaf-devel] Suggestion for improvement Heyaz. So, I went to the LEAF site today trying to imagine myself as a new LRP user who's going there for the first time. And it strikes me...where's the distro? IMO, frontcenter links to both ES2B and Oxygen be a would be a great help. Sure, there's a little releases in the upper left, which leads to a page that has no clickable links on it -- gotta click again in the left banner, though, to actually get to the page. Doing it that way, with the left-banner, makes me feel like I had to mine for something, and may have no gotten the good stuff. So, I guess I'm suggesting a here's the good stuff link, right there on the homepage. Thoughts? -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Suggestion for improvement
Mike: Looks much better, thanks! Quick thing: there's a new half-inch margin on the right hand side that's squishing the page leftwards. Or is my browser just totally hosed? (NS 4.6 on Solaris). -Scott On Thu, 14 Jun 2001, Mike Noyes wrote: Charles Steinkuehler, 2001-06-14 09:51 -0500 I don't know that we need to change the menu items, just make it easier for a new user to find our distributions. Maybe add another 'tagline'...something like What is it? Project Goals: Distributions: Choosing a distribution - Link to a page describing each disto in summary EigerStein - Direct link to Releases/EigerStein Oxygen - Direct link to Releases/Oxygen PPPoE and PPPd - Direct link to Releases/PPPoE and PPPd Affiliates This would make it easy for new visitors to actually find the 'goodies' Everyone, Are our home page and releases page easier to navigate now? Note: I still need to work on our releases page, but I think our home page is alright. -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] lrp.c0wz.com down?
Mike: Yeah, Rick fell off the Earth about a month ago. Hope he's okay... -Scott On Wed, 13 Jun 2001, Mike Noyes wrote: Everyone, It looks like lrp.c0wz.com is down. The root c0wz.com site is still responding. Has anyone heard from Rick lately? I've been unable to reach him recently. -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Covad DOS's Verizon
Saw this on Slashdot, thought I'd share. Colorful. :) http://newscenter.verizon.com/proactive/newsroom/release.vtml?id=56108 -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Monta-Vista Hard-Hat Linux
Charles: Just thinking out loud: NOTE: I'm still very open to suggestions on what to use as the base of the next generation of LRP like functionality. I'm mainly looking at starting with an existing distribution because 'out of the box' you get a working cross-compile environment (no more dedicated Debian Slink boxes just to compile an application or two), and much of the software will be pre-packaged. I was recently contacted by the makers of BlueCat Linux (and its RTOS sister LynxOS) at www.lynuxworks.com, who are actively looking for partners for their distro. I cannot comment on the strengths of their product, but if you'd like a nameemail of the partners manager, that I can provide. -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: OT Re: [Leaf-devel] linuxrouter.org
Oh jeesh. What a f!cking moron. -Scott On Mon, 11 Jun 2001, Mike Sensney wrote: At 09:39 AM 06/11/2001 -0700, Kenneth Hadley wrote: I hope that someone hacked his web server otherwise Ive lost what little respect for Dave Cinege I had left after his fiasco with acepting help. I echo your opinion. Would Dave C feel the same if his own family had been collateral damage? ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: OT Re: [Leaf-devel] linuxrouter.org
Mike: IMO, you're absolutely right in not wanting to help Dave-C with attracting a larger audience. I think your alternate possibility list below, while a strong tactic, would affect the undesired response. However, your other suggestions seem dead-on. The LEAF team *is* the support team (and arguably the developer staff) for LRP. The reason that the LRP mailing list is currently successful and useful is because of us, not because of Dave-C (who, granted, got it all started). Resultingly, our support is now helping Dave-C to spread his message of violent anarchism. Which, clearly, sucks. So IMO, it's a good time to pull the plug, and relocate the support team and development staff to leaf-user. The critical relocations will be for the distro developers: Charles, David, Ewald, etc. The package developers like me will follow, obviously. Thoughts? Perhaps a vote to sever in such a way? I can see how some would see that it's cutting off our nose to spite our face. -Scott On Mon, 11 Jun 2001, Mike Noyes wrote: Bao C. Ha, 2001-06-11 16:01 -0700 I have an evil idea. Should I let the slashdot.org crowd knows about this? Bao, I don't think Dave C's views deserve a larger audience then they are already receiving. We may want to consider: 1) stop answering questions on the linux-router list (boycott/protest) a) refer people to the leaf-user list for EigerStein Oxygen support 2) tell people to submit support requests on our site a) Support Request Tracker b) leaf-user list 3) change all support request links to our site a) leaf.sourceforge.net b) lrp.c0wz.com c) lrp.steinkuehler.net At least 70% of the people that answer questions on the linux-router list are already members of our project. This would be a major change, so everyone would have to agree to it. A couple of alternate possibilities. * We can post an article on our site disclaiming any association with Dave C's anarchist views. * Contact the LRP sponsors and let them know about Dave C's use of the linuxrouter.org web site to promote an anarchist political agenda. -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Pb with dhclient Eigerstein BETA2_test_20010527
Charles: Heya, welcome back. :) IMO, since this ES3 release will be a whole-floppy release, it makes sense to me to release it with dhclient and dnscache pre-setup to groove together nicely. Just my two coppers. -Scott On Thu, 31 May 2001, Charles Steinkuehler wrote: Symptom: When I boot the new package I get after: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 receive_packet failed on eth0: Network is down Then if I issue after login in /etc/init.d/dhclient restart it works ok I replaced the dhclient package with the one on Charle's site version 2.0pl5 (not the one on Eigerstein Beta2 which is I think an earlier version). I was able to login without any problem. Therefore the problem is with the dhclient.lrp in the Beta2_test package. Yes, we need to verify the dhclient package is 2.0pl5. An older version is on the existing EigerStein disks. Another problem is the dhclient-script file which must be hacked when dhclient is running with dnscache. See FAQ section at http://leaf.sourceforge.net/devel/jnilo/dnscache.html Hmm...kind of a sticky problem. Since I now know more about how dhclinet works, what about the following: 1) Return the dhclient scripts to their original form (ie knowing nothing about dnscache) 2) Add a prepend statement to dhclient.conf: prepend domain-name-servers 127.0.0.1; This *should* use the local dnscache to resolve names, falling back to the DNS server(s) provided by the ISP if local resolution fails, and keeps everything standard but the dhclient configuration file, which is where such things are supposed to be set. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] New FAQ at LEAF Page
David: Heya. I like it, though I'd suggest some touch ups to the first paragraph (turning it into two): This question is often asked by firewall users that find dozens, if not hundreds, of TCP packets being logged which were destined to their firewall's DNS port (TCP port number 53). These packets originate from many different IP address, where each sends anywhere from 5 to 8 packets, all within the space few seconds. When caught with tcpdump, these packets will have the SYN and ACK flags set, as if responding to a legitimate TCP initiation packet. Since the firewall did not actually attempt to initiate a connection, it will instinctively reply with a TCP packet with the RST flag set (along with logging the packet in the firewall logs). The presumption is that it is this scan's intent to generate these RST packets, and to use them in an ad-hoc load-balancing scheme. These scans seem correlated with visiting certain web pages, ones using some peculiar load-balancing...etc, etc... Just some suggestions. :) -Scott On Fri, 25 May 2001, David Douthitt wrote: I submitted a new FAQ under section 9: Why am I getting SYN/ACK floods to my DNS port? (or something like that). Tell me what you think, hack it up, etc. Perhaps the Lion worm should be mentioned? ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Something new
George: Thanks anyhow, found one. It's quite a bit different, and will require some rather substantive change in the parser. Anyone out there nuts about working on perl parsers updates? :) -Scott On Tue, 22 May 2001, George Metz wrote: On Mon, 21 May 2001, Scott C. Best wrote: George: Can you send along an IP-Tables log to me? Thanks! I can Google for a BSD log too, make sure that works. That would require me to have one. I don't currently have 2.4 running on my disk image, sad to say, mostly because I'm loathe to take the box down for the upgrade. I'll see what I can find; maybe I can set up some quickie ironclad rules on my server, then portscan it from my workstation. -- George Metz Commercial Routing Engineer [EMAIL PROTECTED] We know what deterrence was with 'mutually assured destruction' during the Cold War. But what is deterrence in information warfare? -- Brigadier General Douglas Richardson, USAF, Commander - Space Warfare Center ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Something new
Heya LEAF'rs. Been working on something new: http://www.echogent.com/cgi-bin/fwlog.pl It's a firewall packet log processor. So, stick in something like: Apr 25 15:18:13 lrp kernel: Packet log: input DENY eth0 PROTO=6 199.172.144.146:80 65.11.107.82:8499 L=1500 S=0x00 I=34491 F=0x4000 T=51 (#58) ...and it'll make an educated guess about what you're seeing, how important it is, etc. Apologies if they're any hiccups in the graphics or anything. Am not an HTML jockey. As always, please let me know if you see any problems with it before I mention it on LRP. Also, of course, if you have a packet log that this processor cannot handle, please let me know. Or if you know what a packet means and this tool isn't telling it to you...let me know that too so that I can put in a rule to handle it appropriately. Thanks! -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Something new
Mike: Not a bad idea. Let me get it working first, though. Still some details to nail down. -Scott On Sat, 19 May 2001, Mike Noyes wrote: Scott C. Best, 2001-05-19 14:18 -0700 Heya LEAF'rs. Been working on something new: http://www.echogent.com/cgi-bin/fwlog.pl It's a firewall packet log processor. So, stick in something like: Scott, We can run cgi scripts from our SourceForge site. How large is the cgi script, and does it require a lot of processing power? -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Vulnerabilities dot org
So, I ran the Nessus scan on an Eigerstein 2.2.16 running echowall. The report, as with Steven's experience, isn't very interesting: nothing found since I left nothing active (I commented out the WANTED_SERVICES line before restarting the firewall and testing). Report attached at the end of the email. What *is* interesting though is the packet logging. Oh my. Filled my ramdisk, preventing echowall from re- running, as echo test file won't work if the disk is full. So...be cautious turning Nessus loose on your own LRP box. :) Makes me wonder though. At the start of the scan, /var/log/syslog, messages and kern.log were 15k, 13k, and 13k respectively. After the scan...all *three* of them were over 980k before I ran out of disk space. Sure, a brute-force DOS attack but...what am I doing wrong where each packet log gets recorded in 3 places? Also...I noticed my cable-modem connect thru the LRP was sluggish after the disk was filled. I checked with www.bandwidthplace.com/speedtest and it confirmed: 671 kpbs with a full disk, and 1293 kbps immediately after a reboot. Perhaps the next time someone on the LRP lists mentions that their LRP box is acting slow we should ask if they recently unleased Nessus on it. cheers, Scott Everyone, I found a site that is performing Nessus and NMAP scans for free. Please test your firewalls and share the results. --- Nessus Scan Report compliments of www.vulnerabilities.org Free Nessus web scan provided by Vulnerabilities.org Contact [EMAIL PROTECTED] or [EMAIL PROTECTED] for a personal evaluation of the scan report, further detailed systems analysis. Of course, we are available for contract to correct your problems, provide recurring network vulnerability analysis, and general hosting system administration Please take a second and drop us a note, or if you would like to share your report with us, email to above! Number of hosts which were alive during the test : 1 Number of security holes found : 0 Number of security warnings found : 0 Number of security notes found : 1 List of the tested hosts : * 65.11.107.92 (Security notes found) [ Back to the top ] 65.11.107.92 : List of open ports : * general/udp (Security notes found) [ back to the list of ports ] Information found on port general/udp For your information, here is the traceroute to 65.11.107.92 : 207.211.208.3 165.113.120.205 165.113.50.146 165.113.50.65 165.113.3.126 24.7.74.62 216.197.144.30 10.0.254.242 10.0.255.14 ? This file was generated by Nessus, the open-sourced security scanner. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Kernel 2.4.x
George: Hey, thanks for the 411. Based on Tom's last post, I don't think updating echowall for dual support should be that difficult. Unlike other config packages, the main script takes a ruleset and munges it with a .conf file, to produce a 3rd run file. That sounds like it would be workable, but it makes the database a bit larger. Not that that's really an issue with Echowall per se, but... =) Have the size of the database is long variable names. :) As per that recent How to write unmaintable code I'll shorten $IPMASQADM to just $8 and knock a few kB's off Now I just have to talk my wife into letting me noodle on it for another weekend. :*) Thanks in advance for any data about the images. Sure thing. I got around my wife by going out and buying her a 30-gig drive for her computer and The Sims House Party Expansion pack. For my wife, it was Napster. She drag'd me to Fry's to get a memory stick update for her Rio player. Never been dragged to Fry's before, found it quite erotic. :^) -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Patched kernel 2.4.3 (about to be) available.
George: Sorry for the late reply... Time to do some good old-fashioned market classification here. We have two base-level types of people using LRP: 1. People who want to have a firewall/router that will let them share IP addresses and don't want to spend the money on a commercially available one. 2. People who want to tinker, and as such have a fair bit of knowledge. I more or less agree with your generalization. I think Eigerstein proves your point substantially. Recall LRP without it, back when modmaker was alive? Every newcomer was pushed in the tinker category. From my pov, Eigerstein was the eighty percent solution, and has been a great success both on its own and for the project in general. The problem then becomes where we draw the line between the two. Perhaps a way to think about it is from the point of view of the newcomer. That is, we'd answer the question: why would a new user use this LEAF stuff. So, similar to what Eigerstein did, we could break it out by high level description: * Using a Cable-modem with a DHCP? Download MapleLEAF 1.0 * Using a DSL-modem with PPPoE? Download FigLEAF 1.3 * Using a dial-up modem? Start here with RedLEAF 1.1 * Experts only: want everything? MallornLEAF is for you. That sort of thing. Or if MapleLEAF was tied to a specific kernel/glibc version, we could post pre-rolled images like MapleLEAF for DSL, MapleLEAF for Developers, etc. Any thoughts or ideas? I'm thinking that trimming the fat off of this stuff, combined with UPX, might be enough for us to go glibc 2.1.x or even 2.2.x for base router images. At least then, it would be easier to transition from the basics to the fun stuff. Starting with a a base router image the same on all of the above LEAF trees would be terribly valuable. Glad this is being thought out... cheers, Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] IP-Masq'ing question
Jack: Hurm. I know that I can't assure you of "a". In fact, quite the opposite: I have no idea what people will be bringing into the wireless LAN. On the other hand, I can safely assure you of "b". Can see your point: if I alias the internal interface to some other subnet's gateway or DNS IP address, it'd be tricky to ever trying to send packets thru the router to the "real" one. Regarding DHCP, I agree completely. That'd be best, and it's certainly going to be the default. But, I'm not sure I can force a user's laptop (say) to use DHCP if it started life in my LAN as a statically configured device. I think I just gotta deal with it, somehow detecting "lost" packets and adapting the interfaces, on the fly, accordingly. Or, as you suggest, run an active LAN scanner (perhaps an ARP watcher?) to see what just joined and make some guesses as to how to handle it. Risk wise, 802.11 certainly has that limitation with the independent-BSS mode. My understanding is in that "software access point" mode, everything on the LAN is essentially a peer, and so an illicit user can see and affect legitimate users directly. In "real" access points, there's a normal BSS mode, in which the AP mediates all of the traffic, and so peers are safer from each other. My understanding, though, is that none of the open-source projects support this second mode -- not until an Orinoco access point gets reverse engineered. -Scott On Fri, 20 Apr 2001, Jack Coates wrote: The only way I can see this working is if you: a) know and define the subnet the fixed addresses will be in b) don't ever need to get to that subnet on the Internet (or at least not at the same time as you're using a wireless device). Better ways: DHCP. It's pretty easy to write a .bat or .sh which releases and renews -- with a little more work and snort you could probably autosense when that sort of activity was required? I'll assume you know about the big ugly holes recently discovered in WEP and have heard the stories about driving around with a laptop and an antenna... The risks aren't new (WEP == wired equivalent protocol and imagine a hub with a patch cable reaching out to the street for anyone to use), but they are recently publicized which means lots more script kiddies know about it. -- Jack Coates Monkeynoodle: It's what's for dinner! On Fri, 20 Apr 2001, Scott C. Best wrote: Heyaz. Curious for any leads, pointers, suggestions, patient explanations here. Here's the situation: given a Linux based NAT'ing firewall/router in between a modem and a 802.11 access point, I'd like to support an 802.11 network device that arrives on the network which is preconfigured "incorrectly". That is, suppose my LAN is 192.168.x.y, but a new device is configured with a static IP# (and static DNS, and even a static proxy) in some *other* range (say, in 206.184.139.137/24 somewhere). Presuming the firewall ruleset is flexible enough, how much of this would common IP-masquerading be able to handle already? Certainly the DNS and and proxy stuff would require some careful forwarding...but what about the NAT'ing and the routing? I've been noodling on this most of the day, and have fairly well convinced myself that it should be fairly straightforward with the NAT'ing, but a bit trickier with the ad-hoc ip-aliasing of the internal interface (so it would appear as the default gateway, DNS, and proxy for multiple devices differently). Anyhow...thanks in advance for any thoughts on this. cheers, Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Unified Embedded Platform Specification
Mike: I'm not so worried about how far "down" they certify as much as how far "up". Certainly, everything downstairs will be LGPL (so mods cannot be taken private, but it can be combined with closed-source apps), and so I'm hoping for something as straightforward as: 2.2.19 kernel, uLibC, busybox 0.5, libsafe, etc. Really, something terribly close to Oxygen... Again though, what worries me is a special-interest high-level app. Like a JVM (or whatever they're called now), UPnP, SNMP, or something else ghastly, fat and insecure. Should be interesting, in any case. -Scott On Wed, 18 Apr 2001, Mike Noyes wrote: Scott C. Best, 2001-04-18 19:58 -0700 Mike: I agree: a potentially watershed article. Quoting from a juicy bit: snip Cool. This will make my echowall porting efforts go that much smoother. ;) Scott, I like the idea, but not who proposed it. Inder Singh's opinions concern me. If I understand his definition below SCO and Solaris are Linux too. If this standard will certify a proprietary OS because of API compatibility I'm against it. http://linuxdevices.com/articles/AT2016752176.html ~ Thus, one answer to the question "Is it Linux?" which may be the most ~ meaningful is that it is Linux if it can run Linux applications, i.e. ~ defining Linux in terms of its APIs/ABIs. This is the aspect that is ~ most important to developers of Linux applications as well as to most ~ embedded Linux developers. It is key to preventing Linux from ~ fragmenting the way that Unix did. ~ ~ From this perspective, products like LynxOS from LynuxWorks, which has ~ a high degree of compliance with the Linux APIs, and will support the ~ ABIs in a future release, are effectively more true to Linux than some ~ of the open source solutions like RTLinux and Zentropix which are ~ derived from Linux, but break the Linux APIs to provide real-time ~ performance. -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] LEAF Distribution
David: I agree, there should be no distribution called LEAF, specifically. But...there *should* be distributions called (for instance) Maple and Oxygen that were developed by LEAF contributors. Essentially, we should distinguish the project name from the distribution name. So, unlike RedHat, more like Transmeta. -Scott On Thu, 5 Apr 2001, David Douthitt wrote: To me, that is what LRP and its variants are all about: these ARE distributions, and part of maintaining a distribution is updating packages, adding features, recompiles, et al. As for a LEAF distribution, I think I would actually shy away from an actual "LEAF" image; the concept is good but the literal implementation would be bad. Put another way, I wouldn't have any problem with "Maple LRP" created by the LEAF project (as one more LEAF variant) but to have a "LEAF LRP" or "LEAF image" would overshadow projects like Eigerstein and Oxygen. Oxygen, among being good for others to use, reflects my own decisions and foibles - I like it that way :-) A LEAF LRP would cause people to think that Oxygen has been superceded by LEAF, or that LEAF is "more current" or "better" which may or may not be true. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Packaging
Actually I like .lrp as well, though my complaint with it is different. I find it difficult to extract files from a .lrp without potentially overwriting important system binaries on the development box. What'd be *much* nicer is if package.lrp expanded to /tmp/package, and then /tmp/package/package.list would be queried to find out where to put everything. -Scott On Thu, 5 Apr 2001, David Douthitt wrote: I seem to be somewhat alone in that I *LIKE* the *.lrp packaging; there is only one change I would make: rename the files from *.lrp to *.tgz. This adds the ability to know what the file format is, and allows Windows hosts to decipher the file automatically. However, there is support for unpacking RPM and DEB files within busybox; I haven't played with them yet, but perhaps a new distribution might find a need for them. I don't know about Debian packages, but RPMs are very nice for a full system, work fast, upgrade well, have dependency checking. and also a huge database, lots of CPU overhead, and aren't usable with generic UNIX utilities like tar, gzip, and cpio... Debian probably has a similar problem, yet I don't like their dpkg hardly at all. I've also used Unixware packages and HP-UX depots; none of them share the fundamental simplicity that the *.tar.gz file for LRP supports. UNIX originally did EVERYTHING in files; I understand that Plan 9 (an ATT post-UNIX OS development) goes even FARTHER with this idea. Why not use it in our packaging? ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] dhclient, rc.pf and psentry in harmony
Jon: Heya. Two very keen improvements; good show. I might lift them in an update to echowall... Thanks! -Scott ... Since dhclient-script is called when the IP address changes, it seems a natural place to call rc.pf. So, in the BOUND and TIMEOUT sections, right after the gateway routing, I put a simple /etc/rc.pf start $new_dhcp_server_identifier $new_ip_address This way, every time the server or client dhcp address changes, it will get updated. Then, in rc.pf, I set DHCP_C="$3" DHCP_S="$2" This lets you update the firewall while supplying the correct addresses manually. And of course IPI="$DHCP_C" ... ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Mirrors and upcoming Oxygen CDROM
Rick: Wow. So *this* is the sensation of being wrong. g I stand corrected. Helluva patch, if it works. Though...if my PASV FTP client asked to connect to port 23, I wonder what the patch would do? Anyhow, apologies abound. Anyone seen it working? -Scott On Wed, 4 Apr 2001 [EMAIL PROTECTED] wrote: On Tue, Apr 03, 2001 at 09:56:20PM -0700, Scott C. Best scribbled: Errr... I believe that ip_masq_ftp is used to make *active* FTP work, on the *client* side. My understanding is that Active FTP is tricky on client-side NAT'ing-firewalls and passive FTP is tricky on server-side NAT-ing firewalls. Unfortunately, this masq modules only solves for one of them, not both. AFAIK, you *gotta* tweak the config files of your FTP server to make it work from behind a NAT'ing firewall. Its response to the PASV request must include the external IP# of the firewall and a port from within the port-range that the firewall is auto-forwarding from. Kick me if I'm way wrong on this... *punch* I know all of that; I'm talking about the patch, originally written by Fred Viles [IIRC], that changes the ip_masq_ftp.o module to correctly deal with server-side-NAT-firewall-PASV connections. This allows you to avoid having to do anything special with your FTP server, in case you're running one that you can't configure like that. -Scott -- rick -- A mind is like a parachute... it only works when it's open. ICQ# 1590117 [EMAIL PROTECTED] Help with LRP: http://lrp.c0wz.com Home page: http://www.c0wz.com ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Oxygen LRP CDROM
David: Wow, a ton of progress. Have you considered doing a network boot? That is, just store the md5 hash on the CDROM that're associated with the packages to load, then just put those packages on, say, sourceforge. Probably a million holes in the idea, but I thought I'd float it out. -Scott On Wed, 4 Apr 2001, David Douthitt wrote: I've been working on other things; I hope to have a usable booting CDROM shortly. The system should be able to boot from CDROM; however, what I'd REALLY like is to be able to 1) boot from CDROM (easy), then 2) load packages from CDROM (harder). The ideal would be to be able to pick up a configuration file which contains a list of files to load. I thought I had this set up until I realized that this file loads packages from whatever volume it happens to be loaded from. What I really need is: * A way to "disconnect" the specification of packages to load FROM the actual source of those packages. [snip] ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Mirrors and upcoming Oxygen CDROM
RicK; [EMAIL PROTECTED] wrote: On Tue, Apr 03, 2001 at 06:00:49PM -0500, David Douthitt scribbled: * Kernel patches: Openwall, bridgefw, VPN+Masq... How about the ip_masq_ftp.o server patch? Huh? You know, the patch that makes passive ftp servers work behind masquerading firewalls? Errr... I believe that ip_masq_ftp is used to make *active* FTP work, on the *client* side. My understanding is that Active FTP is tricky on client-side NAT'ing-firewalls and passive FTP is tricky on server-side NAT-ing firewalls. Unfortunately, this masq modules only solves for one of them, not both. AFAIK, you *gotta* tweak the config files of your FTP server to make it work from behind a NAT'ing firewall. Its response to the PASV request must include the external IP# of the firewall and a port from within the port-range that the firewall is auto-forwarding from. Kick me if I'm way wrong on this... -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Mirrors and upcoming Oxygen CDROM
George: Wow, cool. I looked around for it for an hour and couldn't find anything that said it worked liked this. Got a URL? -Scott On Wed, 4 Apr 2001, George Metz wrote: On Tue, 3 Apr 2001, Scott C. Best wrote: Kick me if I'm way wrong on this... *Kick* Sorry, couldn't pass it up. =) Errr... I believe that ip_masq_ftp is used to make *active* FTP work, on the *client* side. The default module does, yes. However, someone of great ingenuity out there came up with an absolutely brilliant patch that allows a masq'd FTP server to do passive FTP without (much of) a hitch. It's not a widely distributed patch, and I'm not quite sure why it never made it into the base kernel source, as it sounds like it would be incredibly useful all-around. -- George Metz Commercial Routing Engineer [EMAIL PROTECTED] "We know what deterrence was with 'mutually assured destruction' during the Cold War. But what is deterrence in information warfare?" -- Brigadier General Douglas Richardson, USAF, Commander - Space Warfare Center ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] grep options
Pi: Woof! That's terribly annoying. So...forgive my non-sed'ness, but what would be the equiv of, say: "grep -v -i FOO /etc/passwd" ? Thanks again -Scott, thinking about grep.lrp... On Fri, 30 Mar 2001, Pim van Riezen wrote: On Fri, 30 Mar 2001, Scott C. Best wrote: Am having trouble with normal grep options in eigerstein 2.2.16. Anyone else seen this? Getting error messages like "sed: can't read foo..." for simple things like: grep -v foo /etc/passwd Huh? sed with greap? Any thoughts on this? TIA! grep -v didn't even work in the old LRP2.9.8 release. Always had to hack around it by using sed -e "s/foo//" instead of grep -v "foo". Pi ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] grep options
Am having trouble with normal grep options in eigerstein 2.2.16. Anyone else seen this? Getting error messages like "sed: can't read foo..." for simple things like: grep -v foo /etc/passwd Huh? sed with greap? Any thoughts on this? TIA! -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] phpWebSite Vote
Mike: My vote as well for the phpWebSite. Though, I really enjoy the rotten-avacado green and baby-poop brown color theme. Please don't change them. I'll be painting my whole house this coming week to match... g -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [LRP] [Fwd: [Leaf-devel] Linux based Access Point]
Rick: I think it's called WEP: Wired Equivalent Privacy. AFAIK, there are two levels, one which uses 64-bit keys and another which uses 128-bit keys plus RC4. Which is to say, I can set my access point to only respond to PCMCIA cards setup with the LAN name "Froog", and that code word is likely used scramble a 64-bit password challenge or a 128-bit cipher. What I'm unsure of is if the data stream itself is scrambled. Spread-spectrum (as used in 802.11b) has an inherent security to it in the spreading-code. Maybe that's what's exchanged "securely" with WEP. Maybe I should look at the source code already. :) -Scott Additionally, before this discussion found it's way to the LRP list, it was said that communications between client and AP are not allowed to be picked up by other clients, protected with a password-like name [and some sort of encryption?]. An AP is at least those functions in addition to a bridge. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] two port redirection questions
Heyaz. First, anyone seen/used this? http://freshmeat.net/projects/nportredird From the blurb, it *looks* like an ipportfw command with a -s switch. Cool. :) Second...any idea if there's an autofw equivalent of: 'ipmasqadm portfw -l -n'? Can't seem to find out if any port range is being auto-forwarded without cat'ing /proc/net/ip_masq/autofw directly. Weird. I had an autofw rule sitting in my firewall for *months*, as flushing it with 'ipmasqadm portfw -f' didn't clear it, and there's no obvious way of checking. -Scott PS: Yeah, EchoWall 0.51 flushes both portfw and autofw now... ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] FTP and Firewalls rant
Heyaz. I've posted a PDF discussing the FTP protocol and how it works/doesn't work with firewalls to my website: ftp://ftp.echogent.com/docs/FTP_and_Firewalls.pdf Any feedback of course appreciated. I'm thinking this is version 0.9, and I'll knock it into 1.0 shape and put it on Sourceforge. That will likely entail, of course, making the source HTML and not PowerPoint. Hope it proves useful. cheers, Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] DocManager backups
A quick question along long these lines...what's the prefered open-source license for LEAF documentation projects? I'm wrapping up a "FTP and Firewalls" .pdf and I wanted to get that part right. Well, I wanted to get it all right, but I'll start easy... Thanks! -Scott On Fri, 23 Feb 2001, Mike Noyes wrote: Everyone, First everyone deserves a big pat on the back. We have doubled the content that was in the original LRP QA. [snip] ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] bootstrapping signed packages
A quick thought about encrypting and signing. From Schneier's _Applied Cryptography_, section 2.7, the way to do this is to first sign the deliverable in the private key of the distribution, and then encrypt the deliverable *along with the signature* into a single file. So if the package is P, and S() is an encrypted hash signature, what you download is: Ed( P + S(P) ). Ed(), the encryption, and S() the signature, are done using the distro's private-key. Each of the clients either have the public key already *or* they grab it via SSL. First they decrypt the whole thing, then hash the Package, then decrypt the signature and compare the two hashes. If the two match, you now know: the Package is intact, the Package is legitimate. Pub/Priv Key schemes do *not* need a fullblown PGP; that's a user-space application. Crypto packages like Oscar support RSA, now that its US patents have expired. I'm sure a pretty lean "RSA decrypt" app can be written for the client: it doesn't ever need to encrypt or key-generate itself (the bulk of PGP's code I would imagine). IMO, this is all very doable and pretty straightforward. The nasty bit comes is *managing* the distro-key I wave my hand at above. :) Key-distribution, especially key revocation, are terribly nasty problems. It's not perfect, but using SSL to grab a signed certificate is certainly doable, of course. cheers, Scott Mark Seiden wrote: yes, i was imagining a conventional "hash and sign" operation. the entire contents of the tar.gz (including all files and directories, as well as their permissions) would be hashed. The usual method is to create a *.sig file for the binary file (in this case, a *.lrp file). the hash would be signed by the packager, using their private key.(let's ignore for now exactly how, but any kind of digital signature supporting public key will do, for my purpose.) on the client, the public key stored on the floppy would be used to check the signature of the hash, which would determine its authenticity. the hash of the contents would be recalculated, to determine whether any content had been altered after signature. As I understand signatures, a signature not only verifies the sender but also the contents of the item that was signed. If you change the "item" (message, tar file, whatever) then the signature becomes invalid. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] First crack at the XML LRP config
Tom: Heya. Thoughts for you: I think that this is much to low a level of abstraction. I suggest that if you want to represent the user's wishes with regards to firewalling then something more along the line of what is contained in the Seattle Firewall configuration files is more appropriate. Also notice that there are no order dependencies in any of those configuration files. Hmmm. I think we're speaking about different things. :) Let me see if I can remember my thinking on this...a firewall system includes these things: 1. A OS with packet-filtering capability (eg, okay, Linux ;) 2. A command interface to that capability (eg, ipchains) 3. A base ruleset, usually defined in terms of #2 (eg, a *order-dependent* list of ipchains commands). 4. User customizations to augment #3. What I've heard discussed over the last few weeks is: "what sort of user interface can LEAF provide to make the installation of #3 and the creation of #4 easier for the non-learned user?". My opinion has been that the design of this user interface can be simplified if it is independent of #2. It would read and write to a platform-neutral format, and so the talk naturally comes around to XML for that. In that format, we'd specify the whole of #3, including its required order dependencies (which is as Ray pointed out). We'd also store "user intentions" which can be much higher level as you suggest: "FTP_SERVER=192.168.1.2" is all it should take. I'm a big proponent of "solve the UI" problem, so I'm willing to swallow the pill that comes with it: if we *do* make this step away from defining a firewall in terms of ipchains, then there is a "magic happens here" piece of code that translates the XML data back into it. The overall complexity of the task is unchanged; I'm just advocating the shift of the complexity from the "what you see everyday" UI to the "behind the scenes" translation script/process. cheers, Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] LEAF certification
Rick: Heya... Sounds doable. Now to find an Angel to front the $25k. ;) Egadsnow there's the problem; I can't see sinking $25 into it, when it's just going to put a badge that most have never heard of on a single derivative [possibly one that doesn't see a lot of use, at that]. I'd agree with you...except...I heard about the ICSA early last year while pitching a proposal to a cable-modem OEM here in the area. Their CM image is compiled for VxWorks (Wind River's RTOS) and so they wanted a firewall in that OS (which, weirdly, WindRiver does not provide...go figure). I indicated to them my company's firewall capabilities, and his reply was quick: "is your firewall ICSA certified? That's a checklist item for us." So, in a way, the $25k is just the access fee to the real game. These hardware box makers are *not* software people, and they've few experts in-house to rely upon. So, without that, they rely on standards and consortiums and, yeah, certifications. Won't matter a nit to JoeLinux user, and probably won't impress JackHome user, but IMO it matters substantially to CorporateBob *customer*. cheers, Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] LEAF certification
Jack, David, Rick: Heyaz, thanks for the feedback. Some comments below: understanding is that the Linux 2.2 kernels would not be able to make it since the firewalling is not state-ful. I bet 2.2 can be back-patched to use 2.4's netfilter; would that make it stateful? What I read about netfilter says yes, it can be back-ported. Though...what about the ICSA requirements mentioned statefulness? I didn't see it. It does specify a specific set services that must work and no others. I didn't interpret that to mean it must work for a webserver behind the firewall setup to listen to, say, port 53. Eeesh. Perhaps I should ask them for clarification on this... What's the difference between excellence and putting out a product which is better? I should have been more clear about my intent, above; what I wanted to know is why we're going after popularity, instead of creating what we see as the best? Wellour motives for ICSA certification don't have to be the entirety of our motives for the whole LEAF project. Or vice-versa. Certification is just a means to an end: it gets some people to use LEAF who otherwise wouldn't/couldn't. I envision on the LRP list someday we can answer the FAQ: what can I tell my boss about LRP so he'll let me use it instead of a Cisco 2600? with the snappy comeback A derivative of LRP got ICSA certified, and the Cisco 2600 isn't. Based on the feedback, I believe I'm going to move the certification work forward. Here's my plan: I'll create a LEAF release based on Oxygen, stripping down anything server or NAT related. Should be doable on one-floppy. I'll set it up with the firewall ruleset I use on my colo'd /28 subnet. Then I do all the documentation work needed to get it running, and so get it certified. If/when it gets certified, we put a big ICSA sticker next to it on the LEAF site, and maybe do a press release. :) Woo. Some people will come for it, and then they'll start to ask: What about NAT? What about IPSec? That's when we answer with: For those features, use these releases instead: EigerStein is here, Oxygen is here, etc. Sounds doable. Now to find an Angel to front the $25k. ;) -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] First crack at the XML LRP config
Ly: Going to take a stab myself here... RULE CHAINinput/CHAIN ACTIONpolicy=deny/ACTION /RULE RULE CHAINinput/CHAIN ACTIONflush/ACTION /RULE RULE CHAINinput/CHAIN ACTIONADD INTexternal/INT SOURCE_IPanywhere/SOURCE_IP SOURCE_MASK0/SOURCE_MASK DEST_IP255.255.255.255/DEST_IP DEST_MASK32/DEST_MASK PROTOCOLtcp/PROTOCOL LOGGINGno/LOGGING FLAGSsyn/FLAGS POLICYdeny/POLICY /ACTION /RULE A starting point? -Scott On Fri, 2 Feb 2001, Anh (Ly) Vuong wrote: Greetings, I am just typing as go here, and hope to stimulate more thoughts in definning an XML LRP config. I have not dare to start the firewall rules just yet, any thoughts on this topic? Cheers, Ly --- ?xml version=1.0 standalone=yes? LEAF KERNEL VERSION2.2.16/VERSION FEATURES IP FWDING=YES ALWAYS_DEFRAG=YES/ /FEATURES /KERNEL INTERFACES REDIRECT_ICMP=YES INTERFACE START_ON_BOOT=YES BRIDGE=NO PROXY_ARP=YES IDeth0/ID ALIASdmz/ALIAS TYPEethernet/TYPE IP SPOOF=YES LOG_MARTIANS=NO ADDRESS198.162.1.1/ADDRESS MASK_LENGTH24/MASK_LENGTH BROADCAST198.162.1.0/BROADCAST GATEWAY198.162.10.1/GATEWAY /IP /INTERFACE INTERFACE START_ON_BOOT=YES BRIDGE=NO PROXY_ARP=YES IDeth1/ID ALIASprivate/ALIAS TYPEethernet/TYPE IP SPOOF=YES LOG_MARTIANS=NO ADDRESS198.162.2.1/ADDRESS MASK_LENGTH24/MASK_LENGTH BROADCAST198.162.2.0/BROADCAST GATEWAY198.162.1.1/GATEWAY /IP /INTERFACE /INTERFACES DNS DOMAINS DOMAINconfig.lrp.net/DOMAIN DOMAINanother.com/DOMAIN /DOMAINS SERVERS SERVERdns.another.com/SERVER SERVER198.162.10.1/SERVER /SERVERS /DNS /LEAF -- If you find yourself digging a deeper and deeper hole... stop digging. - Anonymous ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] First crack at the XML LRP config
Ray: Hey, I know you. :) I think this attempt doesn't get to the essence of the design problem. [snip] The big problem with ipchains rulesets is that order matters. I agree, of course, order matters. But that's not what I was trying to solve, cuz I didn't identify that as the essence of the design problem. The design problem I was looking at is a platform independent format for a *whole* ruleset. My presumption was that the whole ruleset would be installed, from top-to-bottom, with no rule re-ordering. Sure there's no great trickery there, but it's not been done before either. For that matter, I'm doubtful that XML'ing will help get individual rules right. That requires a rule pre-screener, and why not just let it write its output in ipchains-native format? Writing it in ipchains is the best way if you know it's going into a 2.2 kernal firewall. If it's going into something else, and you really don't know what that something else *is*, then some platform-neutral format makes sense to me. Providing, of course, you've the implicit understanding that when the rules get converted, they get installed into the firewall in the same order that they appear in the XML. And you agree to pay attention to as much as you can (ie, ignore the flag tags if your firewall can't deal with those). Given a *whole ruleset* written this way, it's a bit of work to write a ruleset-to-ipchains converter. But after that, it's easy to write the ruleset-to-ipfwadm one. Or a netfilter one. Once you've got the converter for your platform, now you can write a UI that lets the user add, modify and (sure) break some of the rules. The UI reads from and writes to the same platform-neutral format that the converter does. So *it* doesn't have to be ipchains aware either. That's pretty powerful, especially if the UI (aka, #3 from an earlier thread) was a remote process. In practice, though, I think this just won't fly. It might not. But it got some clear benefits in making firewall-config UI design easier and making it easier to distribute firewalls across platforms. Both fairly worthwhile. And, really, if there *was* a firewall schema out there already defined by W3.org, it'd be even more compelling to use it. But there isn't. So, lets do that. :) In a way, Dave Cinege always had the right idea about this problem ... write some scripts that simplify the basics, and expect the advanced user to do the complicated bits by hand. That's the best model for the advanced user. But I don't think it's the best model for the average user. The average user, I think, would appreciate a better firewall-config UI than editing ipchains commands directly in ae. Or, as you go on to point out, the average LRP-emailer would appreciate a how do I make VNC work? response that could be answered without needing to know the details of their firewall's OS. Shrug. I think it's worthwhile enough to pursue if someone is lit up on the idea and is comfy in XML and firewall rulesets. If not, I wouldn't say this is the best use of LEAF's best coders' time. -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] First crack at the XML LRP config
Ya know...I was thinking about what Ray said, and reflected a bit on how Matthew Schalit did his rc.pf stuff. It might be worthwhile for rule order if there was a type associated with each rule, and a preface to the ruleset would indicate which types got installed in which order. So for instance, borrowing liberally: RULE_TYPE_ORDER order=defaults flush spoof stufd cert local masq int ext final /RULE_TYPE_ORDER Then each RULE could have a tag like: TYPEspoof_1/TYPE So now the XML file itself is not order-dependant, but, rather, it specifies an explicit order instead. -Scott On Sat, 3 Feb 2001, Scott C. Best wrote: Ly: Going to take a stab myself here... RULE CHAINinput/CHAIN ACTIONpolicy=deny/ACTION /RULE RULE CHAINinput/CHAIN ACTIONflush/ACTION /RULE RULE CHAINinput/CHAIN ACTIONADD INTexternal/INT SOURCE_IPanywhere/SOURCE_IP SOURCE_MASK0/SOURCE_MASK DEST_IP255.255.255.255/DEST_IP DEST_MASK32/DEST_MASK PROTOCOLtcp/PROTOCOL LOGGINGno/LOGGING FLAGSsyn/FLAGS POLICYdeny/POLICY /ACTION /RULE A starting point? -Scott On Fri, 2 Feb 2001, Anh (Ly) Vuong wrote: Greetings, I am just typing as go here, and hope to stimulate more thoughts in definning an XML LRP config. I have not dare to start the firewall rules just yet, any thoughts on this topic? Cheers, Ly --- ?xml version=1.0 standalone=yes? LEAF KERNEL VERSION2.2.16/VERSION FEATURES IP FWDING=YES ALWAYS_DEFRAG=YES/ /FEATURES /KERNEL INTERFACES REDIRECT_ICMP=YES INTERFACE START_ON_BOOT=YES BRIDGE=NO PROXY_ARP=YES IDeth0/ID ALIASdmz/ALIAS TYPEethernet/TYPE IP SPOOF=YES LOG_MARTIANS=NO ADDRESS198.162.1.1/ADDRESS MASK_LENGTH24/MASK_LENGTH BROADCAST198.162.1.0/BROADCAST GATEWAY198.162.10.1/GATEWAY /IP /INTERFACE INTERFACE START_ON_BOOT=YES BRIDGE=NO PROXY_ARP=YES IDeth1/ID ALIASprivate/ALIAS TYPEethernet/TYPE IP SPOOF=YES LOG_MARTIANS=NO ADDRESS198.162.2.1/ADDRESS MASK_LENGTH24/MASK_LENGTH BROADCAST198.162.2.0/BROADCAST GATEWAY198.162.1.1/GATEWAY /IP /INTERFACE /INTERFACES DNS DOMAINS DOMAINconfig.lrp.net/DOMAIN DOMAINanother.com/DOMAIN /DOMAINS SERVERS SERVERdns.another.com/SERVER SERVER198.162.10.1/SERVER /SERVERS /DNS /LEAF -- If you find yourself digging a deeper and deeper hole... stop digging. - Anonymous ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] chains/rules schema - win client
I think that the technology should be extensible. But I think that the 'client' application should be cross platform. Some people would enjoy this kind of interface. But they do not choose to or want to run Windows. I agree, it should be cross-platform. But my coding expertise limit my contribution to win32 and some small scripting. we could have two or more identical clients, for each platform. [snip] the remote client idea's purpose was to use ssh, that would not be as secure as a local shell, and it would be used from the lan, the only danger in it would be dsniff! but... what can we do about it? The local-client can access the same info the remote-client would access, though. So why not have it access the material in the same way: SSH. That configuration interface on the firewall, the one that's exchanging the config info with the config utility, is just acting as a network transfer agent, really. What you *do* with the data (that is, what you display for the end-user after you know the details), is much more arbitrary. This enables multi-platform configuration clients pretty straightforwardly. Regarding having a Windows-specific one, IMO I think having it is valuable for one big reason: when the firewall is *first* booted, it's probably not going to be able to get online to reach any 'remote config' utility. Just too many variables: DHCP, PPPoE, static-IP, etc. The LAN side, though, is less of a tangle. Just have to boot the NIC and find the LAN-side address range. So I envision a situation where the user boots the firewall for the first time, and turns on a LAN-machine to run some initial setup configuration. Realistically, 90-percent of the LAN machines are running Windoze: having a 'Setup Wizard' then would be really useful. If it's not that sorta LAN, then we don't have to worry: that admin will be comfortable at the firewall console. -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] chains/rules schema - win client
Egads as this one spiraled up. :) Quick thoughts: I agree. And while I do not mind the command line, it is often nice to have a well crafted tool or interface help you and also reduce the chance of errors. Absolutely - but non-commandline doesn's necessarily mean some x-interface. Granted, to the average windows user, anything less than 1024x768 with 16k colors _seems_ like a command line ;-) (no offense to anybody - I'm a windows user as well). Yikes, from schema to UI in 5 emails. :) Getting back (briefly) to the subject which spawned this thread, let me offer a collection of opinions: 1. To make UI design easier for everyone, it'd be *nice* if the user's intentions for the firewall were stored on the firewall in XML format. A firewall.conf, as it were. 2. Given this firewall.conf file, a middleware process/app/script would be needed to turn this data into the OS-specific firewall commands (e.g. ipchains, ipfwadm, netfilter, etc). This middleware piece could produce either a root-executable script, install the rules directly, or even do both. 3. Given #2, you don't care *how* #1 gets updated. It could be thru a command-line console interface, a LAN-based Windoze app, or a remote server running some ASP scripts connected via an SSH session. Or just vi. Is this a sensible design-model paradigm for LEAF? -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] chains/rules schema - win client
DOH. Forgot something: only #1 really *needs* to be local to the firewall itself. #2 and #3 could both be remote processes. -Scott 1. To make UI design easier for everyone, it'd be *nice* if the user's intentions for the firewall were stored on the firewall in XML format. A firewall.conf, as it were. 2. Given this firewall.conf file, a middleware process/app/script would be needed to turn this data into the OS-specific firewall commands (e.g. ipchains, ipfwadm, netfilter, etc). This middleware piece could produce either a root-executable script, install the rules directly, or even do both. 3. Given #2, you don't care *how* #1 gets updated. It could be thru a command-line console interface, a LAN-based Windoze app, or a remote server running some ASP scripts connected via an SSH session. Or just vi. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] chains/rules schema - win client
So many replies, such little time. :) Will start with this one: On Fri, 2 Feb 2001, Eric Wolzak wrote: 1. To make UI design easier for everyone, it'd be *nice* if the user's intentions for the firewall were stored on the firewall in XML format. A firewall.conf, as it were. I do agree about the description of the firewall in XML (see my mail) but why does this description has to be physical on the Firewall ? because the Firewall as a machine and the description belong formally together as a kind of source code ? Yes. I gave it all of 5 minutes thought, but that's where I ended up with it. The firewall.conf file is what would/could make a firewall unique, and so it should be uniquely stored on the firewall itself. As nr 2 is not on the Firewall itself the output from 2 which is machine /project dependant is the real effector. and has to be on the machine itself. if #2 is too big, too complex or whatsoever that we decide not to run it on the box itself why should the source code be on the box I'm thinking #2 could be either on the firewall itself (a typically script-based tool like Seawall leaps to mind), or could be something remote, like on a win-client or a remote server. It's *output* is what actually affects the firewall, so that piece has to get back onto the firewall machine. But the output doesn't have to stick-around either: the output could be an bash script filled with ipchains commands that just deleted itself after it ran, for instance. In general, though, the most robust thing to do is to put #1 and #2 on the same machine. I'm not aware of anything that *doesn't* do that right now, in fact. As I was writing these three up, and thinking about how *I* intend to make #3 remote (which has clear advantages regarding eliminating a byte-heavy GUI from a CPU and storage-constrained embedded system), I just started to wonder if #2 could become remote as well. Apologies for the confusion. :) -Scott 2. Given this firewall.conf file, a middleware process/app/script would be needed to turn this data into the OS-specific firewall commands (e.g. ipchains, ipfwadm, netfilter, etc). This middleware piece could produce either a root-executable script, install the rules directly, or even do both. 3. Given #2, you don't care *how* #1 gets updated. It could be thru a command-line console interface, a LAN-based Windoze app, or a remote server running some ASP scripts connected via an SSH session. Or just vi. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] chains/rules schema - win client
Matt: Heya. Quick comment: 1. To make UI design easier for everyone, it'd be *nice* if the user's intentions for the firewall were stored on the firewall in XML format. A firewall.conf, as it were. I don't like this whole thread, but I'm a bit crotchety this morning. I disagree with #1. I don't want to have anything to do with XML, and if that's what's going to happen here, then it's not for me. If someone wants to build up some cgi-scripts to do https configuration with the files that exist, I like that idea, as it's possible with weblet or whatever and almost everyone has a browser. I don't like the idea of a standard interface for all the flavors of Lrp. Okay. :) I think we're more in agreement than not. My intention was to speculate on the need for a bedrock piece for, specifically, a firewall UI. Having one would allow more focused work by the people who want to write UI's and the people that want to create rulesets and the people who want to create new capabilities. Given a basis, there could then be created multiple flavors of UI for a LEAF-based firewall-router. Some would be GUI's, some lrcfg-like, some would look suspiciously like ae. So, IMO, it helps to create focused diversity if everyone who did branch out didn't have to worry about the whole enchilada, ceiling to floorboards. Of course, it doesn't *have* to be XML. The alternative is a file format that has agreed-upon fixed variable names of some sort (which I'm using now in my project). cheers, Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Compressed Filesystems
David: To compress all files as well as glibc, why not to rewrite root device filesystem to support compressed file? This is one of those ideas that make one go Duh! Why didn't _I_ think of that? Is there a simple, small, quick compression that would work? It would have to take the form of a kernel patch. Seen LZO? I've had people rave about it to me. Google search for lzo compression and it's the first link. It's optimized for decompression speed and (with miniLZO) for exec size (6k I think?). -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Character Studies (of Users)
Pedro: On Wed, Jan 31, 2001 at 11:48:17AM -, [EMAIL PROTECTED] scribbled: so.. what I say is why not build several LEAF images, for the most common targets (SOHO etc..), and have them approved by some internet security authority (don't know if such auth. exist), then we make a page just for this target audience, explain what a LEAF firewall does, why it is needed, how little he has to 'pay' for it, like you explain things to a 6 year old! we splash a CertifiedAndTestedTroughtBySans (imagine :) logo on the page, and mrJackHappyHomeUser will say, 'wait a minute, this is almost free, certified, easy to understand, I guess I could try one of this'. and LEAF evolves trough the year 2001 killing CSCO :DDD Hey, that's a damn good idea, and well-articulated. The part about getting some sort of certification is new, I don't think I've ever heard anybody say that before; and the rest has been said, but never said quite so well. I agree with Rick: it's a damn fine idea. The certification authority you're looking for is www.icsa.net; I had a potential customer ask me not-so-long-ago about it specifically. It *probably* requires that our firewall be active "out of the box", which means we need a 'SOHO boilerplate' ruleset. I've been building with the presumption of three boilerplate levels the end-user would choose from: Basic, Strict, and Paranoid. Sure, sure, they'd be customizable with a killer UI, but they'd be strong starting points. Also, being sheer marketing, it may cost money to get such ICSA approval of a "SOHO LEAF Image 1.0", but I'll look into it. The money may be the easy part. :) -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] LEAF certification
David: The certification authority you're looking for is www.icsa.net; I had a potential customer ask me not-so-long-ago about it specifically. I know it's probably not a "product" certification, but what about GIAC? Perhaps we could find a GIAC-certified Security Engineer (I think that's their highest level certification) and have them evaluate a LEAF distro release, where we'd publish their report on the LEAF website? Shrug. Seems secondary to ICSA certification, in that many (most?) security-software consumers use certification and "brand names" as an excuse for thinking [goes looking for a copy of The Fountainhead for a confirmation quote]. Which is unfortunately why we'd need it to reach the John-Office (Jack-Home's more IT-aware brother) user: if John was smart enough to use LEAF without *caring* if it was ICSA certified, then he's in a much smaller user category. -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Character Studies (of Users)
Matthew: Heya. My intepretation of: |LO1 - Required Log Events - The Candidate Firewall Product shall |have the capability to log events belonging to the event types |described below... ...is with emphasis on "capability to log". IE, not actual logging all the time for everything. Eeesh. Hee. It is telling that the "Traffic Permitted Inbound" of the 3.0a Criteria doesn't include SSH. ;) -Scott On Wed, 31 Jan 2001, Matt Schalit wrote: Folks, Mike Noyes wrote: Firewall Product Certification Criteria Version 3.0a http://www.icsalabs.com/html/communities/firewalls/ \ certification/criteria/criteria_3.0a.shtml Taking a look at this, it refered to logging all acceptable and unacceptabe access. That'd fill our logs in a hearbeat, then syslog would stop logging. Do you concur? Matthew ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] ICSA Overview
Heyaz. Just so everyone is on the same page without wandering thru that whole doc, I thought I'd summarize ICSA's criteria requirements here. I may offer an interpretation as well, so feel free to call me on something I flubbed. Also, of course, feel free to identify what you know/think to be done already in a current LEAF distro. As you can very well imagine, it's very doable if not done already. -Scott --- Essentially, there are six total pieces: RS: Required Services LO: Logging Requirements AD: Administration FT: Functional Testing ST: Security Testing DO: Documentation Each of those sections has about 3 or 4 subsections, some of them labeled conditional. The go as follows: RS.1.1: A list of services that the firewall must be able to allow real world access to. IE, the firewall must support active FTP, HTTP/S, SMTP and DNS servers located behind the firewall. No mention of NAT. It's allowable (but not required) that the firewall require these services to be on a DMZ. RS.1.2: A list of services the LAN machines must be able to use without trouble. Same list as above plus TELNET. It's allowable (but not required) that the firewall require these services to be proxy'd (eg, SOCKS). RS.1.3: All other traffic gets denied. No Napster I guess. RS.2:All of this must be accomplished without having to install anything proprietary on the clients or the servers (with the exception of management software for the firewall itself). IE, it's transparent for anything that speaks vanilla TCP/IP. LO.1:Once it's up and running such a policy as specified by the RS section, the firewall must have the ability to log the following events: 1. Successful inbound connections to a protected server 2. Successful outbound connections to a public server 3. All attempts, from either side, to access some service not explicitly allowed 4. All attempts, from either side, to send traffic to the firewall itself that's not associated with an explicitly allowed service. LO.2:For each event that is logged, the following must be recorded: 1. A date and time. Accuracy of time is in LO.3. 2. Protocol (eg, PROTO=6, 17, etc) 3. Source IP Address (is this really useful? ;) 4. Dest IP Address. 5. Destination port for TCP/UDP or Message Type for ICMP. 6. How the event was handled (eg, ACCEPT, DENY, REJECT). LO.3:Timestamp must be date, hours, minutes seconds. No mention of NTP here, but its strongly implied. LO.4:Logs must be human readable (ie, straightforward ASCII) LO.5:Conditional: If logging is stored remotely from the firewall, the FQDN or real-world IP number of the firewall itself must also be logged. LO.6:Conditional: If multiple logs are recorded for a single event, there must be some clear means with which to correlate the multiple logs to the single event. AD.1:The firewall must have administrative functions to support: 1. Setting up the above specified policy. 2. Enable the logging as specified above. 3. Conditional: if remote-administration is allowed, either from the public side or LAN based, the firewall itself must have the ability to configure that remote administration. AD.2:The functions of AD.1 must be accessible thru, gasp, an interface. AD.3:To access the Administration Interface, authentication must be done; a password check at a minimum. AD.4:Conditional: If remote-administration is allowed, then at least one of the following must be enforced: 1. If being admin'd from the private side, use of the IP# of the administrative client shall not be the sole means of authentication. 2. If being admin'd via the public-side, then the admin session must either be encrypted and/or a strong authentication mechanism must be used (eg, but not limited to, a one-time password). 3. if not #1 or #2, the remote-admin is disabled. FT.1:Once it's up and running, the certification process will test to see that every service which should work does, and everything that should not work does not. ST.1 Once it's up and running, the certification process will test to see if it can obtain illegal access to the administrative *functions*. Note that it doesn't say access to the functions via the intended admin interface. So buffer overflows here seem fair game to me. ST.2 Once it's up and running, the certification process will unleash some scanners on
Re: [Leaf-devel] Character Studies (of Users)
Eric: Heya. I'm not trying to be facetious here at all, but I wanted to comment: Jack Home-User is the target market for most "home-networking" stuff, but the reality appears to be that Jack doesn't want to buy any of that stuff yet. What I mean is, in a way, the next-big-Internet thing of post-PC info-appliance era of 'home-networking' is a victim of the Internet's early success. For example, when Jack connects to E-Trade to sell CSCO, there's about 5 different networks and 50 computers his transaction goes thru. For him it's a mouse click. All of the "heavy lifting" and troublesome networking equipment has been hidden from Jack, and he *likes* it that way. It's a very intimidating prospect to then convince him that "now you should *buy* some of that equipment and put it in your own home". Er...*sure* he will. I've spent a lot of time thinking about this conundrum (way too much time), and IMNSHO the only way that Jack Home-User is ever going to have a home-network is if his ISP bundles one when he upgrades to a broadband modem. That is, it's not just a modem anymore, it's one of those fancy-smancy 'residential gateways' from someone like 2Wire. The current problem is that those things cost $400 to build, since they're typically stuffed with expensive OS's (WindRiver) and expensive embedded firewalls (SonicWall) and high-end embedded processors (like Philip's Tri-Media processor). What this "bundled gateway" market needs, obviously, is a gateway box that costs $50 to build because it uses LEAF and a low-low-end 486: the casing is more expensive than the content. That solves the OEMs problem. But now the ISP has a problem: it's not really in their financial interest to give Jack a gateway to begin with. They don't meter his bandwidth (this is Jack, not Jauque in this model ;), and since they bundled the gateway, and it's got all these advanced features, Jack Home-user is now most likely to call the ISP to ask for help setting the thing up. Jack's only paying $35/mo for broadband service, and a single tech-support call costs $20 just to answer the phone. So Jack becomes too-expensive a proposition to give a gateway to, and so they don't. Wither the 2Wires of the world. :) What the ISPs want, really, is to somehow discover a new revenue stream from these gateways and people like Jack. Would Jack pay an extra $5 a month "maintenance service" for his new gateway? He might, if it *really* did something valuable for him. Could the ISPs offer such a service to Jack: a web-based remote maintenance service which they could resell for more than they paid for? They might, if I ever get EchoWare finished. :) -Scott On Tue, 30 Jan 2001, Eric Wolzak wrote: Hello i try to present another user, that at least in my part of the world is not so infrequent (funny word) Jack Home-user A family father working in an insurance company, A man you don't even expect to have a computer. But he has one, and now the children want to have one too. He has never heard of another operating sysem besides Windows, he really doesn't even know what an operating system is. And now a fellow told him that he can use a floppy to connect all his computers too the internet over one account. He is very happy that the diskimage is selfextracting and he has got not much more to do than fill out a form on his windows machine to let it install the modules itself and change the configurationscripts automatically. With packages like sshd and so one he has nothing to do, even if he could succesfully log in, he hasn't the slightest idea what router# means and he doesn't want to know either. He is very happy that his "router "(what ever that may be) functions and after visiting a scanner page he is now sure: "so secure, he was never before " After a while jack, being very reluctant in throwing away money , wondered if it is not possible to remote controll the router from a windows programm, use the router as a printer server, perhaps even answer the phone, fax etc. security is after all not that important I hope, i didn't took the wrong words for the description. for this kind of user i made the isdn install script. by the way this user is a compilation of users i met on another german mailinglist :=) Eric Wolzak ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Character Studies (of Users)
Jack: Heya. Some quick comments: Ah, but therein lies another conundrum... if you let your users do the valuable and interesting stuff, there will be two problems -- decreased reliability and increased support cost due to decentralization of core features (mail, web proxy, etc), and It's an interesting question: what services stay centralized and what moves into the edge of the network? Or, if you add network storage into the equation, what services move *outward*. Mostly when people talk about that shiny new era of "home-networking" that's coming Real Soon Now, they speak of two mass-market 'killer apps': VoIP and video on demand. Me, I think it's going to be something else entirely. In any case, my point here is: I think these apps that Jack Home-User will want to run in these new boxes are going to be these bright-and-shiny new ones that don't really exist yet. I don't think Jack will want to run the "legacy" sorts of services that other target characters would. Durn you, Jack. ...increased vulnerability to security issues. Thence ultra-restrictive Terms of Service documents like @Home's. I have an inside view of this due to the local @Home abuse manager being a friend of my wife's -- they don't particularly want to prevent their users doing interesting stuff like mail service, masquerading, etc. Unfortunately the people doing it tend to drop in a RedHat box without thinking about the consequences. They get nailed within hours and become spam and porn relays with ultra-fast upstream connections, and @Home has to struggle to stay off the MAPS RBL and the FBI's top 10. Huh. That's a very interesting motivation of the broadband ISPs that I hadn't fully considered. I don't think it'll be too long before the big ISPs all take steps to prevent their users from doing their own DNS, mail, web servers, etc., and end-users wanting to do that will have to go back to the mom-n-pops where service is more expensive but higher quality. When you consider the plethora of broadband flavors and vendors connecting the Jacks of the world, it seems that the forces of commoditization will drive the ISPs to bundle more and more each year. This is as you suggest, where ISPs will offer AOL-like walled-gardens when it comes to things 'home networking'. That is, "don't worry about mail, web, firewalls, device-discovery and auto-configuration...we'll do all of that for you automagically -- in fact, sign here and agree you will *not* worry about it". But even in that Jacktopia, *some* monetizable, pay-as-you-go services will be installed in the access device at the very edge of the cloud. I think the ISPs will need that, and year-after-year one more services will become commoditized, joining the bundle and falling off the "pay-as-you-go" list. Like when you had to pay extra for voicemail on cellphone plan... ...You might have an insight into this that I'd like to hear -- aren't you the guy who used to run the Bay Area ISP best.net? Yeah, that was me. Sure it was. And James Best, from the Dukes of Hazzard, was my mother-cousin-sister-uncle too. ;) Ahem. :) -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Character Studies (of Users)
Eric: Hello! Some quick replies: What this "bundled gateway" market needs, obviously, is a gateway box that costs $50 to build because it uses LEAF and a low-low-end 486: the casing is more expensive than the content. When do we build it ;) Yeah, no kidding. :) Do we take checks yet? I followed the list of a german variant with a 2.0 kernel and Least cost routing for some time but a good windows remote control and configuration utility.There was moderate trafic. As this adress was published in an article of Chip (computing) in combination with an article about insecurity in the web, the traffic became so high that i canceled my subscription :) . No news sells like bad news. :) in other words, the jacks don't know that they need it. The ISP only want them to have it as long as it doesn't cost them and it is easy to maintain and configurate. Right, exactly. The ISPs will not want these LEAF boxes if they think it's going to make the ISP's life worse. And as Jack Coates pointed out, the ISPs will be fundamentally against having a "big firewall server", like an out-of-the-box RedHat machine, running many exploitable services. -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Project Description
Mike: Quick suggestion: sed 'home-automation' to 'home networking'. I've not heard X10 asked for on the LRP list in a long while. And, what's an "Internet leaf site"? Sounds like a web-forest (Mirkwood?). :) Perhaps: 'Most commonly used as a gateway/router/ firewall to enhance Internet security...'. Thanks! -Scott On Fri, 26 Jan 2001, Mike Noyes wrote: At 12:36 PM 1/26/01 -0500, [EMAIL PROTECTED] wrote: On Fri, Jan 26, 2001 at 08:17:26AM -0800, Mike Noyes scribbled: Current project description: ~ An easy to use embedded Linux network appliance for use in small ~ office, home office, and home automation environments. Although ~ it can be used in other ways, it's primarily used as a ~ gateway/router/firewall for Internet leaf sites. Proposed project description change: An easy to use embedded Linux network appliance for use in small office, home office, and home automation environments. Most commonly used as a gateway/router/firewall for Internet leaf sites, LEAF is very versatile and well suited to many other uses and tasks. 1234567890123456789012345678901234567890123456789012345678901234567890 note: the short project description is limited to 255 characters. This change is 261 characters long. Comments? -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Submit LEAF site to web directories?
Jack: Heya. Quick comment: And the easier it is to use, the bigger a butt-rash it will give to Cisco and Juniper :-) Akshally...from my recent discussions with a heavy-iron maker, their desires with regard to the success of the "edge of the network" SOHO-gateway market is much more along the lines of "by any means necessary". That is, their highest margins are in the cloud, and anything which makes that cloud "bigger" is good for them. An example would be Cisco's cable-modem business: they sell reference designs so that more people can sell cable-modems. The PL of that group can be net-zero...more cale-modem users can *only* be a good thing for CSCO. Bottom line is that I'd bet a cloud-maker would want LEAF to succeed wildly. It's those $5k black-box makers (like..errr.. like the ones George mentioned on LRP earlier in the week ;) that will feel the real chafing. -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Bandwidth Manager
Mike, Rick:
I think it'd be *huge* to add some traffic shaping to LEAF,
with the caveat that we provide a setup interface to it as well, in
the same manner that we provide one for ipchains. That is, we pick
a shaper/bw-manager package, and we bundle it with a script of
the same UI-flavor as our firewall script.
I was looking once at a CBQ solution, and convinced
myself that I could get away with only three bandwidth "classes"
or "priorities" for most target LEAF installations: high-speed,
low-speed, and "time-critical" mode. High-speed would be what LRP
is without shaping, and low speed would be used to intentionally
sit on some LAN machine's peak bandwidth (eg, Junior's PC can only
get 56k). The "time-critical" class would be to suit people using
VoIP, Quake, or other streaming apps that want isochronicity.
Given the ability to provide one of these three modes
to every machine on the LAN, one a machine-by-machine basis,
I think is a 90-percent solution. The ET/BWMGR from Etinc allows
(shiver) "10 levels of priorities...with multiple class groupings".
Excessive, IMO. And, from the "Grand Fireewall Paradigm" thread,
we'd let these modes get specified in the same place and manner
that we specify port-forwarded services.
IMNSHO, of course. :)
-Scott
On Fri, 26 Jan 2001 [EMAIL PROTECTED] wrote:
Would this be anything like
www.securityfocus.com/focus/linux/articles/trafshap.html?_ref=1208318568
??
I was just looking at that last night...
On Fri, Jan 26, 2001 at 11:51:15AM -0800, Mike Sensney scribbled:
Here is a link to a commercial bandwidth manager software package I found
recently. Priced at $595 and runs on either Linux or FreeBSD. This thing is
feature rich and sexy.
http://www.etinc.com/bwmgr.htm
I got to thinking that it sure would be nice to add some of this
functionality to LEAF so I did some looking at FreshMeat:
rshaper is a Linux kernel module that limits the incoming bandwidth for
packets aimed at different hosts ("incoming" meaning traffic that enters
the shaping host; if that host is a gateway between target hosts and the
rest of the Internet, all the traffic of the target hosts will be
shapeable). It's useful for ISPs who offer housing and want to
differentiate their offers and for limiting download bandwidth from
students' boxes or similar setups.
http://freshmeat.net/projects/rshaper
The WRR scheduler is an extension to the Linux 2.2 kernels. It is able to
distribute the bandwidth to different machines at a site in a fair way. As
a default every machine will get equally much of the bandwidth if they have
sufficient demand, but it is possible to make machines transferring much
data over a long or short period of time get less bandwidth. A
plug-and-play ready set of scripts setting up such behavior based on a
configuration file is included. The scripts sets up a Linux bridge which
must be placed between the router and the rest of the site.
http://freshmeat.net/projects/wrr
--
rick -- A mind is like a parachute... it only works when it's open.
ICQ# 1590117 [EMAIL PROTECTED] (home)
Help with LRP: http://lrp.c0wz.com Home page: http://www.c0wz.com
___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Drivers Images
Rick: Anybody have one they want to donate? ;) Akshally...I've a VNS586 PC-104 board from Adastra with one 10BT port and a dual PCMCIA adapter, all packaged in this terribly impressive clear-plastic box. I used it for a while when I was working on a VxWorks project, but you're welcome to use it for LEAF if interested. I could prolly even spare an extra 802.11 card to make sure we got that right. Just let me know! Who ever thought it would be as easy as posting to a list? I was about to post it next to my resume link on lrp.c0wz.com.. ;) That would be great. Has it got any RAM, or does it take standard cheap RAM anyway? Should I email you my snail mail address? Trying to recall the numbers...I *think* it's an 8MB flash (it was a Java project after all ;) and 16M RAM. I've no idea what filesystem is written into the flash, nor am I sure if how to get a Linux kernal in there to begin with. Am actually interested in how you work that part. Yes, snail mail details, please. Unless someone out there has a matter-to-email-proton-converter they'd be willing to donate? (worth a try...) -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Linux-friendly Embedded SBCs
David: Wow, a topic on which I'm fairly well informed! :) I was thinking again about chips - the Linux creator (Linux) was involved in the development of the Transmeta chip, and also the FORTH creator (Charles Moore) developed not one but several chips. What would it be like to compile Linux for the Novix chip or another FORTH chip? Hmmm. From what I understand of Transmeta and its Crusoe processors, Linus was working *not* on the Mobile Linux OS, but rather on the "Code Morphing" layer. This is a layer of embedded software that connects on the inside to the heart of Crusoe (a Very-Long Instruction Word processor) and on the outside presents an interface that looks and feels just like whatever architecture you want: x86, for obvious reasons, in the first release. The keen thing is that the "outside interface" is not fixed: it's defined softly during initialization. So today it's an x86, tomorrow it's a PowerPC, on Monday it's ARM. Going one step further...it can be optimized for size and power by ignoring some of the instruction set that the hardware environment (say, a purpose-built embedded info appliance) just never uses. Very keen stuff. A flawed business model, though, imo, by not staying chipless and just licensing their IP (a-la ARM and Rambus) rather than going for broke and jockeying for designs wins at PC OEMs. I'm not long on anyone that goes up against Intel in that processor market. :) Heya. It'd be worthwhile, I think, for one of our more board-minded LEAF'rs to suggest just such an SBC which we could use as a 'development target'. Not that we won't be putting it into desktop x86's as well, of course, but I was told by a VP at BigIronCompany yesterday that "no one can build a $100 gateway". Hmmm... How hard would it be to use a SBC in a PC (connecting through the ISA bus) to design a SBC LEAF then extract it, box it, and run it? Would be something else! That's the one part of SBC's that gets me: writing the flash image in the first place. I watched a WindRiver field-support guy argue with a Tornado install for 2 hours trying to boot an SBC that was tied to a "robust board support package". Yes, suuure it was... -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Linux-friendly Embedded SBCs
Mike: Heya... What about this? I don't know how hard it would be to port Dave C.'s patches to ARM though. Debian/ARM runs on LART...[snip] Gives me with willies walking away from x86 for a *first* release. -Scott, wimp. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Best License for LEAF Projects
David: Eeek, good question: What is the best license for a distribution such as a LEAF Project? I was considering the MIT License myself, and find it probably matches my goals best, though I'm not yet certain. Quick reference: http://www.opensource.org/licenses/ Several other licenses are valid, including the BSD License, the MIT License, the GNU License, the Artistic License, and quite a few others. Anybody have comments or ideas? From my limited POV, the BSD license is more easily accepted by networking-equipment OEMs who (why not?) would want to put a LEAF-based "DSL-router" on the shelves at Fry's. -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Grand New Firewall Paradigm
Charles: It would be nice to have a general purpose programming language available. I believe Dave plans to include Python as part of the standard Butterfly disto. Worries me in two ways: extra size and giving anyone who does compromise the firewall a development environment. There are also some folks who already have an XML firewall language: http://freshmeat.net/projects/hlfl/?highlight=hlfl I have yet to get enough time to sit down and examine this... Nice find! Checking it out... -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Grand New Firewall Paradigm
David: ...I might create the original config with the script generator Then go poking around in the config file and make some changes rerun the script generator and have recognize the changes (it shouldnt even notice the difference) be at a remote site and connect via SSH and a GUI editor and edit the config at a later date go back and run the script generator In my mind, this is THE biggest problem with almost all Script Generators, whether from the command line or a GUI: if you make hand- tuned changes, then they will be lost next time the generator runs. This speaks volumes about why any firewall generator should read/write to a .conf file rather than create ipchains commands directly. As Charles said, it's the method of rule specification that's most important, not how the (G)UI looks nor how those rules become ipchains commmands. Given a standard, meta-language .conf format, a dozen people could write a dozen UI's, and me the thirteenth guy could still use ae on the .conf to customize the firewall on my machine. IMNSHO, I think LEAF should specify exactly that .conf file format as one of its first objectives. -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/mailman/listinfo/leaf-devel
RE: [Leaf-devel] Grand New Firewall Paradigm
Pedro: IMNSHO, I think LEAF should specify exactly that .conf file format as one of its first objectives. -Scott My thoughts EXACTLY -Kenneth Hadley pardon my intromission, but this is exactly the kind of use XML was made for, if you create a 'schema' for it, all applications can rightly use/modify the .conf file (provided that the app knows the schema) Yes, that's my understanding of XML as well. While I don't think XML is *necessary* for a .conf (bind.conf, for instance, is its own little world), it might be a worthwhile model to shoot for, as there are standardization channels for XML schema's that are bigger than the standardization channels for firewalls. Which means it would get LEAF's stuff out in front of more people quicker. Thoughts on this? -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/mailman/listinfo/leaf-devel
