DEV Community: Lekshmi Chandra

The Art of Predictable Estimations (Part 2): Staying Aligned Through Delivery

Lekshmi Chandra — Tue, 10 Mar 2026 08:12:05 +0000

In Part 1, we looked at how to build predictability into your initial estimates. But creating reliable plans isn’t a one-time exercise—it’s a continuous practice of staying aligned with your team, anticipating change, and protecting your delivery schedule. Here are the next steps to keep your estimates dependable.

Re-Evaluate and Communicate Early

Plans drift. People fall sick, requirements change, or unexpected events happen. Regularly check if your estimates still hold. When you spot risks, communicate early—transparency builds trust and gives you room to negotiate timelines before the pressure hits.

Always Include a Buffer

Last-minute surprises are inevitable. Protect your team by adding a buffer sprint. If nothing comes up, you finish early and look good. If something unexpected arises, you have breathing room to absorb it without burning out your team.

Lock in Cross-Team Deadlines

Dependencies can derail even the best plans. If your release is on September 27, make September 19 the cut-off for feedback from other teams. Managing upstream deadlines shields your team from last-minute chaos and keeps focus where it belongs—on delivering quality.

Run Estimates by Your Team for Feedback

Before committing to stakeholders, validate your estimates with the team doing the work. Walk through the high-level plan and ask for risks. Revisit this every few weeks—collect challenges, restate the launch plan, and nudge the team to think about what could go wrong. These conversations surface risks early and strengthen team ownership.

Build Visibility and Transparency

Use every tool available to keep your plans visible. Create graphs, charts, and dashboards that track progress accurately—double-check that your data comes from the right filters. Continuously analyze bottlenecks and highlight progress in your communications. Metrics aren’t just for reporting—they help the team see where they stand and where to adjust.

Takeaway Nugget

Predictable estimations thrive on transparency—when your team and stakeholders can see the plan, everyone can trust the plan and give their best.

The Art of Predictable Estimations (Part 1): Turning Uncertainty into Clarity

Lekshmi Chandra — Tue, 10 Mar 2026 08:10:59 +0000

In software delivery, predictability matters more than precision. The goal is not to guess the future— it is to navigate uncertainty without surprises and reach the strategic goal. Reliable estimates create trust, align teams, and protect focus. Here are five ways to make your estimates truly dependable.

Deocde all possible unknowns

Most estimations fail because we overlook the predictable distractions—vacations, training, team events, or chances of people being away due to other reasons. None of these are “surprises”; they’re just unplanned. Collect them early, keep a living list, and bake them into your estimates.

Build visibility into the timeline

Is your delivery overlapping with Christmas or the summer holiday rush? Make it visible to everyone. If there is engineering team working during the holidays and the product team will be on vacation, prepare ahead with more feature refinements so that we stay on track. A simple timeline showing these “impact zones” lets the team prepare and helps you adjust estimates before deadlines become unmanageable.

Create sprint breakdowns

On a tight schedule, a high-level sprint breakdown can reveal gaps early. Even rough outlines help identify risks, enabling product teams to swap or cut features before timelines crumble.

Prioritize ruthlessly: Must-Have vs. Should-Have

Not every feature belongs in your MVP. Keep asking, “Is this launch-critical, or can it follow right after?” Clarity here is the difference between meeting a delivery date and slipping into endless scope creep.

Estimate in ranges, not dates

Avoid committing to single-point dates like “September 15.” Instead, offer ranges:

Early: “Second half of September”

Midway: “On track for late September”

Near completion: “Tentatively September 26, unless minor issues push to the 28th.”

Ranges give flexibility, keep communication honest, and help manage expectations.

Takeaway nugget

Predictability isn’t about guessing right—it’s about preparing your team and stakeholders for what’s ahead.

What’s next?

In Part 2, we’ll explore the habits that keep your estimates reliable over time: re-evaluating progress, building buffers, and managing cross-team dependencies to avoid last-minute surprises.

Engineering Management Nugget #7: Undercommit and Overdeliver (On Purpose)

Lekshmi Chandra — Sun, 01 Feb 2026 05:05:39 +0000

One of the fastest ways teams lose trust is through overcommitment. Ambitious plans may look good on paper, but they often result in missed deadlines, stress, and reactive delivery.

