Jacob Langseth wrote: > > Stefan Aeschbacher scribed: > > Hi > > here are some snort rules which could show the presence of a trin00 > > The nature of these attacks do not lend themselves to an > easy defense; finding a master and retrieving its list of > clients is currently one of the best, albeit proactive, > countermeasures. By making rules to detect the master > available for a free IDS, you greatly improve the chances > of fighting the default configuration. Thank you. I thought of the problem of fighting the default configuration and this is definitely a valuable point. I think that the (malicuous) people reading Bugtraq need a certain amount of technical knowledge and such a person will change the default configs. So this rules are mainly to protect against script-kiddies. Searching a master is definitely the better alternative but I have the problem that one of my servers is located in a subnet where I am not allowed to do any administrative actions on the other machines and the people there don't really care about security. (Yea, I should move this server to another location ;). I even assume a check for a master server could be regarded as an attack (If they notice it). So the only thing I (and probably some more people on this list) can do is listen for trin00. > I have a few suggestions, if I may. > > > alert tcp any any -> 192.168.1.0/24 27665 (msg:"Trin00: Attacker to > > Master (default startup pass detected!)"; content:"betaalmostdone";)) > > Trinoo uses crypt(3) to verify this password. Stock crypt(3) > bases its one-way function on DES, which is limited to a 56-bit > key. Passwords exceeding this length are truncated, making > "betaalmo" sufficient to authenticate. right, didn't think to far when I wrote this rule. > > alert tcp any any -> 192.168.1.0/24 27665 (msg:"Trin00: Attacker to > > Master (default r.i. pass detected!)"; content:"gOrave";)) > > The gOrave password is read via stdin during master startup, > making its occurance on the control channel highly unlikely. > (As gOrave is required for startup, it's verification takes > place before the control port is listening.) I think this > rule may be safely dropped. right. thanks you for your corrections Stefan -- Stefan Aeschbacher Federal Institute of Technology Where do you want to go today? Lausanne Switzerland http://www.aeschbacher.ch/stefan - NOT in your direction! -
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:19:25 PDT