I installed and configured suricata to give errors. It gave me error like
Jan 13 11:22:18 201612317 01/13/2017-11:22:18.308560 [] [1:2001219:20] ET SCAN Potential SSH Scan [] [Classification: Attempted Information Leak] [Priority: 2] {TCP}
I wanted to know what does this [1:2001219:20] mean in this rules ?
I found the answer. It is
1 is the classtype
2001219 is the alert id
20 is the revision
Related
I have a script that uses Net::SSH:Perl module. It is able to ssh to RHEL6.9 hosts but not RHEL7.4 hosts. I get the following error:
Protocol error: expected packet type 91, got 80 at /Net/SSH/Perl/Packet.pm line 221
How do I remedy this?
A simple search for the error message gives this post from 2016 and this bug report from 2016 which both indicate that the issue was fixed in version 2.01 of the module, released in 10/2016. Thus, you are probably using an older version and need to upgrade.
i have setup my YIIMP pool but seems that all blocks are rejected, i think is blocknotify problem
14:54:03: BTCRUBLE 213314 - diff 1.592820338 job e to 1/1/1 clients, hash 165.101/114.019 in 0.1 ms
14:54:05: *** REJECTED :( BTC RUBLE block 213314 1 txs
2018-02-02 14:54:05: REJECTED BTCRUBLE block 213314
14:54:23: BTC RUBLE 213314 not reporting
14:54:24: BTCRUBLE 213315 - diff 1.592820338 job f to 1/1/1 clients, hash 157.281/114.019 in 0.1 ms
14:54:25: *** REJECTED :( BTC RUBLE block 213315 1 txs
2018-02-02 14:54:25: REJECTED BTCRUBLE block 213315
My conf file of wallet is like this:
rpcuser=btcrublerpc
rpcpassword=mypassword
rpcport=4921
rpcthreads=8
rpcallowip=127.0.0.1
# onlynet=ipv4
maxconnections=12
daemon=1
gen=0
When i add this blocknotify part i get error blocknotify not found:
alertnotify=echo %s | mail -s "BTC RUBLE alert!" myemail#gmail.com
blocknotify=blocknotify 94.177.204.50:3433 1425 %s
Can someone help please? i can pay to get it working.
Thanks a lot!
To answer your question in your blocknotify call did you put /var/stratum in front of blocknotify example : blocknotify=/var/stratum/blocknotify 94.177.204.50:3433 1425 %s
Rejected blocks have nothing to do with 'blocknotify' that is mere a notification whenever a block has been found. It has no impact, whatsoever on mining.
The problem you are facing your blocks being rejected could be related to Yiiimp coin's admin misconfiguration per se or coin's conf file is not properly configured.
You need to thoroughly check BTCRUBLE's Settings and Daemon tabs in Yiimp coin's admin.
Apparently coin's conf seems fine perhaps you need to add this param
server=1
I need to be connect to 2 STM32s over 2 ST-Links at the same time. I found this issue described here.
However, solution doesn't work for me.
ST-Link ID1: 55FF6B067087534923182367
ST-Link ID2: 49FF6C064983574951291787
OpenOCD cfg file:
source [find interface/stlink-v2.cfg]
hla_serial "55FF6B067087534923182367"
source [find target/stm32f4x.cfg]
# use hardware reset, connect under reset
reset_config srst_only srst_nogate
I get:
$ openocd.exe -f stm32f4_fmboard.cfg
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Error: open failed
in procedure 'init'
in procedure 'ocd_bouncer'
I do not know if solved but:
pi#raspberrypi:~/prog/bootloader $ st-info --probe
Found 1 stlink programmers
serial: 363f65064b46323613500643
openocd: "\x36\x3f\x65\x06\x4b\x46\x32\x36\x13\x50\x06\x43"
flash: 0 (pagesize: 0)
sram: 0
chipid: 0x0000
descr: unknown device
this tool shows serial of st-links and there is option called openocd. When I put hla_serial "\x36\x3f\x65\x06\x4b\x46\x32\x36\x13\x50\x06\x43" in file then it works for me. Your way does not. It also does not work in command line given as argument. It works only as I described in cfg file
The format of the configuration file seems to have changed recently. The following applies for Open On-Chip Debugger 0.10.0+dev-00634-gdb070eb8 (2018-12-30-23:05).
Find out the serial number with lsusb, st-link, or with ls -l /dev/serial/by-id. The latter yields (with two STLink/V2.1 connected):
total 0
lrwxrwxrwx 1 root root 13 Nov 30 14:31 usb-STMicroelectronics_STM32_STLink_066CFF323535474B43125623-if02 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Dec 30 23:55 usb-STMicroelectronics_STM32_STLink_0672FF485457725187052924-if02 -> ../../ttyACM1
The specification on the .cfg-file is now plain hex. Do not use the C string syntax any longer. For selecting the latter device, simply write:
#hla_serial "066CFF323535474B43125623"
hla_serial "0672FF485457725187052924"
I need help regarding my cluster error:
[root#db2]# pcs status
Cluster name: oracluster
Last updated: Mon Feb 22 16:00:12 2016
Last change: Mon Feb 22 15:45:14 2016
Stack: corosync
Current DC: db2 (2) - partition with quorum
Version: 1.1.12-a14efad
2 Nodes configured
5 Resources configured
Online: [ db1 db2 ]
Full list of resources:
ClusterVIP (ocf::heartbeat:IPaddr2): Started db2
Clone Set: dlm-clone [dlm]
Stopped: [ db1 db2 ]
Clone Set: clvmd-clone [clvmd]
Stopped: [ db1 db2 ]
Failed actions:
dlm_start_0 on db2 'not configured' (6): call=18, status=complete, exit-reason='none', last-rc-change='Mon Feb 22 15:57:04 2016', queued=0ms, exec=34ms
PCSD Status:
db1: Online
db2: Online
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
Details:
I have 2 nodes (db1, db2) with shared storage (SAN). Both servers are in RHEL7.1. Now I want to add the storage as a resource. According to RHEL documentation DLM and CLVMD should be added also as a resource. I discovered that the error will disapper when STONITH is enabled, but still DLM is not starting. The log says it needs Fencing Device to be configured, which I don't have right now.
Any work around for this? Do we have a way to disable the fence mechanism and still make the cluster work? Thank you so much in advance!
you said that you have san storage, then you create a partion for fencing and use it as scsi stonith, il will solve your problem, like this exemple:
pcs stonith create scsi-stonith-device fence_scsi devices=/dev/mapper/fence pcmk_monitor_action=metadata pcmk_reboot_action=off pcmk_host_list="node1 node2" meta provides=unfencing
and don't forget to enable stonith with pcs property set stonith-enabled=true
Configure SONITH. It will help you to fix this issue.
I have been working with Snort IDS and I have successfully managed to generate some test logs. The problem I am facing has to do with their format(alert_fast). Some example logs are provided below.
07/23-20:08:56.631567 [] [1:2002911:4] ET SCAN Potential VNC Scan
5900-5920 [] [Classification: Attempted Information Leak] [Priority:
2] {TCP} 10.42.42.253:58606 -> 10.42.42.25:5906
07/23-20:08:56.685455 [] [1:2010937:2] ET POLICY Suspicious inbound
to mySQL port 3306 [] [Classification: Potentially Bad Traffic]
[Priority: 2] {TCP} 10.42.42.253:40328 -> 10.42.42.56:3306
Syslog-ng appends some sort of header to it giving:
Jul 23 20:08:56 SOME_IP 07/23-20:08:56.685455 [] [1:2010937:2] ET
POLICY Suspicious inbound to mySQL port 3306 [] [Classification:
Potentially Bad Traffic] [Priority: 2] {TCP} 10.42.42.253:40328 ->
10.42.42.56:3306
I need a way to get rid of that initial data. I tried using destination d_file { file(“/var/log/file.log” template(“$MSG\n”)); }; but then it yields:
08:56.685455 [] [1:2010937:2] ET POLICY Suspicious inbound to mySQL
port 3306 [] [Classification: Potentially Bad Traffic] [Priority: 2]
{TCP} 10.42.42.253:40328 -> 10.42.42.56:3306
As you can see some of the original log is also removed.
Please note that I want to avoid changing to a different Snort log format at all costs. Surely there must be some way to fix this?
syslog-ng is appending a syslog header to the messages because they do not seem to be well-formatted syslog messages, and syslog-ng does not parse them correctly.
Try to use a separate source for these messages, and set the flags(no-parse) option for the source. Then the template(“$MSG\n”) in your destination should give you the result you want.
Regards,
Robert Fekete
Thanks for responding Robert. Unfortunately I already had flags(no-parse) as part of my original setup. Here's what fixed it:
template my_template {
template("$MSGHDR$MSG\n");
template_escape(no);
};
...
destination some_name {
file("/var/log/snort/alert" template(my_template));
};