Location Research Breakthrough Possible @S-Logix pro@slogix.in

Multinomial Naive Bayes-Based Detection of SSH Brute-Force Attacks Against OpenSSH Server Through Authentication Log Analysis and Gemma 2 2B Instruct-Powered Security Incident Investigation

Description

Organizations commonly use Secure Shell (SSH) to remotely access, administer, and manage Linux servers. OpenSSH Server provides SSH authentication functionality and records authentication-related events that can be used for security monitoring and incident investigation.

SSH authentication logs contain information about login attempts, authentication failures, successful logins, usernames, timestamps, and source addresses where these details are recorded. Repeated failed authentication attempts may indicate a brute-force attack, in which an attacker attempts to discover valid credentials by repeatedly trying to authenticate to an SSH service.

If SSH authentication activity is not monitored effectively, suspicious login patterns may remain unnoticed among legitimate authentication failures and other routine system events. Manually examining large volumes of authentication logs can also make it difficult to correlate related events and reconstruct the sequence of a potential attack.

In this use case, an Ubuntu OpenSSH Server is deployed in an isolated cybersecurity laboratory. Kali Linux is used as the security-testing environment to generate legitimate SSH activity and perform a controlled SSH brute-force attack against the authorized Ubuntu server.

An existing public SSH authentication-log dataset is used as the data source for the machine-learning stage. The dataset is inspected to determine whether it contains suitable normal and brute-force-related records, usable classification labels, and features compatible with the proposed model. The selected records are processed and transformed into numerical features for training.

Multinomial Naive Bayes is used to classify authentication-log records according to the categories supported by the selected dataset. The trained model is then evaluated against held-out records and tested with authentication logs collected during the controlled laboratory attack.

A Python-based log-analysis workflow correlates related authentication events using available information such as timestamps, source IP addresses, usernames, and authentication outcomes. SQLite is used to store relevant log evidence, classification results, correlated events, and investigation records.

Gemma 2 2B Instruct is executed locally through Ollama to analyze the correlated evidence and generate an incident summary, possible root-cause explanations, and recommended investigation steps. The generated report is verified against the original authentication logs to ensure that the conclusions are supported by the collected evidence.

The complete security-validation workflow is:
Public SSH Authentication-Log Dataset
→
Dataset Inspection
→
Normal and Attack-Related Record Selection
→
Data Preprocessing
→
Behavioral Feature Extraction
→
Multinomial Naive Bayes Training
→
Ubuntu OpenSSH Server
→
Controlled SSH Brute-Force Attack
→
Authentication Log Capture
→
ML-Based Log Classification
→
Authentication Event Correlation
→
SQLite Evidence Storage
→
Gemma 2 2B Instruct Analysis
→
Incident Timeline Generation
→
Incident Report Validation
→
Detection Performance Evaluation

Existing Security Problem

Application/Service: OpenSSH Server

OpenSSH Server is the target SSH service in this use case. It provides remote authentication functionality and generates authentication-related log records that can be examined during security monitoring and investigation.

The server is deployed on Ubuntu Linux within the authorized laboratory environment. Kali Linux is used to perform controlled SSH authentication testing against this server.

Existing Problem :

SSH services may receive repeated authentication attempts from unauthorized sources. When an attacker attempts to guess credentials through repeated login attempts, the resulting activity may generate numerous authentication failures.

However, authentication failures can also occur because of legitimate mistakes, outdated credentials, or incorrectly configured applications. Therefore, individual failed-login records cannot always establish whether an attack is occurring.

Traditional investigation may depend on manually examining logs or using predefined rules and fixed thresholds. These approaches can be useful, but they may require additional analysis when authentication events occur in different sequences or when legitimate and suspicious activity share similar characteristics.

The security problem is:
OpenSSH Server
→
Normal SSH Authentication Activity
→
Repeated Authentication Failures
→
Potential SSH Brute-Force Activity
→
Large Volume of Authentication Records
→
Manual Log Analysis and Event Correlation
→
Potential Detection Delays or False Alerts
→
Requirement for ML-Based Log Classification
→
Requirement for Evidence-Based Incident Investigation

