Access logging is the practice of system monitoring via a file or a collection of files that detail all of the various activities on a system. Composed of various events and metadata, good access logging practices will help you stay informed on exactly what is happening in your infrastructure, and exactly who is carrying out these various activities. Logging can help system administrators and security engineers identify threats and discover vulnerabilities, and is critical to passing security audits.

The bottom line is that if you are maintaining any kind of infrastructure, whether it’s cloud-hosted virtual servers or local bare-metal boxes, access logging should be a key part of your infra-management. It’s important to know who did what, on which systems and why.

Access logs usually contain information like:

IP address or hostname of the client
Timestamps of operations or access attempts
Event metadata like “severity”
Result of an attempted operation (success/failure)
Log messaging output from the operation

It’s incredibly important to understand what types of data are being radiated and recorded by your system so that you can stay on top of your infrastructure.

Where can I find access logs?

Access logs are typically present on most web servers by default. Depending on the operating system of the server, the architecture and various other configuration settings, access logs can be recorded in many different places.

Here is an example of different default web server logging locations:

OpenSSH	`var/log/auth`
RDP	TerminalService-LocalSessionManager Operational log
Debian-based systems	`/var/log/apache2`
Rhel-based systems	`/var/log/httpd`
Nginx servers	`/var/log/nginx`
Information Services (IIS) on Windows	`C:\inetpub\logs\LogFiles\W3SVC`

Anatomy of an access log event

Aggregating discrete resources’ audit log collections makes it much easier to sift through access data at scale. Teleport centralizes all of your audit logging, across your entire infrastructure ecosystem all in one place, allowing you to easily keep a bird’s eye view of your network. Let’s take a look at an example log event recorded by a Teleport cluster when a user starts a database session:

{ "cluster_name": "teleport-cluster.example.com", "code": "TDL01I", "db_name": "postgres", "db_protocol": "postgres", "db_service": "aurora", "db_uri": "postgres.cluster-example.us-west-2.rds.amazonaws.com:", "db_user": "shared-dev", "ei": 0, "event": "db.session.start", "namespace": "default", "server_id": "example-id-4200912345", "success": true, "time": "2023-01-27T16:54:19.391Z", "uid": "example-user-id-41728512OU212", "user": "teleport-user-james-gandolfini" }

Here you can find a lot of useful information.

cluster_name: the domain name of the Teleport cluster that the user was accessing the database through
db_name: the name of exactly which database was accessed
db_protoco/db_service: the database protocol and service used by the database
db_uri: where the database is hosted
db_user: the username that the Teleport user logged into
event: the event type, in this case, “db.session.start” indicates the initialization of a database session
success: the status result of the event, in this case “true” (meaning they were able to log in successfully to the database)
time: the timestamp recording the time the database session started
uid/user: the Teleport user that initiated the session

A rich audit log can tell you a lot about the state of your infrastructure and help you keep your resources safe and secure for your users. Fields like `uid` and `user` are extremely important in a case like this where a user is impersonating a shared database user like “shared-dev”. In the database log itself you may see queries executed by “shared-dev” but in this case where the database user is shared by multiple team members, it can be difficult to pinpoint exactly who is accessing your system and what they are doing on it.

With solutions like Teleport Database Access, you are easily able to tie shared resource users to individual engineers’ identities. This is why it can be important to delve deeper than the resource default logging that is present on the resources natively.

Log capture best practices

Capture audit logging on both workstations AND servers.
- Attacks often occur on individual workstations first, which malicious actors then use to pivot to server access or domain controllers.
- Workstations’ audit logs often offer the earliest sign that something is wrong.
Balance performance and audit granularity.
- It is important to know that more granular audit logs will impact performance on both servers and individual workstations so it is important to run performance tests after you change logging settings.
- Don’t compromise on security to enhance performance but also avoid capturing extraneous log data noise.
Centralize your logs.
- Use an external tool, SIEM, or service to extricate all of your logs to a central location. This helps you better format them, organize them and store them for longer-term record keeping.
- Typically logs stored on the infrastructure resources themselves are only meant for short-term retention and will quickly be overwritten.
- Configure your event log size and retention settings to match the needs of your individual setup.

Staying vigilant

Overall if you follow the above guidelines as well as the specific logging policy implementations recommendations for your web servers, you will have much deeper insight into your networking infrastructure.

This is only the first step however in maintaining a secure and compliant network. A good third-party SIEM tool like Splunk or Datadog in conjunction with a Zero-Trust Identity-Native Infrastructure Access platform like Teleport will help you take that extra step to reach your compliance and security goals. You can try Teleport for free today.