Date: Fri, 08 Jun 2001 08:25:37 -0400 From: Jim Conner <jconner@enterit.com> To: "Ted Mittelstaedt" <tedm@toybox.placo.com> Cc: "Bill Moran" <wmoran@iowna.com>, <patl@Phoenix.Volant.ORG>, "Josh Thomas" <jdt2101@ksu.edu>, <freebsd-questions@FreeBSD.ORG> Subject: RE: IPFW rules and outward connections Message-ID: <5.1.0.14.0.20010608082306.024808d0@mail.enterit.com> In-Reply-To: <001201c0efda$63e90b20$1401a8c0@tedm.placo.com> References: <3B200EEF.86F950D1@iowna.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I like your comments, I agree with your comments...I warn against some comments made... Beware the lamers...even a blind squirrel finds a nut now and then. Don't underestimate the power of the darkside. - Jim ph34r th3 ll4mA5 =P I can talk the talk...but I am nowhere near walking the walk. I always thought "hacker jargon" was strangely interesting anyway. At 10:18 PM 6/7/2001 -0700, Ted Mittelstaedt wrote: >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 - Jim - NOTJames - jconner@enterit.com - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - | Today's errors, in contrast: | - | Windows - "Invalid page fault in module kernel32.dll at 0032:A16F2935" | - | UNIX - "segmentation fault - core dumped" | - | Humans - "OOPS, I've fallen and I can't get up" | - -------------------------------------------------------------------------- - (To view this properly use a non-proportional font in your MUA) 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?5.1.0.14.0.20010608082306.024808d0>