Tuesday, August 30, 2022

Masscan Targets Fierce Results

 

<!-- masscan v1.0 scan -->
<nmaprun scanner="masscan" start="1661842484" version="1.0-BETA" xmloutputversion="1.03">
<scaninfo type="syn" protocol="tcp"/>
<host endtime="1661842484">
<address addr="23.221.222.251" addrtype="ipv4"/>
<ports>
<port protocol="tcp" portid="80">
<state state="open" reason="syn-ack" reason_ttl="46"/>
</port>
</ports>
</host>
<host endtime="1661842514">
<address addr="23.221.222.251" addrtype="ipv4"/>
<ports>
<port protocol="tcp" portid="80">
<state state="open" reason="response" reason_ttl="46"/>
<service name="http" banner="HTTP/1.0 200 OK\x0d\x0aX-Correlation-Id: aaaaaaaa\x0d\x0aDate: Tue, 30 Aug 2022 06:54:46 GMT\x0d\x0aContent-Length: 0\x0d\x0a\x0d"/>
</port>
</ports>
</host>
<host endtime="1661842811">
<address addr="23.221.222.4" addrtype="ipv4"/>
<ports>
<port protocol="tcp" portid="22">
<state state="open" reason="syn-ack" reason_ttl="48"/>
</port>
</ports>
</host>
<host endtime="1661842817">
<address addr="23.221.222.4" addrtype="ipv4"/>
<ports>
<port protocol="tcp" portid="22">
<state state="open" reason="response" reason_ttl="48"/>
<service name="ssh" banner="SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.7"/>
</port>
</ports>
</host>
<host endtime="1661843283">
<address addr="23.221.222.253" addrtype="ipv4"/>
<ports>
<port protocol="tcp" portid="80">
<state state="open" reason="syn-ack" reason_ttl="48"/>
</port>
</ports>
</host>
<host endtime="1661843313">
<address addr="23.221.222.253" addrtype="ipv4"/>
<ports>
<port protocol="tcp" portid="80">
<state state="open" reason="response" reason_ttl="48"/>
<service name="http" banner="HTTP/1.0 200 OK\x0d\x0aX-Correlation-Id: aaaaaaaa\x0d\x0aDate: Tue, 30 Aug 2022 07:08:06 GMT\x0d\x0aContent-Length: 0\x0d\x0a\x0d"/>
</port>
</ports>
</host>
<host endtime="1661844305">
<address addr="23.221.222.254" addrtype="ipv4"/>
<ports>
<port protocol="tcp" portid="80">
<state state="open" reason="syn-ack" reason_ttl="48"/>
</port>
</ports>
</host>
<host endtime="1661844336">
<address addr="23.221.222.254" addrtype="ipv4"/>
<ports>
<port protocol="tcp" portid="80">
<state state="open" reason="response" reason_ttl="48"/>
<service name="http" banner="HTTP/1.0 200 OK\x0d\x0aX-Correlation-Id: aaaaaaaa\x0d\x0aDate: Tue, 30 Aug 2022 07:25:08 GMT\x0d\x0aContent-Length: 0\x0d\x0a\x0d"/>
</port>
</ports>
</host>
<host endtime="1661844495">
<address addr="23.221.222.250" addrtype="ipv4"/>
<ports>
<port protocol="tcp" portid="80">
<state state="open" reason="syn-ack" reason_ttl="48"/>
</port>
</ports>
</host>
<host endtime="1661844526">
<address addr="23.221.222.250" addrtype="ipv4"/>
<ports>
<port protocol="tcp" portid="80">
<state state="open" reason="response" reason_ttl="48"/>
<service name="http" banner="HTTP/1.0 200 OK\x0d\x0aX-Correlation-Id: aaaaaaaa\x0d\x0aDate: Tue, 30 Aug 2022 07:28:18 GMT\x0d\x0aContent-Length: 0\x0d\x0a\x0d"/>
</port>
</ports>
</host>
<host endtime="1661844593">
<address addr="23.221.222.5" addrtype="ipv4"/>
<ports>
<port protocol="tcp" portid="22">
<state state="open" reason="syn-ack" reason_ttl="48"/>
</port>
</ports>
</host>
<host endtime="1661844599">
<address addr="23.221.222.5" addrtype="ipv4"/>
<ports>
<port protocol="tcp" portid="22">
<state state="open" reason="response" reason_ttl="48"/>
<service name="ssh" banner="SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.7"/>
</port>
</ports>
</host>
<host endtime="1661844787">
<address addr="23.221.222.252" addrtype="ipv4"/>
<ports>
<port protocol="tcp" portid="80">
<state state="open" reason="syn-ack" reason_ttl="48"/>
</port>
</ports>
</host>
<host endtime="1661844818">
<address addr="23.221.222.252" addrtype="ipv4"/>
<ports>
<port protocol="tcp" portid="80">
<state state="open" reason="response" reason_ttl="48"/>
<service name="http" banner="HTTP/1.0 200 OK\x0d\x0aX-Correlation-Id: aaaaaaaa\x0d\x0aDate: Tue, 30 Aug 2022 07:33:09 GMT\x0d\x0aContent-Length: 0\x0d\x0a\x0d"/>
</port>
</ports>
</host>
<runstats>
<finished time="1661844984" timestr="2022-08-30 02:36:24" elapsed="2578"/>
<hosts up="7" down="0" total="7"/>
</runstats>
</nmaprun>

 

 

 

