Instructor: Syslog.
Now syslog is a protocol for enabling different appliances
and software applications to transmit their logs
or event records to a centralized server.
Syslog is one of the things we talked about
back when we talked about SEAMS,
because it was one of the protocols we could use
to send data to the SEAM.
Now, syslog is going to follow a standard client server model
and this is the defacto standard for logging of events
from distributed systems across a network.
You are going to see syslog in use in so many
of the systems that you're going to work on in a daily basis.
Now, syslog this log runs on most operating systems
and on most networking equipment.
So whether you're using a Cisco router,
or you're using a Windows machine or a Linux server,
all of them can use syslog, and it's going to run over port
five, one, four or 514 using UDP over the TCP IP protocol.
Here on the screen, you can see a basic web front-end
for the pfSense, unified threat manager.
Notice here we have the remote logging options.
The first option is to send log messages
to a remote syslog server, we're going to check that
and say, yes, we want that to happen.
Then we're going to say, where's it coming from?
The source address is going to be the LAN.
Remember, this is a pfSense unified threat manager,
which is essentially a next generation firewall.
So we have to determine, are we going to be logging
the things coming from the outside or things coming
from the inside?
And in this case, we want to be logging things
from the inside, so we're going to use the LAN here.
Then we have what IP format we're going to use?
Are we using IPv4 or IPv6?
In our case, we're going to use IPv4.
Then, we enter in what servers we want it to go to
by their IP address and notice it's port five, one, four
or 514, because that is the UDP port for syslog.
Then we have all of our different options,
what do we want to send there?
And notice, we didn't just say send everything
because we don't want to overwhelm our SEAMs.
Instead, we've thought about what we want to capture.
We want to capture system events and firewall events
and DNS events and PPP events, which is things like
connecting from over remote access,
and we also want to send over our gateway monitoring events,
but the rest of it, we decided that wasn't important to us,
so we left those unchecked.
This is the idea of how easy it is to set up
remote logging and using syslog to send data back
based on the system that's already in place
using pfSense unified threat manager.
Now, when we send these messages back,
what does a syslog message look like?
Well, a syslog message is going to contain a couple of things.
It contains a PRI code, which is a priority code.
It contains a header and it contains a message portion,
let's talk about each of these.
First, we have this PRI code, this priority,
and this is going to be calculated based on the facility
and the severity level of the data.
Next, we have a header, and the header is going to contain
the timestamp of the event and the host name,
so we know where it came from and what time it was.
And hopefully we'll do that in UTC
so we can have everything in a nice standard format.
If not, your SEAM will probably convert it to UTC for you.
And finally, we have the message portion,
which contains the source process of the event
and the related content, basically, what data happened
and what do you want to tell us about?
And that's the idea here with the message portion.
This is the meat and potatoes of this message.
Now, when we dealt with syslog,
there was a couple of drawbacks to it
in the original version.
The original protocol relied on UDP,
as I said, UDP, port five, one, four.
Now, this can cause delivery issues with congested networks
because UDP is a fire-and-forget protocol.
It sends it and doesn't wait for response
and acknowledgement, and so it just assumes it got there.
If you have a congested network,
you can have data that is being dropped
and therefore your information is not going to get
to the log server and not be logged.
In the early days, this may have been okay,
because people assumed everyone on your network
was trustworthy, but these days we don't want that.
We want to make sure our data gets there,
so we're going to have to come up with a solution for this.
The second thing, is that there is not very many
basic security controls.
There wasn't anything like encryption or authentication
included by default with syslog,
and this again was another drawback.
So, in modern implementations of syslog,
we've corrected these things.
Now, due to these security issues,
our newer syslog implementations have added lots
of different features and capabilities
and we're going to talk about a couple of them here.
First, newer implementations use port 1468 for TCP
for consistent delivery.
This way, if the network gets congested
and that message can't get there,
it will redeliver it over and over again
because it's using TCP.
The second improvement, newer implementations can use TLS
or transport layer security to encrypt your messages
being sent to servers.
That way, that data in transit can't be read
by somebody else on the network, it can only be read
by the endpoint who sent it and the server
who's receiving it.
The third thing, is that newer implementations
also use MD-5 and SHA-1 to provide authentication
and integrity.
This way, the messages can have message authentication
and integrity as are transiting your network
to make sure they're not being messed with by anybody else.
This prevents any kind of man-in-the-middle attack
that could destroy the integrity of the message.
Additionally, we have this fourth thing,
which is that some newer implementations
can use message filtering, automated log analysis,
event response scripting, and alternate message formats.
Again, lots of other features, I'm not focusing
too much on this set though, because really
the three big ones that we care about is,
we've moved to TCP for a consistent delivery,
we have moved to TLS for encryption,
and we started using MD-5 and SHA-1
for authentication and integrity.
Now, this newer version of the server
is usually called syslog-ng for syslog next generation,
or rsyslog.
Now the final thing I want to mention about syslog
before we end this lesson, is that syslog
is often used to mean three things.
It can refer to the protocol that we send the data over,
it can refer to the server as in a syslog server,
or it can refer to the log entries themselves
as in syslog data.
People will often just say syslog and they mean all three
or any of these three, depending on the context.
So just be careful about that as you hear people
talking in the industry to make sure you understand
which one of the three they're talking about.