The proposed solution introduces public-dataset-based model training, authentication-log classification, event correlation, evidence storage, LLM-assisted incident investigation, and detection-performance validation.

Attack

Specific Attack: Controlled SSH Brute-Force Attack

The controlled attack scenario evaluates whether repeated SSH authentication attempts against an Ubuntu OpenSSH Server can be recorded, analyzed, and identified by the proposed machine-learning-based detection workflow.

Kali Linux is used as the authorized security-testing machine, while Ubuntu hosts the target OpenSSH Server.

The attack simulation is restricted to the isolated VirtualBox laboratory. It uses a dedicated laboratory account and controlled authentication attempts rather than targeting external servers or third-party accounts.

The objective is to generate authentication-log evidence associated with the known test activity. The resulting records are processed by the trained Multinomial Naive Bayes model and correlated to support incident investigation.

The assessment also evaluates whether Gemma 2 2B Instruct can produce a useful incident summary from the collected evidence without introducing unsupported conclusions.

Attack Behavior :
Kali Linux Testing Machine
→
Connection to Authorized Ubuntu SSH Server
→
Controlled SSH Authentication Attempts
→
Repeated Failed Login Events
→
OpenSSH Authentication Log Generation
→
Authentication Log Capture
→
Log Preprocessing and Feature Extraction
→
Multinomial Naive Bayes Classification
→
Potentially Suspicious Activity Identification
→
Related Authentication Event Correlation
→
SQLite Evidence Storage
→
Gemma 2 2B Instruct Investigation
→
Incident Timeline and Report Generation
→
Detection and Evidence Validation

Security Concept

Machine Learning-Based Authentication Log Classification and LLM-Assisted Incident Investigation

The primary security concept is Machine Learning-Based Authentication Log Classification combined with LLM-Assisted Security Incident Investigation.

The first objective is to establish a suitable classification model using an existing public SSH authentication-log dataset. The selected records are processed into numerical features compatible with Multinomial Naive Bayes.

The second objective is to analyze authentication records generated by the controlled SSH brute-force simulation. The trained model classifies the captured records, and the investigation workflow correlates related events using the available authentication information.

The third objective is to use Gemma 2 2B Instruct to summarize the correlated evidence, reconstruct the observed incident timeline, and provide possible explanations that can be verified against the original logs.

The assessment follows:
Public SSH Authentication-Log Dataset
→
Dataset Suitability Assessment
→
Normal and Attack-Related Record Selection
→
Data Preprocessing
→
Feature Extraction
→
Multinomial Naive Bayes Training
→
Controlled SSH Brute-Force Simulation
→
Authentication Log Collection
→
ML-Based Log Classification
→
Authentication Event Correlation
→
Incident Timeline Reconstruction
→
Gemma LLM-Based Evidence Analysis
→
Incident Summary Generation
→
Evidence Verification and Performance Evaluation

Defensive Mechanism

The security concept defines the overall security strategy.

The following are the specific defensive mechanisms implemented.

Authentication Log Collection :

Authentication records are collected from the Ubuntu OpenSSH Server during legitimate activity and controlled attack simulation.

Purpose: Preserve the authentication evidence required for detection and investigation.

Public Dataset-Based Model Training

An existing public authentication-log dataset is inspected and processed to prepare suitable training records.

Purpose
  • Establish a reproducible data source for training and evaluating the classification model.

Multinomial Naive Bayes Classification

The trained model classifies authentication-log records using the feature representation established during training.

Purpose
  • Identify records belonging to the classification categories supported by the selected dataset.

Authentication Event Correlation

Related authentication events are grouped using available timestamps, source IP addresses, usernames, and authentication outcomes.

Purpose
  • Identify repeated authentication patterns and establish the sequence of related security events.

Controlled Attack Validation

The authentication records generated during the controlled SSH brute-force simulation are compared with the known testing activity.

Purpose
  • Evaluate whether the detection workflow identifies activity associated with the controlled attack.

