How to stop all messages from a specific ip/source?

[QueenOfCode]

Hello

I have an input that I accidentally configured wrong, because two different IPs/sources are sending messages to this one input. Basically, their messages are getting put into the same pot. Whatever I do, I can’t seem to stop this connection between the Graylog input and the source I don’t want.

I’ve tried changing the source’s (the source I don’t want) listening port, remote logging server, etc., but nothing has worked. I can’t change the Graylog input’s listening port (i.e. shift the source I want to another input) because then I’d have to reconfigure the remote logging settings on that source, which right now is in a state I don’t want to touch. So the only way to separate the two sources is through working with the source I don’t want. (Hopefully that made sense?)

The good thing is, the two sources have different IPs. I thought of using extractors to somehow cut messages with a specific IP, but I’m not particularly sure how I would do that.

Or maybe there’s a pipeline rule I can apply? Though I’m not familiar with its rule syntax.

Something ideal would be “if message contains [ip/name], delete entire message”.

Anyone have any good suggestions?

Thanks!

[tmacgbay]

I don’t think you can drop a message with an extractor - or at least I couldn’t see a way to do it when I was poking around just now.

If you already have stream and pipeline attached creating the drop_message() rule is really easy. The docs have the syntax of the rule right here.

[QueenOfCode]

I see.

This is the rule I set up:

rule "drop message"
when
to_string($message.source) == "xxx.xxx.x.x"
then
drop_message();
end

However, if I do a query for that IP, I can still see its messages coming through. Is my rule correct, or is there something else I’m missing?

[tmacgbay]

The rule looks fine as long as “xxx.xx.x.x” is a placemarker for the real IP you are looking to drop.
That rule should be added to a stage in a pipeline that is connected to a stream that is attached to the input in question. You can use the debug() function line in the example drop_message() to see what is going on - debug() messages appear in the Graylog log that you can watch with the command:

tail -f /var/log/graylog-server/server.log

[QueenOfCode]

@tmacgbay

tail -f /var/log/graylog-server/server.log

Yes, I have the real IP in place of the xxx part, and everything was set up as described.
Do you mean put debug() under drop_message in the rule? Is there a way to see debug messages in the Graylog UI?

[tmacgbay]

debug() under the drop_message() is fine. You are looking to see if the rule is even firing off… if ithe debug doesn’t show up in the logs, the message is not reaching that rule for some reason. (i.e. you may need to adjust your message processor chain)

The only way to view the logs from debug() is watching that file (/var/log/graylog-server/server.log) on the Graylog server.

[gsmith]

Hello

@QueenOfCode

I have an input that I accidentally configured wrong, because two different IPs/sources are sending messages to this one input. Basically, their messages are getting put into the same pot. Whatever I do, I can’t seem to stop this connection between the Graylog input and the source I don’t want.

Just an Idea,
Logon to the device you don’t want to send messages to Graylog and stop the log shipper or disable send logs externally from that device.

Or change the port number and configure the device/s that you want to monitor with the new port number. If you change the port number only device /w that port # should be seen. This would depend on how you setup your input. If your still see this device after change the port number then there must be something not configure correctly.

EDIT: I just had a another thought. You can simple use Iptables and since you have the ip address to the device you don’t want, it is possible to drop it with iptables and/or Firewalld.

Example:

iptables -I INPUT -i eth0 -s 1.2.3.4 -j DROP

[QueenOfCode]

Thank you both - the logs from the source I don’t want have stopped now. I did change the port number from the source’s GUI - turns out, I’d thought it’d be immediate, but I guess it needed a few hours to implement/reflect the changes.

[gsmith]

Hello @QueenOfCode

@QueenOfCode

but I guess it needed a few hours to implement/reflect the changes.

It just might be that the journal was holding those messages before processing them.