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]
