AWS Instance Ingest Syslog TCP514

HI There. I am returning to Graylog after nearly a year. I have installed an AWS Instance from the link your web site and was able to access it via its public IP at the first attempt. This is a huge improvement over my previous experience so congratulations to all concerned.

Flushed with success I have redirected a TCP514 syslog from an adjacent AWS Centos image to my Graylog server. I created an input but it keeps failing. I’ve tried TCP, UDP, 513, 514, bind 0.0.0.0 and 127.0.0.1 and the AMI internal address of 10.0.0.22. I’m not seeing anything. I have two questions;

  1. When setting up the input you need to set a bind address. On an AMI should I specify the the internal IP address or does the AMI build link this to 0.0.0.0
  2. Will the Graylog server receive logs on port 514 or do I have to get the source changed to use a higher port such as 1514? (the source is a locked down image and I have to get the supplier to make the necessary change).

Thanks in advance

Hi,

0.0.0.0 should work. I am using that right now. The port should also be fine. You can easy verify by doing a netstat -tupl and check if 514 is there. If you don’t see traffic, check typical AWS things like security groups and NACL’s.

If you need more help, you have to share more bout then setup. Like if both machines are in the same VPC, AZ and or subnet. And what kind of ip you configure at the source end.

https://docs.graylog.org/en/latest/pages/faq.html#how-can-i-start-an-input-on-a-port-below-1024

1 Like

Thanks for your reply. You’re right I should have added some more info. Both machines are in the same subnet. I have an “allow all” rule from the source machine to the Graylog server in the Graylogs SG, to avoid any doubt there.

I’ll run that command and see whats there.
Thanks again.

Thanks for your reply. I saw that article but I’m have very little experience of unix. So i’m guessing I need to try and change my source to use an alternate (higher) port number. I’ll try Spix’s command and if I see traffic there I think i can assume that it its a case of Graylog not hearing it and so the port number will need to be changed.
I’ll let you know how I get on.
Thanks again.

Hi. I have an input configured for 514 which has failed and I run netstat -tupl but i do not see 514 listed.
So I hav now set up another input on port 1514 and guess what, its running AND I can see 1514 in the netstat tupl listing. So now i will get my source reconfigured…

thankyou thankyou thankyou

Yeah, so the graylog process is run by the user “graylog” which is not allowed by default to create servers listening on ports below 1024. The AMI is based on Ubuntu so there are some tricks to circumvent this, but if you are not experienced or don’t want to play with the protection “as designed” you have still one option, (next to changing the source). You could deploy an internal loadbalancer and use that to do the port translation. An extra advantage is the ability to scale your servers without creating any complex setups. Point all the syslog servers on port 514 to the LB and share the data on 1 or multiple graylog nodes on port 1514.

The only disadvantage i see is extra costs…

1 Like

Thanks Spix. That’s a good idea which I may return to if the Graylog server becomes a permanent fixture.
In the meantime I have had my source updated to use port 1514 but I’m still not seeing anything. As I have to communicate with a third party support team on another continent and 6 hours behind me, i was thinking of spinning up a free ubuntu server and generating some logs with that. If i see them then my problem points to the source, if I don’t then I must be missing something, or there’s something that needs to be done as part of bringing up the Graylog AMI which isn’t described in the text.

I’m just looking at my netstat -tupl listing again. There is a line
udp6 0 0 ip-10-0-0-22.eu-we:1514 [::]:*
but the state is blank not listening

My source allegedly is using UDP 1514.
Is there something Imust/can do to make the port listen?

It’s UDP and UDP has only one state (LISTENING) so it’s just not there because that would state the obvious. TCP has also other states (Closed, etc…)

The AMI is of the shelf working, no real (except pw and other doucmented things) changes are needed.

May I ask how do you conclude there aren’t any messages flowing in. What are your input statistics?

I am not seeing the counter increment on the inputs screen nor an i seeing any logs in the show recieved messages screen.

Ironically I’ve just realized that an initial set up had using a log forwarder seemed to burst into life earlier this evening, which if had noticed it would have prevented all this work, although its not an elegant solution.

Spinx. Good news. I changed my input type from Syslog UDP to Raw/Plaintext UDP and its working!!