Before anybody lectures me and tells me that drop/block lists are no panacea: I already know that.

My sec is redonkulious. (And yes, that is a technical term.)

I have a gateway that has a FW, HIDs, NIDs, AV webproxy and segregates my net in to three subnets (LAN, Wifi, DMZ). On this gateway I cobbled together the HW, but just installed an OTS distro. (And I can't find any info about this FW distro for how to import / drop a bulk list of known bad actors.)

On the LAN subnet I have a kinda AI UTM that I built that can adapt and defend itself to some extent.

None of this is uber. It's all built on junk, scraps and re-purposed machines. None of it is original work. The only thing that is unique is the way I've cobbled together FOSS.

I just got a new telecommute job for a tech support service I won't name b/c of their draconian NDA.

They sent me a remote admin terminal. I dropped their machine in the DMZ so they can reach in and touch it whenever they want w/o me having to fiddle with 900 settings to allow them the reach or having to worry about what kind of access that reach would grant them to my LAN. (Their only sec requirements are that you're behind an OTS router, so I put one in the DMZ.)

Well, this shining new beacon of broadcastosity on my net has caught somebody's attention and I can't friggin get them to leave me alone. Every since I dropped their admin terminal on my net my FW has been flat out slammed with flood attacks. To the point that the poor old machine that I use for the gateway is getting bogged down to the point that it can't do it's job and I'm dropping connections all over the place. It's so bad that if I can't get on top of this I'm going to end up losing the new job.

I've run a ton of diags. AFAICT nothing has gotten through yet.

Here's the scenario:

1) I start dropping.
2) I dig around / run diags. (Any more, just go straight to the FW log graphs.)
3) I find a new set of flood attacks coming from a new IP.
3) I trace the IP. It almost always turns out to be on a list of known bad actors that has been reported by somebody, somewhere, some when, in several different reporting sites.
4) I set up a new drop rule. All is right w/ the world.
5) After roughly 2 hours a human or an algo is reading a log and figuring out they've been dropped. Or it's in some kind of framework that auto-rotates. Either way:
6) A new set of flood attacks start coming in from a new IP.
7) Wash, rinse, repeat.

Maybe it's a botnet, IDK? Based on the capacities I estimate for my rig I'm guessing that the flood is faster than ~150Mbps. TBH I'm not sure what it is. It doesn't appear to be a "traditional" DDoS. I don't think they're trying to knock me off line intentionally. I say that b/c (perhaps incorrectly) they are not just going after ports 80 and 8080. They are throwing what looks to me like NMap and metasploit. And I think "flood attack" may be the wrong term also. I think it's more like they are throwing a flood of various attacks so quickly that it is overloading the poor old HW my gateway is on. I'm guessing "real" (industrial) equipment could withstand the pace of attack w/o dropping connection; which is why I think the goal is to crack me rather than knock me off line.

But, any way you slice it we've already played this game ~50x. I just blocked them again, and I'm off today. So I'd like to get this fixed ASAP.

Google has not been my friend on this one.

Since I have no way of knowing how many IPs this jackwagon has up his sleeve I'm looking for a reputable FOSS source that publishes a list of these known bad addresses.

Preferably in a shell script full of drop rules that cant just be imported in to IPTables and is updated fairly regularly.

Even better would be an installable deamon that will just update itself.

Anybody know of anything like that?

Or, am I coming at this the wrong way and do I need to set up a filtering proxy? But wouldn't that just be another way implementing a blacklist?

And if I do need a filtering proxy can anybody recommend a headless distro that can do that well on ~10 year old x86 SMB class junk?

Most likely automated scanners are detecting this admin terminal and find it to be a juicy target. Is there any way to change what it advertises or to firewall some well-known port? The idea would be to prevent the scanners from detecting it.

Well I can't change anything on the admin term per policy and rights. They have a bizarre permissions scheme that I've never even seen before. IDK how in the hell they managed to do this: I can DL and install software, but I can't update anything including the OS or software that I installed. Which is funny b/c they "trust" me to admin their clients machines, but not my own terminal.