Incident Timeline Reconstruction

Correlated authentication events are arranged chronologically to establish the progression of the observed activity.

Purpose
  • Provide a structured view of the authentication events associated with a potential incident.

Evidence Storage

Authentication records, ML predictions, correlation results, and investigation reports are stored in SQLite.

Purpose
  • Maintain structured evidence for investigation, comparison, and validation.

LLM-Assisted Incident Investigation

Gemma 2 2B Instruct analyzes the correlated evidence and generates an incident summary with possible explanations.

Purpose
  • Reduce manual effort in interpreting authentication evidence and preparing investigation reports.

Evidence Verification

The generated incident summary is compared with the original authentication logs and known laboratory test conditions.

Purpose
  • Prevent unsupported LLM-generated statements from being treated as confirmed findings.

Detection Performance Evaluation

The ML predictions are evaluated against suitable known labels and controlled test results.

Purpose
  • Measure classification effectiveness and identify false positives, false negatives, and detection limitations.

Security Tools

Primary SSH Service: OpenSSH Server

OpenSSH Server provides the SSH authentication environment being assessed.

Purpose
  • Provide the target SSH service.
  • Generate authentication records during login activity.
  • Support controlled SSH authentication testing.
  • Provide evidence for incident investigation.

Security Testing Platform: Kali Linux

Kali Linux provides the controlled security-testing environment.

Purpose
  • Perform authorized SSH testing.
  • Generate controlled authentication attempts.
  • Validate the expected attack-related log activity.
  • Support repeatable laboratory testing.

Target Operating System: Ubuntu Linux

Ubuntu provides the target server environment and supports the authentication-log analysis workflow.

Purpose
  • Host OpenSSH Server.
  • Maintain the controlled laboratory account.
  • Generate and store authentication logs.
  • Support log collection and analysis.

Virtualization Platform: VirtualBox

VirtualBox provides the isolated laboratory infrastructure.

Purpose
  • Host the Ubuntu and Kali Linux virtual machines.
  • Separate the target server from the testing environment.
  • Support controlled network communication.
  • Prevent unintended interaction with production infrastructure.

Programming and Automation Tool: Python

Python provides the main implementation environment for the detection and investigation workflow.

Purpose
  • Process authentication-log records.
  • Integrate the machine-learning model and LLM.
  • Automate event correlation.
  • Generate and validate incident reports.

Machine-Learning Library: Scikit-learn

Scikit-learn provides the Multinomial Naive Bayes implementation and classification-evaluation utilities.

Purpose
  • Train the classification model.
  • Generate predictions for test records.
  • Calculate precision, recall, and F1-score.
  • Produce confusion-matrix results.

Data Processing Tool: Pandas

Pandas is used to load, filter, and organize the public dataset and collected authentication records.

Purpose
  • Inspect dataset structure and labels.
  • Prepare records for model training.
  • Organize authentication events.
  • Analyze classification results.

Numerical Processing Tool: NumPy

NumPy supports numerical operations required for feature preparation and model processing.

Purpose
  • Prepare numerical feature arrays.
  • Support data transformations.
  • Assist with model input preparation.

Text Feature Extraction Tool: Scikit-learn CountVectorizer

CountVectorizer can transform suitable labelled authentication-log text into non-negative token-count features for Multinomial Naive Bayes.

Purpose
  • Convert log text into numerical representations.
  • Maintain consistent feature extraction between training and testing.
  • Provide compatible model input when the selected dataset supports text-based classification.

Local LLM Runtime: Ollama

Ollama provides the local execution environment for the selected language model.

Purpose
  • Run the supported language model locally.
  • Receive structured investigation evidence.
  • Return generated incident summaries.
  • Integrate LLM analysis with the Python workflow.

Large Language Model: Gemma 2 2B Instruct

Gemma 2 2B Instruct provides the LLM-assisted incident investigation capability.

Purpose
  • Summarize correlated authentication events.
  • Explain observed activity using the supplied evidence.
  • Suggest possible causes and investigation steps.
  • Generate structured incident reports.

