Rooted Your {0x2E} Com

Changed Paths:
    Modify    /trunk/pulledpork.pl

Added error handling for incorrect snort binary path

Changed Paths:
    Modify    /trunk/doc/README.CHANGES
    Modify    /trunk/etc/pulledpork.conf
    Modify    /trunk/pulledpork.pl

Automatic VRT rules tarball naming (based on Snort -V)

now that we have the initial modifysid stuff I'll spend some time later this week converting my oinkmaster setup to use pulledpork. Then I'll know if what we have is adequate to my needs :) Oh, and thanks :)

Changed Paths:
    Modify    /trunk/README
    Modify    /trunk/etc/modifysid.conf
    Modify    /trunk/pulledpork.pl

Updated the README file Updated the modifysid.conf file for better accuracy Updated the help output

Committed rev 146 that contains initial modifysid code, please checkout and test at your leisure.
Status: Started

Changed Paths:
    Modify    /trunk/doc/README.CHANGES
    Add    /trunk/etc/modifysid.conf
    Modify    /trunk/etc/pulledpork.conf
    Modify    /trunk/pulledpork.pl

Added modifysid.conf Added modifysid capability (-M)

So, does the existing codebase meet your needs now or?

Ah, the MD5s are in a sep directory! OK :)

I'm happy to write some blurb for the start of the conf file with use cases etc. Drop me a line when you are ready to go... :) I'll also make some notes as I move stuff across from oinkmaster and make up a transition doc...

I had Jonkman setup a directory that contains MD5 values for the ET stuff.. so I check that against the MD5 of the currently downloaded file.. if it matches no download.. if it doesn't.. then we download..

Yeah, I have already started on the modify code.. it will be a separate config file. As to the help, I was thinking docs and use cases possibly

Just BTW I assume your pref would be to have a separate file for the arbitrary modification along side the other conf files? I just might get a few hours to look at adding code to do the mods using the existing stuff as a template.

OK -- that about covers it -- my script pulls some other feeds of addresses and builds rules from them but that is out of scope for PP. How do you handle the ET rules? I see there is an rules-mdr.txt file there with the same timestamp of the tarball. Since they change almost every day then I never bothered with checking if the file had changed. If I am going to run PP several times then it is very much an issue :)

happy to help -- not sure what you need? Please be more explicit :-P :)

Oh, and yes, the code to allow for multiple simultaneous ruleset downloads was committed to svn a few weeks ago..