I honestly don't think they know what they are doing. Their "proprietary software suite" consists of a bunch of junk they DLed off the net. With the exception of the VPN and ticketing software I could have gotten the rest of the crap for myself for free. With some of the outbound traffic coming out of it I'm half-way convinced that it was shipped to me w/ a trojan in it. I'm currently going though a whiteboard virtual class w/ ~35 other people to learn their BS and almost everybody is having lag and drop problems. Everybody, including the instructor, keeps blaming it on the collaboration software and folks ISPs. I have not told them about the issues I'm having. They don't seem like the kind of folks that would take too kindly to that kind of news and I'd prolly be out of a yob. Oh well, not my monkey, not my circus.

I worked on it a while yesterday. I finally figured out that all of the inbound was originating from 17 different hosted blocks that are in a handful of countries w/ reps for lax cyber laws and on hosts w/ reps for not caring what they host. I just set drop rules for all 17 blocks and have not been bothered since. Hopefully that solution will stick.

It's hard to tell exactly what was going on b/c my logs are incomplete. It looks like what was happening is a ton of high speed crap would hit my FW, RAM and swap would fill up, the machine correctly dropped everything, but choked on trying to process so much info at once and couldn't maintain a stable connection to the world while it was processing. And of course all that choking prevented some of the logs from being written correctly.

I know I could go with a white list. And I may if it becomes a problem again. But right now I've have not had enough variation in inbound traffic from the tech services VPN to make sure that I've captured their full block. I don't want to lock them out and they don't seem like the kinds of folks who would be receptive to those kinds of questions.

I know there are several ways to auto-block the IPs of failed logs ins. Is there a way to auto-drop IPs that are throwing a ton of high speed scanner crap at me?