For an EM, planning is not about optimism. It is about reliability. Overcommitment usually comes from optimistic estimates, unaccounted dependencies, constant context switching, and pressure from multiple stakeholders. When teams consistently overcommit, they spend more time explaining delays than delivering outcomes. Over time, this also leads to burnout.

Undercommitting does not mean lowering standards. It means planning with real constraints in mind — team capacity, focus time, and uncertainty.

How it works in practice:

In practice, this shows up as planning for less than theoretical capacity, making risks explicit, and treating stretch goals as optional rather than expected. Recommitment should happen only when progress is clearly closer to the finish line — and only if needed. Stakeholders value predictability far more than ambition when it comes to delivery.

Practically, it is important not to accept every timeline suggestion from stakeholders. Before committing, consider team capacity: existing priorities, vacations and dependency resolutions. Draft a plan and review it with the team as a confidence check. Always add a buffer of at least a sprint or a week, because unexpected issues are inevitable. The buffer creates breathing room and prevents corners from being cut. When this is communicated transparently, stakeholders better understand why timelines look the way they do.

Takeaway

When done intentionally, undercommitting and overdelivering supports realistic planning and more effective delivery.

Engineering Management Nugget #6: From Firefighting to Architecting

Lekshmi Chandra — Sun, 01 Feb 2026 04:44:04 +0000

The proportion of time a team spends firefighting — responding to incidents, fixing urgent issues, and reacting to last-minute escalations — is an important signal for an EM. While some level of firefighting is inevitable, living in this mode usually points to deeper system gaps.

Firefighting often feels productive because problems get solved quickly and it feels like we saved the day. However, firefighting pulls effort away from planned work and slowly builds a heroic culture. Over time, constant firefighting hides root causes such as:

unclear requirements and expectations
weak ownership
lack of in-depth system knowledge
missing or fragile processes

The cost eventually shows up as burnout, fragile delivery, and repeated issues.

An EM can influence this by architecting the system to keep firefighting at a minimum.
This is not about designing code — it’s about designing how work flows through the team.

This includes:

clear ownership and responsibility boundaries
predictable planning and review cycles
explicit decision-making frameworks
shared definitions of “done” and quality
guardrails that prevent common failure modes

The goal is not to eliminate problems, but to make them visible earlier and easier to handle.

How This Works in Practice

Track recurring incidents and ask why they repeat
Invest time in preventing the next failure, not just fixing the current one
Use retrospectives to adjust systems, not assign blame
Gradually shift time from urgent tasks to structural improvements

Takeaway

Firefighting solves today’s problem.
As systems improve through thoughtful architecting, emergencies reduce — and when they do happen, time and effort are used more effectively.

Engineering Management Nugget #5: Measuring Without Damaging Culture

Lekshmi Chandra — Sun, 01 Feb 2026 04:31:49 +0000

Metrics, when used well, create clarity and alignment.
Used poorly, they drive fear and shallow optimization.
An EM’s job is not just to measure, but to measure without breaking trust.

Why This Is Hard

Engineering work is complex and often non-linear. When metrics are treated as targets rather than signals, shallow optimization might be done just to correct the metric.

Common failure modes include:

measuring individuals instead of systems
using metrics to evaluate performance rather than to surface issues
reacting to short-term fluctuations instead of long-term trends

Metrics are not a scorecard. They are early warning signals of system and team health.

Good metrics help answer questions like:

Where are we slowing down?
Where is quality degrading?
Where is work getting blocked?

How This Works in Practice

Measure systems, not people. Focus on team-level flow, reliability, and quality.

For example, a poor metric is the number of commits per developer — people have different coding and committing styles.
Similarly, measuring the number or size of merge requests can be misleading. A one-line change can sometimes be more impactful than a 30-file refactor, such as a large renaming change.

Instead, measuring DORA metrics is useful. They surface trends around lead time, review time, deployment frequency, and reliability.

The most important signal is often the simplest:
Did the team on track for the desired outcome within the planned timeframe? If not, that should trigger a conversation with the team.
Transparency builds trust when metrics are not weaponized.

Looking at trends rather than snapshots is critical. One bad week or month is usually noise. Long-running patterns are signals. Metrics should always be paired with context.

Takeaway

As an EM, you set the tone that metrics are used to improve the system — not to rank, pressure, or compare individuals.
When teams feel safe around metrics, they surface problems earlier — and that is the real win.

