Syslog server, A very basic syslog daemon written in assembler.

A very basic winsock v1.1 example of a Syslog Server.
( UDP Port 514 - Official, see Wikipedia )

The attached WinAsm Studio example project is an offshoot from my Router Control project that is still in developement.

The example was created to test router syslog responses after issuing control commands as well as monitor suspicious incoming WAN activity in real-time.

Since the router being used for developement does not conform completely to the RFC-3164 Syslog Message format standard, this example does not bother to analyze and decode the syslog messages that it receives.

I suspect this is probably very common since there are a lot of different hardware makers using different people with unique coding styles to write the firmware for these types of devices.

At least the RFC-3164 document hinted that it would not be uncommon to see subtle differences in datagrams from different applications or devices.


Being just an example...

If you need decoding & formatting, you'll have to add it, and are welcome to post questions on this topic anytime.

An excerpt of RFC-3164 is also included in this example project for your convienence. Of particular use are the syslog message Facility & Severity code tables. It briefly discusses the format of a syslog datagram as well.


In order to get the example to work you will need to...

• Build the project. ( Create the .exe PE file )

• Make sure your network devices and/or router are setup to send syslogs.

• Make sure that these devices send them to the IP address of the machine Simple Syslog Server is running on.

• Run the Simple Syslog Server example you built.

• Use a remote port scan, wait for a DOS attack, or turn the Line Control Protocol, (LCP), for your router on/off through software, and watch the log fill up!

If you are not sure what the IP address is for the machine this example runs from, just run the example anyway. It will display the Host Name and Host IP of the computer to direct syslogs to.


NOTES:

All syslogged activity from your router and/or other network devices will be logged into the listbox control of this example. It does not get logged to disk, and there are no options to save the logs it creates while running at this time.

What this means, is that the example does not care who (what IP) sent the syslog message. It collects all syslog messages if they are directed to it, regardless of their origin on your LAN. It also means you'll have to add your own disk logger.

• The example will display only the sender's IP address and the RAW syslog code & message.

• As an example it does very little error checking.


In summary...

This should be a good base for your own syslog project(s). I just wish someone had posted this for me over a year ago.

Enjoy!

Screenshot....


Attached Image

Here's the example WinAsm Studio project.

Current Version: 1.1

Last Update: Jan.21.2010

File Size: 31KB
MD5: 0d4499242735a77901729d9e65bb7971

Previous downloads: 11

Attached File ( Number of downloads: 23 )
 Login or Register to download

So...

You wanna have fun making your own Syslogger eh'?

Well here are a couple of wave audio files for use as alerts when something fishy is happening.

Enjoy!

Attached File ( Number of downloads: 11 )
 Login or Register to download

Nice work SeaFarer!

I've a lot to do at the moment. But will be back at the weekend. I was only able to get a quick overview about what you have done. Good to know that it is possible to retrieve windows messages which belongs to network. Never did it that way.

Keep up the good work!

Best regards,

XeS

Thanks XeS.

However these are not windows messages. They are syslog messages ( UDP Datagrams ) that are generated by WAN/LAN devices, or Servers, for the purpose of reporting or relaying simple status, error, or some other kind of event based message up the network chain. RFC-3164 has the complete details and history of the protocol.

Now you're starting to get an idea of why I wanted a tool like the one I'm building for my router huh?

Imagine being scanned or attacked and your router had no way to tell you locally? I mean... who keeps a seperate browser window open to watch the router log constantly? Plus the browser cache issues. Slick things can be had from remote.

Perhaps you had to rely on visual observation of indication lamps? Which, how helpful is that? It certainly is not as accurate as analyzing syslog events.

After all something could be happening while you're in the middle of a download!

Not anymore does the router need to be nearby using this type of software based technology! And no longer do the router's internal logs have to be checked, at least as often.

When finished the control will play different .wav files in the background and/or display popups for serious network events.

Red Alert.wav like Star Trek for different types of attacks. Something simple and short like a computer sound for status events.

Besides... emailing the logs is really a stupid option for a local need, it assumes your internet gateway is always up or assumes you run a local mail server.

But it is good to know that email is an option when static WAN IP & DynDNS are not options for relaying syslogs via port 514 across the WAN.

As I mentioned before...

This tool when complete will be something that should have been provided with Router/Modem. Likewise its proving ground and experience for the next gateway in the future that will employ FiOS versus ADSL2+.

Currently I am working on an NTP Server (Port 123 UDP) since the router no longer pings a WAN server for NTP now that syslogs go to a local LAN IP. Weird?

No matter. I'd much rather have the server sync time with NIST, then provide a local LAN based NTP service on port 123 for all other LAN devices and clients, especially the router. This will allow fairly tight timing in the disk based activity log and centralize stuff on a dedicated server.

Again no real technical info to go on other than the word "NTP" in the router setup.

Now that I have the RFC's, I'll start with UDP first and see how the router reacts. Given that port 514 is UDP, I suspect port 123 on the router to be no different.



btw - I have been side tracked. But today was nice enough (40') to turn on the compressor in the garage to blow all the dust out of the used equipment I picked up on monday. So its a good start for updating to a faster PC.

I'll try to write a little more back at you later, but the weekend should be more open for me as well.

@EDIT

I was a little confused with port numbers when I first posted.

NTP uses port 123 ( udp only ) DAYTIME uses port 13 ( udp or tcp/ip )

Darn! Things always have to get more complicated! Since the router uses NTP, this makes things a bit more difficult.

After reading the data formats for RFC-1305 and trying make sense of the specifactions, I am not even sure how to tackle this.

I think I'm going to have to find a better packet sniffer for this new project in order to analyze a complete NTP transaction. It is way more complex than the DAYTIME standard.

@EDIT

One other thing...

If you want a much better synopsis of NTP, RFC-1361 is a lot easier to read and digest. Although it defines SNTP, it gives a much easier to understand overview of NTP RFC-1305.

Its also much less reading!

This post has been edited by SeaFarer on Jan 16 2010, 07:55 AM