You know what they say about "a million monkeys," writing Shakespeare? Well, it works for attacking computer security, too. Send out an "advertisement," which of course can contain arbitrary software (nobody considers what your "advertisement" does, only what it looks like). Now, you've got another "monkey" that can start hammering targets with password attempts. None of the individual monkeys hammers so much, nor so hard, that they arouse individual suspicion, but there are millions of 'em. (Now that we have HTML5, instead of more-limited tools like Flash, there's no limit to the mischief we can cause.)

(Yes, there is a reason why I run so many ad-blockers ...)

Other "bots" troll the web in search of targets: well-known "open port numbers" that seem to have any sort of server listening to them. ssh, VPN ... things that can get you "in."

So, more than anything else, you need to put up a "Dwarvish door," as I suggested in a recent post. You've got to be able to pass through a very-secure entranceway that conceals its own existence. Any and every subsequent access, to anything anywhere, must first pass through that well-hidden door. Nothing less will do.

To gain entrance to any of the public systems that I have deployed, you must know: the IP address, the (non-standard) port number, and the one-of-a-kind digital certificate that will cause the hidden door to reveal itself to you. Then, you must possess a valid certificate, 4096 bits long, that was issued only to you. (You get one chance to do so.) This leads you to a small, guarded room from which you can ssh, or do whatever you're authorized to do. But ... you can't use passwords here, either. You must have more certificates, once again issued only to you. Nothing "faces outward," except what is meant to directly serve the general public.

You don't know, and can't tell, how many hidden doorways there might be. Some lead only to protected rooms from which you can't attempt to do anything else, because you're running under a limited shell. "Congratulations... you just broke into a kiosk."

Authorized users come and go all day, with nary a second thought. Very few "passwords" are required. They are far less inconvenienced now, than they were under the old and cumbersome systems that I replaced. Meanwhile, the attack attempts ... stopped ... cold.

Yes, they can "gang up on" public HTTP servers, and they sometimes do. But they can't attack the guts of the thing, quite literally because they can't find it.

And I thought I was paranoid and played too much D&D as a kid. (Well, still TBH.)

I get NTsec. *MY* nt design didn't have these issues until I dropped *their* box o' crap on it.

But, it is what it is. I've already quit my other job. This is a FT, 100% telecommute gig. So if I want to pay bills I have to deal w/ this box o' crap on my nt. And I've only got limited rights to their box, so there's nothing I can do about it directly on the box or I'd just take it down to bare metal and rebuild it the right way.

So I'm stuck looking for workarounds that will re-securitize my nt w/o stopping their box o' crap from working.

So far the drop rules are holding.

If I need to push my outer physical boundary out even further and drop a proxy in front of the gateway I will. But that will even mean more stuff to learn and do when I'm on a new gig that is already eating up considerable amounts of my time and brain power.

If there's no way to detect and auto-drop IPs throwing scanner crap at the FW/gateway level is there a way to do it w/ a proxy? The only proxies I've ever messed w/ were either out in the world or the AV scanner proxy in my gateway. I've never built one before. In a case like this would it be appropriate to use a proxy as the OPB? In other words: Would the proxy go in front of the gateway? I mean, that would make sense, but it also means that I'd be dropping an appliance in front of my FW. Isn't that an even bigger risk?

Nobody says there isn't. However you only say you run a router with a firewall, HIDS and NIDS but you don't post service configuration and actual attack / block data? And as far as putting stuff in front of things: in this case you're just an end point. And IP Suite intricacies dictate that whatever you put in front of (advertising) devices won't cut it as everything is behind your CPE. *And while sundialsvcs uses too much words (could've just said "provide them with VPN access") here I agree as it kind of fits the bill...

New technologies always have security holes but I think you're exaggerating / misrepresenting things because the amount of known, unfixed exploits in what you call "more-limited" closed source Flash easily exceeds those of the HTML5 spec. If you disagree: I can easily quantify vulnerabilities for Adobe Flash (yes, that's 855 and counting) but can you please do the same for "no limit mischief" HTML5 spec? Or else research a bit before you post sensationalist stuff / misinformation?

Actually, I "used too much words" to refer to *a specific kind, and setup* of [Open]VPN: one that uses tls-auth to conceal the VPN server from the outside world.

Visible OpenVPNs are as much an attack-target as anything else, because, unfortunately, most VPNs are secured with very-short PSKs == Passwords.

Therefore, you conceal the very existence of the server, and place it at an unpredictable non-standard port. You further secure the connection with individually-issued, 4096-bit certificates, "password-encrypted" or not. Now, your services are protected by a VPN that can't even be located by a would-be attacker. And, if any one key is lost or compromised, it "drops dead."

I would go with IPTABLES, IPSET and FAIL2BAN to lock out those ip addresses that are constantly hitting nothing. By nothing I mean trying to log in but unable to. Set it up to block 3 failed attempts within an hour block fro an hour and 5 failed attempts in a day block permanently.


I like this idea also.

I was finally able to confirm that they sent it to me w/ a trojan in it. I locked down my FW. I was able to isolate and block the trojan's outbound traffic at the outer FW. I also found some published filters rules that pertain to that particular trojan and imported them. And I did some custom rules in my FW to change what outbound that box is allowed to do. (Blocked all out and white listed their C&C block). And I blocked a bunch of inbound ports and services for that box. I also set up some extra filters / blocks between the rest of the NT and the DMZ pertaining specifically to that trojan, just to be on the safe side. I think I've managed to shut down all communications to and from the trojan w/o changing the box itself. Their VPN still works. All is quiet again. Hopefully it will stay that way.

I was going to let this go. But then, being a borderline OCD butthead with all the social graces of your average adjustable wrench I decided not to.

1) I'm the paranoid type. I don't like to post specific security configuration information unless absolutely necessary.

2) I didn't post logs b/c I didn't know of what value they would be. As I stated, perhaps not well enough, they were heavily corrupted.

3) I wasn't actually looking for someone to do it for me or give me a direct answer for a step by detailed step on how to fix it. I'd rather figure it out for myself. I feel that I learn a lot more that way.

4) When I ask a general question I don't expect a specific answer. But that does not mean that someone with more knowledge or experience could not be of great assistance w/ a short blurb. Heck, you needn't even have bothered w/ a link. Search terms would have been great b/c the googles were not being my friend. (I thought I made that clear? Perhaps not?)