Database: SQLite

SQLite provides the local database used to organize the investigation evidence.

Purpose
  • Store relevant authentication events.
  • Record model predictions.
  • Maintain correlated event references.
  • Store incident summaries and verification results.

Security Evaluation Tool: Scikit-learn Metrics

Scikit-learn metrics support quantitative model evaluation.

Purpose
  • Calculate classification precision and recall.
  • Measure F1-score.
  • Generate a confusion matrix.
  • Compare predictions against known labels

Process

STEP 01

Prepare the Isolated Cybersecurity Laboratory

  • Create an isolated cybersecurity laboratory using VirtualBox.
  • Configure Ubuntu as the OpenSSH Server and analysis environment.
  • Configure Kali Linux as the security-testing system.
  • Establish controlled network communication between the virtual machines.
  • Assign laboratory IP addresses as required.
  • Verify that Kali Linux can communicate with the Ubuntu server through the intended laboratory network.
  • Confirm that all attack simulation is restricted to the authorized laboratory.
Tools: VirtualBox + Ubuntu + Kali Linux
STEP 02

Deploy OpenSSH Server

  • Install and configure OpenSSH Server on the Ubuntu virtual machine.
  • Start the SSH service
  • Verify that the SSH service is operational.
  • Create a dedicated laboratory account for authentication testing.
  • Perform a legitimate SSH login to confirm that authentication functions correctly.
  • Record the initial server configuration and authentication behavior.
  • Verify that the SSH service is reachable only through the intended laboratory network.
Tools: OpenSSH Server + Ubuntu
STEP 03

Establish the Normal SSH Authentication Baseline

  • Use the authorized laboratory client to perform legitimate SSH login operations.
  • Generate successful authentication events.
  • Perform a controlled failed-login test to verify that authentication failures are recorded.
  • Inspect the available log fields, including timestamps, usernames, source addresses, and authentication outcomes.
  • Determine which records are available for subsequent analysis.
  • Preserve the normal authentication records as baseline evidence.
Tools: OpenSSH Server + Ubuntu + SSH Client
STEP 04

Identify the Public SSH Authentication-Log Dataset

  • Obtain an existing public SSH or authentication-log dataset suitable for the planned machine-learning experiment.
  • Review the dataset documentation, available fields, classification labels, and usage licence.
  • Determine whether the dataset contains suitable normal and brute-force-related records.
  • Verify whether the records can support the proposed Multinomial Naive Bayes classification task.
  • Compare the dataset format with the authentication records generated by Ubuntu OpenSSH Server.
  • Record any differences that may affect training and detection.
Tools: Python + Pandas
STEP 05

Inspect and Preprocess the Public Dataset

  • Load the selected dataset into the Python environment.
  • Inspect the available records and classification labels.
  • Identify missing fields, invalid records, duplicate entries, and inconsistent formatting.
  • Prepare a clean working dataset while preserving the original source data.
  • Review the distribution of the available classification categories.
  • Document the preprocessing operations and the number of usable records.
Tools: Python + Pandas + NumPy
STEP 06

Prepare the Classification Dataset

  • Identify the classification categories supported by the selected dataset.
  • Separate the data into training and testing portions.
  • Preserve the verified labels associated with each record.
  • Avoid placing duplicate or closely related records in both portions where this could produce data leakage.
  • Determine whether the dataset supports binary classification or a different classification task.
  • Record the final dataset distribution and the selected evaluation approach.
Tools: Python + Pandas + Scikit-learn
STEP 07

Extract Features from the Authentication Records

  • Identify the log characteristics suitable for classification.
  • If the dataset contains suitable labelled log text, use CountVectorizer to transform the records into non-negative token-count features.
  • If structured features are used, implement an appropriate numerical representation compatible with Multinomial Naive Bayes.
  • Fit the feature extractor using the training data.
  • Preserve the fitted feature-extraction configuration.
  • Verify that the prepared features are compatible with the selected machine-learning algorithm.
