Case Study: A Lightweight Intrusion Detection System with OpenFaaS and PyTorch

Context

A growing eCommerce business running on a Hetzner VPS found itself increasingly targeted by brute-force attempts, vulnerability scanners, and automated bots. These attacks were not catastrophic, but they were persistent and probing — hitting login endpoints, admin routes, and known exploit paths.

The team, composed of six developers and one systems administrator, sought a solution that would:

• Detect potentially malicious behavior from access logs in real time
• Avoid vendor lock-in and monthly fees
• Improve its detection capabilities over time without manual tuning
• Run on its existing Docker-based infrastructure

---

Constraints and Requirements

The team rejected commercial SIEM solutions due to cost and complexity. They also did not want to introduce a full ELK stack for a single application. Instead, they set the following requirements:

• Use the existing NGINX access logs as the data source
• Run a lightweight function periodically to scan for anomalies
• Apply a model capable of learning and improving over time
• Store suspicious traffic patterns to retrain the model using real data
• Avoid alert fatigue by storing incidents rather than triggering noisy notifications

---

Solution Architecture

To meet these goals, the team built a modular, open-source intrusion detection system using:

• NGINX for logging
• OpenFaaS for scheduled, containerized function execution
• PyTorch for anomaly detection using a lightweight LSTM model
• JSONL file storage to capture and label suspicious activity

The function was scheduled to run every five minutes using the OpenFaaS Cron Connector.

---

Implementation Details

Model

The team trained a PyTorch model to learn the general behavior of normal HTTP requests. It was based on a small LSTM architecture that processed vectorized log lines. The model was trained on historical data from both normal and suspicious sessions, including known scanner patterns and simulated login abuse.

class LogAnomalyDetector(nn.Module):
    def __init__(self, input_dim, hidden_dim):
        super().__init__()
        self.lstm = nn.LSTM(input_dim, hidden_dim, batch_first=True)
        self.fc = nn.Linear(hidden_dim, 1)

    def forward(self, x):
        _, (h, _) = self.lstm(x)
        return torch.sigmoid(self.fc(h[-1]))

---

Detection Logic

Every five minutes, an OpenFaaS function reads a slice of the NGINX access log, transforms the raw text into numeric features, and runs the vectorized data through the PyTorch model.

If the model flags an entry with a high anomaly score, it is appended to a structured JSONL file:

{
  "timestamp": "2025-08-04T23:34:59Z",
  "score": 0.97,
  "raw": "192.168.0.1 - - \"GET /wp-admin HTTP/1.1\" 404 162"
}

The file is stored at /var/log/nginx/anomalies/suspect-log.jsonl and used later for retraining.

---

Why Store Instead of Alert?

The team opted not to trigger real-time notifications. Instead, they prioritized building a dataset of actual events to:

• Review activity in context
• Reduce false positives
• Retrain the model monthly using confirmed suspicious entries

This approach ensured that the detection system would improve over time based on real-world usage patterns.

---

Benefits and Outcomes

---

Future Roadmap

The team is considering the following enhancements:

• Adding a second OpenFaaS function to retrain the model automatically each month
• Introducing optional Telegram alerts for very high anomaly scores
• Building a dashboard to visualize trends in flagged traffic
• Expanding detection logic to include HTTP headers and POST bodies

---

Conclusion

This case study illustrates how a small engineering team can build a secure, intelligent detection system with minimal resources. By combining OpenFaaS with PyTorch and focusing on log-based learning instead of alerts, the company now has a practical, self-improving line of defense — deployed entirely within its own infrastructure.

---

Implementation support or explore a tailored deployment?

---