Date: Wed, 18 Aug 1999 10:55:16 +0200 From: Dan Larsson <support@junglenote.com> To: "'ChrisMic@clientlogic.com'" <ChrisMic@clientlogic.com> Cc: "'mkc@Graphics.Cornell.EDU'" <mkc@Graphics.Cornell.EDU>, Jamie Norwood <mistwolf@ethereal.net>, "freebsd-questions@FreeBSD.ORG" <freebsd-questions@FreeBSD.ORG> Subject: SV: dhcpd Message-ID: <01BEE968.285B8670.support@junglenote.com>
next in thread | raw e-mail | index | archive | help
I think I need to comment on this.. Scroll down. > -----Ursprungligt meddelande----- > Fr=E5n: Christopher Michaels [SMTP:ChrisMic@clientlogic.com] > Skickat: den 17 augusti 1999 16:58 > Till: 'support@junglenote.com'; 'mkc@Graphics.Cornell.EDU' > Kopia: Jamie Norwood; freebsd-questions@FreeBSD.ORG > =C4mne: RE: dhcpd >=20 > Ok, I have to chime in on this one. see below. >=20 > > > Yes it is, but keep reading. He confirmed my guess about wanting = it to > > > prevent servers. Really all it does to people who want to run a = server > > > is annoy them. Meanwhile it annoys your friendly non-abusing = users as > > > well. Not what I would consider a good idea. Not long ago I met = a guy > > > who was running a web server on a machine using dhcp. He had a = friend > > > running his DNS service and every time his IP address changed he = just > > > sent the new address to his friend who updated his DNS and he was = back > > > in business. Of course this works best if both you and your = friend > > > spend all your time on the net... > >=20 > > How does this bother the 'friendly non-abusing user'? I've never = seen, > > even m$ > > boxes included, die from having their ip address changed with or = without > > dhcp. > > You must mean something else, right? > >=20 > I believe what is meant is that any active connections will just > stop responding when the IP address is changed from under them. I can = see > it now, I'm downloading the new service pack to my crappy WordPerfect = 9, it > gets through 20MB of the 36MB patch, and *BOOM*, IP address changes = and the > connection drops, forcing me back to square 1. >=20 > That's an extreem example, what if someone's on ICQ, or playing an > online game, etc, etc.. This would end up alienating your 'good' = customers > more than it would the 'bad' ones. I know I would switch isp's in a > heartbeat (if this is an isp we're dealing with), unreliable service = is > unacceptable when that service is being paid for, and from a = customer's > point of view, this would be un-reliable service. >=20 > On the same tolken, what kind of a lease time are we talking about? > 2hrs, 12hrs, 24hrs? 24 hrs >=20 > > And as I mentioned earlier, from the clients point of view it's much > > easier just to > > apply for a static address. > > The other solution would be to deny access to all and punch holes in = the > > fw for=20 > > every client allowed. This works. I know. But the rules table for = the > > firewall grows=20 > > to monolithic proportions, understandably due to the myriad of = available > > software > > applications.=20 > >=20 > This has it's down sides as well. You'd have to put SO many holes > in this firewall it'd be crazy. My current internet connection is = through a > local university, and they block ALL incomming connections except on = port > 113 (ident). I can't tell you how much trouble this causes me. ICQ > doesn't work right, I can't play most online games, simple things like = a DCC > chat on IRC doesn't work, netmeeting doesn't work, the list goes on. >=20 > I understand what you are trying to do, stop people from abusing the > system and putting up static servers on a dynamic connection. Even = the idea > of blocking well known ports would be undesirable because the people = you > want to stop are, for the most part, smart enough to not use a = standard > port. >=20 > Personally I am against any solution that punishes the good users to > stop the few bad users. I personally feel the best solution would be = to > keep logs of connection time and bandwidth, and have something alert = you to > problem users, people with long uptimes and alot of outgoing = bandwidth. But > then again, this is only my opinion. >=20 >=20 > > A second alternative which is similar to the above. And it's setting > > bandwidth=20 > > rules for every ip in the scope. Which also works, but sets the = problem > > out of=20 > > focus. The following paragraph is the desired solution: "The most desireable solution from my point of view would be to deny = regular ip datatypes (http-data etc) from the internet to the clients. e.g. to deny a request from the internet to access any ip resource on the client = side.=20 And from there punch holes to allow access to certain ips to be accessed = from the internet. This I do not know how to do. If someone does please let me = know." This is an addition to the above paragraph: I might have been unclear of what I meant. This is regardless of which = port destination the actual data is transmitted to on the client side. So the solution = would be to construct a filter that disallows a certain data-type connection/transmission from = the internet=20 to the client, except for those permitted that specific type of data. To me this doesn't sound impossible and I'm sure there already are = solutions for this available. The quirk comes when looking for such a software which = can be run on fbsd. As it seems to me now I have better luck pursuing this issue in a = seperate thread. > >=20 > > /D > >=20 > As I said earlier, this is more trouble than it's worth, there are a > good number of programs that use random/dynamic port numbers. Granted = some > can be restricted, such as ICQ and mIRC, but others cannot = (netmeeting). > And again, let's say you open up ports 4000-5000 for ICQ users, what's = to > stop your "bad" user from just putting a server on that port. >=20 > Another viable option would be to do regular port scans on your > users, but anyone using a *NIX based system will easily be able to = detect > and block those (unless you use a utility such as nmap, and use it's = stealth > mode). This is getting rather complicated tho. >=20 > One last thing, since most of the original posting was chopped off, > I'm going on some assumptions. I am assuming that this is in an ISP > situation where you have dialup users with dynamically assigned IP > addresses. =20 Actually the whole solution is based on a citywide mesh of radio = antennas connected via a fibre backbone to the internet. /D 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?01BEE968.285B8670.support>