HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
EvanAnderson
ts_block
Visual Basic2021–2024
EvanAnderson / ts_block

ts_block

Blocks IP addresses generating invalid Terminal Services logons

2Distinct people
4Mentions
0Explicit recommenders
186GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Blocks IP addresses generating invalid Terminal Services logons

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year4 dated mentions

Observed mentions: 2021-04-18 20:03:08 UTC to 2024-03-08 17:18:33 UTC.

012021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101

What Hacker News says

4 sources
> Is there something inherently insecure about remote desktops, or is MS software here known to be particularly insecure... Exposing RDP to the Internet directly has been frowned-upon because of the attack surface being presented, there's no two factor "story" out-of-the-box, and you're opened up to brute force attempts on cruddy user passwords. Older versions of the Microsoft Remote Desktop Protocol had a much larger attack surface than current versions. The current versions with Network Level Authentication (starting in Windows Vista/Server 2008) present a smaller attacks surface. Older versions used "homegrown" Microsoft crypto, whereas current versions use TLS. Disclosure: I made a FLOSS fail2ban-like tool for RDP many years ago[0]. I had a situation where I was forced to expose RDP to the Internet and I didn't like having it open w/o
Read the rest
some protection against brute force attacks. This tool happens to still work in Server 2022 and will slow the velocity of brute force attacks. I still highly recommend not exposing RDP directly to the Internet anyway. (The ts_block tool is missing some fairly essential functionality that I never got around to implementing. It works fine and is really easy to install but some things are sub-optimal.) [0] https://github.com/EvanAnderson/ts_block
In British Library cyber incident review [pdf]
My old ts_block[0] project does something similar to yours, albeit for RDP only and with much less sophisticated customization. I opted to go with a WMI Event Sink rather than polling the Event Log. I've never done a benchmark to see which architecture would use less CPU, but I can say the WMI event sink causes nearly instantaneous reaction. As an aside: I'd love to hear if somebody tries ts_block on Windows Server 2022. It works fine on 2012 R2 thru 2019 but I've never tried it on 2022. [0] https://github.com/EvanAnderson/ts_block
In Analysis of a large brute force attack campaign against Windows Remote Desktop
The perspectives in the comments on this article re: WiX XML source and Windows Installer being difficult are interesting to me. Like I said elsewhere, I overcame that learning curve so long ago that I can't put myself in a position where it seems daunting now. To be fair, though, an MSI to install a 10 files in "C:\Program Files\AppName", register a couple .NET assemblies, create a couple of shortcuts, and throw a few values into the registry would amount to <100 lines of XML. Here's a years-old WiX 2.0 syntax source file to install 4 files in "C:\Program Files\appname" and run an EXE embedded in the MSI to install a service: https://github.com/EvanAnderson/ts_block/blob/master/MSI/ts_... I've only seen "thousands of lines" of WiX source when dealing programs that install a ton of files, or put scads of entries in the registry. Most of t
Read the rest
he MSIs with WiX are based on a simple skeleton generated from a template, and using "includes" generated by the "candle" tool. Understanding the Windows Installer and the WiX source feels analogous to what I see in "modern" web development-- a bunch of tools that developers use, seemingly without understanding what they do, to create a massive pile of edifice into which original code is finally placed.
In WinGet is terrible, I want AppGet back

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.