Engineering Management Nugget #4: Guardrails Over Control

Lekshmi Chandra — Sun, 01 Feb 2026 04:09:55 +0000

From my perspective, building accountability in a team starts with understanding control.
The real leverage of an engineering manager is not tighter control, but well-designed guardrails.

Control often shows up as:

frequent check-ins
approval gates for small decisions
defining implementation details
monitoring activity instead of outcomes

Guardrails, on the other hand, look like:

clear goals and success criteria
explicit constraints around time, scope, and quality
shared standards and principles
predictable review and feedback loops

How This Works in Practice

Before work starts, make the why explicit.

Then align on:

priorities
non-negotiables
acceptable trade-offs

Use metrics and checkpoints as signals, not enforcement mechanisms.
Step in only when guardrails are crossed — not before.

Takeaway

An effective EM does not control execution.
They design guardrails that allow teams to move fast, safely, and independently.

Guardrails require trust and patience, but they scale far better than control.

Engineering Management Nugget #3: Stepping Back

Lekshmi Chandra — Sat, 31 Jan 2026 04:43:39 +0000

One of the core struggles of engineering management is balancing guidance with ownership.
Intervening too early harms autonomy; intervening too late creates avoidable risks. Knowing when to step back and when to step in is a hard but essential skill.

Why Stepping Back Matters

The primary goal of an EM is to build a team that can consistently deliver high-quality outcomes.
That only happens when teams learn to solve problems independently.

Over-involvement reduces accountability and increases dependency on the manager.
Stepping back is not neglect — it creates space for learning, ownership, and resilience.

For EMs with a technical background, this is especially challenging. You will often have strong opinions on how something should be built. But in the EM role, your responsibility shifts from designing solutions to setting guardrails — clarity on goals, constraints, and risks — not the implementation itself.

How This Works in Practice

Trust the team’s capability
Engineers usually know how to tackle tasks. Your role is to remove blockers and watch for major deviations in effort or scope.

Adjust based on experience
If a task is new to a developer, explicitly account for the learning curve. This investment compounds into future expertise.
For experienced engineers, step back further — let them lead and intervene mainly through questions that surface risks early.

Ask, don’t override
The right questions often do more than direct answers, while keeping ownership with the team.

Takeaway

When stepping into the EM role, the focus shifts from building features to building the team and systems that deliver them.
Your job is to make the why clear — and allow the team to own the how.

Engineering Management Nugget #2: Managing tech debt

Lekshmi Chandra — Fri, 30 Jan 2026 04:39:51 +0000

“Legacy” code is often treated as a problem to avoid.
In reality, every long-lived codebase becomes legacy. The question is not whether tech debt exists, but how deliberately it is managed.

Tech debt accumulates when codebases are not treated as systems that require ongoing maintenance. At the implementation level, this typically shows up as:

outdated dependencies
missing or brittle tests
poor design patterns
poor observability and health checks
delayed upgrades to supported platforms or frameworks

Left unattended, these reduce development speed and increase delivery risk.

Why Tech Debt Matters

A simple analogy works here:
you can cut a tree faster with a sharp axe than with a blunt one.

Teams working on poorly maintained systems spend more time compensating for friction — slower builds, fragile deployments, unexpected regressions. Over time, this directly impacts predictability and morale.

How Engineering Managers Influence Tech Debt

The EM’s role is not to fix tech debt personally, but to shape how the team approaches maintenance.

One effective approach is to build a culture of continuous maintenance:

reserve a small portion of each sprint for improvements
treat maintenance work as planned, scoped tasks
prioritize it after sprint goals, not instead of them

This is similar to gardening: small, regular effort prevents large cleanups later. Attempting to “fix everything” in one dedicated window often fails due to unclear scope and competing priorities.

A continuous approach works better because:

maintenance tasks are refined and bounded
engineers understand limits before starting
work gets completed instead of deferred

Where This Shows Up in Practice

Automate what you can: dependency update bots, CI checks, static analysis
Keep tech debt visible in planning and refinement
Use EM and Tech Lead collaboration: EMs provide outside perspective, Tech Leads drive execution
Monitor the maintenance-to-feature ratio — enough to stay healthy, not so much that delivery stalls

Tech debt management is like going to the gym: consistency matters more than intensity. The goal is system health, not perfection.

The Takeaway