In other words an answer along the lines of:

"Yes, lunkhead, detecting and auto dropping scanner crap at the router level can be done quite easily. It can be done with a snort/guardian or fwsnort/psad combo. Have you even bothered to look at recursive cheeseburgerization?"

Would have been more than sufficient.

I'm paranoid too. Looking at logs is vital.
Who doesn't? And it is hella scary.

Here's what I did.
Installed fail2ban, ssh protection on by default, created a custom jail (happy to share).
Started forwarding apache logs (encrypted sessions) to a centralized logserver using logstash-forwarder.
Installed an "ELK stack" using this excellent guide on the logserver and I can crunch log data all day long.

IP giving me trouble? Search it all in Kibana.
Go back 5m, or a year (assuming > 1 year 'running')

logstash-forwarder sends log data in "near real-time" and I've only noticed it takes Kibana4 longer to refresh a Discover
Search, and by that time the data is already on the logserver.

If I can/could install this ELK stack, I have little doubt that anyone so determined to "figure it out for myself"
cannot do so as well.

logstash-forwarder requires a .crt file but that can be made on the logserver host and copied to the intended
clients.

I have a recipe some where around here. And quite a few links (I save stuff).
I only forward a few select logs but that is easily configured in a logstash-forwarder.conf.

Good Luck.
Discuss!

Subscribed with interest...

I'm running a cobbled together home network with a bunch of junk on it that I do various stuff with. Between real machines, virtual machines, appliances and gizmos I have about 30 things on my net.

My true outer physical boundary is my modem. I bought my own from a company that actually gives a crap about security. It is the first home modem that I have personally ever found that allows you to change the password on it, control where it can be logged in to from and offers occasional firmware updates. Every other modem I've ever had couldn't do any of those things and if they even had a password on them at all it was hard coded and had usually been published by somebody.

After the modem I have a FW, gateway, router, AV proxy, HIDs, NIDs all in one combo that can do a bunch of other stuff too. I built the hardware out of junk. I installed an all in one FW distro on it that has a ton of tools and addons.

I know how to permanently ban IP addys trying to log in to SSH and that is already set up on the gateway.

As it is currently it has a pattern matching traffic analyzer (NIDs) in it. When traffic matches a pattern that traffic is dropped by a second program that monitors the NIDs. Perfect.

But, what is not set up and what I can't find any googles on how to set up is that once a pattern has been matched to just permanently drop all further traffic from the offending IP addy.

With this attack, as far as I can tell, all of the malformed traffic was correctly analyzed and dropped. But the speed and volume of the traffic literally caused the unit to choke when both RAM and swap filled up with traffic faster than the P4 at the heart of the unit could crunch it. And instead of just dropping everything else coming from the offending IPs w/o analyzing it further the unit just kept right on allowing the malformed traffic from the offending IP past the FW and trying to use the pattern matcher / monitor to figure out if the traffic was good or bad.

So, what I would like to figure out how to do is to permanently auto drop any IP that sends me things like network scanning commands or tries to remotely open a shell or any of the other dozens upon dozens of things an automated attack framework can do that are harmful but don't involve trying to log in to SSH.

And If I can throw a service on top of that maintains an auto updating block list of known bad IPs I wouldn't argue w/ that either, every little bit helps.

Mainly what I'm looking for here as far as help goes is:" Have you looked at XYZ?" I don't know enough about what I'm searching for to get any relevant returns. Once I'm on the right path I will be able to find my own way.

I see you are stuck on this, so "You're Welcome".

End Transmission.

I don't get it. Did I miss something?

I've honestly been too busy with the new job to fiddle with this at all. The current set of block rules and filters are holding and I appear to have their trojan contained.

I'll take a self-updating block list if I can get it.

What I would rather have is a daemon that monitors the NIDs and once an IP addy matches a known bad traffic pattern that daemon then tells the FW to auto drop any further traffic from the offending IP. Or something to the same general effect.