I looked through the OpenBSD ports and packages list and didn't find anything, so I think I will use OpenBSD just for a firewall. SSH is only necessary if I give up my monitor and would only be from within the firewall.
Ben [EMAIL PROTECTED] 6/29/2002 8:13:48 PM, Benjamin Huot <[EMAIL PROTECTED]> wrote: >I'm fine with the UNIX terminal. I can do simple things on it like file management. >As my Pentium only has 48MB >RAM it cannot handle GNOME or KDE or even Blackbox very well. MySQL for example makes >more sense from the >command line. > >I am trying to think of what programs I want to use on nix - I'm thinking of MySQL, >but maybe there are some >other good command line programs I could use. I'm not going to do networking with it >though. I may want to share >files with Windows though so if I could do an FTP within the firewall or SAMBA within >the firewall that would be >nice. I tried networking with SAMBA over LAN before but I couldn't get it to work. > >Ben >[EMAIL PROTECTED] > >6/29/2002 3:04:43 PM, Jacob Meuser <[EMAIL PROTECTED]> wrote: > >>On Sat, Jun 29, 2002 at 10:08:04AM -0700, Ben Barrett wrote: >>> I agree, it'a fabulously direct and efficient to grep the logs directly, >>> but one must be comfortable witht he command line (and would likely be >>> spending significant other time on it (the CLI)) in order to do such >>> things beyond repetition of examples (true, examples are how one starts) >> >>Uhh, we're talking about UNIX-like OSes here, right? Why would >>one *NOT* want to be comfortable with the CLI? If I can use grep, >>sed, my shell and all the other wonderful *standard* tools, I can do a >>lot more than what I can do with snort. >> >>> but since this case pertains to a separate firewall box, I assume that >>> Ben Huot simply wants to "check in on it" from time to time... >>> Snort is a great tool that I think is better than tcpdump (sorta like a >>> big brother or maybe a fast-growing grandchild) -- I see some auxillary >>> tools in contrib there: snortreport, demarc, and idscenter... >>> Since he's going to be working on his windows laptop, this might be >>> interesting: >>> >>> http://www.snort.org/docs/writing_rules/chap2.html#tth_sEc2.5.4 >>> 2.5.4 Alert_smb >>> This plugin sends WinPopup alert messages to the NETBIOS named machines >>> indicated within the file specified as an argument to this output >>> plugin. >>> (this is a new feature, and snort must be compiled with the right >>> option) >> >>Alert for what? That the packet filter is particularly busy? This >>is a home firewall. He doesn't have thousands of users. >> >>> There is also a program called SnortSnarf (by a company called >>> SiliconDefense that doesn't seem available on the web), but I did find >>> (thanx google) someone's installation to look at: >>> http://host4.rpi.wulimasters.net/snort/ >>> I like this, but Snort really shines as a NIDS (network-based intrustion >>> detection system)... having a firewall with good packet filtering is >>> only PART of the "secure" feeling we're going for: Using snort also on >>> the (windows laptop, in this case) workstation(s) as well as on the >>> gateway is the way to go >> >>Most IDS literature I've read says to put the IDS on a separate >>machine. Why? Because the gateway is the most likely machine to >>get compromised. That means all your IDS info is now untrustable, >>and that's all the IDS is good for, to know what has already happened. >> >> -- if there is ever any vulnerbility on the >>> workstation, say from web browsing or an email virus, that creates an >>> outgoing connection, your firewall becomes pretty USELESS. This is >>> because for a firewall to be "usable" and not crippling-to-function, it >>> must allow for any outgoing connections (even if on a strange port, who >>> knows what network-based game or file-sharing network you might try). >> >>What? Properly designed stateless packet filters only allow *responses* >>back in. How does that make the packet filter useless? >> >>There're blinking lights on hubs and switches for a reason ... so you can >>see if there's traffic. If you're not doing something to create >>traffic and the lights are blinking, hello, HELLO!!! >> >>Furthermore, a packet filter can just as easily block outgoing packets >>as it can incoming. It does not make it "crippling-to-function" to >>restrict the outgoing connections. >> >>The types of problems you describe are not really software problems, >>they are policy problems. A firewall isn't designed to stop people from >>using Outlook. That's what management is for. >> >>> Using an IDS is a good idea to keep an eye on things... the workstation >>> can send it's snort alerts to the firewall machine (running a >>> host-configured snort installation) to be logged, or better yet, dumped >>> into a database. There are several frontends for analysis of snort >>> databases (I think ACID is the most popular and best-supported). >>> For you hardcore users out there, you ought to be thinking of your SQL >>> queries rather than a silly grep of a flat log file!! : ) >>> That's some WAY advanced correlation capabilities, woo-hoo. >>> Here's where I found some ACID screenshots, lookin good: >>> http://www.andrew.cmu.edu/~rdanyliw/snort/acid_screencaps.html >>> >>> This is cool too: >>> >>> ACID has the ability to analyze a wide variety of events which are >>> post-processed into its database. Tools exist for the following formats: >>> * using Snort (www.snort.org) >>> o Snort alerts >>> o tcpdump binary logs >>> * using logsnorter ( www.snort.org/downloads/logsnorter-0.2.tar.gz) >>> o Cisco PIX >>> o ipchains >>> o iptables >>> o ipfw >>> Cool, huh? >> >>Maybe, if I worked at a large facility and didn't trust that management >>or the other admins knew what they were doing, or if "trusted" >>users weren't really trustworthy. >> >>> In regards to leaving a port (like 22 for ssh) open to the outside: >>> Ben Huot will have to be his own interpretter. Do you want to be able >>> to check on your DSL's security status while away from home? >>> If so, SSH probably the best port you could leave open -- you can >>> forward web requests through it if need be (I sometimes tunnel a web >>> proxy port over ssh for an ad-hoc web VPN, it works well on broadband, >>> even counting windows and OS X)... but if you want to get a lot of >>> alerts and see just how much port-scanning and exploit-searching happens >>> on broadband, run apache on port 80 with nothing but your ACID >>> frontend... I would bet money that your apache (if up to date) install >>> will never ever provide any vulnerability, letting the baddies in; but >>> it will give you access to your logs and providing an open port 80 will >>> show you how bad things would be if you ran an older IIS ; ) >> >>That's, at best, sketchy advice. That's like saying, "Hey, go punch >>that dog. Don't worry, he hasn't been known to bite." >> >>Hello, apache-scalp.c was out before the patches, HELLO!!! >> >>> Jacob, if you didn't catch it above, try some post-processing of your >>> logs, after which point you can use a variety of analysis tools... >> >>Yeah, I use tcpdump and grep all the time. >> >>I'm sorry, but I think security come from diligently following known >>"best practices" and using known and well written software ... basically >>just using common sense, not the latest and greatest logger (which is only >>useful *AFTER* an intrusion occurs). >> >>I'd much rather spend time looking for mistakes in my implementations, >>or ways to harden them, or simply get a greater understanding of them >>than install yet another piece of software that I will also need to make >>sure I'm using properly (and which has a less than stellar security >>history and is of limited use). >> >>Security comes from doing things right. In other words, it's a constant >>learning practice, because the definition of right is always changing. >> >>Adding more softare only adds to the burden. >> >>-- >><[EMAIL PROTECTED]> >> >Landscapes of the Mind >[EMAIL PROTECTED] > Landscapes of the Mind [EMAIL PROTECTED]
