The Reserve Bank of India (RBI) in its latest cyber security policy released on 7th February 2025, has mandated all banks to use .bank.in and non-banks(other financial institutions) to use .fin.in. The goal of the measures is to curb phishing attacks against citizens of India.
Figure 1: Snippet of RBI’s Cybersecurity policy
Notably, Institute for Development and Research in Banking Technology (IDRBT) will be the registrar for the parent domain names (.bank.in and .fin.in)
Technical details
In a DNS context, I am guessing IDRBT would control the parent zones .bank.in and .fin.in and delegate for example icici.bank.in to ICICI Bank authoritative nameservers.
Similarly, zerodha.fin.in would be delegated to Zerodha authoritative nameservers.
IDRBT would be able to control the namespace and delegate child zone to the respective bank or financial institution.
Figure 2: Diagrammatic representation of possible delegation of bank.in and fin.in domain namespace
Limitations of the cyber security policy
In my opinion, this is an excellent move at the policy level from a cybersecurity perspective. There will be operational challenges from the perspective of the banks or financial institutions. I will reserve them for another blog post.
However, this measure will not eliminate all types of phishing/impersonation , typo-squatting or domain shadowing attacks
Despite this, the RBI Cyber Security Policy aims to build trust in the namespace by restricting domain names for banks and non-banks to .bank.in and .fin.in, respectively. From a consumer’s perspective, this simplifies decision-making. As I mentioned earlier, this won’t eliminate all threats, but it is a good start and certainly better than the common advice banks give—checking for the padlock to ensure a website uses HTTPS!
At the time of writing, the delegation from .in at NIXI to IDRBT was not yet operational.
Figure 3: Delegation of bank.in and fin.in not yet implemented at NIXI
It is to be noted, that the RBI cyber security policy implementation will start April 2025 onwards.
This page lists OSINT DNS RPZ Feeds for recursive resolvers to enhance security by blocking malware, phishing, and C2 domains. Submit your RPZ feed if it’s not listed.
Response Policy Zones(RPZ) or DNS Firewall or Protective DNS (thanks CISA) is a solid way to use the DNS protocol as a defense. For a primer on DNS RPZ, please see the blog post
Hello again! Starting today, I am back on these platforms (Facebook, Twitter, Instagram) after quitting them a long time ago. Here, I am outlining why I am rejoining social media.
The primary reason to quit these platforms was for a number of reasons, and I will not get into this bit here. If you are interested, I urge you to read the book “The Age of Surveillance Capitalism.”
In the past couple of years, aside from building a cyber security company, I have tried my best to educate folks in my network by conducting seminars and workshops about some of the cyber scams and cyber security best practices. Rejoining social media will help me reach a wider audience.
One of the consistent feedback I have received from many is that awareness of on these cyber scams and cyber threats does not spread enough.
Considering that fellow Indian citizens lost ₹11,333 crore to cyber scams in the past year(2024) alone, rejoining social media platforms makes sense, as per data from the Home Ministry’s Indian Cyber Crime Coordination Centre (I4C) division, it’s no brainer that awareness and education are need of the hour.
The figure could be more than ₹11,333 crores, considering folks who haven’t reported the cybercrime.
Considering that, to many, Facebook, Twitter, Instagram etc is the Internet it would be foolish to not use these platforms.
I am flipping the switch today by rejoining social media and will be using these social media platforms to share the latest cyber scams and best practices in safeguarding your accounts and data.
If you are following me on any of these platforms, and feel this is noise or spam, please feel free to mute/block me 🙂
If you believe these cyber scams and best practices to counter these need to be amplified and shared with others, please spread the word.
For the nerds reading this, irrespective of how futile this attempt is, I am following OpSec practice by compartmentalizing each website in it’s own VM 🙂
Little Snitch is a network monitor & application firewall for the Mac OS. On 21st May 2024, with the release of Little Snitch 6.0, a notable Blocklists feature has been made available.
While the ability to add a custom blocklist existed in prior versions, it was a manual step. Little Snitch 6.0 changes that. Little Snitch 6.0 now provides a prepopulated list of blocklists for blocking Advertising, Malware, Tracking, Gambling etc.
Considering that the StevenBlack hosts file is one of the premier list for blocking adware, I was surprised not to find the StevenBlack blocklist in the list.
The other nice addition to the list is URLhaus. At the time of writing, there were 183 malicious domain names in the list.
And, the lists auto-update,
What is the advantage of blocking using Little Snitch over a browser extension like uBlock Origin?
I use both the methods. But the method of using Little Snitch is more powerful because it covers access to network connections (adware/malware etc) from any process in the Operating System and not just from those made from within the browser.
For example, Skype making a connecting to dns.google will be detected and can be blocked using Little Snitch.
It’s also important to note that this method of blocking network communication using an application firewall like Little Snitch might not scale if the blocklist is pretty large.
For example, the newly registered domain names dataset will most definitely cause the application to misbehave. In such cases, nothing beats having protection by using a DNS Firewall/DNS RPZ (Protective DNS).
Open Snitch for GNU/Linux
On similar lines to Little Snitch, Open Snitch is a GNU/Linux application firewall. Though I have to mention that I haven’t tried it yet.
While I have been self-learning for some areas of interest, such as geopolitics, international relations and India’s foreign policy, I am looking forward to the course to gain a deeper understanding and networking with peers from various backgrounds in Indian armed forces, public policy Etc.
The classes will be held online on Saturday, requiring 4-5 hours in addition to the assignments and class work. It will be interesting to juggle my $dayjob and manage the class work and the deadlines, but as the saying goes, there is no gain without pain. 😀
One of the objectives for applying for the course was to understand the topics deeper and that geopolitics and international relations play an important role in dictating the flow of events in the cyber threat landscape.
Thanks to my good friend Karthik Bappanad for the encouragement.
If you are an MSME and are looking at complying to the CERT-Indirectives on logs, then, a sensor we’ve built for generating and storing logs of the entire network, might just be what you are looking for.
All service providers, intermediaries, data centres, body corporate and Government organisations shall mandatorily enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days and the same shall be maintained within the Indian jurisdiction. These should be provided to CERT-In along with reporting of any incident or when ordered / directed by CERT-In.
Challenges faced in incident response environments (MSME) with no logs
The idea of building a sensor stemmed from our experiences of incident response in environments with zero security posture.
The same sensor can capture network packets and generate logs per the CERT-In directives.
At the btNOG-9 Conference on the 14th October 2022, I’ll be presenting Incident Response on a shoestring budget
In the presentation, I’ll share the challenges we faced in incident response environments with zero security posture, i.e. lacking logs, etc. The presentation will then focus on the solution – a sensor we built using open-source software such as Suricata and Zeek, logging DNS queries etc.
By deploying a sensor in the network, MSMEs can comply with the CERT-In directives and also facilitate incident responders to investigate security incidents.
Incident responders can leverage the rich logs by intercepting and ingesting packets into tools such as Zeek. If you are new to Zeek, check the blog post, Packets don’t lie – Threat Hunting with Zeek and the APNIC Academy page where a recording of the webinar will be available soon.
Thanks to the kind folks at APNIC for initiating the request and starting the email thread.
The gist of the presentation was about using Zeek to look for anomalies. Before jumping into Zeek, I introduced Network Security Monitoring. Spoke about conn.log and dns.log and used PCAPs from Stratosphere IPS Project to demonstrate threat hunting with Zeek.
Zeek logs are a great source in the context of threat hunting and Incident Response.
A total of 203 folks had registered for the webinar, and around 55-60 attended. That’s been my experience with online webinars and workshops – many folks will register, but a small fraction attend.
While one hour webinar is a brief period to talk about all-things-zeek, I hope the webinar gives a quick introduction to getting started.
But the most important thing was the interactive Q&A session at the end.
The webinar was recorded and should be available in a few days. I will update the blog post with a link to the recording and the slides.
Also, since I am on the topic of Zeek, ZeekWeek 2022 is an in-person event on October 12th – 14th in Austin, TX.
An excellent line-up of speakers, and the schedule is packed with goodness.
While investigating a bit of oddity with the Skype app on Mac OS X, I wanted to capture all traffic from only the Skype processes.
But first, a little background on the issue. All DNS traffic from my systems is routed through a WireGuard tunnel. The peer endpoint at the other end runs a recursive resolver with DNS Response Policy Zones (DNS RPZ).
I’ve been running a WireGuard tunnel and routing DNS from my phone through a recursive resolver(unbound + rpz). Here are the battery stats.
Prior to WireGuard, an OpenVPN tunnel on the phone would drain the battery out in no time! pic.twitter.com/0rJVcJk1iq
The issue is – that as soon as the WireGuard tunnel is disabled, Skype will try connecting to Google DNS(8.8.8.8) and www.bing.com. Perhaps Skype bypasses the local recursive resolver set on the system and sends the DNS queries for its hosts to Google DNS directly? I cannot ascertain that yet, and it warrants a thorough investigation.
I was alerted to this by Little Snitch after I refreshed the rules. A ritual that I seem to follow every few months.
Little Snitch Network Monitor contains a hidden gem. The ability to capture traffic of a specific process.
For example, by right-clicking on any process, you should see the option to Capture Traffic. That should open a terminal window prompting for the sudo password.
After capturing traffic and interrupting should result in a PCAP on the Desktop. Neat!
Measuring ping and DNS from different vantage points using RIPE Atlas has been something that I have been using for some time now. You can read about installing a RIPE Atlas software probe here
A few weeks ago, I came across Shodan’s geoping and geodns API, which provides ping and DNS lookup from a few locations and other details such as RTT. This is great because you can quickly check ping and DNS resolution on systems where you only have curl running.
You always have the RIPE Atlas project for more detailed and sophisticated use-cases. To get started with the RIPE Atlas project, check the webinar I delivered some time ago for APNIC.
A couple of weeks ago, at my $dayjob, we implemented a recursive resolver with RPZ in an enterprise network.
After a few days, the customer got back to us with an issue – the DNS resolution of the domain esic.in failed with an NXDOMAIN response. After a cursory look at the problem, it became evident that esic.in resolved correctly but www.esic.in did not.
The customer also reported that if they switched the resolver to 8.8.8.8, the DNS resolution of www.esic.in was without any problems, and the website was accessible in the network.
So, what is causing the DNS issue with www.esic.in with the on-prem resolver?
Let’s find out. To start with the basics, here are the authoritative name servers of the domain esic.in,
$ whois esic.in | grep "Name Server:"
Name Server: ns-1089.awsdns-08.org
Name Server: ns-52.awsdns-06.com
Name Server: ns-1978.awsdns-55.co.uk
Name Server: ns-882.awsdns-46.net
If we traverse the DNS delegation from the root to esic.in, we get valuable insights,
. 518400 IN NS k.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS g.root-servers.net.
. 518400 IN NS a.root-servers.net.
. 518400 IN NS h.root-servers.net.
. 518400 IN NS m.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS f.root-servers.net.
in. 172800 IN NS ns1.registry.in.
in. 172800 IN NS ns2.registry.in.
in. 172800 IN NS ns3.registry.in.
in. 172800 IN NS ns4.registry.in.
in. 172800 IN NS ns5.registry.in.
in. 172800 IN NS ns6.registry.in.
esic.in. 3600 IN NS ns-882.awsdns-46.net.
esic.in. 3600 IN NS ns-1978.awsdns-55.co.uk.
esic.in. 3600 IN NS ns-52.awsdns-06.com.
esic.in. 3600 IN NS ns-1089.awsdns-08.org.
esic.in. 300 IN A 115.113.201.36
esic.in. 300 IN A 218.248.15.136
esic.in. 172800 IN NS ns-1089.awsdns-08.org.
esic.in. 172800 IN NS ns-1978.awsdns-55.co.uk.
esic.in. 172800 IN NS ns-52.awsdns-06.com.
esic.in. 172800 IN NS ns-882.awsdns-46.net.
And, here is the delegation trace from the root to www.esic.in,
. 518400 IN NS a.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS m.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS h.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS g.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS f.root-servers.net.
in. 172800 IN NS ns1.registry.in.
in. 172800 IN NS ns4.registry.in.
in. 172800 IN NS ns5.registry.in.
in. 172800 IN NS ns6.registry.in.
in. 172800 IN NS ns3.registry.in.
in. 172800 IN NS ns2.registry.in.
esic.in. 3600 IN NS ns-882.awsdns-46.net.
esic.in. 3600 IN NS ns-1089.awsdns-08.org.
esic.in. 3600 IN NS ns-1978.awsdns-55.co.uk.
esic.in. 3600 IN NS ns-52.awsdns-06.com.
www.esic.in. 3600 IN NS lbr1.esic.in.
www.esic.in. 3600 IN NS lbr2.esic.in.
www.esic.in. 0 IN A 218.248.15.136
If you compare the two outputs and look closely, the authoritative nameservers have delegated www.esic.in to the name servers lbr1.esic.in and lbr2.esic.in
And at the time of the issue, the nameservers lbr1.esic.in and lbr2.esic.in did not respond to Do53(UDP) resulting in an NXDOMAIN!
DNSViz also reported the non-responsive nameservers as well as OpenDNS cachecheck,
At the time of writing this blog post, the name servers lbr1.esic.in. and lbr2.esic.in. were responding and www.esic.in was resolving correctly. But for more than 24+ hours, they were unresponsive resulting in some random people on the Internet in India being unable to access the website.
