我想更轻松地从日志消息创build日志检查规则。 理想情况下，我想设置一些东西，使得我只接收一个我收到的logcheck消息，并将其传递给某个工具，然后在正确的位置使用正则expression式位进行日志检查。 然后根据需要对其进行检查并进行调整，然后将其与现有规则一起安装。 具体的上下文是，我目前正在得到一堆这样的消息： Sep 19 06:48:51 sideshowbarker kernel: TCP: drop open request from 186.2.166.213/31877 我已经非常了解如何从手动构build一个日志检查规则，将过滤这种types的消息。 我只是不想手动。 我宁愿自动化，至less部分。
我有两个服务器运行，一个与Apache和一个与Nginx的（都基于Ubuntu），他们正在发送syslogs到我的graylog2节点，但我希望Nginx提供我的访问日志，然后灯栈，以提供我充满错误日志以及。 我创build了一个名为90-graylog2.conf的文件，将syslog发送到我的graylog2节点。 $template GRAYLOGRFC5424,"%protocol-version% %timestamp:::date-rfc3339% %HOSTNAME% %app-name% %procid% %msg%\n" *.* @10.0.2.13:1514;GRAYLOGRFC5424 我只是不确定这样做的正确方法是什么。
我的Ubuntu服务器很长一段时间不能访问，只有重新启动服务器后，我可以再次访问。 我检查了系统日志文件，从昨晚开始显示类似于@@@@@@@@@@@@@，直到重新启动系统。 它是什么？
当一个新的端口在linux debian中侦听时，是否可以使用Syslog进行login？ 我怎样才能做到这一点？ 此外，有没有办法login到top或htop命令的syslog结果？ 问候
我正在浏览我的ELK堆栈中的一些syslog日志文件，并注意到所有的syslog_severity字段都是'notice'，当我可以在日志文件中validation它们不是'注意'的时候。 似乎Logstash默认syslog_severity需要注意。 我有这在我的logstashfilterconfiguration： filter { if [type] == "syslog" { grok { match => { "message" => "<%{NONNEGINT:syslog_pri}>%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:syslog_hostname} %{DATA:syslog_program}(?:\[%{POSINT:syslog_pid}\])?: %{GREEDYDATA:syslog_message}" } add_field => [ "received_at", "%{@timestamp}" ] add_field => [ "received_from", "%{host}" ] } syslog_pri { } date { match => [ "syslog_timestamp", "MMM d HH:mm:ss", "MMM dd HH:mm:ss" ] } } } 我已经看过这里提到的解决scheme，但不要认为这适用于我的情况，如果你看看我的filterconfiguration文件。 […]
我正在浏览我的ELK堆栈中的一些syslog日志文件，并注意到所有的syslog_severity字段都是'notice'，当我可以在日志文件中validation它们不是'注意'的时候。 似乎Logstash默认syslog_severity需要注意。 每当我去kibanasearch，无论我把什么放在logstashfilterconfiguration文件，kibana总是返回严重性通知。 我有这在我的logstashfilterconfiguration： filter { if [type] == "syslog" { grok { match => { "message" => "%{SYSLOG5424LINE}" } add_field => [ "received_at", "%{@timestamp}" ] add_field => [ "received_from", "%{host}" ] } syslog_pri { syslog_pri_field_name => "syslog5424_pri" } date { match => [ "syslog5424_ts", "ISO8601" ] } } } 我已经看过这里提到的解决scheme，但不要认为这适用于我的情况，如果你看看我的filterconfiguration文件。 我已经尝试了这里提到的解决scheme，并重新启动我的logstash服务 sudo service logstash […]
我的服务器在本周六00:00 CET的周末期间被封锁，原因不明，最后的syslog信息有点奇怪： Nov 18 23:58:58 ns kernel: [16705160.366491] [UFW BLOCK] IN=eth0 OUT= MAC=00:25:90:46:78:b6:00:1b:c6:10:dc:02:08:00 SRC=123.249.24.175 DST=xx.xxx.xx.xxx LEN=46 TOS=0x00 PREC=0x00 TTL=239 ID=54 321 ROTO=UDP SPT=34197 DPT=123 LEN=26 Nov 19 00:00:01 ns CRON[20272]: (root) CMD (invoke-rc.d atop _cron) ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ […]
就在几天前，我们突然间得到了像这样的信息，每隔几分钟就被转移到每个开放的terminal： 来自syslogd @ hartnell的消息在Wed Sep 2 11:15:27 2009 … hartnell clusvcmgrd [5887]：readServiceBlock：服务号码不匹配2，0。 我们正在运行： Linux hartnell.cluster 2.4.21-32.0.1.ELsmp＃1 SMP 2月17日17:46:36 EDT 2005 x86_64 x86_64 x86_64 GNU / Linux 红帽企业Linux AS版本3（Taroon更新9） 任何想法，为什么这可能突然开始？ 也许一个日志文件已经填满？
我在Solaris 10上遇到了系统日志的一些问题。看起来configuration不正确，日志消息堆积如山，永远不会写入/ var / adm / messages。 以下是/ var / adm / messages中的内容： Sep 10 03:10:17 air syslogd: Could not completely output pending messages while preparing re-configuration Sep 10 03:10:17 air syslogd: discarded 1082 messages and restart configuration. Sep 12 03:10:17 air syslogd: Could not completely output pending messages while preparing re-configuration Sep 12 03:10:17 […]
我一直在这个工作太久了。 我相信答案应该是显而易见的，但是… Snort手册： http ://www.snort.org/assets/125/snort_manual-2_8_5_1.pdf在第39页（根据Acrobat Reader第40页）列出了两个日志输出：“统一输出”和“日志文件输出”我猜测前者是指“统一”的输出模式…这让我觉得答案是“不，snort不能输出检测到端口扫描到系统日志的警报”。 我一直在使用的configuration文件是： alert tcp any 80 -> any any (msg:"TestTestTest"; content: "testtesttest"; sid:123) preprocessor sfportscan: proto { all } \ memcap { 10000000 } \ scan_type { all } \ sense_level { high } \ logfile { pscan.log } （是的，我知道很基本）。 一个简单的nmap触发输出到pscan.log 任何人都可以确认吗？ 或者指出我如何做到这一点？