Closed GoogleCodeExporter closed 9 years ago
/etc/nsm/securityonion/sguild.email is the correct file.
You can restart sguild using the following command:
sudo nsm_server_ps-restart
I just tested and can confirm that email works. Make sure that you read all
the comments in sguild.email and quote variables when necessary. While
troubleshooting, reference the sguild log file:
/var/log/nsm/securityonion/sguild.log
Original comment by doug.bu...@gmail.com
on 5 Nov 2011 at 9:02
okay ! Thanks for the file.
I've made the same changes, but it is not better.
You can find my sguild.email :
# $Id: sguild.email,v 1.3 2006/01/18 19:23:00 bamm Exp $ #
#
# Configuration details for emailing alerts goes here.
# File is read on init and reread on a HUP.
#
# Enable the emailing of events. Don't worry about the other email options if
this
# is NOT enabled.
set EMAIL_EVENTS 1
# A smtp server to send through
set SMTP_SERVER 192.168.200.35
# Comma deliminated list of recipients.
set EMAIL_RCPT_TO "myemail@mydomain.com"
# The From/Reply to:
set EMAIL_FROM "root@localhost"
# Subject. This is optional.
# The subject can now use the msg subs too.
set EMAIL_SUBJECT "RT Event From %sn"
# Message format.
# %sn=sensor name %msg=snort message %t=timestamp %sip=src ip %dip=dest ip
# %sp=src port %dp=dst port %shost=src hostname %dhost=dst hostname
# %eid=event id (sid.cid) %sig_id=(signature ID) %class=(snort classification)
set EMAIL_MSG "\[%t\] ALERT %eid from %sn: %msg. %sip (%shost):%sp -> %dip
(%dhost):%dp"
# EMAIL_CLASSES: Space delimited classifications from the snort
classification.conf that
# you want to be emailed (paged) when an event matching that category triggers.
# Use the short names (ie successful-admin, successful-user, attempted-user,
etc)
set EMAIL_CLASSES "successful-admin trojan-activity attempted-admin
attempted-user" # misc-activity policy-violation"
# EMAIL_PRIORITIES: Space delimited list of priorities from the snort
classification.conf
# that you want to be emailed (paged) when an event matching that priority is
received.
# Use the integers 1-5
# 0=none
set EMAIL_PRIORITIES 1 2
#set EMAIL_PRIORITIES "0"
# EMAIL_DISABLE_SIDS: A list of snort IDs (sids) that you wish to disable from
the
# above classes (if any).
# 0=none.
#set EMAIL_DISABLE_SIDS "0"
# EMAIL_ENABLE_SIDS: A list of snort IDS (sids) that you want to enable, but
are NOT
# included in EMAIL_CLASSES. NOTE: This overrides EMAIL_DISABLE_SIDS.
# 0=none
#set EMAIL_ENABLE_SIDS "1000003"
For me, it seems to be good, but I don't receive any mails.
I've got a strange message in my sguild.log :
no clients to send msg to
So, I don't know where to search...
Thank you.
Original comment by jeansma...@gmail.com
on 7 Nov 2011 at 1:05
I destroyed the VM I originally confirmed this in, so I no longer have the
sguild.email that worked for me. I know when I got the correct configuration,
I saw an entry in sguild.log that said email was enabled (or something to that
effect).
Try quoting your variables like this:
set EMAIL_EVENTS "1"
set SMTP_SERVER "192.168.200.35"
set EMAIL_PRIORITIES "1 2"
Do you have events with priorities of 1 or 2? You could try enabling all of
them:
set EMAIL_PRIORITIES "1 2 3 4 5"
Original comment by doug.bu...@gmail.com
on 7 Nov 2011 at 1:12
I've tried the changes you said, but doesn't change anything. :-(
Maybe I've got two problems.
The first one, all my categories are "Unclassified".
The second, I've got this in my logfile :
2011-11-07 13:55:06 pid(1440) Client Command Received:
SendClientSensorStatusInfo
2011-11-07 13:55:06 pid(1440) Sending sock21: SensorStatusUpdate {4
{security-ossec security-ossec ossec {2011-11-07 07:17:01} 1} 5 {secuity-eth0
security-eth0 httpry {2011-11-07 13:35:25} 1} 1 {security-eth0 security-eth0
pcap {2011-11-07 13:53:27} 1} 2 {security-eth0 securty-eth0 sancp {2011-11-07
13:54:39} 1} 3 {security-eth0 security-eth0 snort {2011-11-07 13:43:39} 1}}
2011-11-07 13:55:09 pid(1440) Sensor agent connect from 127.0.0.1:55587 sock22
2011-11-07 13:55:09 pid(1440) Validating sensor access: 127.0.0.1 :
2011-11-07 13:55:09 pid(1440) Valid sensor agent: 127.0.0.1
2011-11-07 13:55:09 pid(1440) Sensor Data Rcvd: VersionInfo {SGUIL-0.8.0
OPENSSL ENABLED}
2011-11-07 13:55:09 pid(1440) Sensor Data Rcvd: RegisterAgent data
security-eth0 security-eth0
2011-11-07 13:55:09 pid(1440) Sensor Data Rcvd: SancpFile 2
parsed.security-eth0.stats.eth0.1320674073.20111107 775
2011-11-07 13:55:11 pid(1453) loaderd: Loaded
/nsm/server_data/securityonion/load/parsed.security-eth0.stats.eth0.1320674073.2
0111107 into the table sancp_security-eth0_20111107.
The question is, this line :
2011-11-07 13:55:09 pid(1440) Sensor agent connect from 127.0.0.1:55587 sock22
is it normal ?
Original comment by jeansma...@gmail.com
on 7 Nov 2011 at 1:56
When you say "Unclassified", do you mean "Unclassified" in Sguil?
"Classification" in this context is actually referring to the Snort (not Sguil)
classification. So take a look at a Snort rule and find the classtype. For
example:
alert ip any any -> any any (msg:"GPL ATTACK_RESPONSE id check returned root";
content:"uid=0|28|root|29|"; fast_pattern:only; classtype:bad-unknown;
sid:2100498; rev:8;)
In this case, the classtype is "bad-unknown".
To answer your second question, those log entries look normal to me.
Original comment by doug.bu...@gmail.com
on 8 Nov 2011 at 4:49
Let's try starting over and keeping it simple.
If you've already made a lot of changes to /etc/nsm/securityonion/sguild.email,
replace it with a fresh copy of the file:
sudo cp /usr/share/nsmnow/templates/server/sguil/config/sguild.email
/etc/nsm/securityonion/sguild.email
Modify /etc/nsm/securityonion/sguild.email by changing:
set EMAIL_EVENTS 0
to:
set EMAIL_EVENTS 1
and:
set SMTP_SERVER localhost
to:
set SMTP_SERVER smtp.example.com
(replace smtp.example.com with your actual SMTP server)
Restart sguild:
nsm_server_ps-restart
Verify that /var/log/nsm/securityonion/sguild.log shows it enabling Email:
Executing: sguild -c /etc/nsm/securityonion/sguild.conf -a
/etc/nsm/securityonion/autocat.conf -g /etc/nsm/securityonion/sguild.queries -A
/etc/nsm/securityonion/sgui
ld.access -C /etc/nsm/securityonion/certs
2011-11-08 00:05:30 pid(17666) Loading access list:
/etc/nsm/securityonion/sguild.access
2011-11-08 00:05:30 pid(17666) Sensor access list set to ALLOW ANY.
2011-11-08 00:05:30 pid(17666) Client access list set to ALLOW ANY.
2011-11-08 00:05:30 pid(17666) Adding AutoCat Rule:
||ANY||ANY||ANY||ANY||ANY||ANY||%%REGEXP%%^URL||1
2011-11-08 00:05:30 pid(17666) Email Configuration:
2011-11-08 00:05:30 pid(17666) Config file: ./sguild.email
2011-11-08 00:05:30 pid(17666) Enabled: Yes
2011-11-08 00:05:30 pid(17666) Server: smtp.example.com
2011-11-08 00:05:30 pid(17666) Rcpt To: root@localhost
2011-11-08 00:05:30 pid(17666) From: root@localhost
2011-11-08 00:05:30 pid(17666) Classes: successful-admin trojan-activity
attempted-admin attempted-user
2011-11-08 00:05:30 pid(17666) Priorities: 0
2011-11-08 00:05:30 pid(17666) Disabled Sig IDs: 0
2011-11-08 00:05:30 pid(17666) Enabled Sig IDs: 1000003
<snip>
If you're not seeing the Email Configuration in sguild.log, then something is
wrong with the sguild.email config file.
I did the above and then replayed a pcap with some attacks in it:
tcpreplay -i eth1 -t *.pcap
Check sguild.log file for Email activity:
root@Demo-Master:/etc/nsm/securityonion# grep Email
/var/log/nsm/securityonion/sguild.log
2011-11-08 00:05:30 pid(17666) Email Configuration:
2011-11-08 00:06:21 pid(17666) Sending Email: [2011-11-08 00:06:20] ALERT
8.703 from Demo-Master-eth1: GPL RPC STATD UDP stat mon_name format string
exploit attempt . 210.114.220.46 (Unknown):654 -> 192.168.1.102 (Unknown):919
2011-11-08 00:06:21 pid(17666) Email sent to: root@localhost
2011-11-08 00:06:21 pid(17666) Sending Email: [2011-11-08 00:06:20] ALERT
8.708 from Demo-Master-eth1: GPL FTP SITE overflow attempt . 207.35.251.172
(Unknown):2243 -> 192.168.1.102 (Unknown):21
2011-11-08 00:06:21 pid(17666) Email sent to: root@localhost
Check mail (I did this on an isolated network without an existing mail server,
so I installed a local mail server and aliased smtp.example.com to localhost in
/etc/hosts.):
root@Demo-Master:/etc/nsm/securityonion# mail
"/var/mail/root": 2 messages 2 new
>N 1 root@localhost Mon Nov 7 23:53 19/746 RT Event From
Demo-Master-eth1
N 2 root@localhost Mon Nov 7 23:53 19/714 RT Event From Demo-Master-eth1
Original comment by doug.bu...@gmail.com
on 8 Nov 2011 at 4:52
Thank you for your reply !
The start of the service with the email config file is good. I just had to make
a "cd /etc/nsm/securityonion" with a "nsm_server_ps-restart" there.
But in my log file, I've just one line with the grep Email, it's the line
"Email configuration:".
After that, nothing. As I have got some events on the web interface.
I've made some changes in /etc/sguil/sguil.conf with the same mail server, and
no problem, I can send emails with the Sguil application.
How can I test my ids with the PCAP ?
Thanks.
Original comment by jeansma...@gmail.com
on 8 Nov 2011 at 3:11
It shouldn't matter what directory you're in when you issue
"nsm_server_ps-restart". That command doesn't reference your current directory
at all.
Keep in mind that the events that show up when you first start (or restart)
Sguil are events that were already in the database and Sguil will not generate
emails for them. It only generates emails when new events come in that match
the criteria in sguild.email. It sounds like you don't have any new events
coming in that are in the default classifications: successful-admin
trojan-activity attempted-admin attempted-user.
You can do the same test I did by downloading the Honeynet Scan-of-the-Month
#19 file here:
wget http://old.honeynet.org/scans/scan19/scan19.tar.gz
tar zxvf scan19.tar.gz
sudo tcpreplay -i eth0 -t newdat3.log
(if necessary, replace eth0 with your sniffing interface)
Once tcpreplay finishes replaying the traffic, wait a few seconds and check
your log file again:
grep Email /var/log/nsm/securityonion/sguild.log
If all went well, you should see the same log entries that I copied above and
hopefully have some email.
Original comment by doug.bu...@gmail.com
on 9 Nov 2011 at 3:38
Thanks Doug for your help !
I received a mail this afternoon, with a single ping from an host to another. I
had never been so happy to have a mail.
In fact, the problem was the "attacks" were always the same, and if I've well
understand what you said, Sguil doesn't send mail if it had already been seen ?!
But can I change this mode to receive all by mail ?
Thanks a lot !
Original comment by jeansma...@gmail.com
on 9 Nov 2011 at 8:15
You're welcome!
Now that you've confirmed that mail is working, you can tweak the following
settings to tune exactly which events generate emails:
set EMAIL_CLASSES "successful-admin trojan-activity attempted-admin
attempted-user"
set EMAIL_PRIORITIES "0"
set EMAIL_DISABLE_SIDS "0"
set EMAIL_ENABLE_SIDS "1000003"
Just to re-iterate, when you first start the Sguil daemon, it will NOT generate
emails for those events which are already in the database. As new events come
in, Sguil will look at the variables listed above to determine whether an email
should be generated or not.
Original comment by doug.bu...@gmail.com
on 9 Nov 2011 at 9:21
Yes, I saw those lines.
I will tune with them after.
My question was in fact, how to have email with an event that repeats ?
For example, I've got a DNS server on my local network. Another server asks it
for an update of its records. This request is stored in the database, and I can
see it with the web interface.
But, I have no emails to prevent me of that.
I would like to receive an email for every event, even if it has already been
seen.
I don't know if I'm clear... !?
Original comment by jeansma...@gmail.com
on 9 Nov 2011 at 9:29
In that example, you should:
- look at the existing alert you have
- find the SID in the alert and add it to EMAIL_ENABLE_SIDS
- sudo nsm_server_ps-restart
From then on, EVERY time that event occurs you will then receive an email.
Original comment by doug.bu...@gmail.com
on 9 Nov 2011 at 9:35
"The start of the service with the email config file is good. I just had to
make a "cd /etc/nsm/securityonion" with a "nsm_server_ps-restart" there."
This was an important clue. I just wasn't smart enough to realize it at the
time! Thanks, jeansmacks!
I realized this morning that Sguild looks for sguild.email in the current
directory or in /etc/sguild/. Since /etc/sguild didn't exist, the email
configuration doesn't get loaded unless your current directory is
/etc/nsm/securityonion/. The best fix is to symlink /etc/sguild -->
/etc/nsm/securityonion/ and I've packaged this into an official update:
http://securityonion.blogspot.com/2011/11/security-onion-20111130-now-available.
html
Original comment by doug.bu...@gmail.com
on 30 Nov 2011 at 2:21
Trying to get sguild to send email alerts however receiving error "couldn't
open client socket:address already in use" is this a problem related to using
the workstation as both a server and a sensor? Thanks in advance for any replys
Original comment by hydersc...@gmail.com
on 1 Dec 2011 at 1:31
Hello hyderscott,
This particular issue is closed. What you describe is a separate issue.
Please create a new issue (or send an email to our mailing list) with as many
details as you can provide to troubleshoot this further.
Thanks,
Doug
Original comment by doug.bu...@gmail.com
on 1 Dec 2011 at 1:37
Doug, i replayed the capture from
http://old.honeynet.org/scans/scan19/scan19.tar.gz
and got an email notifications for that. However when I try to be notified
everytime a specific SID happens get nothing. I put the SID under set
EMAIL_ENABLE_SIDS "XXXXX"
Thanks
Original comment by johns01...@gmail.com
on 14 Feb 2013 at 4:18
This particular issue is closed. If you need further help, please use our
mailing list. Thanks!
Original comment by doug.bu...@gmail.com
on 14 Feb 2013 at 11:21
Original issue reported on code.google.com by
jeansma...@gmail.com
on 4 Nov 2011 at 12:23