# Nmap 7.92 scan initiated Tue Aug 30 00:55:28 2022 as: nmap -vv -iR 500 --open -oN /home/g0d/docs/randscan
Nmap scan report for a104-118-174-68.deploy.static.akamaitechnologies.com (104.118.174.68)
Host is up, received echo-reply ttl 49 (0.26s latency).
Scanned at 2022-08-30 00:56:05 CDT for 950s
Not shown: 998 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT    STATE SERVICE REASON
80/tcp  open  http    syn-ack ttl 49
443/tcp open  https   syn-ack ttl 49

Nmap scan report for customer-082-139-072-144.solcon.nl (82.139.72.144)
Host is up, received echo-reply ttl 45 (0.15s latency).
Scanned at 2022-08-30 00:56:05 CDT for 905s
Not shown: 801 filtered tcp ports (admin-prohibited), 194 filtered tcp ports (no-response), 2 closed tcp ports (reset)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT     STATE SERVICE REASON
443/tcp  open  https   syn-ack ttl 45
5060/tcp open  sip     syn-ack ttl 45
8089/tcp open  unknown syn-ack ttl 45

Nmap scan report for p4ff47ef5.dip0.t-ipconnect.de (79.244.126.245)
Host is up, received echo-reply ttl 50 (0.20s latency).
Scanned at 2022-08-30 00:56:05 CDT for 915s
Not shown: 774 filtered tcp ports (admin-prohibited), 222 filtered tcp ports (no-response), 2 closed tcp ports (reset)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT     STATE SERVICE REASON
5060/tcp open  sip     syn-ack ttl 50
8089/tcp open  unknown syn-ack ttl 50

Nmap scan report for 192.229.211.138
Host is up, received echo-reply ttl 56 (0.032s latency).
Scanned at 2022-08-30 00:56:06 CDT for 961s
Not shown: 996 filtered tcp ports (no-response), 2 closed tcp ports (reset)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT    STATE SERVICE REASON
80/tcp  open  http    syn-ack ttl 56
443/tcp open  https   syn-ack ttl 56

Nmap scan report for modemcable179.10-81-70.mc.videotron.ca (70.81.10.179)
Host is up, received syn-ack ttl 47 (0.092s latency).
Scanned at 2022-08-30 00:56:06 CDT for 939s
Not shown: 998 filtered tcp ports (no-response), 1 closed tcp port (reset)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT    STATE SERVICE REASON
443/tcp open  https   syn-ack ttl 47

Nmap scan report for a23-202-74-100.deploy.static.akamaitechnologies.com (23.202.74.100)
Host is up, received echo-reply ttl 53 (0.063s latency).
Scanned at 2022-08-30 00:56:05 CDT for 962s
Not shown: 998 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT    STATE SERVICE REASON
80/tcp  open  http    syn-ack ttl 53
443/tcp open  https   syn-ack ttl 53

Nmap scan report for a72-247-171-81.deploy.static.akamaitechnologies.com (72.247.171.81)
Host is up, received echo-reply ttl 52 (0.064s latency).
Scanned at 2022-08-30 00:56:05 CDT for 955s
Not shown: 998 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT    STATE SERVICE REASON
80/tcp  open  http    syn-ack ttl 52
443/tcp open  https   syn-ack ttl 52

Nmap scan report for dslb-092-077-238-107.092.077.pools.vodafone-ip.de (92.77.238.107)
Host is up, received echo-reply ttl 43 (0.17s latency).
Scanned at 2022-08-30 00:56:05 CDT for 945s
Not shown: 782 filtered tcp ports (admin-prohibited), 215 filtered tcp ports (no-response), 2 closed tcp ports (reset)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT     STATE SERVICE REASON
5060/tcp open  sip     syn-ack ttl 43

Nmap scan report for ip206.ip-51-79-136.net (51.79.136.206)
Host is up, received echo-reply ttl 41 (0.24s latency).
Scanned at 2022-08-30 00:56:05 CDT for 952s
Not shown: 994 closed tcp ports (reset), 4 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT    STATE SERVICE REASON
22/tcp  open  ssh     syn-ack ttl 41
111/tcp open  rpcbind syn-ack ttl 41

