[Snort-devel] Re: Snort v1.8.1 portscan.log owner problem?
erek at ...105...
Thu Aug 30 15:15:15 EDT 2001
[ comments inline ]
On Thu, 30 Aug 2001, JP Vossen wrote:
> I never got any kind of answer on this. Anyone know anything? My alerts
> still don't work, and snort crashes pretty often. Since I wrote a cron job to
> make sure it's still running, and restart if not, it's die on Aug 26, twixe on
> the 27th, 29th and 30th. This could be just a goofy machine. It's running
> RedHat 6.2 on an old 486...
Well... I've been running build 1.8.1-RELEASE build 76 since the cvsupdate on
the 28th with no issues. But then again, I'm running on Solaris. :-/
Try to run snort out of gdb and send the output in. There's instuctions in
the BUGS file on how to do that and what we'll need to see from the backtrace.
(Note: You'll get a much wider distro if you post to snort-users. Lots more
folks there who have seen things than here.... Here's where some of the main
brain cells for snort toss around ideas. There is where the lusers like me
hang out. :)
> Snort Ver: 1.8.1
> System Architecture: x86
> Operating System and version: RedHat Linux 7.1
> What rules (if any) you were using:
> What command line switches you were using:
> daemon /usr/sbin/snort -u snort -g snort -s -d -D -A fast -i $INTERFACE -l \
> /var/log/snort -c /etc/snort/snort.conf
> I noticed that snort creates in /var/log/snort/:
> -rw------- 1 root root 0 Aug 23 02:58 portscan.log
> But I'm running "-u snort -g snort". The docs say that -u/-g "Change the xID
> Snort runs under to YYYY after initialization. This switch allows Snort to
> drop root priveleges after it's initialization phase has completed as a
> security measure."
You're right. It _does_ create the file as root, but thats due to the code.
The check for file/open file/create file is done before it drops to the snort
user. If the file exists already it will be fine. You can touch it, chown
snort:snort it and all should be happy. Dig around on the archives, I posted
about that when -u and -g were first added.
> To me, this means that when snort tries to write to portscan.log it'll fail,
> yet I just tested it and it wrote to the file fine, even though ps shows it
> running as user snort. Am I missing something or did I screw up when I built
> the RPM or what?
Use the source, Luke! :) If you look at the code, the file is locked before
the UID/GID is changed. Since it's locked, you can still write to it as if
you were root. Not a Good Thing(tm). Have your startup script touch it, and
chown it before starting snort.
> I'm also confused about -s and -A. The the man page, it seems like -A and
> -D should result in a /var/log/snort/alert file, yet I don't get one.
> I'm also confused about the relationship between -A and -s, since the FAQ
> (6.17) seems to indicate a conflict between syslog and the alert file.
> Or is that only for .conf stuff.
Keep in mind that the command line options _override_ what is in the .conf
file. If your .conf has "output alert_syslog: LOG_AUTH LOG_ALERT" and you
place -A fast on your command line the -A option overrides what is in the
.conf file. Read the startup messages, it should say something to that
> Finally, I'm confused because I'm seeing
> what seems to be duplicate snort messages in my /var/log/loginlog,
> messages, and syslog. I'm using the stock RH7.1 syslog.conf, with a bunch
> of additions made by Bastille Linux. I can provide my syslog.conf if
> anyone cares to see it.
To see where it all goes: It's tedious, but useful. I have a copy of mine
hacked to do this when I need to track something down... For _each_ log
level, and for each log type have a seperate file. log.auth, log.local0,
log.local1, etc. Make sure you put all of them seperately, touch the files
and then restart syslogd. Fire off some alerts and see where they go. Many
times things aren't going to the facility and log level you're expecting.
Makes it a lot easier to track this way...
Hope this helps!
More information about the Snort-devel