rulestate change and basic regex (not to modify the rule itself yet, that's coming) exists.. perhaps some better documentation is in order... wanna help :-P
Labels: -Type-Defect Type-Enhancement

The system kinda works like this already... it will not download each run unless the md5sum has changed (this is the default function) you can also specify the -n runtime flag to perform only rule tuning / rules file creation operations. What is the precise use-case for this.. do you intend on using your already pre-packaged rules file or just ET / VRT rulesets but not downloading again?
Labels: -Type-Defect Type-Enhancement

The oinkmaster config file has a pretty good list of use-cases that rule-modification should handle. I agree with Russell that src/dst modification is at the top of the list, but a generic regex-like interface is very useful in enabling less-common but still useful modifications. Oinkmaster examples-list: # Example to enable a rule (in this case SID 1325) that is disabled by # default, by simply replacing leading "#alert" with "alert". # (You should really use 'enablesid' for this though.) # Oinkmaster removes whitespaces next to the leading "#" so you don't # have to worry about that, but be careful about possible whitespace in # other places when writing the regexps. # modifysid 1325 "^#alert" | "alert" # You could also do this to enable it no matter what type of rule it is # (alert, log, pass, etc). # modifysid 1325 "^#" | "" # Example to add "tag" stuff to SID 1325. # modifysid 1325 "sid:1325;" | "sid:1325; tag: host, src, 300, seconds;" # Example to make SID 1378 a 'drop' rule (valid if you're running # Snort_inline). # modifysid 1378 "^alert" | "drop" # Example to replace first occurrence of $EXTERNAL_NET with $HOME_NET # in SID 302. # modifysid 302 "\$EXTERNAL_NET" | "\$HOME_NET" # You can also specify that a substitution should apply on multiple SIDs. # modifysid 302,429,1821 "\$EXTERNAL_NET" | "\$HOME_NET" # You can take advantage of the fact that it's regular expressions and # do more complex stuff. This example (for Snort_inline) adds a 'replace' # statement to SID 1324 that replaces "/bin/sh" with "/foo/sh". # modifysid 1324 "(content\s*:\s*"\/bin\/sh"\s*;)" | \ # "${1} replace:"\/foo\/sh";" # If you for some reason would like to add a comment inside the actual # rules file, like the reason why you disabled this rule, you can do # like this (you would normally add such comments in oinkmaster.conf # though). # modifysid 1324 "(.+)" | "# 20020101: disabled this rule just for fun:\n#${1}" # Here is an example that is actually useful. Let's say you don't care # about incoming welchia pings (detected by SID 483 at the time of # writing) but you want to know when infected hosts on your network # scans hosts on the outside. (Remember that watching for outgoing # malicious packets is often just as important as watching for incoming # ones, especially in this case.) The rule currently looks like # "alert icmp $EXTERNAL_NET any -> $HOME_NET any ..." # but we want to switch that so it becomes # "alert icmp $HOME_NET any -> $EXTERNAL_NET any ...". # Here is how it could be done. # modifysid 483 \ # "(.+) \$EXTERNAL_NET (.+) \$HOME_NET (.+)" | \ # "${1} \$HOME_NET ${2} \$EXTERNAL_NET ${3}" # The wildcard (modifysid * ...) can be used to do all kinds of # interesting things. The substitution expression will be applied on all # matching rules. First, a silly example to replace "foo" with "bar" in # all rules (that have the string "foo" in them, that is.) # modifysid * "foo" | "bar" # If you for some reason don't want to use the stream preprocessor to # match established streams, you may want to replace the 'flow' # statement with 'flags:A+;' in all those rules. # modifysid * "flow:[a-z,_ ]+;" | "flags:A+;" # Example to convert all rules of classtype attempted-admin to 'drop' # rules (for Snort_inline only, obviously). # modifysid * "^alert (.*classtype\s*:\s*attempted-admin)" | "drop ${1}" # This one will append some text to the 'msg' string for all rules that # have the 'tag' keyword in them. # modifysid * "(.*msg:\s*".+?)"(\s*;.+;\s*tag:.*)" | \ # "${1}, going to tag this baby"${2}" # There may be times when you want to replace multiple occurrences of a # certain keyword/string in a rule and not just the first one. To # replace the first two occurrences of "foo" with "bar" in SID 100, # simply repeat the modifysid statement: # modifysid 100 "foo" | "bar" # modifysid 100 "foo" | "bar" # Or you can even specify a SID list but repeat the same SID as many # times as required, like: # modifysid 100,100,100 "foo" | "bar" # Enable all rules in the file exploit.rules. # modifysid exploit.rules "^#" | "" # Enable all rules in exploit.rules, icmp-info.rules and also SID 1171. # modifysid exploit.rules, snmp.rules, 1171 "^#" | "" # Disable all rules by default modifysid * "(.+)" | "#${1}"

This was one of my contributions to oinkmaster :) In our environment I end up modifying either source or dest addresses to reduce FPs as an alternative to disabling the rule outright. I also have added flowbit:noalert to a bunch of rule and tweaked the thresholds on others. I currently have about 50 modify rules...

This is an enhancement request -- can't figure out how to tag it as such... I have several different sensor configurations each with multiple sensors. I manage these all from a central box. Current set up with oinkmaster is that I have a script that checks MD5s of all the tarballs and download any that have changed -- I then unpack the tarballs. I then run oinkmaster for each set of sensors and generate the rule sets and push them out to the sensors and restart them. I also use both VRT and ET rules so I need multiple feeds (but I see Mike L has prompted you on that one :) So what I want is an equivalent of the oinkmaster "directory" configuration option. Otherwise we end up pulling the VRT rules 3 times and getting 503 and it will take all night :) Thanks, Russell