Tech debt is unavoidable. Neglect is optional.

Approaching tech debt as continuous maintenance keeps systems healthy and delivery predictable — without slowing the business down.

Engineering Management Nugget #1: Managing expectations

Lekshmi Chandra — Fri, 30 Jan 2026 04:11:52 +0000

Missed deadlines and overtime are rarely caused by poor execution.
They are usually the result of misaligned expectations early in the delivery cycle.

When scope, capacity, or timelines are unclear, teams compensate late. Over time, creates reactive delivery and reduces predictability. Managing this alignment is a core responsibility of an engineering manager.

Why Expectation Management Matters?

Engineering managers operate between multiple stakeholders, but the primary responsibility is toward the engineering team. Sustainable delivery depends on it.

Delivery risk typically accumulates through small, compounding factors:

optimistic estimates
incremental change requests
unplanned dependencies
fluctuating team availability

Individually, these are manageable. Together, they distort timelines. The EM’s role is to surface these constraints early and realign expectations before they compound.

Make Reality Visible

Expectation management becomes easier when reality is visible.

Clear views of:

team capacity
delivery progress
known risks and dependencies

shift discussions from assumptions to facts. Transparency reduces surprise, and reduced surprise improves trust. When stakeholders understand constraints, collaboration improves.

Where This Shows Up in Practice

At the daily level, ambiguity is already a risk.
If a developer has two high-priority tasks, clarifying sequence and trade-offs early prevents downstream delays. Over time, teams learn to surface these conflicts themselves.

At the release level, expectation management is continuous.
Feasibility checks, progress updates, and early risk signaling prevent last-minute corrections and delivery heroics.

The Takeaway

Consistent delivery is the result of well-managed expectations, not increased pressure.

Strong engineering management aligns reality early — for the team and for the product.

Debugging AWS lambda locally

Lekshmi Chandra — Thu, 08 Jul 2021 12:37:45 +0000

This post explains how to debug a lambda on a developers machine using sam (serverless application model).

This will invoke the local AWS lambda function on a docker and quits after the invocation completes.

Prepare the dependencies:

1. Template file

As in any sam application, we need a template file which specifies the serverless application. This has to be in the root of the application. If it is on another path, it can be specified using --template parameter.

2. Docker

Keep docker running so that the lambda can be deployed in a container.

3. Prepare incoming data

Most lambda wakes up on an event occurrence and that event will be passed as parameter to the lambda. In addition, there will be request data. Since we are running the lambda in local, we need to provide these data. For that, create a json file and keep some sample data in it.

For example, I would create a localTesting folder and keep a lambda-params.json in it. The data to be passed can be configured as below:

//localTesting/lambda-params.json

{
  "body": "{\"url\": \"/test-page\"}"
}

This will be passed as the --event param.

4. Prepare env variables

In addition to incoming data, there will be some env variables which the lambda will look for during the execution. We need to provide that too. For that we can create another file called local-env.json in the localTesting folder and keep the required info like below:

{
  "Publish": {
    "ENVIRONMENT_NAME": "staging",
    "S3_BUCKET_NAME": "staging-s3",
    "AWS_SDK_LOAD_CONFIG": 1
  }
}

Configurations specific to another entry point can be configured as comma separated list in this file.

This file can be specified in the --env-vars parameter.

5. CLI installations

Time to install sam cli. For mac, the installation commands using home brew are the following:

brew tap aws/tap
brew install aws-sam-cli

more help on installation https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install-mac.html

6. Grab the entry point name

Almost there. We can grab the name of the entrypoint which we are going to trigger. It will be in the template file as the name of the lambda description. For my case, it is Publish.

7. Find CodeUri path

Go to the template file and find the CodeUri in your lambda specification. We need this folder with the lambda logic to be generated before running the lambda.

8. Build

If you are using node, go to package.json and find the command which to build the code, which would possibly result in the codeUri path in the previous step to be generated.

Run it

Now that we have all the necessary dependencies tackled, we just have to run it

sam local invoke --env-vars localTesting/local-env.json --event localTesting/lambda-params.json "Publish"

This expects the template to be on the root. If it's on another path, specify that too using --template parameter.

For example,

sam local invoke --template src/template.yml --env-vars localTesting/local-env.json --event localTesting/lambda-params.json "Publish"

This will print out the lambda response on the terminal. You can add logs to debug or even build newer features easily now.