Nmap scan report for 88.133.17.165
Host is up, received echo-reply ttl 43 (0.18s latency).
Scanned at 2022-08-30 00:56:05 CDT for 927s
Not shown: 792 filtered tcp ports (admin-prohibited), 203 filtered tcp ports (no-response), 3 closed tcp ports (reset)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT     STATE SERVICE REASON
443/tcp  open  https   syn-ack ttl 43
5060/tcp open  sip     syn-ack ttl 43

Nmap scan report for 183.115.133.147
Host is up, received echo-reply ttl 40 (0.20s latency).
Scanned at 2022-08-30 00:56:05 CDT for 926s
Not shown: 985 closed tcp ports (reset), 14 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT     STATE SERVICE  REASON
1717/tcp open  fj-hdnet syn-ack ttl 39

Nmap scan report for 223-30-0-0.lan.sify.net (223.30.188.76)
Host is up, received syn-ack ttl 236 (0.31s latency).
Scanned at 2022-08-30 00:56:06 CDT for 961s
Not shown: 993 closed tcp ports (reset), 6 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT    STATE SERVICE REASON
443/tcp open  https   syn-ack ttl 236

Nmap scan report for 104.252.169.15
Host is up, received echo-reply ttl 49 (0.071s latency).
Scanned at 2022-08-30 00:56:04 CDT for 959s
Not shown: 856 filtered tcp ports (host-prohibited), 140 filtered tcp ports (no-response), 3 closed tcp ports (reset)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT      STATE SERVICE REASON
20221/tcp open  unknown syn-ack ttl 49

Nmap scan report for ip40.ip-141-94-56.eu (141.94.56.40)
Host is up, received echo-reply ttl 41 (0.15s latency).
Scanned at 2022-08-30 00:56:04 CDT for 958s
Not shown: 993 closed tcp ports (reset), 4 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT     STATE SERVICE   REASON
80/tcp   open  http      syn-ack ttl 41
443/tcp  open  https     syn-ack ttl 41
9100/tcp open  jetdirect syn-ack ttl 41

Read data files from: /usr/bin/../share/nmap
# Nmap done at Tue Aug 30 01:12:10 2022 -- 500 IP addresses (48 hosts up) scanned in 1001.92 seconds

 

23.221.222.1
23.221.222.2
23.221.222.3
23.221.222.4
23.221.222.5
23.221.222.6
23.221.222.7
23.221.222.8
23.221.222.9
23.221.222.10
23.221.222.11
23.221.222.12
23.221.222.13
23.221.222.14
23.221.222.15
23.221.222.16
23.221.222.17
23.221.222.18
23.221.222.19
23.221.222.20
23.221.222.250
23.221.222.251
23.221.222.252
23.221.222.253
23.221.222.254%                                                                                                                                   g0d➜~/docs»      

What real hacking looks like...

 


Monday, August 29, 2022

mesh-Based IRC chat

ESP-WIFI-MESH

ESP-WIFI-MESH is a wireless communication network with nodes organized in a mesh topology using the simultaneous AP-STA feature on Espressif SoCs. It provides a self-forming and self-healing network, with ease of deployment. The network topology of ESP-WIFI-MESH can scale up to 1000 nodes in large areas, without requiring any specific Wi-Fi infrastructure support. ESP-WIFI-MESH can also be used to cover Wi-Fi blind spots in home-deployment scenarios where the Wi-Fi signal cannot be reached.

Easy and Secure Setup

We provide ready-to-use, yet customizable, phone apps that facilitate the auto-discovery of new nodes and allow their easy configuration with the Bluetooth LE method. This method ensures that the configuration is pushed securely to the nodes at scale. This enables the ESP-WIFI-MESH administrator to manage node groupings and choose the best routing for any given deployment.

Self-forming and Self-healing

In the auto-routing mode, the ESP-WIFI-MESH network gets formed automatically, according to the signal strength values of peers seen by the nodes. This mode also facilitates the automatic reconnection between different nodes, whenever a parent node goes off. This offers automatic healing and provides fail-safety within the mesh.

No Extra Gateways Required

Typically other mesh networks require additional mesh infrastructure equipment to cover wider areas. ESP-WIFI-MESH does not require any additional equipment to form a network. It also scales well with a low-capacity Wi-Fi access point, since the access point is completely unaware of the existence of ESP-WIFI-MESH nodes.

IP Connectivity

All the nodes in the ESP Mesh network can get IP connectivity and communicate both with each other and the external world. The internet access of these nodes is provided by a root node acting either as a NAT or a bridge.

Secure by Design

ESP-WIFI-MESH is based on standard Wi-Fi connectivity and it can use standard WPA2 network security among the mesh nodes to ensure communication security.

