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=1470&alloc_id=3638&op=click ___ 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] 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] 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? --- 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
[leaf-devel] OT: Job opening
Heyaz. Quick off-topic: my day-job is looking for a *nix IT guy, 650 area code, fulltime (sal, bennies, etc) if you're interested. I can pass your resume along. cheers, Scott --- 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[3]: [Leaf-devel] Dave Cinege
Ray: Akshally...I pinged the DNS servers that WHOIS reported a few minutes after Mike first emailed. They were not responding to pings. They are now, obviously. I think that's all that Mike meant when he said "not working". -Scott On Thu, 8 Aug 2002, Mike Sensney wrote: > Sorry. Didn't mean to cause offence. > > Thursday, August 8, 2002, 1:51:19 PM, Ray Olszewski wrote: > RO> At 01:23 PM 8/8/02 -0700, Mike Sensney wrote: > >>Thursday, August 8, 2002, 1:20:45 PM, Ray Olszewski wrote: > >> > >>RO> What do you mean by "DNS is not working"? My tests say it is working just > >>RO> fine. Excerpts below: > >> > >>RO> ray@waverly:~$ whois linuxrouter.org > >> > >>Whois only looks up the domain registration. It does not check to see > >>if DNS is working. > > RO> Mike -- I'm not stupid (not that stupid, anyway). Please read my entire > RO> prior message. After doing the whois check (to get the addresses of the DNS > RO> servers), I used "host" to check that actual names resolved, and ping'ed > RO> linuxrouter.org successfully. It's all there in what I posted. --- 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] 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: [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] Telnet script
Heh. Cool. The elegant things impress me these days. :) -Scott, who enjoyed the Ticker thread... On Mon, 28 Jan 2002, Mike Sensney wrote: > Here is an interesting little telnet client written in bash. > I haven't tried it so I don't know if it works... > Author: Tim Waugh at Red Hat. > > http://people.redhat.com/twaugh/ftp/pmt/pmt > ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Greetings from the wonderful world of NoCat...
S: Thanks for your patience with me on this. :) > > > 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. > > > > My impression was that the NoCatAuth process verified this > > login-password-MAC thing, and so would need to storesomething? > > True, but in a typical setup, none of this information is ever sent to > or stored on the gateway. That all happens over SSL to a (theoretically) > secure box elsewhere on the Internet. A large part of the design of > NoCatAuth is intended to preserve trust -- you don't give your password > to a gateway you don't necessarily trust, and the gateway doesn't trust > *you* to tell it who you think you are. Ah! This was one of my "other questions". :) There's another box (say, a RADIUS server) that the user authenticates with, then? Upon which...a go/no-go is delivered back to the gateway? I guess I thought the gateway/firewall box *was* this authentication server. > > 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? > > I'm afraid I don't understand your question, then. In a nutshell, > NoCatAuth severely limits a client's access to network services (in a > customizable fashion) until authentication occurs. What would we need a > TCP hack like LaBrea for? Well...not that I've done this...I was thinking that one way of preventing a user from getting onto the WLAN in a useful way (say, to attack another WLAN user that's behind the firewall) would be to make LaBrea (on the gateway) consume all of the subnet address space. Only after a user is authenticated would it "release" a specific IP address from the tarpit, and give out that address to the user in a DHCP lease. Again, just thinking out loud here: if the unused IP space was tarpitted, it'd seem to me more difficult for someone to spoof their way onto the WLAN and cause mischief. -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] Greetings from the wonderful world of NoCat...
Schuyler: Hello! Welcome to LEAF. I got about a dozen questions about NoCat (*great* name, btw), but I'll start with just three. Feel free to reply on-list or off-list or whatever you think is best: 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. 2. Any thoughts about HereUAre.com? I met with them last year down in Santa Clara, CA., though nothing came of it. 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. Again, welcome! Looking forward to your thoughts... cheers, Scott On Thu, 24 Jan 2002, Schuyler Erle wrote: > Hi, everyone. I've been invited to represent the NoCat development team > on this list. For a while, we had been developing an LRP derivative for > wireless projects called WRP. After putting some work into it, we ran > into the > fundamental limitations of the floppy media, especially considering that > our flagship project (NoCatAuth) was being developed in perl, of all > things, which would *never* fit on a floppy. > > A few things have revived my interest since then. OpenAP, in particular, > shows that there is a great need for free wireless network software in > embedded environments. Recent developments in uClibc have restored my > faith in the possibility of fitting useful linux applications in > floppy-sized distributions. Finally, demand for a C port of NoCatAuth > suggests that we revisit the notion of supporting a platform for it. > > So here we are. You can find all of our work at http://nocat.net. Right > now, WRP is kind of in disrepair, but I'll be looking shortly at > bringing it up to date with the latest busybox, uClibc, and linux > kernels, or perhaps merging functionality with other LEAF projects. Your > comments and advice are welcome. Please feel free to direct any > questions my way, especially those relating to wireless networking > distros. > > SDE > > ___ > 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] 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] 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 contribu
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
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
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
Matt: Sounds good! I haven't checked echoWall on Oxygen yet, so good going. BTW, please *do* feel free to "plagiarize" from what I wrote. It's a BSD license, and gawd knows I learned most of the basics from your rc.pf to begin with. :) Honestly I'm flattered that anyone's using it all besides me... Quick question: when you start it up, does it blow away what was there by default, or will there be conflict? cheers, Scott On Wed, 14 Nov 2001, Matt Schalit wrote: > > Packet Firewall - pfw >Version 0.94 > > New Package: pfw.lrp > > I'm posting today about the first release I'm making available > of my ipchains firewall, pfw. It's based on an ipfwadm firewall > that I wrote a couple of years ago, called rc.pf. > > ftp://ftp.schalit.net/pub/Pfw/ > > pfw is a simple shell script with a few other files > containing functions and variables that starts an > ipchains based, default DENY, set of firewall rules. > > It's meant for the following setup: > > internet --- LEAF --- hub/switch > eth0eth1 | | | | > lan computers > > where eth0 is a static ip or assigned by dhcp. > > pfw is Dachygen certified :-) > (It runs on Dachstein and Oxygen out of the box) > > If you get pfw.lrp and load it onto your LEAF router during > boot, it will install but not be running. To get help, type > pfw. To run the Packet Firewall, type pfw start. > > There's no files to edit unless you want to enable inbound > services. If so, you can use lrcfg or acfg and edit the > configuration file for optional services, /usr/local/etc/popts > > Simply type 'pfw' at a command prompt for more help. > Then give it a 'pfw start' to raise the firewall and > give yourself all the standard outbound access you > expect. > > Usage: pfw > > pfw is not as powerful as Echowall, in that it can not > handle dmz's or complex inbound services as easily. pfw was > developed without analyzing Echowall so as to not plagiarize > the work of others. pfw requires one to spell out the exact > rule for an inbound service, unlike Echowall's convenient labels, > but hey, it runs on Dachygen, which was one of the main goals. > > Best regards and thanks to Jeff N. and Paul B., > Matthew Schalit > > ___ > 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
Jeff: Akshally...no. :) Gatping wasn't released so much as it was wrapped into the echowall distribution for the purpose of brute-force updating the ARP cache. It doesn't have much utility beyond that...which is NOT to say that I wouldn't welcome any improvements that yield a version compatable with Oxygen. :) -Scott On Wed, 31 Oct 2001, Jeff Newmiller wrote: > On Wed, 31 Oct 2001, David Douthitt wrote: > > [...] > > > Breakpoint 1, send_ping (s=5, h=0x804ac58) at gatping.c:161 > > 161 buffer = ( char * ) malloc ( ( size_t ) ping_pkt_size ) > > ; > > (gdb) n > > 162 memset ( buffer, 0, ping_pkt_size * sizeof ( char ) ) > > ; > > (gdb) p buffer > > $1 = 0x804a398 "P\235\020@P\235\020@\020" > > (gdb) n > > 166 icp->icmp_type = ICMP_ECHO ; > > This trace doesn't seem to show the whole story. From the Scott's code: > > 157 buffer = ( char * ) malloc ( ( size_t ) ping_pkt_size ) ; > 158 memset ( buffer, 0, ping_pkt_size * sizeof ( char ) ) ; > 159 icp = ( struct icmp * ) buffer ; > > To my way of thinking, this code shows poor programming practice. It > should look something like: > > 157 icp = ( struct icmp * ) > calloc ( 1 >, ( size_t ) ( sizeof( struct icmp ) > + sizeof( PING_DATA ) ) ); > > The ping_pkt_size value is initialized in main, using an uninitialized > value for ping_data_size. The buffer size of 8 is too small, and the icp > (well, pdp) initialization code is overwriting memory beyond the buffer. > > Yecch. This was released? > > --- > 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
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] Echowall on Oxygen needs ipmasqadm and ipfwd
Matt: I *doubt* this will work, but have you tried lifting the ipfwd utility from an ES2B disk, and see if it just happens to work on a Oxygen disk? I was surprised myself when I found ipfwd on ES2B by default. You can find its source here: http://www.cag.lcs.mit.edu/~cananian/Projects/IPfwd/release/ -Scott On Fri, 26 Oct 2001, Matthew Schalit wrote: > Matthew Schalit wrote: > > > > I guess I need ipmasqadm and ipfwd for Echowall > > to work on Oxygen, but I can't find them in > > .lrp format. Are they compiled, David? > > > > Thanks, > > Matt > > > 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. > > 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] gatping segfault in Oxygen
David: Great, thanks! I'll update the package on my ftp site. BTW, have you been able to build the patched code on a glibc2.0 system? I used to use c0wz for my building, but can't now with Rick's situation... -Scott On Thu, 25 Oct 2001, David Douthitt wrote: > "Scott C. Best" wrote: > > > 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. > > In compiling gatping (0.2), I get lots of interesting things :-/ > > # make > gcc -s -O2 -Wall -o gatping gatping.c > gatping.c: In function `main': > gatping.c:106: warning: unused variable `buf' > gatping.c:104: warning: unused variable `j' > gatping.c:104: warning: unused variable `i' > gatping.c:143: warning: control reaches end of non-void function > gatping.c: In function `send_ping': > gatping.c:183: warning: control reaches end of non-void function > gatping.c: In function `make_target_list': > gatping.c:217: warning: implicit declaration of function `inet_aton' > gatping.c:218: warning: implicit declaration of function `inet_ntoa' > gatping.c:218: warning: assignment makes pointer from integer without a > cast > gatping.c:192: warning: unused variable `j' > gatping.c:191: warning: unused variable `buflen' > gatping.c:236: warning: control reaches end of non-void function > gatping.c: In function `search_arp': > gatping.c:248: warning: unused variable `testbuf' > gatping.c:246: warning: unused variable `m' > gatping.c:246: warning: unused variable `k' > gatping.c:246: warning: unused variable `j' > gatping.c:246: warning: unused variable `i' > gatping.c:288: warning: control reaches end of non-void function > gatping.c: In function `in_cksum': > gatping.c:295: warning: unused variable `answer' > gatping.c:307: warning: control reaches end of non-void function > > I created a patch to fix most of them; it is attached. I also created a > minimal Makefile to allow a make. > > I've also created a lrp/* directory for gatping (but not Echoware).. > > I've also created a gatping package - also included. ___ 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] gatping segfault in Oxygen
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 On Tue, 23 Oct 2001, Matthew Schalit wrote: > > Is there a way to code around gatping? > It's stopping me from deploying echowall. > If someone has a few minutes, make me debug > version of gatping I can run through gdb. > As usual, mine has no symbols. > > It's probably a library mismatch. I did > an ldd and it it found the three libs. I > forget which. Sorry it's not booted. I think > this latest Oxygen uses glibc-2.1.3 or something. > > Thanks, > Matt > > ___ > Leaf-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/leaf-devel > gatping2.tgz
Re: [Leaf-devel] Framebuffer & vnc
David: Point taken about Xvnc. But I was thinking more along the lines of redoing vncserver so that it wasn't a nice interface to Xvnc, but rather was a nice interface to sshd or telnetd. A VNC viewer/server uses the RFB protocol, so really the idea is to create an RFB-to-ssh or RFB-to-telnet interpreter. The benefit to supporting the RFB service is that you can now use any VNC viewer as, effectively, an ssh/telnet client. I still think it's groovy. Though I won't put aside my MindTerm stuff just yet. :) -Scott On Wed, 26 Sep 2001, David Douthitt wrote: > "Scott C. Best" wrote: > > > > 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? > > As I look at it here, vncserver is just a Perl program to provide a nice > interface to Xvnc. > > Xvnc requires libm and libdl, and is 1.3M in size uncompressed and > stripped. > > Sounds doable, as long as you have lots of memory and lots of disk > space. > > However, I'd question the usefulness of an X server running on a LEAF > router for admin purposes. Running X (Xvnc is just a Xserver with all > of the display stuff ripped out in favor of a network connection) - > Running X means that you'd have Xclients added in - which means lots of > X libraries, and all new binaries, such as rxvt, et al. > > I agree with Jeff - ssh works fine. > > If you want graphical administration, run a Xclient on the LEAF system > and display on a X server elsewhere. You could even, if you wanted, run > a vnc client on the LEAF box, displaying a remote display, where your > graphical administration tools run on the LEAF system are displaying. > > ___ > 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
Re: [Leaf-devel] ipchains redirect
Charles: Ah...I get it now, sure. Some vendors, I think LinkSys is one, call this "DMZ mode" where everything not explicitely directed somewhere is sent, by default, to a "DMZ host". Not sure if that host is masq'd or proxy-arp'd though, in those implementations. I wonder, though, what this would do as a last port-forward rule: ipmasqadm autofw -A -r tcp 1 65536 -h $DMZ_HOST Am not sure if autofw is parsed serially until a match is found, like ipchains does things. -Scott On Tue, 25 Sep 2001, Charles Steinkuehler wrote: > > > I haven't played with this much, but one of the things on the list of > stuff > > > to "play with one of these days" is using redirect to provide for an > > > 'internal server' machine, similar to the way the low-end firewall boxes > do. > > > I *think* this would work properly for everything from game servers to > VPN > > > access, although security in such a situation isn't the greatest > (although > > > it's not too bad if combined with port-forwarded DMZ rules). > > > > Not sure I follow: would you use redir instead of > > portfw rules? Or do you see it being used on the internal > > interface's input chain? > > No, the redirects go on the external interface input rules. > > The basic idea is to mimic the functionality of the firewall 'bricks' > available from Linksys, D-Link, Netgear, &c that provide for a single > internal "server" IP. Basically, any inbound packets that are not either > destined for local services or existing masqueraded connections, get > forwarded (redirected) to an internal system. I *think* this can be used > like a partial static-NAT, essentially splitting the single available IP > between several systems. > > The fundamental difference between doing this with a redirect and using > port-forwards, is the flexability of IPChains. I think the redirect rule > could send anything not dealt with by previous rules to a remote system > (even non-TCP/UDP traffic), providing a 'catch-all' port-forwarding I don't > think it's possible to implement with portfw. > > Charles Steinkuehler > http://lrp.steinkuehler.net > http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) > > > ___ 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
[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] 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. 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 > f
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] Updated packages
David: Heya. Quick question: what did arpwatch come in at? I understood it depended on libpcap, which was like 90kB. Or, is that lib already in Oxygen? thanks, Scott On Mon, 6 Aug 2001, David Douthitt wrote: > Some new or updated packages are now available at > http://leaf.sourceforge.net/pub/oxygen/packages/ : > > rain.lrp -- a packet injector tool > cold.lrp -- a packet analyzer > nmap.lrp -- a port scanning security tool > arpwatch.lrp -- a program to watch for changes in ARP addresses > scanssh.lrp -- look for versions of SSH running on other servers > tcpflow.lrp -- watch TCP network "flows" > > ___ > 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
Re: [Leaf-devel] bridge filter patch
David: Ah, perfect: bridge.sourceforge.net. Thanks! Just so I read you right: Oxygen has the bridge utils installed or not? -Scott -Scott > "Scott C. Best" wrote: > > > > 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. > > Couple of times :-) > > The patch you referred to is obsolete; there is a new set of bridge > utilities and a new bridge-firewall patch. The new utilities are also > being converted to work with 2.4; as I understand it the utilities are > done but the iptables/bridge-firewall patch is experimental. > > The bridgex utilities as done by Materhorn's Matthew Grant are obsolete; > now the utilities are being mantained by Lennert Buytenhek > ([EMAIL PROTECTED]). > > The info is at bridge.sourceforge.net; the current Oxygen development > image is set up as a bridge with a bridging 2.2 kernel with firewall > patches. I haven't excersized the bridge or the bridge firewall, but > the kernel works just fine (2.2.19). > > However, the bridge utils would not compile for glibc 2.0.7. No doubt > Matt's old bridgex would, but I haven't used that; the current bridge > utils I've packaged up and put into a *.lrp on the current Oxygen devel. > image. > > ___ > 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] vncviewer
David:
Very cool. I got VNC all over the place; hard to
live without it now. Always used it behind my LEAF box,
though, never on it.
Good going, though. :)
-Scott
On Mon, 25 Jun 2001, David Douthitt wrote:
> I recently got the vncviewer application put up into a package; I
> can't remember if it works in glibc 2.0 or 2.1 - I thought it worked
> in glibc 2.0, but I can't really remember.
>
> It does work in the 2.1 environment, and does well. It uses SVGAlib
> (included), and only needs the mouse in as much as the window manager
> needs a mouse.
>
> Since I've been trying out different window managers ("tiny" and
> "small" aren't just for floppy-disk systems :-) I've found that both
> pwm and ice have nice keyboard controls - pwm in fact was designed to
> have GOOD keyboard control.
>
> So with vncviewer on one end and pwm on the other, what more do you
> need? :-)
>
> Would anyone like to try it out?
>
> ___
> 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] 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=14&page_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
Re: [Leaf-devel] LRP & firewalls
Jacques: Good idea. Let me offer some candid ones about echowall: Pro: --- 1. Installs and deinstalls into ES without conflicting with ES's builtin scripts. 2. Has built-in support for 30 services which need specific port-forward and IPfwd settings. 3. Supports the above services for LAN machines's which have DHCP-assigned addresses. Ie, specifying a server is based on MAC-ID. 4. Automatically re-inits on DHCP lease renewal or PPPoE renewal. 5. Works out of the box with RFC-1918 external IP addresses. 6. Deny's without logging most of the background-radiation log fillers (like NetBIOS broadcasts, IGMP's, etc.) Cons: 1. No DMZ support. 2. Requires gatping subnet-scanning utility (~10kB). 3. No easy hooks for customization like builtin scripts. 4. No dancing mice. Hope that helps... -Scott On Wed, 20 Jun 2001, Jacques Nilo wrote: > It looks like the list of available firewalls for LRP is growing. My > understanding (correct me if I am wrong) is that we have, on the top of > the "standard" LRP script, 3 main firewall LRP packages available > echowall 1.2 > rcf 5.2 > seattle 4.1 > I think it would be really useful if we could come up with a list of > pros and cons for each package, some kind of benchmarking. > What do you think ? > Jacques > > > ___ > 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] 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
[Leaf-devel] echowall 1.1 released
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
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] Suggestion for improvement
Mike: I'm hardly the best judge of what's best for new users. But I'm very opinionated, if that helps! ;) My suggestion would be to add a "Get a LEAF Disk image Right Here, Right Now" right under the Affiliates section of the main page. Have that link take the user to the current Releases page where Eigerstein and Oxygen are active links to their sites (which I see Eigerstein is already!). On that release page, indicate under Eigerstein that it's "the best version for new users" (and that the latest version is ES2B), and under Oxygen indicate "the best version for LEAF developers". Lastly, on that Oxygen page, have a link that leads to the tar.gz's. Maybe even a "Image last updated on: Date" thing so people know how current things are. Just my two-coppers. Thanks! -Scott On Thu, 14 Jun 2001, Mike Noyes wrote: > Scott C. Best, 2001-06-13 23:25 -0700 > > 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, front¢er > >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, > I could remove the "Releases" menu item. Then make "EigerStein" and > "Oxygen" root menu choices. My preference is to add links to the releases > page. Let me know which way you think is easier for the new user. > > -- > 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] 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, front¢er > > 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
[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, front¢er 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] 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] 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
Re: [Leaf-devel] New Development Platform?
I think Charles' POV is a good one. If we know most of the core requirements of LEAF (eg, floppy-based, BusyBox, uLibC, .deb and .rpm support, easy cross-compiling, etc) it shouldn't be too hard to roll our own distro, and specify our own development platform as *seperate* things. I don't even think it be a bad idea. :) -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 name&email 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 draft?
I just wanted to split a quick hair. No affront to Pi, I just needed a handy quote to speak from: > My point: This is an LRP issue. Deal with it in LRP and try not to > generalize it into something larger. Abstaining from politics is politics > as well. > > Pi To be sure, McVeigh is not a "political" issue. It is an *ideological* issue. Dave-C's advocation of terrorism and violent extremism does not merit a comparison to even the most libertarian political agenda. It is not "politically correct" to condemn the actions of McVeigh, or the actions of the bombers in Lebanon, Jerusalem, Kenya, Tanzania, etc. Condemnation of terrorism is the flip-side of a near-universal love of life and respect for it. In the religion of my family, this mindset was known as simply "ethical". Which, as has been pointed out, has nothing to do with an operating system. Sorry for the soapbox'ing. -Scott ___ 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: 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
[Leaf-devel] ES3 suggestion
Charles: Heya. Since you suggested some enhancements to ES3 before it's released, I wanted to suggest some of my own. Little things, in specific regard to the firewall setup scripts. My intent is to eliminate some of the FAQ support questions that come up on the list. 1. First, when it refreshes, I'm not sure that it flushes the rules *and* the portfw's/autofw's. I could be wrong here, but I think it only flushes the ipchains rules and doesn't touch what was previously setup with ipmasqadm. 2. Given the increased popularity of ISPs giving out RFC-1918 private addresses with DHCP and then static NAT'ing them, I think part of the firewall setup which blocks the RFC-1918 address specifically should be dropped. 3. Many of the trojan's I've read about use blind-attacks where a response from the target isn't needed. So the attacker can spoof the return IP address, and they often choose from the reserve-address range (and use the "eleet" port of 31337). Anyhow. as per CIAC alert K-032, I think the following reserved address traffic should be blocked explicitly: $IPCHAINS -A input -i $IF_EXT -b -s 0.0.0.0/8 -j DENY $IPCHAINS -A input -i $IF_EXT -b -s 169.254.0.0/16 -j DENY $IPCHAINS -A input -i $IF_EXT -b -s 192.0.2.0/24 -j DENY $IPCHAINS -A input -i $IF_EXT -b -s 224.0.0.0/4 -j DENY $IPCHAINS -A input -i $IF_EXT -b -s 240.0.0.0/5 -j DENY $IPCHAINS -A input -i $IF_EXT -b -s 248.0.0.0/5 -j DENY 4. Lastly, at the end of the setup script, some "noise blocker" rules should be stuck in. This helps eliminate log file buildup (and the risk of resulting tooth decay...). Since they're at the very end, they not interfering with normal op's that would have been setup earlier. $IPCHAINS -A input -i $IF_EXT -d 255.255.255.255 -j DENY $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 137 -p tcp -j DENY $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 137 -p udp -j DENY $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 138 -p tcp -j DENY $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 138 -p udp -j DENY $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 67 -p udp -j DENY $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 68 -p udp -j DENY That's it. Please let me know what you think. Of course, I'd be willing to do the dirty work of editing the scripts and tar'ing them up for the inclusion in the new release. Just wanted to be sure the above has enough perceived value. cheers, Scott ___ 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
Re: [Leaf-devel] Something new
George: Can you send along an IP-Tables log to me? Thanks! I can Google for a BSD log too, make sure that works. -Scott On Mon, 21 May 2001, George Metz wrote: > On Sat, 19 May 2001, Scott C. Best wrote: > > > > > 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: > > > > BRAVO! > > We've been needing one of these for a while, good to see that someone's > stepped up and done it. > > Will it - either currently or eventually - handle IPTables output? It's > almost but not quite the same. > > -- > 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] 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
[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] 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
[Leaf-devel] Found my development platform.
Forgive the off-topic moment of levity but...Oooo. http://www.jp.playstation.com/linux/image/main.jpg I can see it now...a Missle Command like interface to zap incoming packets of questionable origin... :^) -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] 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] Kernel 2.4.x
George: Heya. Just wanted to confirm the 2.4.3 disk images available at your site: the disk images do *not* have the FTP patch, but the kernel tarball *does*. To get an LRP image with the patch, I should dig it out of the second tarball and roll it into the first. I get that right? 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". It then sets that file off, and then deletes it. Anyhow...the main script could pretty easily detect the environment (ipchains or netfilter), and "build" the run file in the right manner. Not just command and flag format, but the chain components as well -- so for ipchains, it'd add to the input chain and the forward chain, but for netfilter just the forward chain. 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. -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] IP-Masq'ing question
Jack: That's an interesting picture... > wireless areaInternet > | | > LRP LRP > | | > ---LAN--- If the LAN side interface on the right LRP box thought that its subnet was 0.0.0.0/0, then it would use ARP to find the MACID of anything that sent a packet from the wireless area. I could then setup proxy-ARP for the LAN side interface on the left LRP box to respond to anything that the right side ARP'd for... This will keep me up late. :) Thanks for the input. I totally agree I'll be better-off simply using DHCP, sure. The idea becomes more sellable (to the people I'm selling to) if I could make this fly too. Thanks again. -Scott > Both LRP's masq, both LRP's treat the top interface as default network. > Wireless LRP forwards everything into the LAN, masqing it as a single > IP. The hard part now is Internet access from the wireless LAN, because > you can't give the LRP two default routes pointing in two different > directions :-) Nor can you use the massively annoying "static routes > supernetting the whole Internet" trick because you're likely to get > registered addresses on the wireless net from time to time. Routing into > the LAN is easy, but routing from the wireless area to the Internet is > going to be challenging. > > I think you're better off changing people's IP addresses. > > -- > Jack Coates > Monkeynoodle: It's what's for dinner! > > On Sat, 21 Apr 2001, Jack Coates wrote: > > > I don't think it's going to work, then. "On the fly" reconfiguration > > would mean downing the interface everytime a new machine joined the > > wireless LAN, which would get really annoying to the users. But if you > > treat the LAN like the Internet (0.0.0.0/0) then you can't route to it. > > > > Actually, that could work, I think, with proxy arp. > > > > wireless int -> 192.168.254.254, bridging enabled > > def route forwards all traffic to eth1 > > masquerade as 192.168.1.1 > > eth1 -> 192.168.1.254 > > > > another LRP is the Internet gateway. Double-NATing is goofy as hell and > > will probably break something. > > > > > > > ___ > 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] 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
[Leaf-devel] IP-Masq'ing question
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
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: > > > > 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] Unified Embedded Platform Specification
Mike: I agree: a potentially watershed article. Quoting from a juicy bit: "Our objective is to encourage the adoption of a single unified embedded Linux 'platform' for embedded middleware and application software, so that software developers can rely upon the APIs being available in any ELC-endorsed embedded Linux and do not have to develop separate ports and validation for each embedded Linux distribution," according to ELC Chairman and CEO of LynuxWorks, Dr. Inder Singh. "This will help to establish Linux as a viable open, multi-vendor software platform alternative to other single- vendor embedded solutions, such as Windows CE, PalmOS or VxWorks and further accelerate the adoption of Linux in emerging post PC applications." Cool. This will make my echowall porting efforts go that much smoother. ;) -Scott On Wed, 18 Apr 2001, Mike Noyes wrote: > Everyone, > I belive this ELC announcement is significant. Opinions? > > Unified Embedded Platform Specification Established and > Promoted by Embedded Linux Consortium Board > http://www.embedded-linux.org/pressroom.php3#66 ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: CRC error on shorewall.lrp NO ERROR
Eric: I too still have problems grabbing .lrp's with Netscape. I recall someone posting an explanation and a fix to the LRP list early last year, but it didn't take. :) -Scott > I tried again a download with netscape (with shift, right click etc) > every time crc error, but after using internet explorer ( very unusual > for me ;) ) there was no problem at all > So the problem was at my side (don't understand why I have got a > problem with Netscape this time) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] just to confirm
Just wanted to confirm that ipmasqadm portfw can *only* handle tcp and udp right now behind the -P switch. Yes? If so...then to confirm: IPSec (even using *only* tunnel-mode ESP and not AH) and PPTP must terminate on a masq'ing firewall router right now. Or, is there some other way to forward IP protocols 47, 50 and 51. Also...has anyone built a redir.lrp or IPFwd.lrp package yet, or have I found something else to do? :) Thanks! -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Packaging
Jeff: heya... > > Jeff: > > Sorry you don't agree. > > Well, I am too. I feel like one of us is operating under some > misconceptions about how lrpkg or tar works. By continuing this > thread, I hope to grok your concern, or perhaps you will find your > concerns were not justified. I spent a while trying to figure why I was having this trouble un-tar'ing .lrp archives. And I think now it was my own dumb mistake. My best.com shell account is a 2.2.8-STABLE FreeBSD system. And, in a global .cshrc, the untar is aliases to "tar -xfP". So...my own fault for not using tar *directly*, rather than relying on a system alias -- the -P switch, of course, preserves absolute paths. Which generates some obvious errors when dncache.lrp (for examples) tries to create a directory in /etc. I still think David raised some great points in his last letter, but I wanted to indicate that my primary "user difficulty" with untar has been mitigated. Prior to this conversation, I was having (perhaps a common) difficulty looking at the contents of a package without actually installing it. My fault. -Scott ___ 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] 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 > AT&T 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] 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] Mirrors and upcoming Oxygen CDROM
Goerge: Got it from Tom on the LRP list, thanks. One of those days when amost everything I said out loud was dead wrong. :) But then, if this is what it takes to get a no-hitter outta my Red Sox, I can get used to it... -Scott On Thu, 5 Apr 2001, George Metz wrote: > On Tue, 3 Apr 2001, Scott C. Best wrote: > > > 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? > > Uh... Not presently. See Rick's message though. =) > > -- > 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] 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: Wow. So *this* is the sensation of being wrong. 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] 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] 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] new firewall package
I posted an update for echowall, 0.7, to my ftp server. I added a command option "scan" to the echowall command options, so it's easier to determine what the MACID's are for your intended servers. I also redid the README documentation so it's more suited for the beginner. Of course, any feedback appreciated. -Scott PS: ftp://ftp.echogent.com/EchoWall/echowall.lrp ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] new firewall package
Phew. Spent the day getting 'echowall.lrp' into shape. I know I know...there's no market for such things, but I hate half-finished endeavors. ;) Download at: ftp://ftp.echogent.com/EchoWall/echowall.lrp There's a README and md5 hash there in that directory too. Here's the "what makes echowall different" pitch: essentially, its aim is simplicity for the most entry level user. It fairly simple compared to Seawall: no DMZ support yet, and no QoS stuff. It presumes the user is using LRP as a masquerading firewall/router for a single Class-C address range. So, an "eighty-percent" solution, and a stepping-stone for my ICSA-certification endeavor. Also, it makes use of the MACID-based server identification so that, for example, you could setup a machine to be a webserver and *still* have that server get its IP-address via DHCP. In general, it's the genesis of what we spoke about in that thread from a few months ago, the "Grand New Firewall Paradigm" one. So, there's a boilerplate rules file, a user-customizable config file, and a main script which munges the two into an ipchains executable. The main script also lets you 'install' the firewall to setup at boot, or 'deinstall' it to sit idly. Anyhow, I think it's pretty good. If you could, please download it and kick the tires. Based on your guys' preliminary feedback, I'll decide whether to unleash it upon the main LRP list. Feedback welcome, of course, Thanks! -Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] Functional Admin -kudos
Yeah, no kidding. A thousand thanks, Mike. :) I've got you on my list of "owing a FineBottleofSomethingNice" should you ever be local to claim it. -Scott On Fri, 30 Mar 2001, Steven Peck wrote: > I have to go with David here and I think it deserves a mention. > > You are coordinating work on an Open Source project. You have been driving > force and crucial to installing and maintaining the website (you then found > a better solution and made it happen :getting help counts), coordinating and > writing documentation, doing the backend administrative work on getting a > CVS tree going, setting up/manageing multiple mail lists, ftp permissions, > Sourceforge updates and issues. Gathering a consensus on a variety of > disparate issues (color, theme, logo, style, directory structure, now CVS) > from a set of developers, and misc contributors of varying techinical levels > and interests.) You have 'brought' in folks (Pim) by making them aware of > what we are doing here. Regular updates/notification of Sourceforge issues. > Prompting for standards in Documentation, etc. > > This is a synopsis. > > I've been on paying contracts that were not as well managed/coordinated. > This is something that you can probably add to your resume in some fashion. > Heck, I'll give you a reference letter if you want. :) > > -- > Steven Peck [EMAIL PROTECTED] > http://leaf.blkmtn.org > > -Original Message- > From: David Douthitt > To: [EMAIL PROTECTED] > Sent: 3/30/2001 7:50 AM > Subject: Re: [Leaf-devel] Packages in PatchManager & CVS > > Mike Noyes wrote: > > > > David Douthitt, 2001-03-30 09:23 -0600 > > > I'm a barely > > functional admin for this project. > > I disagree vehemently! This project has better documentation than > I've seen almost anywhere else on Sourceforge; the PHPWebSite is > phenomonal. > > > ___ > 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
David: Hey, you win. The "sed '/regexp/d' file" works well. Thanks! Learn something new every day... Of who made this decision to handicap grep in LRP...it reminds me of the axiom "when the only tool you have is a hammer, you treat every problem like a nail". Heh. Back to re-writing my scripts now... -Scott On Fri, 30 Mar 2001, David Douthitt wrote: > "Scott C. Best" wrote: > > > [...] what would be the > > equiv of, say: "grep -v -i FOO /etc/passwd" ? > > sed '/[Ff][Oo][Oo]/d' /etc/passwd ___ 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] Different topic....
David: No kidding. That one came out of my WayBack machine... -Scott On Mon, 26 Mar 2001, David Douthitt wrote: > Scott C. Best wrote (about): > > > AT&T-NorthPoint To Curtail Service > > > > By BRUCE MEYERSON > > AP Business Writer > > NEW YORK (AP) via NewsEdge Corporation - > > > Public Access Networks Corp., a New York-based Internet services > > provider also known as Panix, [...] > > Now there's a name I haven't heard in a *VERY* long time. Would they be > classified as one of the nations oldest ISPs? Or would that be the > Well? ... > > ___ > 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
