Security you can verify

I harden MikroTik RouterOS to the same standard I hold my own infrastructure to: hardware-backed keys, encrypted everything, hostile traffic dropped at the edge. Security is not a service I sell on the side.

Verified at the source — MikroTik’s own security exam, the score confirmable on mikrotik.com.

  • MTCSE98%3 sittings since 2019 · 94% → 92% → 98%

The standard I hold

Every network decision passes one filter before any other: how does this fail, and who does it let in? These are the standards I do not move on — the reason the work is more deliberate, and the reason it holds.

  • 01

    Threat-model first

    Every protocol and configuration choice begins with how it breaks, not how it works — the failure case is the design input, not an afterthought.

  • 02

    Defence in depth, at every layer

    No single control is trusted to stand alone. The edge, the transport, the host, and the identity each carry their own guarantee, so one failure is contained instead of fatal.

  • 03

    Hardware-backed cryptography, non-negotiable

    Private keys never live on a general-purpose computer, and a physical touch is required for every operation — a stolen machine yields nothing.

  • 04

    Verifiable over trusted

    Every public claim is independently checkable. When privacy and marketing pull in opposite directions, privacy wins — every time.

  • 05

    Encrypted everything

    Nothing sensitive moves or rests in the clear; confidentiality and integrity are carried together, the way a regulated environment expects.

  • 06

    Operational security as discipline

    Least privilege by default, a clean line of responsibility — the customer owns the physical, I own the logical.

What I run in production

The security I actually run — production depth across the stack, nearly every line a capability in production.

Command by area

1 Learning · 2 Aware · 3 Confident · 4 Fluent · 5 Teach

  • deployed leaf
  • knowledge ahead of deployment
Security Introduction (3)
  • Common Network Attacks & MechanismsTeach
  • Threats OverviewTeach
  • RouterOS Security DeploymentTeach
OSI-Layer Attacks (4)
  • L2 Attack Prevention (MNDP/DHCP)Teach
  • Flood Prevention (TCP-SYN/UDP/ICMP-Smurf)Teach
  • Brute-Force Defense (FTP/Telnet/SSH)Teach
  • Port-Scan Detection & PreventionTeach
Cryptography (5)
  • Intro & TerminologyTeach
  • Encryption MethodsTeach
  • Symmetric & Asymmetric AlgorithmsTeach
  • PKITeach
  • Certificate TypesTeach
Securing the Router (4)
  • Port KnockingTeach
  • Secure Connections (HTTPS/SSH/WinBox)Teach
  • Default Service PortsFluent, knowledge ahead of deployment
  • SSH TunnelingTeach

Grouped by curriculum topic, deepest first. Solid indigo runs to the depth I deploy in production; the one hatched cap (service ports) marks knowledge ahead of an already-deep deployment.

  • Hostile traffic dies at the edge.

    Unsolicited connections are absorbed and dropped at the network edge before they cost a service anything; repeat offenders escalate to a longer shut-out, and reconnaissance scans are spotted and the source dropped. Defence in depth, three layers deep — the background noise of the internet never becomes your problem.

  • A cryptographic identity published in full.

    A 3-tier PKI with a public certificate chain and a live revocation list, a published GPG fingerprint, and every commit cryptographically signed — an identity that stands up to inspection, in public.

  • VPN chosen by threat model, not by convention.

    Modern encrypted transports — WireGuard, SSTP, IPsec IKEv2 — for new work; weak legacy protocols (L2TP/MPPE, PPTP) assessed honestly and migrated away, never left running because they were already there.

  • Access and SSH hardened to Ed25519, no password login.

    Ed25519 host keys with strong-crypto enforcement, hardware-backed authentication, a strict management allow-list, and no password login or weak-crypto fallback to climb down to.

  • Wireless hardened to WPA3 and 802.11r.

    802.11r fast transition, WPA3 with a WPA2 fallback only where a client needs it, management-frame protection, and one centralised security policy instead of a patchwork of access points configured by hand.

  • Attack-surface reduction as a habit.

    I generate keys air-gapped and RF-shielded, hold master keys offline in secure deposit, and keep a public revocation path so a compromise surfaces instead of hiding.

  • Disaster recovery with a tested failsafe path.

    Several independent ways back in when a primary path is lost, and recovery proven from encrypted offline backups — so a bad day stays a bad day, not a lost client.

The cryptographic standard, named

PKI
ECDSA P-384 (CA) / P-256 (end-entity)
Signing
Ed25519 — GPG and every commit
Encryption
Curve25519
SSH
Ed25519
DNSSEC
ECDSA P-256
TLS
1.2+, Perfect Forward Secrecy enforced

Public algorithms — every one independently checkable.

The security paradox

Most solo consultants ask you to trust their security. I publish the proof instead. Here is the difference, side by side — and everything you need to check it for yourself.

The typical solo consultantThis practice
Private keysSit on a laptop disk — one stolen machine is one stolen identity.Hardware-backed — the private key never touches a general-purpose computer, and a physical touch is required for every operation.
Cryptographic identityA self-signed certificate, with no revocation path once it leaks.A 3-tier PKI with a public certificate chain and a published revocation list.
What is actually protectedDisk encryption, and that is the whole story.Encrypted everything, plus DNSSEC-signed records, cryptographically signed commits, and private key material generated offline.
VPN protocol choiceWhatever the box shipped with — often a weak legacy default, left running because it was already there.Chosen by threat model — modern encrypted transports for new work, weak legacy assessed and migrated away.
Disaster recoveryOne backup, on the same disk that just failed.Several independent recovery paths, tested, restored from encrypted offline backups.
How you know it is trueTake my word for it.Verify it yourself, in public — the checks are right below.