Note: remember to rebuild after every change. If you keep build in watch mode, you don't even have to build again.

Bonus tip:

If you wan't to test only the application logic of a lambda, you could invoke the built lambda function with necessary params without sam.

Two ways to keep gitlab CI files maintainable

Lekshmi Chandra — Mon, 12 Apr 2021 15:07:54 +0000

Once we had a gitlab CI file. It was short and sweet. One year later, it grew 350 lines long.

There were these problems:

Too much content - too much scrolling, hard to visualize and work on.
Hard to disable some jobs temporarily - mostly for debugging infra or test environment or emergency deployment (let that never happen!).

Let's try to solve it with some features from gitlab.

1. Leverage templating

Gitlab CI supports using templates within the .gitlab-ci.yml file.

Consider a sample .gitlab-ci.yml file as follows

stages:
   - setup
   - soft-qa //lint and unit tests
   - build
   - hard-qa //e2e's
   - deploy-storybook
   - pack
   - notify-devs-staging-can-be-deployed
   - deploy-staging
   - notify-devs-prod-can-be-deployed
   - deploy-production
   - suggest-release-notes

variables: 
    var1: '1'
    // .. and so on

conditions:
    only_master: 
       // configs
    branches:
       // configs
    // and more...

## cache related configs

## setup related configs

## jobs for each for the stages start
.
.
.
. // 200 lines later
.
## jobs end

I will still keep the stages in the .gitlab-ci.yml untouched so that I can get a preview of all the stages right at the start of the file.

Let's now split this into smaller templates.

For templates, I will create a folder in the repo root called ci-templates. Now let's extract out one job from the main file and place it in a template in this folder. Note, all these files has to YAML, to be included into a .gitlab-ci.yml file.

/ci-templates/.soft-qa.yml

soft-qa:
  image: node:14.5
  stage: soft-qa
  <<: *npm_cache_pull
  allow_failure: false
  script:
    - yarn lint
    - yarn test:unit:ci
  artifacts:
    paths:
      - coverage/lcov.info

Time to use the template. Go to .gitlab-ci.yml and include this file like below. I will place it at the position of the replaced job.

include: '/ci-templates/.soft-qa.yml'

We are using this syntax - with relative path - as we are using the file from the same repo. You can keep the file in another repo on the same gitlab instance or even in a public remote repository and use it! Just look up the syntax and update accordingly, like below:

For another repo:

include:
  - project: 'my-space/my-another-project'
    file: '/templates/.build-template.yml'

For remote:

include:
  - remote: 'https://somewhere-else.com/example-project/-/raw/master/.build-template.yml'

In a similar way, extract out other jobs as well and remove them from the .gitlab ci file. I have abstracted the notify stages to a file called .notifications.yml and deployment related jobs to .deploy.yml, thus separating the concerns from one single file. Now, include becomes a list like below:

include: 
   - '/ci-templates/.soft-qa.yml'
   - '/ci-templates/.build.yml'
   - '/ci-templates/.hard-qa.yml'
   - '/ci-templates/.deploy-storybook.yml'

When pipeline starts, all included files are evaluated and deep merged into the .gitlab-ci file.

Catch, Catch, Catch

Things are getting interesting. I have certain conditions like only_tag, only_branches in these jobs. How would I provide them to these files without duplicating it in every files?

Enter extends.

I will consolidate my conditions in a file, say, .conditions.yml.

// /ci-templates/.conditions.yml

.only_tag:
  only:
    - /^v\d+\.\d+\.\d+$/
  // and more...

To use it in a template, include it first in the .gitlab-ci file

include: 
   - '/ci-templates/.conditions.yml'
   - '/ci-templates/.soft-qa.yml'
   - '/ci-templates/.build.yml'
   - '/ci-templates/.hard-qa.yml'
   - '/ci-templates/.deploy-storybook.yml'

Then, in the template file, add extend. Extend is a way of extending the congfigurations to another file. YAML anchors can be used but only from the same file. So this is a way to use jobs from another template.

deploy_staging:
  extends: .only_tag
  <<: *deploy

Now, deploy_staging will be created only for tags.

Finally, the .gitlab-ci file will look something like:

stages:
   - setup
   - soft-qa //lint and unit tests
   - build
   - hard-qa //e2e's
   - deploy-storybook
   - pack
   - notify-devs-staging-can-be-deployed
   - deploy-staging
   - notify-devs-prod-can-be-deployed
   - deploy-production
   - suggest-release-notes

variables: 
    var1: '1'
    // .. and so on

## cache related configs

## setup related configs

include: 
   - '/ci-templates/.conditions.yml'
   - '/ci-templates/.soft-qa.yml'
   - '/ci-templates/.build.yml'
   - '/ci-templates/.hard-qa.yml'
   - '/ci-templates/.deploy-storybook.yml'
   - '/ci-templates/.pack.yml'
   - '/ci-templates/.notifications.yml'
   - '/ci-templates/.deploy.yml'
   - '/ci-templates/.suggest-release-notes.yml'

Now let's go back to the initial problems and check whether they are fixed:

Too much content to scroll - now, we can view whole content in the IDE window - Fixed
Hard to disable jobs - now, we just have to comment the template in the include list - Fixed

How will I know, if I commented out a required job? Like, by mistake, I commented the pack job. For deployment packed resources are necessary. Here, we will know that the deployment failed much later when the deployment runs. To solve this, there is a way to mark dependencies on previous jobs. That is explained in next step.

2. Use `needs` or `dependencies` as applicable

One way to track that you have the dependent artifacts are available before starting a job is by using dependencies or
needs keyword.

By default, all artifacts from previous stages are passed to each job. However, you can use the dependencies keyword to define a limited list of jobs to fetch artifacts from.

build_frontend:
   stage: build
   script: yarn build

deploy:
   stage: deployment
   dependencies: 
      - build_frontend

In this case, if the build_frontend is not available, while merging the templates, the pipeline will report error that the build_frontend is not available. Easy to understand.

Another utility is the needs. It is mainly used when you are running jobs out of order and still ensure that the dependency job is completed before starting a job. The difference of needs from dependencies is that, in needs, no artifacts from previous steps are downloaded by default. You need to use artifacts: true config on the job like below to download them:

deploy:
  needs:
   - job: build_1
     artifacts: true
   - job: build_2
     artifacts: false

This helped me reduce the complexity of the CI file. Hope it helps you too.

Peace ✌️

Honeypot for bots implemented in alpine-nginx docker

Lekshmi Chandra — Tue, 07 Jul 2020 17:08:19 +0000

We can try to block the scraping bots which exhaust server resources by setting up a honeypot trap in nginx and block those unwanted IP's. This article is for opensource nginx on alpine linux base image. Nginx plus already has a bot trapping feature.

Steps:

1. Creating the trap

We will add some invisible links to the web page. Human users won't click on on it. Only the bots which scrape the page will access these specific hidden hrefs. <a href="/one-trap-here"></a> Trap ready.

2. Add rule in nginx to handle the traps

   location /one-trap-here {
      include honeytrap.conf;
   }

Once the trap is visited, we will include the honey trap conf.

3. Writing honeytrap.conf

This is another nginx configuration file which will handle the script execution to block the ip that accessed the page.

Nginx cannot execute scripts on it's own and Common Gateway Interface (CGI) is used for this purpose. FastCGI is the package that efficiently manages script execution for large number of incoming requests.

Since we need to run a simple script that blocks the ip, we can use fcgiwrap. fcgiwrap is the lightweight FastCGI wrapper.

So, we can install fcgiwrap

and honeytrap.conf will look something like

fastcgi_intercept_errors off;
fastcgi_pass unix:/run/fcgiwrap-unix.sock;  
include fastcgi_params;
root /usr/local/libexec;
fastcgi_param SCRIPT_FILENAME $document_root/block-ip.cgi;

The fcgiwrap process communicates to nginx using socket file which we have to create in /run/ and the owner, the same user as the nginx.

once fcgiwrap is installed, the following will link it as a socket file.

/usr/bin/fcgiwrap -s unix:/run/fcgiwrap-unix.sock &

4. Add CGI script

Content of /usr/local/libexec/block-ip.cgi could be to execute a shell script that will do the actual blocking and to return the http status code applicable in this scenario.

#!/bin/sh

echo "Status: 410 Gone"
echo "Content-type: text/plain"
echo

echo "Get lost, $REMOTE_ADDR!"
/usr/local/bin/block-ip.sh

Don't forget to make the script executable.

5. Add shell script

