Tag: apnic

CERT-In : Sensor for MSME networks for logs

If you are an MSME and are looking at complying to the CERT-In directives 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.

What do the CERT-In directives on logs state

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.

CERT-In sensor MSME logs

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.

For a broader deep dive into why Network Security Monitoring is important in the context of incident response, check my presentation on Packets don’t lie – Network Security Monitoring (NSM) for the masses

Aside from the folks at BtCIRT, I am hoping there would be a bunch of other folks from a security background interested in incident response.

Packets don’t lie – Threat Hunting with Zeek

Earlier today, I presented a webinar on ‘Packets don’t lie – Threat Hunting with Zeek.‘

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.

Shodan geoping and geodns -Quickly check ping and DNS resolution across multiple locations

Measuring ping and DNS from different vantage points using RIPE Atlas has been something that I have been using for some time now.

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. 

curl https://geonet.shodan.io/api/geoping/139.59.19.245 | jq .
[
  {
    "ip": "139.59.19.245",
    "is_alive": true,
    "min_rtt": 41.439,
    "avg_rtt": 41.539,
    "max_rtt": 41.689,
    "rtts": [
      41.68868064880371,
      41.4891242980957,
      41.43881797790527
    ],
    "packets_sent": 3,
    "packets_received": 3,
    "packet_loss": 0,
    "from_loc": {
      "city": "Singapore",
      "country": "SG",
      "latlon": "1.3215,103.6957"
    }
  },
  {
    "ip": "139.59.19.245",
    "is_alive": true,
    "min_rtt": 229.823,
    "avg_rtt": 230.04,
    "max_rtt": 230.268,
    "rtts": [
      230.2682399749756,
      229.82311248779297,
      230.0271987915039
    ],
    "packets_sent": 3,
    "packets_received": 3,
    "packet_loss": 0,
    "from_loc": {
      "city": "Santa Clara",
      "country": "US",
      "latlon": "37.3924,-121.9623"
    }
  },
  {
    "ip": "139.59.19.245",
    "is_alive": true,
    "min_rtt": 183.42,
    "avg_rtt": 183.567,
    "max_rtt": 183.683,
    "rtts": [
      183.68268013000488,
      183.41970443725586,
      183.59804153442383
    ],
    "packets_sent": 3,
    "packets_received": 3,
    "packet_loss": 0,
    "from_loc": {
      "city": "Frankfurt am Main",
      "country": "DE",
      "latlon": "50.1025,8.6299"
    }
  },
  {
    "ip": "139.59.19.245",
    "is_alive": true,
    "min_rtt": 185.742,
    "avg_rtt": 185.865,
    "max_rtt": 185.993,
    "rtts": [
      185.99295616149902,
      185.86158752441406,
      185.74166297912598
    ],
    "packets_sent": 3,
    "packets_received": 3,
    "packet_loss": 0,
    "from_loc": {
      "city": "Amsterdam",
      "country": "NL",
      "latlon": "52.3740,4.8897"
    }
  },
  {
    "ip": "139.59.19.245",
    "is_alive": true,
    "min_rtt": 267.025,
    "avg_rtt": 267.047,
    "max_rtt": 267.061,
    "rtts": [
      267.0609951019287,
      267.05384254455566,
      267.0247554779053
    ],
    "packets_sent": 3,
    "packets_received": 3,
    "packet_loss": 0,
    "from_loc": {
      "city": "Clifton",
      "country": "US",
      "latlon": "40.8344,-74.1377"
    }
  },
  {
    "ip": "139.59.19.245",
    "is_alive": true,
    "min_rtt": 261.196,
    "avg_rtt": 261.239,
    "max_rtt": 261.279,
    "rtts": [
      261.1956596374512,
      261.24072074890137,
      261.2793445587158
    ],
    "packets_sent": 3,
    "packets_received": 3,
    "packet_loss": 0,
    "from_loc": {
      "city": "London",
      "country": "GB",
      "latlon": "51.5085,-0.1257"
    }
  }
]

The geodns API enables looking up DNS across multiple locations. 

curl https://geonet.shodan.io/api/geodns/brainattic.in  | jq .
[
  {
    "answers": [
      {
        "type": "A",
        "value": "139.59.19.245"
      }
    ],
    "from_loc": {
      "city": "Clifton",
      "country": "US",
      "latlon": "40.8344,-74.1377"
    }
  },
  {
    "answers": [
      {
        "type": "A",
        "value": "139.59.19.245"
      }
    ],
    "from_loc": {
      "city": "Frankfurt am Main",
      "country": "DE",
      "latlon": "50.1025,8.6299"
    }
  },
  {
    "answers": [
      {
        "type": "A",
        "value": "139.59.19.245"
      }
    ],
    "from_loc": {
      "city": "London",
      "country": "GB",
      "latlon": "51.5085,-0.1257"
    }
  },
  {
    "answers": [
      {
        "type": "A",
        "value": "139.59.19.245"
      }
    ],
    "from_loc": {
      "city": "Amsterdam",
      "country": "NL",
      "latlon": "52.3740,4.8897"
    }
  },
  {
    "answers": [
      {
        "type": "A",
        "value": "139.59.19.245"
      }
    ],
    "from_loc": {
      "city": "Singapore",
      "country": "SG",
      "latlon": "1.3215,103.6957"
    }
  },
  {
    "answers": [
      {
        "type": "A",
        "value": "139.59.19.245"
      }
    ],
    "from_loc": {
      "city": "Santa Clara",
      "country": "US",
      "latlon": "37.3924,-121.9623"
    }
  }
]

The geodns command provides the output in shell format, 

# geodns google.com
142.250.178.14                 London
142.250.186.46                 Frankfurt am Main
142.250.80.46                  Clifton
142.251.36.46                  Amsterdam
74.125.68.100                  Singapore
74.125.68.101                  Singapore
74.125.68.102                  Singapore
74.125.68.113                  Singapore
74.125.68.138                  Singapore
74.125.68.139                  Singapore

Similarly, the geoping command,

# geoping 8.8.8.8
Amsterdam (NL)                 0.863 ms       (min: 0.509 ms, max: 1.414 ms)
Clifton (US)                   1.985 ms       (min: 1.729 ms, max: 2.443 ms)
Frankfurt am Main (DE)         1.167 ms       (min: 0.754 ms, max: 1.979 ms)
London (GB)                    0.769 ms       (min: 0.527 ms, max: 1.229 ms)
Santa Clara (US)               2.273 ms       (min: 1.638 ms, max: 3.151 ms)
Singapore (SG)                  1.53 ms       (min:  1.13 ms, max: 2.204 ms)

The details about the geoping and geodns commands are available here