Don’t trust it — check it

  • DNSSECdig +dnssec tarikin.comthe ad flag in the reply means the chain validates — independently, from your own machine.
  • GPG fingerprintA829 222C ADA3 8E9B E140 EA9C 11AE 5088 0470 27C4the public key lives on the public keyservers — match these characters before you trust a signature.
  • Signed commitsgit log --show-signatureevery commit carries a hardware-backed signature — the output shows a good signature and the key it matched.
  • Certificate authorityca.tarikin.comthe certificate chain and the live revocation list, published for anyone to inspect.

Agree a secret in plain sight

Two strangers agree a secret while you record every word they exchange. Watch it happen — then try to steal it.

stranger Aher secret turn · stays home
path: +76° → +38° = +114°
stranger Bhis secret turn · stays home
path: +38° → +76° = +114°
common baseher publichis publicthe shared colour

agreed at both ends — never sent

A colour model of the X25519 key agreement — the real one-way step lives on a curve, not in paint.

Your turn — you are the eavesdropper.

Drag the needle — how close can you get to the colour they agreed?

what you capturedcommon baseher publichis publicthe turns — never crossed
Distance to the secret—
your blendtheir secret colour
Why does it stop short?the maths behind the wedge

You are stuck 38° short — and 38° is exactly one of the two secret turns. A blend always lands between its ingredients, so everything you can pour lives inside the wedge — and the secret sits one turn beyond it. Could you cheat instead? On a colour wheel, yes: subtract the base from a public and a turn falls right out. Curve25519 is the wheel where that subtract button does not exist — running the step backwards is the hard problem, and the curve does not even leak how close you are. The whole secret rests on that missing button. Close is not a key.

And the two turns? Deleted the moment the session ended. That is Perfect Forward Secrecy — a full recording of the wire stays sealed: no key stolen later reopens it.

Name the math · X25519this round’s live numbers — verify, don’t trust
colour = hue angle
chip(H) = hsl(H, 88%, 52%) — 1° of hue = 1° on the wheel
public base
H₀ = 205°
private turns
a = +38° · b = +76° — never sent
A sends
(H₀ + a) mod 360 = 243°
B sends
(H₀ + b) mod 360 = 281°
A computes
(281° + a) mod 360 = 319°
B computes
(243° + b) mod 360 = 319° — identical: H₀ + a + b either way
your best blend
blend(t) = H₀ + t·max(a, b) → at most 281°
the gap
|319° − 281°| = 38° = min(a, b) — the smaller secret turn
the real thing
A = a·G · B = b·G · S = a·(b·G) = b·(a·G) = ab·G on Curve25519

Running this wheel backwards is one subtraction. Running Curve25519 backwards is the elliptic-curve discrete-log problem — no known shortcut faster than about 2^126 curve operations on today’s computers. The colours are reversible; the curve is not.

Colour is only the model here. The real one-way street is ECDLP on Curve25519 — a hard mathematical conjecture, not the physical impossibility of unmixing paint: these pigments could be separated again; the curve, as far as anyone knows, cannot be run backwards.

Forward secrecy seals the past, not the future: a stolen long-term key can still impersonate the server to new visitors until the certificate is revoked. It signs the handshake — it is never an input to the key schedule.

Drag the needle — how close can you get to the colour they agreed?

Vivid chip = a colour in play: the common base everyone can see, the two colours broadcast in the open, the shared colour agreed but never sent, and the eavesdropper’s blend. Each is labelled, and the readout prints the distance in degrees — nothing depends on colour alone.

The exchange also has a page of its own: a Diffie-Hellman key-exchange visualizer you can bookmark or send. Open the standalone visualizer →

Where the depth comes from

Specifics, not adjectives — the record behind the standard.

  • Lineage

    Threat modelling, grounded in how systems fail.

    Pentestit Zero Security: A — the course that grounded threat modelling as a design input — completed three months before the first MikroTik security exam.

  • Persistence

    The security exam, sat three times in six years.

    94%, then 92%, then 98% — the most recent the highest of any specialist exam I hold.

  • Recognition

    Ranked at the top of the field, then moved and kept building.

    #1 MikroTik consultant in Russia in 2019, #2 in Europe through 2021 — ranked on MikroTik’s own consultants page. Founder of the first authorised MikroTik training centre in Vietnam, and a MikroTik Trainer Candidate.

  • Delivery

    Three working languages.

    Russian at technical-native depth, English for documentation, Vietnamese for client-facing work on the ground.

  • Track record

    Zero breaches since 2015.

    A decade of financial-sector work under NDA.

Nikita Tarikin and the MikroTik trainer who examined him, Kuala Lumpur 2019, the MTCSE certificate shown on a laptop.
Kuala Lumpur, 2019 — minutes after the first MTCSE. Beside me, the MikroTik trainer who examined it; on the screen, the certificate. 94% on the first sitting.

The work is defensive engineering — architecture, hardening, key ceremony, threat modelling. I build the protection and prove it holds; that is the whole of the brief.

Where security connects

Security is a property of the whole network, not a box you bolt on — it leans on the domains around it, and the certification behind the claims.

MikroTik Certified Security Engineer (MTCSE) certificate issued to Nikita Tarikin — scored 98%.
The credential, in full

This is the issued MTCSE certificate — the document behind the 98%, shown whole.

Certificate ID 2505SE5381 — cross-checkable on mikrotik.com.

Bring me your security posture — a hardening pass, or an audit that tells you exactly where it holds and where it does not. I will scope it.

Scope a hardening pass or audit