Custom rule not being added with sudo rule-update
565 views
Skip to first unread message
gary boyce
Dec 2, 2015, 11:16:09 AM12/2/15
to security-onion
I have added this rule to /etc/nsm/rules/local.rules
Alert icmp 8.8.8.8 any -> any any (msg:”ICMP”;
sid:9001511; rev:1;)
When I run sudo rule-update after adding a rule (only one in local.rules) it doesn't add any new rules.
Rule Stats...
New:-------0
Deleted:---0
Enabled Rules:----18079
Dropped Rules:----0
Disabled Rules:---4179
Total Rules:------22258
This is my first time with custom rules. I don't really need to get alerts on pings to or from 8.8.8.8 but the rule seemed simple enough to test with. What am I doing wrong? Also, Squil isn't showing anything based on the new rule after updating the rules either.
Alert icmp 8.8.8.8 any -> any any (msg:”ICMP”;
sid:9001511; rev:1;)
When I run sudo rule-update after adding a rule (only one in local.rules) it doesn't add any new rules.
Rule Stats...
New:-------0
Deleted:---0
Enabled Rules:----18079
Dropped Rules:----0
Disabled Rules:---4179
Total Rules:------22258
This is my first time with custom rules. I don't really need to get alerts on pings to or from 8.8.8.8 but the rule seemed simple enough to test with. What am I doing wrong? Also, Squil isn't showing anything based on the new rule after updating the rules either.
Doug Burks
Dec 2, 2015, 11:39:16 AM12/2/15
to securit...@googlegroups.com
Hi Gary,
Replies inline.
On Wed, Dec 2, 2015 at 11:13 AM, gary boyce <modsb...@gmail.com> wrote:
> I have added this rule to /etc/nsm/rules/local.rules
> Alert icmp 8.8.8.8 any -> any any (msg:”ICMP”;
> sid:9001511; rev:1;)
>
> When I run sudo rule-update after adding a rule (only one in local.rules) it doesn't add any new rules.
>
> Rule Stats...
> New:-------0
> Deleted:---0
> Enabled Rules:----18079
> Dropped Rules:----0
> Disabled Rules:---4179
> Total Rules:------22258
I think it's normal for these stats to not include local.rules.
> This is my first time with custom rules. I don't really need to get alerts on pings to or from 8.8.8.8 but the rule seemed simple enough to test with. What am I doing wrong? Also, Squil isn't showing anything based on the new rule after updating the rules either.
Are you sure your sensor is seeing ICMP traffic from 8.8.8.8?
--
Doug Burks
Need Security Onion Training or Commercial Support?
http://securityonionsolutions.com
Replies inline.
On Wed, Dec 2, 2015 at 11:13 AM, gary boyce <modsb...@gmail.com> wrote:
> I have added this rule to /etc/nsm/rules/local.rules
> Alert icmp 8.8.8.8 any -> any any (msg:”ICMP”;
> sid:9001511; rev:1;)
>
> When I run sudo rule-update after adding a rule (only one in local.rules) it doesn't add any new rules.
>
> Rule Stats...
> New:-------0
> Deleted:---0
> Enabled Rules:----18079
> Dropped Rules:----0
> Disabled Rules:---4179
> Total Rules:------22258
> This is my first time with custom rules. I don't really need to get alerts on pings to or from 8.8.8.8 but the rule seemed simple enough to test with. What am I doing wrong? Also, Squil isn't showing anything based on the new rule after updating the rules either.
--
Doug Burks
Need Security Onion Training or Commercial Support?
http://securityonionsolutions.com
gary boyce
Dec 2, 2015, 11:43:34 AM12/2/15
to security-onion
Doug Burks
Dec 2, 2015, 12:04:42 PM12/2/15
to securit...@googlegroups.com
If the ICMP traffic isn't making it to your Security Onion sniffing
interface, then the alert won't fire.
You'll need to make sure that your tap or span port is configured
correctly and collecting traffic from the proper location in your
network.
> --
> You received this message because you are subscribed to the Google Groups "security-onion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
> To post to this group, send email to securit...@googlegroups.com.
> Visit this group at http://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/d/optout.
interface, then the alert won't fire.
You'll need to make sure that your tap or span port is configured
correctly and collecting traffic from the proper location in your
network.
> You received this message because you are subscribed to the Google Groups "security-onion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
> To post to this group, send email to securit...@googlegroups.com.
> Visit this group at http://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/d/optout.
gary boyce
Dec 2, 2015, 12:24:35 PM12/2/15
to securit...@googlegroups.com
The monitoring interface is plugged into a 3560g cisco switch. The switch port is set as a monitoring port of the port the router is plugged into. If I plug my laptop to that port and run Wireshark I can see the improvement traffic.
Doug Burks
Dec 2, 2015, 1:57:11 PM12/2/15
to securit...@googlegroups.com
Can you see the ICMP traffic using tcpdump on the sniffing interface
(replacing eth1 with your actual sniffing interface)?
sudo tcpdump -nni eth1 host 8.8.8.8 and icmp
Are you getting other alerts?
Please run the following command:
sudo sostat-redacted
There will be a lot of output, so you may need to increase your
terminal's scroll buffer OR redirect the output of the command to a
file:
sudo sostat-redacted > sostat-redacted.txt 2>&1
sostat-redacted will automatically redact any IPv4/IPv6/MAC addresses,
but there may be additional sensitive info that you still need to
redact manually.
Attach the output to your email in plain text format (.txt) OR use a
service like http://pastebin.com.
(replacing eth1 with your actual sniffing interface)?
sudo tcpdump -nni eth1 host 8.8.8.8 and icmp
Are you getting other alerts?
Please run the following command:
sudo sostat-redacted
There will be a lot of output, so you may need to increase your
terminal's scroll buffer OR redirect the output of the command to a
file:
sudo sostat-redacted > sostat-redacted.txt 2>&1
sostat-redacted will automatically redact any IPv4/IPv6/MAC addresses,
but there may be additional sensitive info that you still need to
redact manually.
Attach the output to your email in plain text format (.txt) OR use a
service like http://pastebin.com.
gary boyce
Dec 2, 2015, 2:29:11 PM12/2/15
to security-onion
s# tcpdump -nni eth1 host 8.8.8.8 and icmp
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
19:28:01.529479 IP 192.40.125.129 > 8.8.8.8: ICMP echo request, id 1, seq 5447, length 40
19:28:01.544838 IP 8.8.8.8 > 192.40.125.129: ICMP echo reply, id 1, seq 5447, length 40
19:28:01.672145 IP 192.40.126.198 > 8.8.8.8: ICMP 192.40.126.198 udp port 65237 unreachable, length 174
19:28:01.677735 IP 192.40.126.198 > 8.8.8.8: ICMP 192.40.126.198 udp port 65237 unreachable, length 174
19:28:02.266303 IP 192.40.125.178 > 8.8.8.8: ICMP echo request, id 6843, seq 12557, length 64
19:28:02.282261 IP 8.8.8.8 > 192.40.125.178: ICMP echo reply, id 6843, seq 12557, length 64
19:28:02.542540 IP 192.40.125.129 > 8.8.8.8: ICMP echo request, id 1, seq 5448, length 40
19:28:02.557906 IP 8.8.8.8 > 192.40.125.129: ICMP echo reply, id 1, seq 5448, length 40
19:28:02.628519 IP 192.40.126.198 > 8.8.8.8: ICMP 192.40.126.198 udp port 47566 unreachable, length 168
19:28:02.723474 IP 192.40.126.198 > 8.8.8.8: ICMP 192.40.126.198 udp port 47566 unreachable, length 168
19:28:02.996850 IP 192.40.126.150 > 8.8.8.8: ICMP echo request, id 23301, seq 55000, length 64
19:28:03.012777 IP 8.8.8.8 > 192.40.126.150: ICMP echo reply, id 23301, seq 55000, length 64
19:28:03.267482 IP 192.40.125.178 > 8.8.8.8: ICMP echo request, id 6843, seq 12558, length 64
19:28:03.283473 IP 8.8.8.8 > 192.40.125.178: ICMP echo reply, id 6843, seq 12558, length 64
19:28:03.564490 IP 192.40.125.129 > 8.8.8.8: ICMP echo request, id 1, seq 5449, length 40
19:28:03.579857 IP 8.8.8.8 > 192.40.125.129: ICMP echo reply, id 1, seq 5449, length 40
19:28:03.789754 IP 192.40.126.162 > 8.8.8.8: ICMP 192.40.126.162 udp port 29237 unreachable, length 234
^C
17 packets captured
606 packets received by filter
0 packets dropped by kernel
gary boyce
Dec 2, 2015, 2:40:06 PM12/2/15
to security-onion
On Wednesday, December 2, 2015 at 1:57:11 PM UTC-5, Doug Burks wrote:
http://pastebin.com/embed_js.php?i=grz7BDM7
Doug Burks
Dec 2, 2015, 4:23:00 PM12/2/15
to securit...@googlegroups.com
Please follow the instructions here:
https://github.com/Security-Onion-Solutions/security-onion/wiki/Best-Practices
Then disable the following signatures which are firing quite a bit:
SURICATA STREAM 3way handshake with ack in wrong dir
SURICATA STREAM 3way handshake wrong seq wrong ack
SURICATA STREAM ESTABLISHED packet out of window
SURICATA STREAM Packet with invalid ack
SURICATA STREAM ESTABLISHED invalid ack
SURICATA STREAM ESTABLISHED retransmission packet before last ack
GPL SNMP public access udp
SURICATA STREAM Packet with invalid timestamp [1;62r [H [61;70H [1;61r [H [61d
SURICATA STREAM 3way handshake SYNACK resend with different ack
SURICATA STREAM 3way handshake SYN resend different seq on SYN recv
SURICATA STREAM 3way handshake right seq wrong ack evasion
SURICATA STREAM TIMEWAIT ACK with wrong seq
SURICATA STREAM CLOSEWAIT FIN out of window
SURICATA TLS invalid handshake message
SURICATA STREAM ESTABLISHED SYNACK resend with different ACK
SURICATA STREAM FIN2 invalid ack
SURICATA STREAM FIN out of window
SURICATA STREAM Last ACK with wrong seq
SURICATA STREAM FIN invalid ack
SURICATA STREAM SHUTDOWN RST invalid ack
SURICATA SMTP no server welcome message
SURICATA STREAM ESTABLISHED SYNACK resend with different seq
https://github.com/Security-Onion-Solutions/security-onion/wiki/ManagingAlerts
Then try your test again and see if you get alerts from your ICMP rule.
https://github.com/Security-Onion-Solutions/security-onion/wiki/Best-Practices
Then disable the following signatures which are firing quite a bit:
SURICATA STREAM 3way handshake with ack in wrong dir
SURICATA STREAM 3way handshake wrong seq wrong ack
SURICATA STREAM ESTABLISHED packet out of window
SURICATA STREAM Packet with invalid ack
SURICATA STREAM ESTABLISHED invalid ack
SURICATA STREAM ESTABLISHED retransmission packet before last ack
GPL SNMP public access udp
SURICATA STREAM Packet with invalid timestamp [1;62r [H [61;70H [1;61r [H [61d
SURICATA STREAM 3way handshake SYNACK resend with different ack
SURICATA STREAM 3way handshake SYN resend different seq on SYN recv
SURICATA STREAM 3way handshake right seq wrong ack evasion
SURICATA STREAM TIMEWAIT ACK with wrong seq
SURICATA STREAM CLOSEWAIT FIN out of window
SURICATA TLS invalid handshake message
SURICATA STREAM ESTABLISHED SYNACK resend with different ACK
SURICATA STREAM FIN2 invalid ack
SURICATA STREAM FIN out of window
SURICATA STREAM Last ACK with wrong seq
SURICATA STREAM FIN invalid ack
SURICATA STREAM SHUTDOWN RST invalid ack
SURICATA SMTP no server welcome message
SURICATA STREAM ESTABLISHED SYNACK resend with different seq
https://github.com/Security-Onion-Solutions/security-onion/wiki/ManagingAlerts
Then try your test again and see if you get alerts from your ICMP rule.
gary boyce
Dec 3, 2015, 8:59:58 AM12/3/15
to security-onion
Thanks for your help! I have stopped Snorby, all other services as outlined in best practices. I have also disabled the sids for the top ten most hit. I still don't see the ICMP alert being triggered or see ICMP for 8.8.8.8 in squil. Also, can you direct me to a link explaining how to clear ALL previous alerts so I can start fresh?
Doug Burks
Dec 3, 2015, 9:18:40 AM12/3/15
to securit...@googlegroups.com
In Sguil, select all alerts by clicking the first alert, holding down
Shift, and then clicking the last alert. Then press the F8 key to
categorize them and remove them from the RealTime Events tab.
It may be possible that you have a backlog of Suricata Stream events
and you won't actually see the new ICMP alert until barnyard has
completed processing the backlog. Are you still getting alerts from
the rules you disabled?
Shift, and then clicking the last alert. Then press the F8 key to
categorize them and remove them from the RealTime Events tab.
It may be possible that you have a backlog of Suricata Stream events
and you won't actually see the new ICMP alert until barnyard has
completed processing the backlog. Are you still getting alerts from
the rules you disabled?
gary boyce
Dec 3, 2015, 9:44:07 AM12/3/15
to security-onion
Thanks. I don't seem to be still getting alerts on the disabled sids. Is there any way to clear any backlog of Suricata Stream events?
gary boyce
Dec 3, 2015, 10:34:49 AM12/3/15
to security-onion
Looking at squil after a restart does show that I am still getting alerts on those disabled sids.
gary boyce
Dec 3, 2015, 10:39:12 AM12/3/15
to security-onion
this is my disablesid.con
cat /etc/nsm/pulledpork/disablesid.conf
# example disablesid.conf V3.1
# Example of modifying state for individual rules
# 1:1034,1:9837,1:1270,1:3390,1:710,1:1249,3:13010
1:2101411,1:2210020,1:22100:45,1:2210029,1:2210000,1:2210010,1:2210044,1:2210021
,1:2210046,1:2210015,1:2210003
# Example of modifying state for rule ranges
# 1:220-1:3264,3:13010-3:13013
# Example of modifying state for MS and cve rules, note the use of the :
# in cve. This will modify MS09-008, cve 2009-0233, bugtraq 21301,
# and all MS00 and all cve 2000 related sids! These support regular expression
# matching only after you have specified what you are looking for, i.e.
# MS00-<regex> or cve:<regex>, the first section CANNOT contain a regular
# expression (MS\d{2}-\d+) will NOT work, use the pcre: keyword (below)
# for this.
# MS09-008,cve:2009-0233,bugtraq:21301,MS00-\d+,cve:2000-\d+
# Example of using the pcre: keyword to modify rulestate. the pcre keyword
# allows for full use of regular expression syntax, you do not need to designate
# with / and all pcre searches are treated as case insensitive. For more informa
tion
# about regular expression syntax: http://www.regular-expressions.info/
# The following example modifies state for all MS07 through MS10
# pcre:MS(0[7-9]|10)-\d+
# Example of modifying state for specific categories entirely (see README.CATEGO
RIES)
# VRT-web-iis,ET-shellcode,ET-emergingthreats-smtp,Custom-shellcode,Custom-emerg
ingthreats-smtp
# Any of the above values can be on a single line or multiple lines, when
# on a single line they simply need to be separated by a ,
# 1:9837,1:220-1:3264,3:13010-3:13013,pcre:MS(0[0-7])-\d+,MS09-008,cve:2009-0233
# The modifications in this file are for sample/example purposes only and
# should not actively be used, you need to modify this file to fit your
# environment.
cat /etc/nsm/pulledpork/disablesid.conf
# example disablesid.conf V3.1
# Example of modifying state for individual rules
# 1:1034,1:9837,1:1270,1:3390,1:710,1:1249,3:13010
1:2101411,1:2210020,1:22100:45,1:2210029,1:2210000,1:2210010,1:2210044,1:2210021
,1:2210046,1:2210015,1:2210003
# Example of modifying state for rule ranges
# 1:220-1:3264,3:13010-3:13013
# Example of modifying state for MS and cve rules, note the use of the :
# in cve. This will modify MS09-008, cve 2009-0233, bugtraq 21301,
# and all MS00 and all cve 2000 related sids! These support regular expression
# matching only after you have specified what you are looking for, i.e.
# MS00-<regex> or cve:<regex>, the first section CANNOT contain a regular
# expression (MS\d{2}-\d+) will NOT work, use the pcre: keyword (below)
# for this.
# MS09-008,cve:2009-0233,bugtraq:21301,MS00-\d+,cve:2000-\d+
# Example of using the pcre: keyword to modify rulestate. the pcre keyword
# allows for full use of regular expression syntax, you do not need to designate
# with / and all pcre searches are treated as case insensitive. For more informa
tion
# about regular expression syntax: http://www.regular-expressions.info/
# The following example modifies state for all MS07 through MS10
# pcre:MS(0[7-9]|10)-\d+
# Example of modifying state for specific categories entirely (see README.CATEGO
RIES)
# VRT-web-iis,ET-shellcode,ET-emergingthreats-smtp,Custom-shellcode,Custom-emerg
ingthreats-smtp
# Any of the above values can be on a single line or multiple lines, when
# on a single line they simply need to be separated by a ,
# 1:9837,1:220-1:3264,3:13010-3:13013,pcre:MS(0[0-7])-\d+,MS09-008,cve:2009-0233
# The modifications in this file are for sample/example purposes only and
# should not actively be used, you need to modify this file to fit your
# environment.
Doug Burks
Dec 3, 2015, 11:16:38 AM12/3/15
to securit...@googlegroups.com
Suricata writes alerts into unified2 files in
/nsm/sensor_data/HOSTNAME-INTERFACE/. Barnyard2 reads those unified2
files and is probably still trying to process through the backlog of
Suricata Stream events. Try deleting the unified2 files and see if
that helps.
/nsm/sensor_data/HOSTNAME-INTERFACE/. Barnyard2 reads those unified2
files and is probably still trying to process through the backlog of
Suricata Stream events. Try deleting the unified2 files and see if
that helps.
gary boyce
Dec 3, 2015, 1:10:03 PM12/3/15
to security-onion
I deleted the unified2 files and restarted the nsm services. I am still seeing hits on the alerts for the sids that were disabled and I still am not seeing any alerts for my icmp rule.
Doug Burks
Dec 3, 2015, 1:44:30 PM12/3/15
to securit...@googlegroups.com
If you're still receiving alerts for sids that were disabled, then either:
- the sids weren't disabled (check /etc/nsm/rules/downloaded.rules to
verify that all disabled rules have been commented out)
and/or
- there are still old unified2 files. What is the output of the following?
ls -alh /nsm/sensor_data/*/*unified*
- the sids weren't disabled (check /etc/nsm/rules/downloaded.rules to
verify that all disabled rules have been commented out)
and/or
- there are still old unified2 files. What is the output of the following?
ls -alh /nsm/sensor_data/*/*unified*
gary boyce
Dec 3, 2015, 2:25:27 PM12/3/15
to security-onion
After closer inspection I found that the rules I disabled weren't being hit. It was similar rules I was seeing. I checked /etc/nsm/rules/downloaded.rules and I am seeing the rules I disabled commented out.
Immediately after removing all unified2 files it said "ls: cannot access /nsm/sensor_data/*/*unified*: No such file or directory" But after restarting the nsm services and letting it run for a while this is whats there.
ls -alh /nsm/sensor_data/*/*unified*
-rw-r--r-- 1 sguil sguil 33M Dec 3 17:05 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449160697
-rw-r--r-- 1 sguil sguil 33M Dec 3 17:32 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449162330
-rw-r--r-- 1 sguil sguil 32M Dec 3 17:57 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449163956
-rw-r--r-- 1 sguil sguil 32M Dec 3 18:13 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449165441
-rw-r--r-- 1 sguil sguil 32M Dec 3 18:27 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449166412
-rw-r--r-- 1 sguil sguil 33M Dec 3 18:44 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449167262
-rw-r--r-- 1 sguil sguil 2.2M Dec 3 18:45 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449168262
Immediately after removing all unified2 files it said "ls: cannot access /nsm/sensor_data/*/*unified*: No such file or directory" But after restarting the nsm services and letting it run for a while this is whats there.
ls -alh /nsm/sensor_data/*/*unified*
-rw-r--r-- 1 sguil sguil 33M Dec 3 17:05 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449160697
-rw-r--r-- 1 sguil sguil 33M Dec 3 17:32 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449162330
-rw-r--r-- 1 sguil sguil 32M Dec 3 17:57 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449163956
-rw-r--r-- 1 sguil sguil 32M Dec 3 18:13 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449165441
-rw-r--r-- 1 sguil sguil 32M Dec 3 18:27 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449166412
-rw-r--r-- 1 sguil sguil 33M Dec 3 18:44 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449167262
-rw-r--r-- 1 sguil sguil 2.2M Dec 3 18:45 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449168262
Doug Burks
Dec 4, 2015, 6:10:36 AM12/4/15
to securit...@googlegroups.com
Can you send new sostat-redacted output?
Also check the Suricata log file in /var/log/nsm/HOSTNAME-INTERFACE/
to see if there are any additional clues.
Also check the Suricata log file in /var/log/nsm/HOSTNAME-INTERFACE/
to see if there are any additional clues.
gary boyce
Dec 4, 2015, 8:16:59 AM12/4/15
to security-onion
There seems to be a problem with the signature/rule I created.
Do you see whats wrong with it?
root@Telpage-IDS:~# cat /var/log/nsm/Telpage-IDS-eth1/suricata.log
Executing: suricata --user sguil --group sguil -c /etc/nsm/Telpage-IDS-eth1/suricata.yaml --pfring=eth1 -F /etc/nsm/Telpage-IDS-eth1/bpf-ids.conf -l /nsm/sensor_data/Telpage-IDS-eth1
4/12/2015 -- 07:35:27 - <Notice> - This is Suricata version 2.0.8 RELEASE
4/12/2015 -- 07:35:27 - <Error> - [ERRCODE: SC_ERR_INVALID_VALUE(130)] - format error '”ICMP”'
4/12/2015 -- 07:35:27 - <Error> - [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "Alert icmp 8.8.8.8 any -> any any (msg:”ICMP”;sid:9001511; rev:1;)" from file /etc/nsm/rules/local.rules at line 1
4/12/2015 -- 07:35:27 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rules loaded from /etc/nsm/rules/local.rules
4/12/2015 -- 07:35:58 - <Notice> - all 4 packet processing threads, 3 management threads initialized, engine started.
http://pastebin.com/embed_js.php?i=vhDcT8TV
t
Do you see whats wrong with it?
root@Telpage-IDS:~# cat /var/log/nsm/Telpage-IDS-eth1/suricata.log
Executing: suricata --user sguil --group sguil -c /etc/nsm/Telpage-IDS-eth1/suricata.yaml --pfring=eth1 -F /etc/nsm/Telpage-IDS-eth1/bpf-ids.conf -l /nsm/sensor_data/Telpage-IDS-eth1
4/12/2015 -- 07:35:27 - <Notice> - This is Suricata version 2.0.8 RELEASE
4/12/2015 -- 07:35:27 - <Error> - [ERRCODE: SC_ERR_INVALID_VALUE(130)] - format error '”ICMP”'
4/12/2015 -- 07:35:27 - <Error> - [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "Alert icmp 8.8.8.8 any -> any any (msg:”ICMP”;sid:9001511; rev:1;)" from file /etc/nsm/rules/local.rules at line 1
4/12/2015 -- 07:35:27 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rules loaded from /etc/nsm/rules/local.rules
4/12/2015 -- 07:35:58 - <Notice> - all 4 packet processing threads, 3 management threads initialized, engine started.
http://pastebin.com/embed_js.php?i=vhDcT8TV
Doug Burks
Dec 4, 2015, 8:51:31 AM12/4/15
to securit...@googlegroups.com
The quotes around ICMP look incorrect. Try standard straight quotes
instead of curly quotes.
instead of curly quotes.
gary boyce
Dec 7, 2015, 2:19:56 PM12/7/15
to security-onion
I hope your weekend was good. I have changed the quotations in that rule, updated the rules, disabled the suricata stream catagory and ran sguil-db-purge, then restarted the server. I only have 54 items in que according to squert and I'm not seeing much on sguil. I have cat all items in sguil and I am still not seeing the alert for the rule I made. I am seeing the traffic on the interface.
sudo tcpdump -nni eth1 host 8.8.8.8 and icmp
19:18:43.665870 IP 8.8.8.8 > 192.40.125.129: ICMP echo reply, id 1, seq 2186, length 40
19:18:43.988344 IP 192.40.125.178 > 8.8.8.8: ICMP echo request, id 6843, seq 50190, length 64
19:18:44.003693 IP 8.8.8.8 > 192.40.125.178: ICMP echo reply, id 6843, seq 50190, length 64
19:18:44.687559 IP 192.40.125.129 > 8.8.8.8: ICMP echo request, id 1, seq 2187, length 40
19:18:44.702807 IP 8.8.8.8 > 192.40.125.129: ICMP echo reply, id 1, seq 2187, length 40
19:18:44.989895 IP 192.40.125.178 > 8.8.8.8: ICMP echo request, id 6843, seq 50191, length 64
19:18:45.005274 IP 8.8.8.8 > 192.40.125.178: ICMP echo reply, id 6843, seq 50191, length 64
19:18:45.681009 IP 192.40.125.129 > 8.8.8.8: ICMP echo request, id 1, seq 2188, length 40
19:18:45.691231 IP 192.40.125.140 > 8.8.8.8: ICMP 192.40.125.140 udp port 3069 unreachable, length 159
19:18:45.696264 IP 8.8.8.8 > 192.40.125.129: ICMP echo reply, id 1, seq 2188, length 40
19:18:45.991480 IP 192.40.125.178 > 8.8.8.8: ICMP echo request, id 6843, seq 50192, length 64
19:18:46.006808 IP 8.8.8.8 > 192.40.125.178: ICMP echo reply, id 6843, seq 50192, length 64
19:18:46.017505 IP 192.40.125.140 > 8.8.8.8: ICMP 192.40.125.140 udp port 59239 unreachable, length 86
^C
14 packets captured
344 packets received by filter
117 packets dropped by kernel
Any more ideas?
sudo tcpdump -nni eth1 host 8.8.8.8 and icmp
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
19:18:43.650611 IP 192.40.125.129 > 8.8.8.8: ICMP echo request, id 1, seq 2186, length 40
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
19:18:43.665870 IP 8.8.8.8 > 192.40.125.129: ICMP echo reply, id 1, seq 2186, length 40
19:18:43.988344 IP 192.40.125.178 > 8.8.8.8: ICMP echo request, id 6843, seq 50190, length 64
19:18:44.003693 IP 8.8.8.8 > 192.40.125.178: ICMP echo reply, id 6843, seq 50190, length 64
19:18:44.687559 IP 192.40.125.129 > 8.8.8.8: ICMP echo request, id 1, seq 2187, length 40
19:18:44.702807 IP 8.8.8.8 > 192.40.125.129: ICMP echo reply, id 1, seq 2187, length 40
19:18:44.989895 IP 192.40.125.178 > 8.8.8.8: ICMP echo request, id 6843, seq 50191, length 64
19:18:45.005274 IP 8.8.8.8 > 192.40.125.178: ICMP echo reply, id 6843, seq 50191, length 64
19:18:45.681009 IP 192.40.125.129 > 8.8.8.8: ICMP echo request, id 1, seq 2188, length 40
19:18:45.691231 IP 192.40.125.140 > 8.8.8.8: ICMP 192.40.125.140 udp port 3069 unreachable, length 159
19:18:45.696264 IP 8.8.8.8 > 192.40.125.129: ICMP echo reply, id 1, seq 2188, length 40
19:18:45.991480 IP 192.40.125.178 > 8.8.8.8: ICMP echo request, id 6843, seq 50192, length 64
19:18:46.006808 IP 8.8.8.8 > 192.40.125.178: ICMP echo reply, id 6843, seq 50192, length 64
19:18:46.017505 IP 192.40.125.140 > 8.8.8.8: ICMP 192.40.125.140 udp port 59239 unreachable, length 86
^C
14 packets captured
344 packets received by filter
117 packets dropped by kernel
Any more ideas?
Doug Burks
Dec 7, 2015, 4:44:39 PM12/7/15
to securit...@googlegroups.com
Please send the following:
/etc/nsm/rules/local.rules
Suricata log file
sostat-redacted output
/etc/nsm/rules/local.rules
Suricata log file
sostat-redacted output
Heine Lysemose
Dec 8, 2015, 3:00:10 AM12/8/15
to securit...@googlegroups.com
Hi
alert icmp any any -> 8.8.8.8 any (msg:"ICMP TO GOOGLES DNS"; sid:9001511; rev:1;)
What if you do the rule like...
Regards,
Lysemose
gary boyce
Dec 8, 2015, 8:56:43 AM12/8/15
to security-onion
With out changing anything else, I came in this morning to find alerts on my rule. Why would it take so long to show me the alerts?
> > >> >> > Visit this group at http://groups.google.com/group...
Doug Burks
Dec 8, 2015, 9:08:58 AM12/8/15
to securit...@googlegroups.com
Is it possible you're still dealing with a backlog of alerts?
gary boyce
Dec 8, 2015, 9:41:26 AM12/8/15
to security-onion
I don't believe so. I have changed sguil's purge maxuncat to 1000 and re-ran sguil-db-purge. I have also made autocats for all the more common sigs that are showing. This is all I'm showing in sensordata.
ls -alh /nsm/sensor_data/*/*unified*
-rw-r--r-- 1 sguil sguil 33M Dec 8 00:54 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449524935
-rw-r--r-- 1 sguil sguil 33M Dec 8 01:48 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449536075
-rw-r--r-- 1 sguil sguil 33M Dec 8 02:37 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449539308
-rw-r--r-- 1 sguil sguil 33M Dec 8 02:51 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449542229
-rw-r--r-- 1 sguil sguil 33M Dec 8 02:53 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449543101
-rw-r--r-- 1 sguil sguil 32M Dec 8 03:54 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449543191
-rw-r--r-- 1 sguil sguil 33M Dec 8 05:41 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449546864
-rw-r--r-- 1 sguil sguil 32M Dec 8 06:56 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449553262
-rw-r--r-- 1 sguil sguil 7.6M Dec 8 07:25 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449557809
-rw-r--r-- 1 sguil sguil 33M Dec 8 09:50 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449559568
-rw-r--r-- 1 sguil sguil 32M Dec 8 10:46 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449568211
-rw-r--r-- 1 sguil sguil 33M Dec 8 11:56 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449571560
-rw-r--r-- 1 sguil sguil 33M Dec 8 12:09 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449575770
-rw-r--r-- 1 sguil sguil 33M Dec 8 12:59 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449576597
-rw-r--r-- 1 sguil sguil 33M Dec 8 13:04 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449579574
-rw-r--r-- 1 sguil sguil 32M Dec 8 13:31 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449579856
-rw-r--r-- 1 sguil sguil 32M Dec 8 13:55 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449581488
-rw-r--r-- 1 sguil sguil 3.6M Dec 8 14:39 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449582950
ls -alh /nsm/sensor_data/*/*unified*
-rw-r--r-- 1 sguil sguil 33M Dec 8 00:54 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449524935
-rw-r--r-- 1 sguil sguil 33M Dec 8 01:48 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449536075
-rw-r--r-- 1 sguil sguil 33M Dec 8 02:37 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449539308
-rw-r--r-- 1 sguil sguil 33M Dec 8 02:51 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449542229
-rw-r--r-- 1 sguil sguil 33M Dec 8 02:53 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449543101
-rw-r--r-- 1 sguil sguil 32M Dec 8 03:54 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449543191
-rw-r--r-- 1 sguil sguil 33M Dec 8 05:41 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449546864
-rw-r--r-- 1 sguil sguil 32M Dec 8 06:56 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449553262
-rw-r--r-- 1 sguil sguil 7.6M Dec 8 07:25 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449557809
-rw-r--r-- 1 sguil sguil 33M Dec 8 09:50 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449559568
-rw-r--r-- 1 sguil sguil 32M Dec 8 10:46 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449568211
-rw-r--r-- 1 sguil sguil 33M Dec 8 11:56 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449571560
-rw-r--r-- 1 sguil sguil 33M Dec 8 12:09 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449575770
-rw-r--r-- 1 sguil sguil 33M Dec 8 12:59 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449576597
-rw-r--r-- 1 sguil sguil 33M Dec 8 13:04 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449579574
-rw-r--r-- 1 sguil sguil 32M Dec 8 13:31 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449579856
-rw-r--r-- 1 sguil sguil 32M Dec 8 13:55 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449581488
-rw-r--r-- 1 sguil sguil 3.6M Dec 8 14:39 /nsm/sensor_data/Telpage-IDS-eth1/snort.unified2.1449582950
Doug Burks
Dec 8, 2015, 9:45:07 AM12/8/15
to securit...@googlegroups.com
maxuncat and autocat don't have any effect on barnyard2. If barnyard2
is still processing a backlog of alerts, then there will be a delay
for new alerts appearing.
is still processing a backlog of alerts, then there will be a delay
for new alerts appearing.
gary boyce
Dec 8, 2015, 9:48:57 AM12/8/15
to security-onion
How do I clear the backlog or even check if there is one?
gary boyce
Dec 8, 2015, 3:52:17 PM12/8/15
to security-onion
Doug,
Thanks for your help on this matter. I am going to start a new thread since my original question was answered and my new question is unrelated to the original.
Thanks for your help on this matter. I am going to start a new thread since my original question was answered and my new question is unrelated to the original.
Reply all
Reply to author
Forward
0 new messages