Date: Thu, 7 Jun 2001 22:18:02 -0700 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Bill Moran" <wmoran@iowna.com>, <patl@Phoenix.Volant.ORG> Cc: "Josh Thomas" <jdt2101@ksu.edu>, <freebsd-questions@FreeBSD.ORG> Subject: RE: IPFW rules and outward connections Message-ID: <001201c0efda$63e90b20$1401a8c0@tedm.placo.com> In-Reply-To: <3B200EEF.86F950D1@iowna.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I'll relate a recent story security and access lists that may interest some folks. We have a customer who one day discovered some changes in some logfiles in a Linux 2.2 webserver system they had. After investigating they determined that their server had been cracked into. They called us for help. We arrainged a site survey the following day and a meeting to talk about how to secure their connection. The next morning before the meeting we noticed that their connection to us (a full T1) had gone into saturation on the outbound channel at 4:00am. This was atypical behavior of course. I called them and told them what was going on but not to do anything as I wanted to see the server myself. When I got there after about 15 minutes I determined that someone had uploaded a IRC proxy (GNU source) to their server, obviously their server was participating in a DoS attack against some target. I also determined that the system was so old and the probability of inserted trojans so high that it wasn't worth attempting to secure, I just told them to get their data off it and reformat it and reinstall a current version of Linux and this time to install the appropriate security patches. Needless to say they didn't have the time immediately to do this but they planned to do it the following week. (this customer is a distributor and the info on the webserver was basically public data anyway, and they didn't care that someone had access to it) But they did ask if there was anything I could do about the DoS hijack. Since it would have been pointless to delete the IRC proxy off their webserver (since the cracker could just upload it again through the same hole) I decided to insert a block of port 6667 in their border router. This of course disabled the control channel for the IRC proxy and stopped the hijack. Now, in my humble opinion, it would have been child's play for the cracker to simply access the system again, and modify the IRC proxy to use a different port for the IRC control channel. After all I didn't block any other ports, all the holes were there. This WAS a DoS attack and thus it didn't matter one whit what port was in use in the attack, any would have worked. So I didn't expect my block to last any length of time. But, guess what, it was completely effective for over a week before they finally redid their server. This is the kind of mentality that your dealing with, with most crackers. Sure, there's some really good (or warped) crackers out there who would have reactivated their little toy in seconds. But these people aren't going to waste their time on something like this site. The real mentality that your dealing with, with 99% of these crackers out there are people so dumb that they cannot even make a simple port number modification in their code. They barely have any understanding of networking technology and even crude and simple access lists are beyond their comprehension. All they do is to follow some recipies that their betters have put together for them, and if something goes wrong and the recipie doesen't work, they have no idea how to go about fixing it (or breaking the system, depending on your viewpoint) and so they just move on to the next easy-to-compromise system. This is really the situation of the street where half the homes lock their doors and the other half don't. There are so very many ancient Linux or unsecured Windows systems out there that if you make even a modicum of effort to lock your door, since most crackers are basically morons, they are unable to deal with the situation and just move on to the next house/system. Of course, if you do have something of real value there, like a database of thousands of valid credit card numbers, then this doesen't apply. But, the point is that Hollywood makes it out that all crackers are super-sophisticated technologists that know computer systems back, forth and upside down, and that to block them you have to have super-sophisticated methods yourself. But, the reality is that most crackers are morons and even simple filters and blocks that aren't themselves that good, present enough of an obstacle to these people that they won't be able to figure out a way around them. Ted Mittelstaedt tedm@toybox.placo.com Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com >-----Original Message----- >From: owner-freebsd-questions@FreeBSD.ORG >[mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of Bill Moran >Sent: Thursday, June 07, 2001 4:32 PM >To: patl@Phoenix.Volant.ORG >Cc: Josh Thomas; freebsd-questions@FreeBSD.ORG >Subject: Re: IPFW rules and outward connections > > >patl@Phoenix.Volant.ORG wrote: > >> > Will allow the IP listed to initiate a ssh connection to anyone or >> > receive a ssh connection from anyone, while the second rule >ensures that >> > the connection can continue to communicate and the final rule blocks >> > anything that doesn't fit into the first category. >> > tcp communications must establish themselves, therefore >anything that is >> > not specifically allowed to "setup" will never get to the "established" >> > state. (it's probably best, for speed, to always put the "established" >> > rule near the beginning of your ruleset) >> >> But some l33t h4x0r can craft bogus packets which -claim- to be part >> of a non-existant established connection. > >ph33r m3!!! :p ... silly h4x0r5p33k. >I'm curious, then. Do you feel that dynamic rules are more secure then? >So far it appears the ipfw rulesets I've put together have scared off >anyone with malicious intent, as I've not yet had a break-in. But that >doesn't mean my boxes are 100%. >Really, just about any ruleset can be breached by someone with enough >time/knowledge. Do you know of any way that a forged >established-connection packet can do anything more than DoS? There are >other defenses to be taken against DoS, such as rate limiting, etc. >Don't mean to take this off-topic (am I?) but I'm alway on the lookout >to see what more I can learn about security. > >-Bill > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001201c0efda$63e90b20$1401a8c0>