[Snort-users] Re: Snort-users digest, Vol 1 #3790 - 8 msgs

dunervst at ...348... dunervst at ...348...
Tue Dec 2 23:56:03 EST 2003


Thanks to Eric Grejda. i changed the symlink and it works.


----- Original Message ----- 
From: <snort-users-request at lists.sourceforge.net>
To: <snort-users at lists.sourceforge.net>
Sent: Tuesday, December 02, 2003 4:28 PM
Subject: Snort-users digest, Vol 1 #3790 - 8 msgs


> Send Snort-users mailing list submissions to
> snort-users at lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/snort-users
> or, via email, send a message with subject or body 'help' to
> snort-users-request at lists.sourceforge.net
>
> You can reach the person managing the list at
> snort-users-admin at lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Snort-users digest..."
>
>
> Today's Topics:
>
>    1. passive tap (christian graf)
>    2. Re: Slightly OT: high speed packet generation
>        software (Dirk Geschke)
>    3. Re: Announce: FLoP-1.0 --- Fast Logging Project for snort (Dirk
Geschke)
>    4. Re: Slightly OT: high speed packet generation software (Peter
Schawacker)
>    5. Re: Announce: FLoP-1.0 --- Fast Logging Project for snort (fwd)
(Dirk Geschke)
>    6. Problem with compiling snort (dunervst at ...348...)
>    7. RE: Problem with compiling snort (Grejda, Eric)
>
> --__--__--
>
> Message: 1
> From: christian graf <chr.graf at ...348...>
> To: "Snort-Users at ...1973...  ""Sourceforge. Net    ""(E-mail)"
> <snort-users at lists.sourceforge.net>
> Date: 02 Dec 2003 10:32:35 +0100
> Subject: [Snort-users] passive tap
>
> Hi,
>
> my experiences with another IDS than snort are the following:
> 1) the easiest solution is mirroring the e.g. 100Mbit link to a 1Gig
> link. Having this you are avoiding oversubscritpion and you do not have
> to change anything on your IDS. Thats independant from the usage of any
> taps. You don't need them in this scenario.
> 2) The worst is like other said, having two instances of SNORT/libpcap
> running. Huge overhead, poor performance and the loss of any
> stateful-capabilities / preprocessors. That will not satisfy anybody.
> 3) the bridging solution
> I tried this and the results a really bad. Bridging produces overhead
> and more important, as the your SNORT-device is acting like a bridge,
> you have to DISABLE the forwarding on your "snort-bridging-device". If
> not, all packets may be seen on both interfaces and therefore you get
> all alerts twice. I wouldn't take it.
> 4) the bonding
> yes, the bonding was a real nice success. Just enable the
> bonding-interface and you get what you want. You can use 2 nics, having
> the tapped rx and tx streams recombined in the bonding-interface and you
> need only one instance of snort running. I have never thought if packets
> may be disordered when using a bonding-interface. This could be a
> potential problem when thinking about statefulness and the
> preprocessors. But maybe anybody in this list could clarify this.
> regarding this limitation, point (1) is the most safe unless your
> switch/router is powerful enough in his mirroring capabilities.
>
>
> hope this helps
>
> christian
>
>
>
>
> --__--__--
>
> Message: 2
> Subject: Re: [Snort-users] Slightly OT: high speed packet generation
> software
> From: Dirk Geschke <Dirk at ...10648...>
> To: doug at ...10143...
> Cc: snort-users at lists.sourceforge.net
> Organization:
> Date: 01 Dec 2003 22:09:26 +0100
>
> Hi Douglas,
>
> > I'm curious to know what everyone else uses for high speed packet
> > generation. I'm not so much interested in single packets, but rather,
> > something that can generate a lot of traffic. Noise is irrelevant, as
I'm
> > an looking to do IDS testing. I've looked a little at a few on freshmeat
> > (packETH, pacgen, http_load) but have no experience with any of them. By
> > high speed, I mean something that'll push 100Mb/s, and (hardware
allowing)
> > 1Gb/s
> >
> > Ideally, it would be nice to have something that emulated sessions
between
> > a couple of ip addresses, but I'll take a variety of packet generation.
>
> the false-positive-generator fpg is able to generate false positive
> network packets based on a snort.conf file. This programs reads the
> rules of the snort.conf file and tries to generate a network packet
> with all parts necessary to generate an alert.
>
> The program is able to generate traffic much faster than your network
> (at least more than 100 Mb/s on an actual computer. I never had a
> gigabit network so far...)
>
> To compile the program you need libnet-1.1 or higher. The sources of
> fpg are part of the FLoP project (http://www.geschke-online.de/FLoP).
> On this page you can find a compiled version of fpg for linux/x86.
>
> Best regards
>
> Dirk
>
>
>
> This program is par
>
>
>
> --__--__--
>
> Message: 3
> From: Dirk Geschke <Dirk at ...10648...>
> To: bamm at ...539...
> Cc: snort-users <snort-users at lists.sourceforge.net>, snort-devel
<snort-devel at lists.sourceforge.net>
> Organization:
> Date: 01 Dec 2003 23:05:07 +0100
> Subject: [Snort-users] Re: Announce: FLoP-1.0 --- Fast Logging Project for
snort
>
> Hi Bamm,
>
> > I hope you don't think I was attacking flop. I actually want
> > to take a close look at what you've done and also talk to you
> > about supporting sguil (http://sguil.sf.net) and its DB schema.
>
> I did not assume that you wanted to attack the project but there
> were some points which needed some comments.
>
> > My only intent was to start a discussion of the main disadvantage
> > of using the unix socket plugin with snort: that if for any reason,
> > the process reading the unix socket dies, any alerts that snort
> > writes while the proc is down, is gone for ever. In short, by using
> > the unix socket, you've added another potential point of failure to
> > your IDS. Please understand, that I believe that risk is fairly low
> > (at least for a well written/tested program), but there are those
> > that may not be willing to accept that risk, just like there are those
> > that won't entertain the idea of an inline IDS (versus passive
monitoring)
> > for the sole reason a inline IDS brings another point of failure into
the
> > network.
>
> With any solution you introduce some possible problems. Think either of
> a hanging snort waiting for the output plugins and therefore simply
> missing some packets to sniff. Or think of a filled up filesystem where
> no process is able to write any byte which could have just more and
> worser side effects. With unix domain sockets you can add an extra
> layer of security. I just mentioned it: The output-plugin realizes
> if a process is reading on the socket or not. So if writing to the
> socket fails you can start another output plugin or simply write
> the data in a file.
>
> The problem here is: You need a mechanism how you want to handle this
> special situation. And much worser: How to watch for the process which
> waits for data in this special file...
>
> > Now that that is said, can you answer a couple of questions (why RTFM
when
> > I have your ear ;) ).
>
> > From the documentation I did read, it looks like if servsock (the
process
> > that recieves data from the sockserv) dies or becomes unreachable for an
> > extended period of time, then sockserv (the proc that reads the unix
sock)
> > will die. I saw the experimental 'drop' feature, but I am wondering if
you
> > had any plans to instead start writing the events to disk and then be
able
> > to read those alerts back into sockserv and send them off once servsock
> > becomes available again?
>
> Okay, this can lead to problems in two sitution. Either when sockserv is
> started or if an alert arises. If there is no servsock process listening
> the program tries MaxTry times to connect to servsock. Between two tries
> the process waits WaitTime seconds. This values are set by default to
> 10, which is quite small but can be adjusted with the command line
> options -M and -W.
>
> The reason why this values are so small by default is to make it easier
> to test it. And the main reason why I don't use an infinite loop is to
> have the possibility to inform someone of the problem.(I simply assume
> that there is a job in the background surveying the processes. How else
> will you notice that there is a problem? But in principle you can choose
> high values for this parameters.)
>
> The drop feature was introduced as a "stability" factor. Think of a lot
> of buffered alerts and no servsock. Then the memory usage will increase
> until malloc() fails. The result would be a dying sockserv and all
> alerts are lost. With drop you can get a short information of wich
> alerts are logged. This contains of the signature, the IP addresses
> and ports (if ther are any) involved in the process together with the
> timestamp. This values are either send to a list of recipients and if
> this is not possible the alerts are written to syslog or stdout. (Think
> of a network problem: No E-Mail can be sent so we write to stdout or
> syslog.) So effectively you only loose some network headers and the
> payload.
>
> And finally: Yes, first I thought on a temporarily buffering of alerts
> by writing them to disk. But then you have the same problems we already
> discussed with barnyard. Additionally there is a further problem: When
> and how will you reload these alerts? Will you stop reading from the
> unix socket until all data is read in from disk? Or should we create
> a third thread, mixing up with the other by storing the alerts again
> in memory? Think of a disturbed network where you can't reach the
> cental server. All alerts will fill up memory, where dumped to disk
> and reread until you have to redump them again? And what is with the
> alerts ariving from snort inbetween?
>
> So there are a lot of problems with this approach.
>
> If you assume that sockserv will not die due to an unknown behaviour
> like power shortage or something else. Then let us start a small
> calculation: The alert information together with the payload of a
> full saturated (MTU) packet is less than 3 kB of memory (to be more
> precisely 1360 Byte + 1514 Bytes). Now memory is quite cheap so I
> assume you may have 300 MB (it's easier to calculate) of memory
> available solely for sockserv. Then you can buffer up to 100,000
> alerts until you are running into problems. And this is for the case
> that all alerts use the maximum MTU size of Ethernet...
>
> A problem could arise if you have to restart or replace sockserv.
> But I guess you won't do this on a heavy attack...
>
> > Also, any plans to do much of the same thing with servsock (like
> > if the DB somehow become unavailable for an extended length of time)?
> > I can think of a couple of circimstances that may cause either the DB
> > and/or servsock to become 'unavailable' (such as a server reboot, DB
> > cleaning, etc). This also adds more points of failure, where if one
> > component dies, events could be lost to /dev/null.
>
> Hmm, this is a little bit more complicated. I don't know how I can
> identify problems with the database connection within servsock. But
> the good thing is: Good databases will never die ;-)
> In fact databases will rarely die and my project assumes that the
> database is running on the same host as servsock. Otherwise we can't
> feed the database via an unix socket... So a reboot is no issue. DB
> cleaning could be: but this can be done online. Then maybe servsock
> will work a little bit slower...
>
> > Anyway, the project definately looks cool and I am glad see there
> > is a real alternative to unified out and barnyard out there.
>
> Fine, give it a try and give me a note how it worked...
>
> Finally one note to sguil: I just took a look at the project site
> and TCL/TK is not really my world. But if I understand it the right
> way than it seems to be a more complex system than FLoP...
> Which database design are you using? I think it is the same one as
> of snort/ACID? Did you ever think about the possibility to store the
> whole pcap data in the database? This should make it unnecessary to
> store them on disk on a separate way.
>
> Best regards
>
> Dirk
>
>
>
>
>
> --__--__--
>
> Message: 4
> From: "Peter Schawacker" <peter at ...5403...>
> To: <snort-users at lists.sourceforge.net>
> Subject: Re: [Snort-users] Slightly OT: high speed packet generation
software
> Date: Mon, 1 Dec 2003 12:14:55 -0800
>
> Doug,
>
> Have  look at tcpreplay:
> http://tcpreplay.sourceforge.net/
>
> -Peter
>
> ----- Original Message ----- 
> From: <doug at ...10143...>
> To: <snort-users at lists.sourceforge.net>
> Sent: Monday, December 01, 2003 11:45 AM
> Subject: [Snort-users] Slightly OT: high speed packet generation software
>
>
> > I'm curious to know what everyone else uses for high speed packet
> > generation. I'm not so much interested in single packets, but rather,
> > something that can generate a lot of traffic. Noise is irrelevant, as
I'm
> > an looking to do IDS testing. I've looked a little at a few on freshmeat
> > (packETH, pacgen, http_load) but have no experience with any of them. By
> > high speed, I mean something that'll push 100Mb/s, and (hardware
allowing)
> > 1Gb/s
> >
> > Ideally, it would be nice to have something that emulated sessions
between
> > a couple of ip addresses, but I'll take a variety of packet generation.
> >
> > -- 
> > Douglas J Nordwall http://rex.nmhu.edu/~musashi
> > System Administrator Pacific Northwest National Labs
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program.
> > Does SourceForge.net help you be more productive?  Does it
> > help you create better code?  SHARE THE LOVE, and help us help
> > YOU!  Click Here: http://sourceforge.net/donate/
> > _______________________________________________
> > 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://www.geocrawler.com/redir-sf.php3?list=snort-users
>
>
>
> --__--__--
>
> Message: 5
> To: Bamm Visscher <bamm at ...539...>
> cc: snort-users <snort-users at lists.sourceforge.net>,
>    snort-devel <snort-devel at lists.sourceforge.net>
> Date: Tue, 02 Dec 2003 14:31:37 +0100
> From: Dirk Geschke <Dirk_Geschke at ...1344...>
> Subject: [Snort-users] Re: Announce: FLoP-1.0 --- Fast Logging Project for
snort (fwd)
>
> Hi Bamm,
>
> > I've learned to expect the unexpected. For me, many of my sensors
> > are remote, and I don't control any of the networks. So, if we take
> > our 'central' network down for maintenance, my remote sensors wouldn't
> > be able to connect to the central servsock until it's back up. Usually
> > this is no more than two to four hours, but every once in a while it
> > can go down for longer. Yes, we write alerts to disk after they use X
> > amount of mem (set in a conf file). They are written one alert per file
> > and then read back in order once the backend becomes available again.
> > There are numerous ways to accomplish this and I like the extra
reliability
> > it provides. I don't think it's right to compare it to barnyard since we
> > are only writing to disk when we can't send the alerts up. I'd rather
take
> > a small hit in my snort performance rather than losing alerts
altogether.
>
> the idea of FLoP is to have a fast logging. Therefore I assumed a
> dedicated network for the communication between the remote sensors
> and the central server. So in addition there neither encryption of
> the data nor is there any validation of the sensor (aka sockserv)
> connecting to the central server. (On stealth sensors this is just
> a need to have a second network. But indeed I think this network
> should be resevered for the NIDS.)
>
> Further if you don't get too much alerts then sockserv should still
> be able to work (except for power shortage). The problem is if you
> get too many alerts. But then I see the problem of re-inserting
> the stored files in the same way. When will you do this if the
> actual attack rate is high. Do you then want to store the actual
> alerts on the disk and first insert the old ones?
>
> > > Hmm, this is a little bit more complicated. I don't know how I can
> > > identify problems with the database connection within servsock. But
> > > the good thing is: Good databases will never die ;-)
> >
> > We can dream can't we ;)
>
> Oh yes, at least sometimes... But indeed I never had problems with
> abnormal dieing of databases. (A full disk is an abnormal situation.)
>
> > > In fact databases will rarely die and my project assumes that the
> > > database is running on the same host as servsock. Otherwise we can't
> > > feed the database via an unix socket... So a reboot is no issue. DB
> > > cleaning could be: but this can be done online. Then maybe servsock
> > > will work a little bit slower...
> >
> > Depends on the database.  We use postgres and while a 'normal' vacuum
> > is good for routine maintenance, once you postgres DB gets huge (tens
> > of millions of rows) you probably need to run 'VACUUM FULL' which will
> > totally lock the DB until its done (were talking hours here). I'd be
> > interested to see how servsock respondes to a locked DB. Generally, I
> > restart the DB and only allow local connections when I need to do a
> > 'VACUUM FULL', this causes the remote agents to start buffering their
> >  events locally (our version of servsock isn't run on the DB machine).
>
> Hmm, I fear servsock will run into trouble if the database id off.
> Before tearing down the database you can stop servsock so no new
> alerts are accepted, the old ones are stored and then you can wait
> for the database to come online again. Then restart servsock. If
> the parameters for sockserv are chosen appropiate all should go
> on as before. That's at least a possibility.
>
> Stopping the database during servsock is running will simply drop
> the alerts to nirwana. (Ok, you will get an error message from
> the client library wich is printed to stdout or syslog which
> contains the failed statement.) But it is no good idea at all.
>
> But how many sensors are you running to get such amount of
> data even if the connection to the sensors go off for a few
> hours inbetween?
>
> I think a database should be cleare by some automatically process
> to spool off old or less important data. Who really cares about
> alerts of the last month? Yes, you should think of making a
> backup but I think it is not really required to be part of a vital
> database.
>
> [...]
>
> > > Which database design are you using? I think it is the same one as
> > > of snort/ACID? Did you ever think about the possibility to store the
> > > whole pcap data in the database? This should make it unnecessary to
> > > store them on disk on a separate way.
> >
> > No, sguil does not use the standard snort/acid schema. There have
> > been many discussions about this, but basically the standard schema
> > isn't as scalable as I and others need/want it to be. I can send you
> > a diagram (once I create it) otherwise you can just take a peek at
> > the create_sguildb.sql script in the source. Pcap data for each alert
> > is stored in the DB. The pcap that is stored on the sensors is for
> > entire streams (think 'log ip any any -> any any'). It's hard enought
> > to store that data locally, I can't imagine trying to push that data
> > up to a DB (let alone dealing with it once it's there). Sguil uses
> > barnyard and the op_sguil plugin for recieving RT events and INSERTing
> > them into the DB right now. Are you interested in discussing
> > (off this list) an option for FLoP to use the sguil schema and to send
> > alerts directly to sguild?
>
> I just took a short look at create_sguildb.sql. At first glance it
> does not look very different in contrast to the ACID database but
> contains some fields which are not included in the FLoP "design".
>
> Is it possible that the tables contain a lot of redundancy? This
> seems not to be very fast...
>
> But I have to look at in a silent moment and read the documentation
> of sguil too. But this will take some time which I don't have in the
> moment...
>
> Best regards
>
> Dirk
>
>
>
> --__--__--
>
> Message: 6
> From: <dunervst at ...348...>
> To: <snort-users at lists.sourceforge.net>
> Date: Tue, 2 Dec 2003 15:14:14 +0100
> Subject: [Snort-users] Problem with compiling snort
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_007E_01C3B8E6.F26AA4D0
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> Hi together,
>
> i have a Problem with every snort version out there. The issue is that i =
> compile snort like that:
>
> ./configure --with-mysql
> make
> make check
> make install
>
> during the configure option it shows me that mysql support is ok. When i =
> am done, there is nothing. No /etc/snort, no subsys/snort, no =
> var/log/snort and no /usr/sbin/snort. There is really nothing. When i =
> make a rpm of the tar file it is working, but i can=B4t use it with =
> mysql. After rpmbuild i got 2 Pakages snort and snort-mysql. I installed =
> both but every time i restart snort it tells me that it can=B4t shut =
> down the service. In the message log=20
>
> snort: database: 'mysql' support is not compiled into this build of =
> snort
> snort: FATAL ERROR: If this build of snort was obtained as a binary =
> distribution (e.g., rpm, or Windows), then check for alternate builds =
> that contains the necessary 'mysql' support.  If this build of snort was =
> compiled by you, then re-run the the./configure script using the =
> '--with-mysql' switch. For non-standard installations of a database, the =
> '--with-mysql=3DDIR' syntax may need to be used to specify the base =
> directory of the DB install.  See the database documentation for cursory =
> details (doc/README.database). and the URL to the most recent database =
> plugin documentation.
>
> What does that error came from ? How to fix it. I tried to compile =
> manually, but it is not working. My mysql server it up and running very =
> well. Snort db and tables are created via the snort_db_install_script.
>
> Please Help me, i tried snort-2.0.5 and snort 2.0.4 and snort 2.0.2
> Thank you in advance
> Michael
> ------=_NextPart_000_007E_01C3B8E6.F26AA4D0
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META http-equiv=3DContent-Type content=3D"text/html; =
> charset=3Diso-8859-1">
> <META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><FONT face=3DArial size=3D2>
> <DIV><FONT face=3DArial size=3D2>
> <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial size=3D2>Hi=20
> together,</FONT></SPAN></DIV>
> <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial=20
> size=3D2></FONT></SPAN> </DIV>
> <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial size=3D2>i have =
> a Problem=20
> with every snort version out there. The issue is that i compile snort =
> like=20
> that:</FONT></SPAN></DIV>
> <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial=20
> size=3D2></FONT></SPAN> </DIV>
> <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial =
> size=3D2>./configure=20
> --with-mysql</FONT></SPAN></DIV>
> <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial=20
> size=3D2>make</FONT></SPAN></DIV>
> <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial size=3D2>make=20
> check</FONT></SPAN></DIV>
> <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial size=3D2>make=20
> install</FONT></SPAN></DIV>
> <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial=20
> size=3D2></FONT></SPAN> </DIV>
> <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial size=3D2>during =
> the configure=20
> option it shows me that mysql support is ok. When i am done, there is =
> nothing.=20
> No /etc/snort, no subsys/snort, no var/log/snort and no /usr/sbin/snort. =
> There=20
> is really nothing. When i make a rpm of the tar file it is working, but =
> i can=B4t=20
> use it with mysql. After rpmbuild i got 2 Pakages snort and snort-mysql. =
> I=20
> installed both but every time i restart snort it tells me that it =
> can=B4t shut=20
> down the service. In the message log </FONT></SPAN></DIV>
> <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial=20
> size=3D2></FONT></SPAN> </DIV>
> <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial size=3D2>snort: =
> database:=20
> 'mysql' support is not compiled into this build of =
> snort</FONT></SPAN></DIV>
> <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial size=3D2>snort: =
> FATAL ERROR:=20
> If this build of snort was obtained as a binary distribution (e.g., rpm, =
> or=20
> Windows), then check for alternate builds that contains the necessary =
> 'mysql'=20
> support.  If this build of snort was compiled by you, then re-run =
> the=20
> the./configure script using the '--with-mysql' switch. For non-standard=20
> installations of a database, the '--with-mysql=3DDIR' syntax may need to =
> be used=20
> to specify the base directory of the DB install.  See the database=20
> documentation for cursory details (doc/README.database). and the URL to =
> the most=20
> recent database plugin documentation.</FONT></SPAN></DIV>
> <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial=20
> size=3D2></FONT></SPAN> </DIV>
> <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial size=3D2>What =
> does that error=20
> came from ? How to fix it. I tried to compile manually, but it is not =
> working.=20
> My mysql server it up and running very well. Snort db and tables are =
> created via=20
> the snort_db_install_script.</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT> </DIV>
> <DIV><SPAN class=3D407164813-02122003></SPAN><FONT face=3DArial =
> size=3D2>P<SPAN=20
> class=3D407164813-02122003>lease Help me, i tried snort-2.0.5 and snort =
> 2.0.4 and=20
> snort 2.0.2</SPAN></FONT></DIV>
> <DIV><FONT size=3D+0><SPAN class=3D407164813-02122003></SPAN><SPAN=20
> class=3D407164813-02122003></SPAN><FONT face=3DArial size=3D2>T<SPAN=20
> class=3D407164813-02122003>hank you in=20
> advance</SPAN><BR></FONT></FONT></SPAN><FONT face=3D"Lucida Sans =
> Unicode"=20
> size=3D2>Michael</FONT></DIV></FONT></DIV></FONT></DIV></BODY></HTML>
>
> ------=_NextPart_000_007E_01C3B8E6.F26AA4D0--
>
>
>
> --__--__--
>
> Message: 7
> From: "Grejda, Eric" <EGrejda at ...10102...>
> To: "'dunervst at ...348...'" <dunervst at ...348...>,
> snort-users at lists.sourceforge.net
> Subject: RE: [Snort-users] Problem with compiling snort
> Date: Tue, 2 Dec 2003 10:10:36 -0500
>
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
>
> ------_=_NextPart_001_01C3B8E6.706F5840
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> When you just do a build of the Snort source code (by using the make
> utility), it installs everything under /usr/local.  Things won't be =
> broken
> out into the Redhat directory structure you describe when you do that =
> unless
> you start passing further options to the configure script to set that =
> up.
> When you make an RPM file those options are set for you automatically.
> =20
> I ran into the same problem you describe, and it's really easy to fix. =
> If
> you change to the directory /usr/sbin and list all of the snort files =
> (ls
> -alF snort*) you'll see two different copies of the Snort binary,
> snort-mysql and snort-plain.  snort is a symlink to snort-plain, by =
> default.
> Change what the symlink points to: rm -f /usr/sbin/snort ; ln -s
> /usr/sbin/snort-mysql /usr/sbin/snort and try it again.  That's what I =
> had
> to do when I was building RPMs.
> =20
> By the way - great job on that.  It's made rolling Snort out on =
> multiple
> systems much, much easier.
>
> --
> Eric Grejda
>
>
> -----Original Message-----
> From: dunervst at ...348... [mailto:dunervst at ...348...]=20
> Sent: Tuesday, December 02, 2003 9:14 AM
> To: snort-users at lists.sourceforge.net
> Subject: [Snort-users] Problem with compiling snort
>
>
>
>
> during the configure option it shows me that mysql support is ok. When =
> i am
> done, there is nothing. No /etc/snort, no subsys/snort, no =
> var/log/snort and
> no /usr/sbin/snort. There is really nothing. When i make a rpm of the =
> tar
> file it is working, but i can=B4t use it with mysql. After rpmbuild i =
> got 2
> Pakages snort and snort-mysql. I installed both but every time i =
> restart
> snort it tells me that it can=B4t shut down the service. In the message =
> log=20
> =20
> snort: database: 'mysql' support is not compiled into this build of =
> snort
> =20
> What does that error came from ? How to fix it. I tried to compile =
> manually,
> but it is not working. My mysql server it up and running very well. =
> Snort db
> and tables are created via the snort_db_install_script.
>
>
> ------_=_NextPart_001_01C3B8E6.706F5840
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Diso-8859-1">
> <TITLE>Message</TITLE>
>
> <META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
> class=3D488190615-02122003>When=20
> you just do a build of the Snort source code (by using the make =
> utility),=20
> it installs everything under /usr/local.  Things won't be broken =
> out into=20
> the Redhat directory structure you describe when you do that unless you =
>
> start passing further options to the configure script to set that =
> up. =20
> When you make an RPM file those options are set for you=20
> automatically.</SPAN></FONT></DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
> class=3D488190615-02122003>I ran=20
> into the same problem you describe, and it's really easy to fix. If you =
> change=20
> to the directory /usr/sbin and list all of the snort files (ls -alF =
> snort*)=20
> you'll see two different copies of the Snort binary, snort-mysql and=20
> snort-plain.  snort is a symlink to snort-plain, by default.  =
> Change=20
> what the symlink points to: rm -f /usr/sbin/snort ; ln -s =
> /usr/sbin/snort-mysql=20
> /usr/sbin/snort and try it again.  That's what I had to do when I =
> was=20
> building RPMs.</SPAN></FONT></DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
> class=3D488190615-02122003></SPAN></FONT> </DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
> class=3D488190615-02122003>By the=20
> way - great job on that.  It's made rolling Snort out on multiple =
> systems=20
> much, much easier.</SPAN></FONT></DIV><!-- Converted from text/plain =
> format -->
> <P><FONT size=3D2>--<BR>Eric Grejda<BR></FONT></P>
> <BLOCKQUOTE dir=3Dltr=20
> style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
> solid; MARGIN-RIGHT: 0px">
>   <DIV></DIV>
>   <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
> align=3Dleft><FONT=20
>   face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
> dunervst at ...348...=20
>   [mailto:dunervst at ...348...] <BR><B>Sent:</B> Tuesday, December 02, 2003 =
> 9:14=20
>   AM<BR><B>To:</B> snort-users at lists.sourceforge.net<BR><B>Subject:</B> =
>
>   [Snort-users] Problem with compiling snort<BR><BR></FONT></DIV>
>   <DIV><FONT face=3DArial size=3D2>
>   <DIV><FONT face=3DArial size=3D2>
>   <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial =
> size=3D2>during the=20
>   configure option it shows me that mysql support is ok. When i am =
> done, there=20
>   is nothing. No /etc/snort, no subsys/snort, no var/log/snort and no=20
>   /usr/sbin/snort. There is really nothing. When i make a rpm of the =
> tar file it=20
>   is working, but i can=B4t use it with mysql. After rpmbuild i got 2 =
> Pakages=20
>   snort and snort-mysql. I installed both but every time i restart =
> snort it=20
>   tells me that it can=B4t shut down the service. In the message log=20
>   </FONT></SPAN></DIV>
>   <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial =
> color=3D#0000ff=20
>   size=3D2></FONT></SPAN> </DIV>
>   <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial =
> size=3D2>snort: database:=20
>   'mysql' support is not compiled into this build of =
> snort</FONT></SPAN></DIV>
>   <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial =
> color=3D#0000ff=20
>   size=3D2></FONT></SPAN> </DIV>
>   <DIV><SPAN class=3D407164813-02122003><FONT face=3DArial =
> size=3D2>What does that=20
>   error came from ? How to fix it. I tried to compile manually, but it =
> is not=20
>   working. My mysql server it up and running very well. Snort db and =
> tables are=20
>   created via the=20
>   =
> snort_db_install_script.</FONT></SPAN></DIV></FONT></DIV></FONT></DIV></=
> BLOCKQUOTE></BODY></HTML>
>
> ------_=_NextPart_001_01C3B8E6.706F5840--
>
>
>
> --__--__--
>
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-users
>
>
> End of Snort-users Digest
>





More information about the Snort-users mailing list