Tools: Python + Scikit-learn + Pandas + NumPy
STEP 08

Train the Multinomial Naive Bayes Model

  • Configure the Multinomial Naive Bayes classifier
  • Provide the processed training features and their verified labels.
  • Train the model using the selected public dataset.
  • Save the trained model and its corresponding feature-extraction configuration.
  • Verify that the model can generate predictions for compatible input records.
  • Record the training configuration for reproducibility.
  • Do not assume that successful training guarantees reliable detection on Ubuntu-generated logs.
Tools: Python + Scikit-learn
STEP 09

Evaluate the Initial Classification Model

  • Provide the held-out test records to the trained model.
  • Generate predictions for the test data.
  • Compare the predictions with the known test labels.
  • Calculate precision, recall, and F1-score where appropriate.
  • Generate a confusion matrix to examine the classification errors.
  • Inspect false positives and false negatives.
  • Record the evaluation results and determine whether the model is suitable for controlled laboratory testing.
Tools: Python + Scikit-learn + Pandas
STEP 10

Validate the Live Authentication Log Format

  • Generate legitimate SSH activity in the Ubuntu laboratory.
  • Collect the corresponding authentication records.
  • Inspect the actual log format and available fields.
  • Compare the live records with the public dataset used during training.
  • Determine whether the same feature-extraction process can represent both datasets consistently.
  • Verify that the live records can be transformed into the feature dimensions expected by the trained model.
  • Document any compatibility limitations before continuing.
Tools: Ubuntu + OpenSSH Server + Python + Pandas
STEP 11

Perform the Controlled SSH Brute-Force Attack

  • Configure Kali Linux as the authorized testing machine.
  • Use the dedicated laboratory account and target only the Ubuntu OpenSSH Server.
  • Generate a controlled sequence of repeated SSH authentication failures.
  • Keep the test volume limited to the requirements of the experiment.
  • Record the test start time, end time, target address, and known testing conditions.
  • Verify that the simulation does not affect external systems or third-party accounts.
  • Preserve the testing information for subsequent log validation.
Tools: Kali Linux + Ubuntu + OpenSSH Server
STEP 12

Capture and Validate the Attack-Related Authentication Logs

  • Inspect the Ubuntu authentication logs generated during the controlled test.
  • Identify records corresponding to the test using the recorded time window and available source information.
  • Preserve the relevant records as the original evidence.
  • Review the timestamps, usernames, source addresses, and authentication outcomes where available.
  • Confirm that the captured events correspond to the intended laboratory activity.
  • Record any missing information that could affect classification or correlation.
Tools: Ubuntu + OpenSSH Server + Python
STEP 13

Preprocess the Captured Authentication Logs

  • Parse the captured authentication records.
  • Normalize supported fields and handle missing or inconsistent values.
  • Apply the same preprocessing configuration established during model training.
  • Reuse the fitted feature extractor rather than fitting a new one on the attack records.
  • Verify that the generated features have the expected dimensions and ordering.
  • Check whether the captured records can be processed without losing important authentication information.
  • If the live logs are incompatible with the training pipeline, revise the data-processing approach before claiming successful detection.
Tools: Python + Pandas + NumPy + Scikit-learn
STEP 14

Perform Machine-Learning-Based Log Classification

  • Load the trained Multinomial Naive Bayes model and its fitted feature extractor.
  • Provide the processed laboratory authentication records to the model.
  • Generate predictions for the captured records.
  • Record the predicted category associated with each log entry.
  • Preserve references to the original records so that predictions can be verified.
  • Compare the predictions with the known laboratory test conditions and suitable ground-truth labels.
  • Record both successful classifications and incorrect predictions.
Tools: Python + Scikit-learn
STEP 15

Correlate Related Authentication Events

  • Review the classified authentication records.
  • Group related events using available timestamps, source IP addresses, usernames, and authentication outcomes.
  • Arrange the associated events chronologically.
  • Calculate relevant statistics, such as the number of failed attempts observed during the testing period.
  • Distinguish observed facts from interpretations based on repeated patterns.
  • Preserve references to the original records associated with each correlated event group.
  • Prepare the correlated evidence for database storage and incident investigation.
