I get this type of attack also. The latest one is different in both the length of time spent on it and the distinct characteristic of only attempting to gain root access. By all indications, this was a scripted attack. The port numbers used seemed to follow a general upward trend with a pseudo-random reset to a lower port. I'm sure there are multiple scripts for running brute force attacks of this kind. I expect the scripted attacks to grow ever more sophisticated over time, as there is definitely a professional bent to system cracking these days. I do have a question for y'all. Is there some non-crippling thing I can do to my system to detect an attack and : 1) send me an email (optionally), 2) log the conversation for xxx seconds, 3) automatically update the firewall to block the offending user/script. Keep in mind I'm running on an antique here: Pentium Pro 200 MHz @ 40MB RAM w/ ~8 GB of disk. P.S. - I have an email and phone call in to the good people at the USDA and will update you all on anything I may find out. Assuming they will ever admit that one of their PCs has been compromised.
-----Original Message----- From: Dustin Decker .
I've been seeing a lot of traffic that behaves in similar fashion, across sensors deployed on various ISP's for which the only common link is being a client of mine, and the attacks. I (and more importantly my clients) stay off the radar pretty well, so I am inclined to think this is a scripted process, executed after a root-kit is installed etc. to further the conquest.
If you watch the behavior, and the ascending port numbers, it looks more and more like I am correct. What I find interesting is the sources change over time, and then we see the script trying an even larger number of user names.
Another reference point - I see this a lot more on roadrunner clients than any others. Someone is ramping up for something, looking for launch platforms is my guess. Anyone interested in seeing the entire conversations (rather than the logged info below) can drop me an e-mail and I will obfuscate things and offer 'em up. Due to confidentiality clauses in my contracts, I will have to munge the IPs that I am protecting, and make a mess of the checksums etc.
-----Original Message----- From: kclug-bounces@kclug.org [mailto:kclug-bounces@kclug.org] On Behalf Of Brian Densmore [snip] I do have a question for y'all. Is there some non-crippling thing I can do to my system to detect an attack and : 1) send me an email (optionally), 2) log the conversation for xxx seconds, 3) automatically update the firewall to block the offending user/script. Keep in mind I'm running on an antique here: Pentium Pro 200 MHz @ 40MB RAM w/ ~8 GB of disk.
Portsentry is the knee-jerk reaction you might get from some folks. I tend to disagree however, as it is also frequently used to bind to other service ports, which can make for a busier box... and reactive blocking isn't so much a science as an art. Any reactive system has a tendency, once an attacker has deduced its use, to be a perfect denial of service tool. (I.E. if you bank at umb.com, a spoof of that IP address directed at you can black hole it, and your significant other can't reach the website to pay bills, etc.) Snort can do the log conversation for xxx seconds bit you asked about - it can log the whole thing truth be known. If you want to get daring, you can look at snort in-line as well. When traffic of a particular type occurs, you can intercept the responses from your system (or others hiding behind your snort install) and rewrite them on the way out. An excellent use for this is to catch outbound scan attempts from [insert Windows worm of the week here] infestations and kill 'em. I generally don't have this problem, but if folks like, oh, RoadRunner.com were to do this, it would make life a lot easier for the rest of us. Obviously there are pluses and minuses to pretty much everything. Paper or plastic, Coke or Pepsi, Free or Slave, Kerry or Bush - merely illusions of choice. The same seems to be true of security - short of turning it off and locking it away, there is no silver bullet. D.
Quoting Dustin Decker <dustin.decker@1on1security.com>:
-----Original Message----- From: kclug-bounces@kclug.org [mailto:kclug-bounces@kclug.org] On Behalf Of Brian Densmore
[snip]
Keep in mind I'm running on an antique here: Pentium Pro 200 MHz @ 40MB RAM w/ ~8 GB of disk.
The last time I used Portsentry which (combined with tcpwrappers or iptables and smtp service and a bit of shell scripting) will do what you're after, I ran it on similar hardware under Red Hat 6.x. I didn't notice it taxing the system, but I was only having it add entries to /etc/hosts.deny. The systems I needed to get in from were all "whitelisted" in /etc/hosts.allow.
reactive blocking isn't so much a science as an art. Any reactive system has a tendency, once an attacker has deduced its use, to be a perfect denial of service tool.
Excellent point, that's one of the reasons I stopped using it. Another was, if you're writing code that's going to take user input, it is often repeated in secure programming literature that you should check the user input and make sure it's sane, that it fits your application. It is assumed that you know what valid inputs consist of, they probably aren't things like "' or 1='1". If you get a user input that doesn't fit your expectations, by all means stop processing it and ask again or disconnect the user, etc. Shouldn't this same idea apply to services on your system? Say you want to offer SSH. Unless you're an ISP or something, you shouldn't need to offer SSH access to any address anywhere. You know what IP ranges you generally operate from, set your firewall to allow access from IPs within those ranges and deny everything else. Add another layer, configure SSH to only allow certain users remote access. By all means, don't allow root to login remotely. Configure your MaxStartups accordingly, and so on...
If you want to get daring, you can look at snort in-line as well. When traffic of a particular type occurs, you can intercept the responses from your system (or others hiding behind your snort install) and rewrite them on the way out.
I've got to take some time to play with Snort. I didn't know it could do that. Are there signatures available for common problem traffic?
Obviously there are pluses and minuses to pretty much everything.
[snip]
Kerry or Bush - merely illusions of choice.
Nice.
The same seems to be true of security - short of turning it off and locking it away, there is no silver bullet.
I hope you're locking it deep. Bunker busters are hell on computers. -- Dave Hull http://insipid.com
"Dave Hull" <dphull@insipid.com> wrote:
Another was, if you're writing code that's going to take user input, it is often repeated in secure programming literature that you should check the user input and make sure it's sane, that it fits your application. It is assumed that you
That's not just 'secure' programming, but 'sane' programming. It is a maxim of the military that "No plan survives contact with the enemy." As a technical support veteran, I have formulated the analogous "No software survives contact with the user". Yes, it's a bit hyperbolic, but I've seen enough of what end users do to know that the proverbial Million Monkeys have a long way to go.
Shouldn't this same idea apply to services on your system? Say you want to offer SSH. Unless you're an ISP or something, you shouldn't need to offer SSH access to any address anywhere. You know what IP ranges you generally operate from, set your firewall to allow access from IPs within those ranges and deny everything else.
The problem with that one is 'generally'. You never know when an ISP will change the IP range that you use in a location, and you also never know when you're going to be somewhere else and need to get in. It might be better to have an extra layer of security for an IP outside that range. For instance, you might have it challenge the user to enter some special password (or just su to root to run a command that validates the session) and if that fails, dump them before they can do anything else.
Monty J. Harder wrote:
The problem with that one is 'generally'. You never know when an ISP will change the IP range that you use in a location, and you also never know when you're going to be somewhere else and need to get in.
It might be better to have an extra layer of security for an IP outside that range. For instance, you might have it challenge the user to enter some special password (or just su to root to run a command that validates the session) and if that fails, dump them before they can do anything else.
There's also "port knocking": http://www.portknocking.org/ . In order for the firewall to open up port 22, you would have to send a special sequence of packets, e.g. attempt to connect to a specific combination of ports in a specific order.
Quoting Gerald Combs <gerald@ethereal.com>:
There's also "port knocking": http://www.portknocking.org/ . In order for the firewall to open up port 22, you would have to send a special sequence of packets, e.g. attempt to connect to a specific combination of ports in a specific order.
What is the current thinking on port knocking? When I first heard about it, I thought is sounded like an interesting idea. Keep your ports closed, unless someone knocks on various ports and in some preprogrammed order and then fire up the service for that particular IP address, etc. It does add an additional layer and it's all about layers, right? How complicated can port knock sequences be? Can you do 1024 or more seemingly random knocks on a variety of ports in fairly short order? Can the client and the host be programmed to use key pairs so the knock sequence is not the same every time? -- Dave Hull http://insipid.com
"Gerald Combs" <gerald@ethereal.com> wrote:
There's also "port knocking": http://www.portknocking.org/ . In order for the firewall to open up port 22, you would have to send a special sequence of packets, e.g. attempt to connect to a specific combination of ports in a specific order.
It's an interesting idea, but I think it's in the category of 'security through obscurity'. I think it would be cleaner to just send a UDP packet, containing within it certain authentication information (including a timestamp), digitally signed with a private key, that would give pretty high confidence that you are legit before the TCP socket ever is opened.
Monty J. Harder wrote:
"Gerald Combs" <gerald@ethereal.com> wrote:
There's also "port knocking": http://www.portknocking.org/ . In order for the firewall to open up port 22, you would have to send a special sequence of packets, e.g. attempt to connect to a specific combination of ports in a specific order.
It's an interesting idea, but I think it's in the category of 'security through obscurity'. I think it would be cleaner to just send a UDP packet, containing within it certain authentication information (including a timestamp), digitally signed with a private key, that would give pretty high confidence that you are legit before the TCP socket ever is opened.
I think this what they do, only the authentication information is spread across the "knocks." If I understand their documentation correctly, a table is created that maps byte values to port numbers. To send a message, you have to knock the port corresponding to each byte in the message, in the proper order. I'm not sure I'd use something like this. If I needed a port opened dynamically in this fashion, I'd probably use a browser-based certificate to authenticate against a CGI which could open up the port. It does have a certain "1337" appeal, though.
So it this totally seperate from your firewall and just dynamically add lines to your config or is it a addon to the firewall and your firewall calls it when someone is knocking. Really cool stuff I should go read the site info. Thanks, Jonathan -- dj_goku -www.djgoku.com- -www.tektronic.org-
Quoting "Monty J. Harder" <lists@kc.rr.com>:
"Dave Hull" <dphull@insipid.com> wrote:
[snip]
you should check the user input and make sure it's sane, that it fits your application. [snip] That's not just 'secure' programming, but 'sane' programming. It is a maxim of the military that "No plan survives contact with the enemy." As a technical support veteran, I have formulated the analogous "No software survives contact with the user".
I agree. I was shocked when I listened to a former colleague of mine whine about users not inputing their phone number correctly on a web interface he had created. "I even put instructions right next to the fields explaining that they shouldn't input dashes or spaces or parentheses..." he said. After he cooled down, I told him that he should never expect his users to read and/or follow directions. Don't trust, but verify. He'd never thought it through before, but I saw the scales fall away from his eyes. Scary thing is, he had previously been writing code for a rather large new media company, building web sites with user interfaces. Another web application I worked with recently was vulnerable to SQL injection resulting in theft of service. I told the primary developer about and he claimed that was only the case on the test server, I asked him if I could try it on the production system. With him watching over my shoulder I went through the exact same process and he couldn't believe it. He'd heard of SQL injection, but hadn't ever read anything about it. As I dug deeper in their configuration, I determined that it was possible for an attacker to completely wipe out the database. It's amazing what you'll find in the wild. -- Dave Hull http://insipid.com
"Dave Hull" <dphull@insipid.com> wrote:
I agree. I was shocked when I listened to a former colleague of mine whine about users not inputing their phone number correctly on a web interface he had created. "I even put instructions right next to the fields explaining that they shouldn't input dashes or spaces or parentheses..." he said.
Instead of putting tr -cd '[0-9]' or if you want to allow things like 'ext' (which probably ought to be in a separate field) tr -cd '[:alnum:]' (or equivalent for the language) into his input code. There could be a client-side rule that suppresses the non-numeric characters from even showing up in the field. Sheesh. I almost always have a process of canonicalizing input (unless some other form of validation is being done). If only certain
participants (6)
-
Brian Densmore -
Dave Hull -
djgoku -
Dustin Decker -
Gerald Combs -
Monty J. Harder