From martinson.jacob at gmail.com Tue May 2 16:18:40 2006 From: martinson.jacob at gmail.com (jacob martinson) Date: Tue, 2 May 2006 15:18:40 -0500 Subject: Darc - config file In-Reply-To: <4456963D.3080902@planetdiscover.com> References: <44299B4A.2030501@planetdiscover.com> <44539687.5050507@planetdiscover.com> <5b7479590604290941x12866335p3d60870e6fef15c4@mail.gmail.com> <445397C8.5090308@planetdiscover.com> <5b7479590604290946y37c3ca3dl85a9c5a3344ce7e3@mail.gmail.com> <4456658B.2010409@planetdiscover.com> <5b7479590605011312x484fdebepf2f05c2ca3b2f208@mail.gmail.com> <445682B9.8080606@planetdiscover.com> <5b7479590605011546q22014e9fp2532744b5f635c6e@mail.gmail.com> <4456963D.3080902@planetdiscover.com> Message-ID: <5b7479590605021318v5a4cd90cl41572b03e984d6e@mail.gmail.com> Ted, I just put another version out there. I didn't add code to make sure the local binaries are executable (there are a number of different binaries darc runs on the management system and I'm not in a position at the moment to make all the changes to check everywhere) but I did improve the error reporting so instead of getting the ambiguous message you saw earlier you'll see this: 'Error running aide in compare mode' nice: /usr/local/bin/aide: Permission denied or whatever the details are for the particular problem that was encountered. I'm hoping that will at least reduce the amount of time it takes to track down the problem. I thought that was how it worked before but I had made a mistake in my code that prevented the detailed errors from coming through. Also, I added a new option... --only-email-failures This causes the email reports to only be sent if one or more hosts failed a check or was unable to be checked for some reason. I didn't include that option initially because I think it could give the admin a false sense of security. If he gets used to not seeing reports come in he won't know if something breaks that causes reporting to not work - like the mail server getting owned for instance. But... to each his own... it wasn't difficult to add and you've been so much help I couldn't say no =) I also changed the name of the sample config from config.py to sample_config.py so you *should* be able to just unpack the binaries on top of the old ones to upgrade. Also, I changed the default recipient list so my gmail account isn't in there. Thanks for that one =) -jacob On 5/1/06, Ted M Harapat wrote: > Ah, I never tried the CLI output. Now that I look I see so much good > info in there. > > Excellent point about the ssh key changing. One forgets that there is a > purpose to alert you of a change after so long. > > I am surprised how fast it runs the check. I have 61 hosts and it takes > a 61-62 seconds to check them all. > > Everything is looking good. Thanks again for the changes. > > -ted > > > jacob martinson wrote: > > my responses are inline... > > > > On 5/1/06, Ted M Harapat wrote: > >> Jacob, > >> > >> Okay, I'm up to 0.3.49 now. > >> > >> I didn't see an obvious way to do the upgrade so I just copied the .py > >> files and then stole the part with the defined hosts in the config.py > >> file and put it in the new one. I ran it once before pulling your email > >> out as the recipient so you might have gotten one of my reports. (You > >> ought to change it to a bogus domain at least so you don't get lots of > >> these from future users each night.) > >> > > > > hahaha, excellent suggestion, thanks =) > > > >> I don't quite understand the ssh key auto-population. At least I've > >> never heard of anything that did it. But next time a host changes I'll > >> be thankful its in there. > > > > This won't pick up a *changed* host key, it just stores it if it isn't > > already there. You don't want it to automatically swap out a changed > > key because a changed key is the only indicator you're going to get if > > someone is running a man in the middle attack on you. > > > >> One gotcha you need to add is to tell them to make sure the aide binary > >> is executable on the Management system. I didn't have that and I was > >> getting countless "Error running aide in compare mode" errors. Took me a > >> bit to realize that the local binary was why. > > > > I will add a check to automatically try to chmod +x the binaries if > > they're not exectuable and report a more detailed error if the chmod > > is unsuccessful. > > > >> > >> Once done, I got a clean report from my hosts then added a > >> evil_guy_shell.sh script and that was picked up and displayed perfectly > >> in the email report. So it worked beautifully! I love the new report > >> format - good enough to give a non technical person (manager) an email > >> copy without touch up. Thanks for the work on here. It worked before but > >> now it really shines. > >> > > > > thanks, that was my goal =) > > > >> Is the only way to update the database to run the "--update-all" flag? I > >> saw that in the new version notes but not in the other docs. Or did I > >> skim it too fast? > > > > you can update an individual host's baseline with the -u option - > > > > ./darc.py -c config.py -u hostname > > > > it's in the command line help output - > > > > -uUPDATE_HOST, --update=UPDATE_HOST > > Update baseline database with the contents of > > the most > > recent archive database (based on timestamped > > directory > > and filename paths). Used when you want to > > acknowledge > > and accept the filesystem changes in the last > > report > > for a particular host. > > > >> > >> Perhaps a feature to add (unless I missed it already being there), is to > >> not send a report if all the hosts passed. I can filter it out on the > >> mail client but it might be a nice "quiet" option. > >> > > > > i'll see what i can do =) > From ted.harapat at planetdiscover.com Thu May 4 10:55:25 2006 From: ted.harapat at planetdiscover.com (Ted M Harapat) Date: Thu, 04 May 2006 09:55:25 -0500 Subject: Darc - config file In-Reply-To: <5b7479590605021318v5a4cd90cl41572b03e984d6e@mail.gmail.com> References: <44299B4A.2030501@planetdiscover.com> <44539687.5050507@planetdiscover.com> <5b7479590604290941x12866335p3d60870e6fef15c4@mail.gmail.com> <445397C8.5090308@planetdiscover.com> <5b7479590604290946y37c3ca3dl85a9c5a3344ce7e3@mail.gmail.com> <4456658B.2010409@planetdiscover.com> <5b7479590605011312x484fdebepf2f05c2ca3b2f208@mail.gmail.com> <445682B9.8080606@planetdiscover.com> <5b7479590605011546q22014e9fp2532744b5f635c6e@mail.gmail.com> <4456963D.3080902@planetdiscover.com> <5b7479590605021318v5a4cd90cl41572b03e984d6e@mail.gmail.com> Message-ID: <445A15DD.7010609@planetdiscover.com> Jacob, I completely agree about not seeing positive email responses being a bad practice. Initially I thought it would be more convenient to try to cut back the amount of email reports I get each morning but I came to the same conclusion that you just brought up. I'll probably end up filtering the ones that have "0 failed" and "0 unchecked" to a temporary folder where I examine the mail each day before sending it to the final trash folder. I can see people using it though. Especially the people who think security is more of a nuisance rather than a necessity and don't want to see anything about the subject if its not a problem. -ted jacob martinson wrote: > Ted, > > I just put another version out there. I didn't add code to make sure > the local binaries are executable (there are a number of different > binaries darc runs on the management system and I'm not in a position > at the moment to make all the changes to check everywhere) but I did > improve the error reporting so instead of getting the ambiguous > message you saw earlier you'll see this: > > 'Error running aide in compare mode' > nice: /usr/local/bin/aide: Permission denied > > or whatever the details are for the particular problem that was > encountered. I'm hoping that will at least reduce the amount of time > it takes to track down the problem. I thought that was how it worked > before but I had made a mistake in my code that prevented the detailed > errors from coming through. > > Also, I added a new option... --only-email-failures > > This causes the email reports to only be sent if one or more hosts > failed a check or was unable to be checked for some reason. I didn't > include that option initially because I think it could give the admin > a false sense of security. If he gets used to not seeing reports come > in he won't know if something breaks that causes reporting to not work > - like the mail server getting owned for instance. But... to each his > own... it wasn't difficult to add and you've been so much help I > couldn't say no =) > > I also changed the name of the sample config from config.py to > sample_config.py so you *should* be able to just unpack the binaries > on top of the old ones to upgrade. > > Also, I changed the default recipient list so my gmail account isn't > in there. Thanks for that one =) > > -jacob