Applications

  • Smart Lighting: smart lights, lighting networks
  • Smart Home: smart switches, sockets, plugs, etc.
  • Automation: big parking lots, small factories, shared offices

Benefits of the ESP-WIFI-MESH

ESP-WIFI-MESH Lighting Solution

Watch the Video

ESP32-MeshKit-Sense

ESP32-MeshKit-Light

ESP-MDF Github

ESP-MDF Develop

2022 ESPRESSIF SYSTEMS (SHANGHAI) CO., LTD. All rights reserved.

SSH BRUTE FORCE ATTACKS HAVE SLOWED


Chris Siebenmann :: CSpace » blog » sysadmin » SSHBruteForceAttacksNoMoreHere
Large scale Internet SSH brute force attacks seem to have stopped here
August 27, 2022

The last time I paid attention to what happened when you exposed an SSH port on the Internet was years and years ago, when I gave up being annoyed by log messages and either stopped paying attention or firewalled of my SSH ports from the general Internet. Back then, it was received wisdom (and my general experience) that having an SSH port open drew a constant stream of SSH brute force attacks against a revolving cast of whatever logins the attackers could come up with.

Recently I set up a Grafana Loki setup that captures our systemd logs. As part of getting some use out of it (beyond questions about how server clocks drift), I built a Grafana dashboard that reports on SSH authentication failures across our Ubuntu fleet (among other things). What I saw surprised me, because what our exposed SSH servers experience today seems to be nothing like it was in the past.

(One caution is that it may be that most attackers no longer direct their attention against universities at all, and now aim their scans at, say, cloud providers, which could be much richer territory for insecure SSH servers.)

For the most part, SSH brute force attacks against us are gone. When they appear in some time period, they come in high volume from single IP addresses (or only a few IP addresses); some of the time these are cloud server IPs. Almost all of the brute force attacks are directed against the 'root' account, and any single round tends to be directed against only a single one of our servers rather than being spread over multiple ones. As mentioned, attacks are bursty; there are periods with no login attempts and then periods where someone apparently fires up a single attacking IP address for an hour or a day.

For some numbers, over the past 7 days we had 24,000 attempts against 'root' and only 749 against the next most popular target, which is a login name ('admin') that doesn't even exist here. Just over 10,000 of those attempts came from a single IP address, and just four IPs made 1,000 or more attempts against anything. Besides root, only five login names had more than 100 attempts (and none of them exist here): 'admin', 'user', 'ubuntu', 'debian', and 'pi'. And only three machines saw more than 1,000 attempts (across all targeted login names).

One of the things I've learned from this is that targeted blocking of only a few IPs is disproportionately effective at stopping brute force SSH attacks here. Also, since we already block Internet logins to 'root', we're in almost no danger. No matter how many times they try, they have literally no chance of success.

(It does make me curious about what sort of passwords they're trying for 'root'. But not curious enough to set up a honeypot SSH server and then try to give it a hostname that's interesting enough to attract attackers.)
Written on 27 August 2022.
« Using systemd timers to run things frequently (some early notes)
Getting USB TEMPer2 temperature sensor readings into Prometheus (on Linux) »

These are my WanderingThoughts
(About the blog)

Full index of entries
Recent comments

This is part of CSpace, and is written by ChrisSiebenmann.
Twitter: @thatcks
Mastodon: @cks

* * *

Categories: links, linux, programming, python, snark, solaris, spam, sysadmin, tech, unix, web
Also: (Sub)topics

This is a DWiki.
GettingAround
(Help)
Page tools: View Source, Add Comment.
Search:
Atom Syndication: Recent Comments.
Last modified: Sat Aug 27 22:04:12 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.

Saturday, August 27, 2022

UPDATE -- CODE & GITHUB

survival

The best suited organisim is one who perceived reality thru the best interpretive biological senses.  

Precieving more of reality will always create niches in throughout time that can be exploited to carve out a place for itself in culture.

So the question becomes what technology and why should we use it to our benefit.

Friday, August 26, 2022

Exert technological know-how into real world AGENCY and make change.

 A new digital age and the evolution from data sheep to data brokers.

 

If you've followed the early entertainment in this subject, you'd understand humanity is now inevitability bound for better or worse to the even advance of Technology.  Our cybernetic devices, if you own phones, tablets, and computers your a cyborg simply an high latency one.  

But today all our devices have turned us into walking data farms, more importantly; money farms.

Is it not time we give up this passive mindset and move forward as true AGENTS (that is exerting our agency into the world).  We can accomplish this with a small change, simply do you research on the devices you use,  learn to professional work with those devices so you can use them proactively or provocatively.  No longer giving them our lives in data form but forcing them to pay to take it or pay us for it.

Current Project

Short History of the CCP Cyber

    Whether this is due to their naivety, thinking the state will cover their activities, or their inability to understand that the Great Fi...