Tools: Python + Pandas
STEP 16

Store Authentication Evidence and Classification Results

  • Create the SQLite database required for the investigation workflow.
  • Define suitable tables for authentication events, classification results, correlated events, and incident reports.
  • Store relevant timestamps, source information, authentication outcomes, and ML predictions.
  • Maintain the known laboratory test condition separately from the model's prediction.
  • Associate each correlated event group with its original log records.
  • Verify that stored records can be retrieved for investigation and evaluation.
Tools: Python + SQLite
STEP 17

Generate the LLM-Assisted Incident Investigation Report

  • Prepare the correlated authentication events, relevant ML predictions, and chronological timeline.
  • Provide the structured evidence to Gemma 2 2B Instruct through Ollama.
  • Request an incident summary describing the observed authentication activity, supporting evidence, possible explanations, and recommended investigation steps.
  • Require the model to distinguish confirmed log evidence from hypotheses.
  • Review the generated report against the original authentication records.
  • Correct or flag unsupported claims before saving the report.
  • Store the verified report and its associated evidence references in SQLite.
Tools: Python + Ollama + Gemma 2 2B Instruct + SQLite
STEP 18

Perform Final Detection Validation and Incident Investigation Review

  • Repeat the workflow using legitimate SSH activity and controlled brute-force test activity.
  • Review the classification results for the available test records.
  • Evaluate the model using suitable ground-truth labels.
  • Review the accuracy of the correlated authentication timeline.
  • Compare the incident report with the original authentication evidence.
  • Identify false positives, false negatives, and unsupported LLM-generated conclusions.
  • Compare the public training data with the laboratory-generated logs and document any generalization limitations.
  • Record the final classification metrics, correlation results, and report-verification findings.
  • Finalize the security assessment with reproducible evidence and recommendations for improvement.
Tools: Python + Scikit-learn + SQLite + Ollama + Gemma 2 2B Instruct + OpenSSH Server + Kali Linux + Ubuntu

Outcome

An OpenSSH Server is successfully deployed on an Ubuntu virtual machine within an isolated cybersecurity laboratory for controlled SSH authentication testing.

The authentication logging behavior of the target server is validated using legitimate login operations and controlled failed-login tests, establishing the initial authentication evidence baseline.

An existing public SSH authentication-log dataset is inspected and processed to determine whether it supports the proposed Multinomial Naive Bayes classification task.

The selected dataset is transformed into numerical features, and the classification model is trained using the verified labels available in the public records.

The initial model performance is evaluated using held-out test data, providing measurable results for classification effectiveness and identifying false positives and false negatives.

A controlled SSH brute-force attack is performed from Kali Linux against the authorized Ubuntu OpenSSH Server, generating authentication records for the practical detection experiment.

The captured authentication records are processed using the established feature-extraction pipeline, allowing the trained model to classify compatible laboratory-generated log records.

Related authentication events are correlated using available timestamps, source addresses, usernames, and authentication outcomes, producing an evidence-based timeline of the observed activity.

SQLite stores the relevant authentication records, model predictions, correlated events, and investigation results in a structured format.

Gemma 2 2B Instruct analyzes the correlated evidence and generates a readable incident summary containing the observed activity, possible explanations, and recommended investigation steps.

The generated incident report is verified against the original authentication logs to identify unsupported conclusions and preserve the distinction between observed evidence and possible causes.

The classification results, event-correlation quality, and incident-report accuracy are evaluated using the available ground truth and controlled laboratory testing evidence.

The complete workflow of public dataset preparation, machine-learning training, SSH brute-force simulation, authentication log collection, ML classification, event correlation, evidence storage, LLM-assisted investigation, and final detection validation is demonstrated.

The final project provides a practical AI for Cybersecurity implementation that combines machine-learning-based authentication log classification with LLM-assisted security incident investigation, while documenting the detection limitations and data-compatibility requirements that affect real-world deployment.