[Snort-users] pulledpork question: do not nuke tarball post-processing and some feature requests

Tony Robinson deusexmachina667 at ...11827...
Sat Dec 8 15:50:09 EST 2012


Responses also inline. Also, thanks for the response on a Saturday.

On Sat, Dec 8, 2012 at 1:44 PM, JJC <cummingsj at ...11827...> wrote:

> Inline....
>
> On Sat, Dec 8, 2012 at 10:32 AM, Tony Robinson
> <deusexmachina667 at ...11827...> wrote:
> > Hey fellas,
> >
> > This is a question regarding pulledpork. I would e-mail JJ directly, but
> I
> > feel this may be beneficial to future users, so I want to ask here
> (besides,
> > one of you may know the answer to this or may have done this yourselves!)
> >
> > I'm working on autosnort and dropping in pulled pork integration. I've
> got
> > it to work properly, however I'm running into a problem where it is
> working
> > *too* well - pp nukes its working directory after running. I want the
> > tarball in the directory for my script to extract the config files out of
> > the tarball's etc directory (except sid-msg.map and snort.conf --
> > sid-msg.map is obvious, but I pulled snort.conf directly from
> labs.snort.org
> > and do not want it overwritten during the install). I've got a
> work-around
> > in place that I think will work for now. I read from the pp mailing list
> > that the script *sort of* supports processing from local rule tarballs
> so I
> > wanted to try the following as a work-around:
> >
> > 1) call pulled pork with -g to just grab the rules tarball.
> > 2) use my script to untar the tarball, grab the conf files and copy them
> for
> > the snort install
> > 3) call pulled pork again with the -n option in addition to other
> options I
> > want for rule processing. let pulled pork work its magic here
>
> The tarball should remain after PP is done processing, it only nukes
> it's working directory.  This is how the process local tarball
> workaround works.. simply  place the tarball in the path that you have
> pp defined to store it then run pp and tell it not to check the
> hash... make sense?


got it.

>
> >
> > If you are open for pulled pork feature requests however, I would like to
> > request the following:
> >
> > 1) an option to not nuke the rules tarball post-download
> > --I can see the subroutine where the temp directory is cleaned out,
> would it
> > be as simple as defining a variable for do not clean, a flag for do not
> > clean and adding in the 'if' statement where the routine is called, to
> run
> > cleanup only if this flag is NOT present? Perl isn't my native language,
> but
> > if its as simple as that, I would be willing to try and write this
> > functionality in, test it out and contribute it.
>
> As noted above, the tarball should remain in the temp path that you
> defined for it to write said tarball to.  If it's disappearing then
> there is another process doing this.
>

yeah found out what my problem is. my script is removing the files out of
/tmp after failing to untar the rule tarball. It was trying to untar the
md5 file instead. Afterwards, I have a cleanup routine that is removing
everything out the /tmp directory.

Hurr. I program gud.

Anyhoo, I've fixed that issue and will be doing some testing to make sure
it works properly.


> >
> > 2) an option to copy the config files out of the rule tarball's 'etc'
> > directory (with the exception of sid-msg.map (and in my case,
> snort.conf))
> > -I know how to do this in bash:
> > -untar the tarball
> > -use a for loop to copy the files from /tmp/etc directory listing piped
> to
> > grep -v used to remove snort.conf and sid-msg.map from the directory
> > listing, to the defined etc directory for the actual snort installation
> > -- Have no clue where to even start for doing this in Perl.
> > -Is this considered out of scope since it isn't strictly rule management?
>
> Something similar to this was recently proposed, but more as a config
> file comparison.. PP runs and spits out information about differences
> between the snortrules tarball snort.conf and your current version.
> Though there is no formal feature request it is an interesting
> use-case.. feel free to add the feature request in the bug tracker at
> pulledpork.googlecode.com
>
>
Will do. Thanks for hearing me out.


> >
> > Cheers,
> >
> > DA
> >
> > --
> > when does reality end? when does fantasy begin?
> >
> >
> ------------------------------------------------------------------------------
> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> > Remotely access PCs and mobile devices and provide instant support
> > Improve your efficiency, and focus on delivering more value-add services
> > Discover what IT Professionals Know. Rescue delivers
> > http://p.sf.net/sfu/logmein_12329d2d
> > _______________________________________________
> > Snort-users mailing list
> > Snort-users at lists.sourceforge.net
> > Go to this URL to change user options or unsubscribe:
> > https://lists.sourceforge.net/lists/listinfo/snort-users
> > Snort-users list archive:
> > http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users
> >
> > Please visit http://blog.snort.org to stay current on all the latest
> Snort
> > news!
>



-- 
when does reality end? when does fantasy begin?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20121208/7135d2b2/attachment.html>


More information about the Snort-users mailing list