Re: [Leaf-devel] [Leaf-user] Testing help needed
On 12/1/01 at 8:30 PM, Jack Coates <[EMAIL PROTECTED]> wrote: > On Sat, 1 Dec 2001, Charles Steinkuehler wrote: > > Or just grab a bunch of multi-port serial cards from > > e-bay, and setup a log-host using serial links. You can > > keep the log host disconnected from the net entirely (or > > more likely, keep it's interface un-configured, and > > bring it up/down manually if you ever need to network). > I saw this suggested in one of my paranoiac books (maybe > "Network Intrusion Detection Analyst's Handbook"?) -- but > they went one better by suggesting that you then copy > everything to lp on the loghost. Hook up an old dot matrix > printer with a Costco-sized case of paper, and you've got > court-admissible documentation of everything that happens > on your network. The recommendation I saw went even further - and suggested that any serial cable could be clipped so that the log host was receive only. There was also discussion on how to do this for network cables - and, as I remember, 10BaseT can't be done this way easily. -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-devel] [Leaf-user] Testing help needed
On 12/1/01 at 3:12 PM, Jack Coates <[EMAIL PROTECTED]> wrote: > On Sat, 1 Dec 2001, Tony wrote: > > If so, wouldn't it be easier/safer/more secure to > > forward them to an internal syslog server? > syslog-ng is supposed to fix a lot of these problems, but I've never > gotten around to taking a look at it. syslog-ng is very nice; it's set up to act as our central UNIX log server for the corporation. It has a unique ability in that it can use TCP instead of UDP - allowing it to be tunneled via ssh to an external server where it can then receive log messages from a syslog-ng located on that side. This allows you to receive messages through a firewall that blocks UDP syslog traffic (as it ought to). -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-devel] [Leaf-user] Testing help needed
On Sat, 1 Dec 2001, Charles Steinkuehler wrote: > > I like doing this, but there are concerns with doing it in anything less > > than a perfectly trusted environment: If your log host is unavailable, > > you're not logging; if malicious listeners are on the LAN, they can see > > everything you log (could be quite useful when scanning or rooting a > > server); if malicious users are on the LAN, they can flood the listening > > syslog server and prevent real logs from getting through. > > > > syslog-ng is supposed to fix a lot of these problems, but I've never > > gotten around to taking a look at it. > > Or just grab a bunch of multi-port serial cards from e-bay, and setup a > log-host using serial links. You can keep the log host disconnected from > the net entirely (or more likely, keep it's interface un-configured, and > bring it up/down manually if you ever need to network). > I saw this suggested in one of my paranoiac books (maybe "Network Intrusion Detection Analyst's Handbook"?) -- but they went one better by suggesting that you then copy everything to lp on the loghost. Hook up an old dot matrix printer with a Costco-sized case of paper, and you've got court-admissible documentation of everything that happens on your network. -- Jack Coates Monkeynoodle: A Scientific Venture... ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-devel] [Leaf-user] Testing help needed
> I like doing this, but there are concerns with doing it in anything less > than a perfectly trusted environment: If your log host is unavailable, > you're not logging; if malicious listeners are on the LAN, they can see > everything you log (could be quite useful when scanning or rooting a > server); if malicious users are on the LAN, they can flood the listening > syslog server and prevent real logs from getting through. > > syslog-ng is supposed to fix a lot of these problems, but I've never > gotten around to taking a look at it. Or just grab a bunch of multi-port serial cards from e-bay, and setup a log-host using serial links. You can keep the log host disconnected from the net entirely (or more likely, keep it's interface un-configured, and bring it up/down manually if you ever need to network). I've got a bunch of serial cards I picked up for about $5 each, just no time to make it go :( Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
RE: [Leaf-devel] [Leaf-user] Testing help needed
All valid points, I hadn't thought of those reasons. Thanks Tony > > On Sat, 1 Dec 2001, Tony wrote: > > > > > I guess I don't completely understand why you need a JFFS for > > something that under normal circumstances, isn't written to > > physically. If you have a crash/powerdown situation, with resumption > > of service, you just reload your image and continue to > > firewall/route. Would the JFFS be in play to preserve the logs? > > If so, wouldn't it be easier/safer/more secure to forward them to an > > internal syslog server? > > > > I like doing this, but there are concerns with doing it in > anything less > than a perfectly trusted environment: If your log host is unavailable, > you're not logging; if malicious listeners are on the LAN, > they can see > everything you log (could be quite useful when scanning or rooting a > server); if malicious users are on the LAN, they can flood > the listening > syslog server and prevent real logs from getting through. > > syslog-ng is supposed to fix a lot of these problems, but I've never > gotten around to taking a look at it. > > -- > Jack Coates > Monkeynoodle: A Scientific Venture... > > ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-devel] [Leaf-user] Testing help needed
On Sat, 1 Dec 2001, Tony wrote: > > I guess I don't completely understand why you need a JFFS for > something that under normal circumstances, isn't written to > physically. If you have a crash/powerdown situation, with resumtion > of service, you just reload your image and continue to > firewall/route. Would the JFFS be in play to preserve the logs? > If so, wouldn't it be easier/safer/more secure to forward them to an > internal syslog server? > I like doing this, but there are concerns with doing it in anything less than a perfectly trusted environment: If your log host is unavailable, you're not logging; if malicious listeners are on the LAN, they can see everything you log (could be quite useful when scanning or rooting a server); if malicious users are on the LAN, they can flood the listening syslog server and prevent real logs from getting through. syslog-ng is supposed to fix a lot of these problems, but I've never gotten around to taking a look at it. -- Jack Coates Monkeynoodle: A Scientific Venture... ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-devel] RE: [Leaf-user] Testing help needed
On Sat, 1 Dec 2001, Tony wrote: > Is it just me that's wondering, but why do you need a journaling > filesystem for a firewall that runs in RAM? I can understand (I > guess) if you are using it for a stripped down server application > like smtp server, or whateverbut I was under the impression that > a journaling filesystem's best attribute was crash recovery because > of the way it writes to disk. For a database app server, or smtp > server, I can see the benefits. But, again, as a router that loads a > minimal filesystem, why go to the bother? > > Later > > Tony > Two reasons -- the filesystem might not be on a RAM disk, or you might want the increased performance for certain applications. A mail relay built on LEAF would be the perfect example for the first, you'd put the mail spool on hard disk because using a RAM disk opens the possibility that you'll accept mail and lose power before forwarding it, which will cause the mail to be permanently lost, which is against the RFCs. An FTP repository full of small files would be a decent example for the second; ReiserFS is optimized for work with lots of tiny files, so you could increase performance by using it on the RAM disk. -- Jack Coates Monkeynoodle: A Scientific Venture... ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
RE: [Leaf-devel] RE: [Leaf-user] Testing help needed
Ah, I see. I thought perhaps I was missing something. > > The sort answer is because I wanted to play with it :) > I experiment like that also. Now I understand. I thought perhaps I had my head somewhere and missed a whole shift in direction with the filesystems. > There *are* a bunch of valid reasons to run a journaling > filesystem on a thin server, and I do use my disto's for more than just > firewalls, but for a router, JFFS is probably more important than something like > reiserfs or ext3. > And I agree. Like I said in my first post, if your machines are doing other things, especially with HD's, I see why you would want to use a JFS. I guess I don't completely understand why you need a JFFS for something that under normal circumstances, isn't written to physically. If you have a crash/powerdown situation, with resumtion of service, you just reload your image and continue to firewall/route. Would the JFFS be in play to preserve the logs? If so, wouldn't it be easier/safer/more secure to forward them to an internal syslog server? Again, I am not trying to critique, more just trying to understand why. Hell, if you saw some of the crap I implement just to try it, you'd think I _like_ frustration and extra work :-) Later, Tony ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Testing help needed
Am Samstag, 1. Dezember 2001 19:22 schrieb Tony: > Is it just me that's wondering, but why do you need a journaling filesystem > for a firewall that runs in RAM? I can understand (I guess) if you are > using it for a stripped down server application like smtp server, or > whateverbut I was under the impression that a journaling filesystem's > best attribute was crash recovery because of the way it writes to disk. > For a database app server, or smtp server, I can see the benefits. But, > again, as a router that loads a minimal filesystem, why go to the bother? You're not alone - I've been astonished too. AFAIK the advantages of journaling fs are related to the HD size, especially in case of an unclean umount and the necessery fschk. (This is at least what I've learned from IBM regarding HPFS and JFS) kp ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-devel] RE: [Leaf-user] Testing help needed
> Is it just me that's wondering, but why do you need a journaling filesystem for a firewall that runs in RAM? I can understand (I guess) if you are using it for a stripped down server application like smtp server, or whateverbut I was under the impression that a journaling filesystem's best attribute was crash recovery because of the way it writes to disk. For a database app server, or smtp server, I can see the benefits. But, again, as a router that loads a minimal filesystem, why go to the bother? The sort answer is because I wanted to play with it :) With the fact that reiserfs killed ext2 support as a module, and the user-space filesystem tools won't compile against the older glibc used, this is rapidly looking like the proverbial *bad idea*, so the whole experiment is being shelved until I start on a disto with a 2.2.4 kernel and modern libc... There *are* a bunch of valid reasons to run a journaling filesystem on a thin server, and I do use my disto's for more than just firewalls, but for a router, JFFS is probably more important than something like reiserfs or ext3. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
RE: [Leaf-user] Testing help needed
Is it just me that's wondering, but why do you need a journaling filesystem for a firewall that runs in RAM? I can understand (I guess) if you are using it for a stripped down server application like smtp server, or whateverbut I was under the impression that a journaling filesystem's best attribute was crash recovery because of the way it writes to disk. For a database app server, or smtp server, I can see the benefits. But, again, as a router that loads a minimal filesystem, why go to the bother? Later Tony > The existing 2.2.19 kernel trees won't correctly load some of > the filesystem modules, which appears to be an interaction between the > openwall patches and the reiserfs patch. > ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-devel] Re: [Leaf-user] Testing help needed
> > Since we have just overcome 2.2.19 issues with Sangoma wanpipe, which > > are all kernel version/re-compile related, we want to release the new > > wanpipe.lrp for state-of-the-state Dachstein-CD. > Fundamentally, there's nothing I'm aware of in 2.2.20 that's mandatory vs > 2.2.19, once the security patches have been applied to the 2.2.19 kernels > (which the latest 2.2.19-2 kernels have included), so I could go either > way... OK, I've just decided to stick with the 2.2.19 kernel tree. Changes from the existing kernel tree will consist of removal of the reiserfs patch, and an upgrade of the openwall patch to ow4, neither of which should cause too much trouble (I hope). This is the easiest thing for me to do, and sounds like it will help you out, as well. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Testing help needed
> [ snip ] > > We are un-clear as to your plans for 2.2.x kernels ;> I just want a recent 2.2.x kernel that works. > Since we have just overcome 2.2.19 issues with Sangoma wanpipe, which > are all kernel version/re-compile related, we want to release the new > wanpipe.lrp for state-of-the-state Dachstein-CD. If the wanpipe stuff breaks again with 2.2.20, let me know. > Please, share your thoughts and plans . . . The existing 2.2.19 kernel trees won't correctly load some of the filesystem modules, which appears to be an interaction between the openwall patches and the reiserfs patch. After a bit of testing, I determined the best way to fix this is to simply drop the reiserfs patch, since I don't really have time to re-compile all the kernels, and I REALLY don't have time to start crawling through kernel code. Anyway, since I was re-compiling everything anyway, I thought I'd try to use 2.2.20, but this is not mandatory. If there are problems with 2.2.20, I can easily drop back to 2.2.19. While I specifically mentioned the VPN_MASQ patches, I'd consider the Sangoma support important as well. Let me know if it's broken in .20, if you have time to test. Fundamentally, there's nothing I'm aware of in 2.2.20 that's mandatory vs 2.2.19, once the security patches have been applied to the 2.2.19 kernels (which the latest 2.2.19-2 kernels have included), so I could go either way... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Testing help needed
Charles Steinkuehler wrote: > > As part of getting a final floppy version released, I have created (yet > another) new kernel tree . > > http://lrp.steinkuehler.net/files/kernels/2.2.20-1-small/ > http://lrp1.steinkuehler.net/files/kernels/2.2.20-1-small/ > http://lrp2.steinkuehler.net/files/kernels/2.2.20-1-small/ > > The existing kernels have problems with reiserfs, which combined with the > openwall patches seems to cause most loadable filesystem modules to fail > with unresolved module dependencies. Since I have to re-compile all the > kernels anyway, I'm making the jump to 2.2.20 at the same time. [ snip ] We are un-clear as to your plans for 2.2.x kernels ;> Since we have just overcome 2.2.19 issues with Sangoma wanpipe, which are all kernel version/re-compile related, we want to release the new wanpipe.lrp for state-of-the-state Dachstein-CD. Please, share your thoughts and plans . . . -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Testing help needed
As part of getting a final floppy version released, I have created (yet another) new kernel tree . http://lrp.steinkuehler.net/files/kernels/2.2.20-1-small/ http://lrp1.steinkuehler.net/files/kernels/2.2.20-1-small/ http://lrp2.steinkuehler.net/files/kernels/2.2.20-1-small/ The existing kernels have problems with reiserfs, which combined with the openwall patches seems to cause most loadable filesystem modules to fail with unresolved module dependencies. Since I have to re-compile all the kernels anyway, I'm making the jump to 2.2.20 at the same time. Anyway, I'm completely dropping reiserfs with the 2.2.20 kernels (not to fear...it's now in the released 2.4 kernel tree, so it will be back in the next 2.4 based release), and I've updated some of the kernel patches. The VPN_MASQ kernel patch, however, has not been updated for 2.2.20, and in fact is the same patch used for 2.2.18. The patch applied with some offsets, but everything seemed to compile cleanly. Can anyone actually running a masqueraded VPN setup try to test this and let me know if the modules actually work? Other possible problem areas include: - eicon ISDN drivers didn't compile cleanly...they had problems with undeclared calls to memset...a simple addition of #include "linux/string.h" cured this, but I don't know if the modules will acutally work. Anyone got one of these things they're running LRP/LEAF on? - For some reason, the drivers from Intel (e100.o & e1000.o) are no longer compiling, so I just left them out...use the ones from the normal kernel tree or D Becker, which are included. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