Basic firewall in linux is handled by netfilter and we can add rules to the iptables in linux to drop any incoming request from a specific ip.

In iptables, there are chains for INPUT, FORWARD and OUTPUT packets and you can add what action to take when a specific address makes requests like below

/sbin/iptables -A trap1 -s ${REMOTE_ADDR} -j DROP

This means drop all requests from this remote address, append this to the trap1 chain. Further, this chain needs to be added to the ACCEPT, FORWARD, OUTPUT chains.

Rather, a more cleaner approach would be to use ipset. With ipset, we can create specific sets for ipv4 addresses, ipv6 addresses, host name etc - basically you can categorize the items and then add them to the iptables.

ipset -A trap1ipset ${REMOTE_ADDR}

To disconnect any keepalive connection to nginx, we could use conntrack-tools also.

First step would be to create ipsets for ipv4 and ipv6 addresses and add them to iptables. Note that separate package ipv6tables is required for ipv6 address handling. This has to be done on when the docker image boots up, possibly in the start up scripts.
sample

ipset -N ipv4trap iphash family inet
ipset -N ipv6trap iphash family inet6
iptables -A INPUT -m set --match-set ipv4trap src -j DROP
ip6tables -A INPUT -m set --match-set ipv6trap src -j DROP

And,the anatomy of the shell script is as follows:

#!/bin/bash
IPT=/sbin/iptables

if [[ -z ${REMOTE_ADDR} ]]; then
    if [[ -z "$1" ]]; then
        echo "REMOTE_ADDR not set!"
        exit 1
    else
        REMOTE_ADDR=$1
    fi
fi

if [[ "$REMOTE_ADDR" != "${1#*[0-9].[0-9]}" ]]; then
  ipset -A ipv4trap ${REMOTE_ADDR}
  /usr/sbin/conntrack -D -s ${REMOTE_ADDR}
elif [[ "$REMOTE_ADDR" != "${1#*:[0-9a-fA-F]}" ]]; then
  ipset -A ipv6trap ${REMOTE_ADDR}
  /usr/sbin/conntrack -D -s ${REMOTE_ADDR}
else
  echo "Unrecognized IP format '$1'"
fi

Important: To access the network utils docker needs added privileges on start up.

Either, --cap-add NET_ADMIN flag has to be passed on docker run command
or

cap-add 
  - NET_ADMIN

has to be added in the docker compose file.

Now, this can be tested by accessing one of the trap urls. Look for rules getting added in the iptables under ACCEPT chain. The next try to access will not be accepted by the container.

iptables --list

ipset list

can be used to view details.

This solution could be improved for a persistent one where IP's will be saved and loaded to the iptables when the container boots up.

For that, ipset save and ipset restore could come handy - which will write the IP's in memory to a file and restore it.

ipset save bad-ips -f ipset-bad-ips.backup

and

ipset restore -! < ipset-bad-ips.backup

Adaptations for docker:

Copying and making the scripts executable can be done on the Dockerfile as needed.

Creating the socket file can be done using startup script or startup CMD in Dockerfile.

DEV Community: Lekshmi Chandra

The Art of Predictable Estimations (Part 2): Staying Aligned Through Delivery

The Art of Predictable Estimations (Part 1): Turning Uncertainty into Clarity

Engineering Management Nugget #7: Undercommit and Overdeliver (On Purpose)

Engineering Management Nugget #6: From Firefighting to Architecting

Engineering Management Nugget #5: Measuring Without Damaging Culture

Engineering Management Nugget #4: Guardrails Over Control

Engineering Management Nugget #3: Stepping Back

Engineering Management Nugget #2: Managing tech debt

Engineering Management Nugget #1: Managing expectations

Debugging AWS lambda locally

Prepare the dependencies:

1. Template file

2. Docker

3. Prepare incoming data

4. Prepare env variables

5. CLI installations

6. Grab the entry point name

7. Find CodeUri path

8. Build

Run it

Two ways to keep gitlab CI files maintainable

1. Leverage templating

Catch, Catch, Catch

2. Use needs or dependencies as applicable

Honeypot for bots implemented in alpine-nginx docker

Steps:

1. Creating the trap

2. Add rule in nginx to handle the traps

3. Writing honeytrap.conf

4. Add CGI script

5. Add shell script

2. Use `needs` or `dependencies` as applicable