Re: SNORT not adding entries to snort/portscan ???
On Sat, Nov 30, 2002 at 06:25:47PM -0800, Andris Kalnozols wrote: Is this an example of what you mean? /usr/sbin/sendmail: /lib/libc.so.6: version `GLIBC_2.3' not found (required by /usr/sbin/sendmail) After `apt-get' upgraded sendmail to 8.12.6, this error appeared. As I recall from another Debian list, the response from whoever compiled this version was something like Oops, stuff happens in the testing distro but, a month later, there's still no working replacement. How does one go about fixing this kind of problem? Andris More basic than that. You will find packages that refuse to build without pulling in a new libc6 they don't even need. This comes from a dependency for say: = libc6_2.2.5-13 when there is actually no reason that anything after = libc6_2.2.1-1 would have worked. Perhaps there are good reasons for requiring the absolute latest revision. Usually there are not unless you really do intend to upgrade a large chunk of your system. The case you are describing is far worse. It's broken period, not just an annoyance and the cause of loads of unnecessary package dependency caused upgrades. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SNORT not adding entries to snort/portscan ???
Perhaps what I'm suggesting is an idea for the package people to consider. Instead of Required: being univalued, perhaps have a minimum useable version required and a preferred version. Default to the prefered but give the user via dselect and apt a means of pinning to the minimum instead. That would let me selectively pull in a number of security tools I began using on a sid dist that I sorely miss in woody. I simply don't have time to repackage them all and be my own package maintainer. I doubt any of them has *real* dependencies such that they would not work perfectly well with the woody libs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SNORT not adding entries to snort/portscan ???
Perhaps what I'm suggesting is an idea for the package people to consider. Instead of Required: being univalued, perhaps have a minimum useable version required and a preferred version. Default to the prefered but give the user via dselect and apt a means of pinning to the minimum instead. That would let me selectively pull in a number of security tools I began using on a sid dist that I sorely miss in woody. I simply don't have time to repackage them all and be my own package maintainer. I doubt any of them has *real* dependencies such that they would not work perfectly well with the woody libs.
Re: SNORT not adding entries to snort/portscan ???
Once again I ask, please do not use procmail or any other automated system to report mail to razor that comes from a Debian list!!! From: Andris Kalnozols [EMAIL PROTECTED] Subject: Re: SNORT not adding entries to snort/portscan ??? To: debian-security@lists.debian.org Date: Sat, 30 Nov 2002 18:25:47 PST Delivery-date: Sat, 30 Nov 2002 21:37:04 -0500 X-Razor-Warning: SPAM. Regards, Phil On Sat, 30 Nov 2002 at 06:25:47PM -0800, Andris Kalnozols wrote: Perhaps I did not state this clearly enough. The majority of cases I run across are caused by an entirely unnecessary dependancy to a version of libc6 which isn't in any way required for the package in question. Yes, one can fix this manually. Every time, for every package. Which naturally means you do it once or twice and then say oh forget it and wait a year or whatever until the next stable upgrade. Package Dependencies on lib versions (or any other entity for that matter) really are several entirely different things: * the API changed and my application will fail with any lib version prior to this one because it relies on the changes. * bug fixes went into this lib version without which my app will crash. * bug fixes went into this version which I specifically want/prefer for my application, but it won't crash on the older one. * I just like to use the latest set of lib version digits for no particular reason. I suspect the majority of package version dependencies fall into the last category. If this was dealt with, there would be a much higher level of interoperability between packages in various dists. Still a caveat emptor, but far, far easier to deal with. Is this an example of what you mean? /usr/sbin/sendmail: /lib/libc.so.6: version `GLIBC_2.3' not found (required by /usr/sbin/sendmail) After `apt-get' upgraded sendmail to 8.12.6, this error appeared. As I recall from another Debian list, the response from whoever compiled this version was something like Oops, stuff happens in the testing distro but, a month later, there's still no working replacement. How does one go about fixing this kind of problem? Andris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Phil PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.txt | gpg --import -- Excuse #41: Bank holiday - system operating credits not recharged
Re: SNORT not adding entries to snort/portscan ???
Once again I ask, please do not use procmail or any other automated system to report mail to razor that comes from a Debian list!!! From: Andris Kalnozols [EMAIL PROTECTED] Subject: Re: SNORT not adding entries to snort/portscan ??? To: debian-security@lists.debian.org Date: Sat, 30 Nov 2002 18:25:47 PST Delivery-date: Sat, 30 Nov 2002 21:37:04 -0500 X-Razor-Warning: SPAM. Regards, Phil Hi, Phil. Was this admonition directed at me or was the display of the X-Razor-Warning: SPAM. header meant to illustrate the negative consequences to the true guily party? Although we plan to implement SpamAssassin, we'll take the conservative approach and _not_ enable the automatic reporting feature to Razor for just the reason you stated. Andris
Re: SNORT not adding entries to snort/portscan ???
On Sat, Nov 30, 2002 at 06:25:47PM -0800, Andris Kalnozols wrote: Is this an example of what you mean? /usr/sbin/sendmail: /lib/libc.so.6: version `GLIBC_2.3' not found (required by /usr/sbin/sendmail) After `apt-get' upgraded sendmail to 8.12.6, this error appeared. As I recall from another Debian list, the response from whoever compiled this version was something like Oops, stuff happens in the testing distro but, a month later, there's still no working replacement. How does one go about fixing this kind of problem? Andris More basic than that. You will find packages that refuse to build without pulling in a new libc6 they don't even need. This comes from a dependency for say: = libc6_2.2.5-13 when there is actually no reason that anything after = libc6_2.2.1-1 would have worked. Perhaps there are good reasons for requiring the absolute latest revision. Usually there are not unless you really do intend to upgrade a large chunk of your system. The case you are describing is far worse. It's broken period, not just an annoyance and the cause of loads of unnecessary package dependency caused upgrades.
Re: SNORT not adding entries to snort/portscan ???
Dale == Dale Amon [EMAIL PROTECTED] writes: Dale I've a general issue along those lines. There are often Dale tools I'd like to install but most packages specify = a Dale version of libc6 even when the package would basically run Dale with any libc that ever existed. Dale In one sense this is a more general issue, but it's also a Dale security one in that it prevents using adding important Dale tools to an older dist on a one off basis, even if that tool Dale would give a substantial increase in security. I would have thought a reasonable number of packages can be upgraded by grabbing the source, patching using the Debian diff and dpkg-buildpackage'ing. I've done this on a small number of packages without problems. Some manualy fixing of the diff maybe necessary obviously if there are bug fix patches included that aren't required for the newer version. I was under the impression that if people wished to have newer stable versions then it is up to individuals to handle this themselves. It is not something that the Debian project can be expected to maintain. Sincerely, Adrian Phillips -- Your mouse has moved. Windows NT must be restarted for the change to take effect. Reboot now? [OK] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SNORT not adding entries to snort/portscan ???
On Sat, Nov 30, 2002 at 01:56:53PM +0100, Adrian Phillips wrote: Dale == Dale Amon [EMAIL PROTECTED] writes: Dale I've a general issue along those lines. There are often Dale tools I'd like to install but most packages specify = a Dale version of libc6 even when the package would basically run Dale with any libc that ever existed. I would have thought a reasonable number of packages can be upgraded by grabbing the source, patching using the Debian diff and dpkg-buildpackage'ing. I've done this on a small number of packages without problems. Some manualy fixing of the diff maybe necessary obviously if there are bug fix patches included that aren't required for the newer version. I was under the impression that if people wished to have newer stable versions then it is up to individuals to handle this themselves. It is not something that the Debian project can be expected to maintain. Perhaps I did not state this clearly enough. The majority of cases I run across are caused by an entirely unnecessary dependancy to a version of libc6 which isn't in any way required for the package in question. Yes, one can fix this manually. Every time, for every package. Which naturally means you do it once or twice and then say oh forget it and wait a year or whatever until the next stable upgrade. Package Dependencies on lib versions (or any other entity for that matter) really are several entirely different things: * the API changed and my application will fail with any lib version prior to this one because it relies on the changes. * bug fixes went into this lib version without which my app will crash. * bug fixes went into this version which I specifically want/prefer for my application, but it won't crash on the older one. * I just like to use the latest set of lib version digits for no particular reason. I suspect the majority of package version dependencies fall into the last category. If this was dealt with, there would be a much higher level of interoperability between packages in various dists. Still a caveat emptor, but far, far easier to deal with. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SNORT not adding entries to snort/portscan ???
Perhaps I did not state this clearly enough. The majority of cases I run across are caused by an entirely unnecessary dependancy to a version of libc6 which isn't in any way required for the package in question. Yes, one can fix this manually. Every time, for every package. Which naturally means you do it once or twice and then say oh forget it and wait a year or whatever until the next stable upgrade. Package Dependencies on lib versions (or any other entity for that matter) really are several entirely different things: * the API changed and my application will fail with any lib version prior to this one because it relies on the changes. * bug fixes went into this lib version without which my app will crash. * bug fixes went into this version which I specifically want/prefer for my application, but it won't crash on the older one. * I just like to use the latest set of lib version digits for no particular reason. I suspect the majority of package version dependencies fall into the last category. If this was dealt with, there would be a much higher level of interoperability between packages in various dists. Still a caveat emptor, but far, far easier to deal with. Is this an example of what you mean? /usr/sbin/sendmail: /lib/libc.so.6: version `GLIBC_2.3' not found (required by /usr/sbin/sendmail) After `apt-get' upgraded sendmail to 8.12.6, this error appeared. As I recall from another Debian list, the response from whoever compiled this version was something like Oops, stuff happens in the testing distro but, a month later, there's still no working replacement. How does one go about fixing this kind of problem? Andris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SNORT not adding entries to snort/portscan ???
Dale == Dale Amon [EMAIL PROTECTED] writes: Dale I've a general issue along those lines. There are often Dale tools I'd like to install but most packages specify = a Dale version of libc6 even when the package would basically run Dale with any libc that ever existed. Dale In one sense this is a more general issue, but it's also a Dale security one in that it prevents using adding important Dale tools to an older dist on a one off basis, even if that tool Dale would give a substantial increase in security. I would have thought a reasonable number of packages can be upgraded by grabbing the source, patching using the Debian diff and dpkg-buildpackage'ing. I've done this on a small number of packages without problems. Some manualy fixing of the diff maybe necessary obviously if there are bug fix patches included that aren't required for the newer version. I was under the impression that if people wished to have newer stable versions then it is up to individuals to handle this themselves. It is not something that the Debian project can be expected to maintain. Sincerely, Adrian Phillips -- Your mouse has moved. Windows NT must be restarted for the change to take effect. Reboot now? [OK]
Re: SNORT not adding entries to snort/portscan ???
On Sat, Nov 30, 2002 at 01:56:53PM +0100, Adrian Phillips wrote: Dale == Dale Amon [EMAIL PROTECTED] writes: Dale I've a general issue along those lines. There are often Dale tools I'd like to install but most packages specify = a Dale version of libc6 even when the package would basically run Dale with any libc that ever existed. I would have thought a reasonable number of packages can be upgraded by grabbing the source, patching using the Debian diff and dpkg-buildpackage'ing. I've done this on a small number of packages without problems. Some manualy fixing of the diff maybe necessary obviously if there are bug fix patches included that aren't required for the newer version. I was under the impression that if people wished to have newer stable versions then it is up to individuals to handle this themselves. It is not something that the Debian project can be expected to maintain. Perhaps I did not state this clearly enough. The majority of cases I run across are caused by an entirely unnecessary dependancy to a version of libc6 which isn't in any way required for the package in question. Yes, one can fix this manually. Every time, for every package. Which naturally means you do it once or twice and then say oh forget it and wait a year or whatever until the next stable upgrade. Package Dependencies on lib versions (or any other entity for that matter) really are several entirely different things: * the API changed and my application will fail with any lib version prior to this one because it relies on the changes. * bug fixes went into this lib version without which my app will crash. * bug fixes went into this version which I specifically want/prefer for my application, but it won't crash on the older one. * I just like to use the latest set of lib version digits for no particular reason. I suspect the majority of package version dependencies fall into the last category. If this was dealt with, there would be a much higher level of interoperability between packages in various dists. Still a caveat emptor, but far, far easier to deal with.
Re: SNORT not adding entries to snort/portscan ???
Perhaps I did not state this clearly enough. The majority of cases I run across are caused by an entirely unnecessary dependancy to a version of libc6 which isn't in any way required for the package in question. Yes, one can fix this manually. Every time, for every package. Which naturally means you do it once or twice and then say oh forget it and wait a year or whatever until the next stable upgrade. Package Dependencies on lib versions (or any other entity for that matter) really are several entirely different things: * the API changed and my application will fail with any lib version prior to this one because it relies on the changes. * bug fixes went into this lib version without which my app will crash. * bug fixes went into this version which I specifically want/prefer for my application, but it won't crash on the older one. * I just like to use the latest set of lib version digits for no particular reason. I suspect the majority of package version dependencies fall into the last category. If this was dealt with, there would be a much higher level of interoperability between packages in various dists. Still a caveat emptor, but far, far easier to deal with. Is this an example of what you mean? /usr/sbin/sendmail: /lib/libc.so.6: version `GLIBC_2.3' not found (required by /usr/sbin/sendmail) After `apt-get' upgraded sendmail to 8.12.6, this error appeared. As I recall from another Debian list, the response from whoever compiled this version was something like Oops, stuff happens in the testing distro but, a month later, there's still no working replacement. How does one go about fixing this kind of problem? Andris
Re: SNORT not adding entries to snort/portscan ???
My driver is a tulip for a linksys card The snort list told me that the version in woody is known to be broken so I downloaded snort 1.9 and manually installed it.. yuk! FYI: when run from the command line, the BETA in woody was saying something about exhausting trees. REQUEST! can 1.9 be put in woody? can 2.0 be put in when it comes out? Simon Kirby wrote: On Fri, Nov 29, 2002 at 02:01:26PM +0100, Marcel Weber wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanasaki JiJi schrieb: | 1.8.4-Beta1 Build 91 | | It also seems to be dying without any reports to syslog | This also happens to my setup. I'm restarting snort every night now. This seems really weird, but try switching to the e100 driver if you are currently using eepro100. It may just be timing related, but it seemed to make a difference. (We're using tg3 now and it's still fine.) Simon- [Simon Kirby][Network Operations] [ [EMAIL PROTECTED] ][ NetNation Communications ] [ Opinions expressed are not necessarily those of my employer. ] -- = = Management is doing things right; leadership is doing the = = right things.- Peter Drucker= =___= = http://www.sun.com/service/sunps/jdc/javacenter.pdf = = www.sun.com | www.javasoft.com | http://wwws.sun.com/sunone = = -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SNORT not adding entries to snort/portscan ???
On Thu, Nov 28, 2002 at 10:19:24 -0600, Hanasaki JiJi wrote: Snort is reporting scans in the alert.log but not the portscan.log Which version? AFAIK the version in woody still has wrong log rotation causing it to log to a file descriptor corresponding to an already deleted file (#158042). HTH, Ray -- A Microsoft Certified System Engineer is to information technology as a McDonalds Certified Food Specialist is to the culinary arts. Michael Bacarella commenting on the limited value of certification.
Re: SNORT not adding entries to snort/portscan ???
1.8.4-Beta1 Build 91 It also seems to be dying without any reports to syslog J.H.M. Dassen (Ray) wrote: On Thu, Nov 28, 2002 at 10:19:24 -0600, Hanasaki JiJi wrote: Snort is reporting scans in the alert.log but not the portscan.log Which version? AFAIK the version in woody still has wrong log rotation causing it to log to a file descriptor corresponding to an already deleted file (#158042). HTH, Ray -- = = Management is doing things right; leadership is doing the = = right things.- Peter Drucker= =___= = http://www.sun.com/service/sunps/jdc/javacenter.pdf = = www.sun.com | www.javasoft.com | http://wwws.sun.com/sunone = =
Re: SNORT not adding entries to snort/portscan ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanasaki JiJi schrieb: | 1.8.4-Beta1 Build 91 | | It also seems to be dying without any reports to syslog | This also happens to my setup. I'm restarting snort every night now. Marcel - -- Marcel Weber - [EMAIL PROTECTED] PGP/GPG Key: http://www.ncpro.com/GPG/mmweber-at-ncpro-com.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE952Um1EXMUTKVE5URAjWQAJ0QmqZ4v1zFAhPkmLg0tELbpnEqIgCgxwNM fiTZExp08VpjfTmiefvCDKY= =ydnx -END PGP SIGNATURE-
Re: SNORT not adding entries to snort/portscan ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanasaki JiJi wrote: | My driver is a tulip for a linksys card | | The snort list told me that the version in woody is known to be broken | so I downloaded snort 1.9 and manually installed it.. yuk! | | FYI: when run from the command line, the BETA in woody was saying | something about exhausting trees. | | REQUEST! can 1.9 be put in woody? can 2.0 be put in when it comes out? | My driver was a 8139too. As SNORT is a security related tool (active security) and the threats are changing from time to time the signatures have to be up to date as well as the tool itself. What about considering outdated security tools as hazardous to the system's security? Taking this point of view, why not distributing updated versions via debian-security? Marcel - -- Marcel Weber - [EMAIL PROTECTED] PGP/GPG Key: http://www.ncpro.com/GPG/mmweber-at-ncpro-com.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE956WQ1EXMUTKVE5URAk0DAJ9giopxfg/8Y+lnWY3qL9nNjYSWiACgqiZ/ k9jVwvo2duJbgfhmLNyzqSk= =dEC6 -END PGP SIGNATURE-
Re: SNORT not adding entries to snort/portscan ???
On Fri, Nov 29, 2002 at 06:36:16PM +0100, Marcel Weber wrote: What about considering outdated security tools as hazardous to the system's security? Taking this point of view, why not distributing updated versions via debian-security? I've a general issue along those lines. There are often tools I'd like to install but most packages specify = a version of libc6 even when the package would basically run with any libc that ever existed. In one sense this is a more general issue, but it's also a security one in that it prevents using adding important tools to an older dist on a one off basis, even if that tool would give a substantial increase in security. You can force things, but then you've hassles for life every time you use apt and dselect.
Re: SNORT not adding entries to snort/portscan ???
Hanasaki JiJi wrote: Snort is reporting scans in the alert.log but not the portscan.log Any thoughts? Hi! Now I *have* my snort reporting scans in the portscan.log in Version 1.8.4-beta1 (Build 91). Because of this message, I started playing with my snort.conf. When I uncommented the rules at the end of the snort.conf (except shellcodes.rules), snort started reporting in that file. If you wish, I can send you my snort.conf. Bye (and I sorry for my english, it is not good enough) :-) Alfonso
Re: SNORT not adding entries to snort/portscan ???
Please do send the file. I have put 1.9 in manaully its rocking! Alfonso Federico Simó wrote: Hanasaki JiJi wrote: Snort is reporting scans in the alert.log but not the portscan.log Any thoughts? Hi! Now I *have* my snort reporting scans in the portscan.log in Version 1.8.4-beta1 (Build 91). Because of this message, I started playing with my snort.conf. When I uncommented the rules at the end of the snort.conf (except shellcodes.rules), snort started reporting in that file. If you wish, I can send you my snort.conf. Bye (and I sorry for my english, it is not good enough) :-) Alfonso -- = = Management is doing things right; leadership is doing the = = right things.- Peter Drucker= =___= = http://www.sun.com/service/sunps/jdc/javacenter.pdf = = www.sun.com | www.javasoft.com | http://wwws.sun.com/sunone = =
Re: SNORT not adding entries to snort/portscan ???
Here it goes! I attach the snort.conf, but I only changed this part: -- #= # Include all relevant rulesets here # # shellcode, policy, info, backdoor, and virus rulesets are # disabled by default. These require tuning and maintance. # Please read the included specific file for more information. #= include bad-traffic.rules include exploit.rules include scan.rules include finger.rules include ftp.rules include telnet.rules include smtp.rules include rpc.rules include rservices.rules include dos.rules include ddos.rules include dns.rules include tftp.rules include web-cgi.rules include web-coldfusion.rules include web-frontpage.rules include web-iis.rules include web-misc.rules include web-attacks.rules include sql.rules include x11.rules include icmp.rules include netbios.rules include misc.rules include attack-responses.rules include backdoor.rules # include shellcode.rules include policy.rules include porn.rules include info.rules # include icmp-info.rules include virus.rules include local.rules -- I hope it helps! Hanasaki JiJi wrote: Please do send the file. I have put 1.9 in manaully its rocking! #-- # http://www.snort.org Snort 1.8.1 Ruleset # Contact: [EMAIL PROTECTED] #-- # NOTE:This ruleset only works for 1.8.0 and later #-- # $Id: snort.conf,v 1.77.2.1 2002/01/11 00:17:35 roesch Exp $ # ### # This file contains a sample snort configuration. # You can take the following steps to create your # own custom configuration: # # 1) Set the network variables for your network # 2) Configure preprocessors # 3) Configure output plugins # 4) Customize your rule set # ### # Step #1: Set the network variables: # # You must change the following variables to reflect # your local network. The variable is currently # setup for an RFC 1918 address space. # # You can specify it explicitly as: # # var HOME_NET 10.1.1.0/24 # # or use global variable $interfacename_ADDRESS # which will be always initialized to IP address and # netmask of the network interface which you run # snort at. # # var HOME_NET $eth0_ADDRESS # # You can specify lists of IP addresses for HOME_NET # by separating the IPs with commas like this: # # var HOME_NET [10.1.1.0/24,192.168.1.0/24] # # MAKE SURE YOU DON'T PLACE ANY SPACES IN YOUR LIST! # # or you can specify the variable to be any IP address # like this: var HOME_NET any # Set up the external network addresses as well. # A good start may be any var EXTERNAL_NET any # Set up your SMTP servers, or simply configure them # to HOME_NET var SMTP $HOME_NET # Set up your web servers, or simply configure them # to HOME_NET var HTTP_SERVERS $HOME_NET # Set up your sql servers, or simply configure them # to HOME_NET var SQL_SERVERS $HOME_NET # Define the addresses of DNS servers and other hosts # if you want to ignore portscan false alarms from them... var DNS_SERVERS $HOME_NET ### # Step #2: Configure preprocessors # # General configuration for preprocessors is of # the form # preprocessor name_of_processor: configuration_options # frag2: IP defragmentation support # --- # This preprocessor performs IP defragmentation. This plugin will also detect # people launching fragmentation attacks (usually DoS) against hosts. No # arguments loads the default configuration of the preprocessor, which is a # 60 second timeout and a 4MB fragment buffer. # The following (comma delimited) options are available for frag2 #timeout [seconds] - sets the number of [seconds] than an unfinished #fragment will be kept around waiting for completion, #if this time expires the fragment will be flushed #memcap [bytes] - limit frag2 memory usage to [bytes] bytes preprocessor frag2 # stream4: stateful inspection/stream reassembly for Snort #-- # Use in concert with the -z [all|est] command line switch to defeat # stick/snot against TCP rules. Also performs full TCP stream # reassembly, stateful inspection of TCP streams, etc. Can statefully # detect various portscan types, fingerprinting, ECN, etc. # stateful inspection directive # no arguments loads the defaults (timeout 30, memcap 8MB) # options (options are comma delimited): # detect_scans - stream4 will detect stealth portscans and generate alerts #
