2 Feb
2002
2 Feb
'02
5:01 p.m.
On February 2, Jeff Hellige wrote:
However, the admin must assume that someone WILL just walk in and do
whatever they wish, when the admin least expects it...some people do
it because they're assholes, some just do it without thinking because
they weren't raised to have any manners. One must strive to make the
network resilient to such crap.
-Dave
--
Dave McGuire
St. Petersburg, FL "Less talk. More synthohol." --Lt. Worf
I guess my
opinion, which isn't very popular here, is that unless
permission has been explicitly given, one should not assume permission
to a local LAN, or internet access through the LAN. I do recognize that
my position is due to working frequently at secured sites. One such
facility, in San Antonio, prohibits ANY access to their network by
non-employees. Contractors must tell a technician what commands to
enter, and which buttons to click.
I agree with the above. Nobody should ever just assume it is
ok to do whatever they wish on somebody elses network withouth
getting explicit permission first. I have similar problems with
contractors in a similar secure building. If for no other reason
than it is bad etiquette to impose yourself into someone elses area
without permission to do so. 
2 Feb
2 Feb
10:45 a.m.
On Sat, 2 Feb 2002, Dave McGuire wrote:
On February 2, Jeff Hellige wrote:
However, the admin must assume that someone WILL just walk in and do
whatever they wish, when the admin least expects it...some people do
it because they're assholes, some just do it without thinking because
they weren't raised to have any manners. One must strive to make the
network resilient to such crap.
Moral of the story: if you're anal about this sort of thing, don't leave
unguarded or unused network ports "hot".
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
I guess
my opinion, which isn't very popular here, is that unless
permission has been explicitly given, one should not assume permission
to a local LAN, or internet access through the LAN. I do recognize that
my position is due to working frequently at secured sites. One such
facility, in San Antonio, prohibits ANY access to their network by
non-employees. Contractors must tell a technician what commands to
enter, and which buttons to click.
I agree with the above. Nobody should ever just assume it is
ok to do whatever they wish on somebody elses network withouth
getting explicit permission first. I have similar problems with
contractors in a similar secure building. If for no other reason
than it is bad etiquette to impose yourself into someone elses area
without permission to do so. 
5:24 p.m.
However, the admin must assume that someone WILL
just walk in and do
whatever they wish, when the admin least expects it...some people do
it because they're assholes, some just do it without thinking because
they weren't raised to have any manners. One must strive to make the
network resilient to such crap.
True. I was looking at it from the point as to whether it
was ok for someone to do it at all, regardless of what thier motives
might be behind it or whether the network was secure enough to handle
it if someone did happen to do so. With our LAN for instance, we
don't enable or allow DHCP at all...everyone is on static IP
addresses. We're always having to track down conflicts though
because there's a small group within the building that think they can
do whatever they wish.
Jeff
--
Home of the TRS-80 Model 2000 FAQ File
http://www.cchaven.com
http://www.geocities.com/siliconvalley/lakes/6757
6:12 p.m.
On Sat, Feb 02, 2002 at 11:24:18PM -0500, Jeff Hellige wrote:
How about using DHCP to ground them? As in:
- all machines legitimately using the network are known as well as
their ethernet addresses,
- assign all those legitimate machines an (basically fixed) IP via
DHCP,
- for all unregistered machines, offer them IP addresses in the
127.0.0.0 range as well as themself as their default router and other
stuff to make their network connection a notwork connection
You still get notified of them via the logs of your DHCP server and -
given suitable networking hardware - can track them down.
Regards,
Alex.
--
9./10. M?rz 2002: 4. Chemnitzer Linux-Tag http://www.tu-chemnitz.de/linux/tag/
"I sense much NT in you. NT leads to Blue Screen, Blue Screen leads to
downtime, downtime leads to suffering. NT is the path to the Dark Side."
-- Ellsworth, one small voice
However, the
admin must assume that someone WILL just walk in and do
whatever they wish, when the admin least expects it...some people do
it because they're assholes, some just do it without thinking because
they weren't raised to have any manners. One must strive to make the
network resilient to such crap.
True. I was looking at it from the point as to whether it
was ok for someone to do it at all, regardless of what thier motives
might be behind it or whether the network was secure enough to handle
it if someone did happen to do so. With our LAN for instance, we
don't enable or allow DHCP at all...everyone is on static IP
addresses. We're always having to track down conflicts though
because there's a small group within the building that think they can
do whatever they wish. 
6:45 p.m.
On Sun, 3 Feb 2002, Alexander Schreiber wrote:
How about using DHCP to ground them? As in:
- all machines legitimately using the network are known as well as
their ethernet addresses,
- assign all those legitimate machines an (basically fixed) IP via
DHCP,
- for all unregistered machines, offer them IP addresses in the
127.0.0.0 range as well as themself as their default router and other
stuff to make their network connection a notwork connection
I kind of like that! No! I *REALLY* like it! Have you tested this?
By The Way, concerning my scenario, I'm on the BOD of the computer
group, without any input as to the building's network setup. Although
I'm liking the security suggestions too.
Doc
3 Feb
3 Feb
2:09 a.m.
> - all machines legitimately using the network
are known as well as
> their ethernet addresses,
> - assign all those legitimate machines an (basically fixed) IP via
> DHCP,
> - for all unregistered machines, offer them IP addresses in the
> 127.0.0.0 range as well as themself as their default router and other
> stuff to make their network connection a notwork connection
I kind of like that! No! I *REALLY* like it! Have
you tested this?
We have something like this at PLNU. Unknown MAC addresses get dropped into
a category where the network will only allow them to connect to the
registration server -- it drops packets bound elsewhere. To register for a
"fixed IP over DHCP" lease, they have to have their bills paid and their
student ID, SSN, etc., and then they get the DHCP lease for the year
wherever they go on campus. The system is now almost totally automated.
So, an unauthorised laptop connecting on campus basically doesn't work;
their packets end up in /dev/null. There are plenty of public terminals if
surfin der Veb's all they want to do.
--
----------------------------- personal page: http://www.armory.com/~spectre/ --
Cameron Kaiser, Point Loma Nazarene University * ckaiser(a)stockholm.ptloma.edu
-- A baby is God's opinion that the world should go on. -- Carl Sandburg ------
5:04 a.m.
On Sun, 3 Feb 2002, Cameron Kaiser wrote:
I go to Purdue University. Remembering that we are a *state* funded
institution, I'll go through the differences we have here.
Most classrooms have PC's, and a lot of Professors/Instructors have
laptops. Next to pretty much any live network jack for the PC in the
classroom there is a live 'extra' network jack, usually with DHCP enabled
so anyone could use it (yes, ANYONE with a machine that supports DHCP).
Most labs around here are not open anywhere near 24x7, although during
the semester (excluding all university holidays when EVERYTHING is locked
up) there usually is at least one lab open.
Personally, I like the fact that if I'm giving a presentation, I can plug
my laptop into any open ethernet port without having to talk to someone...
especially considering my parents are paying about $15k/year to send me
here. 'It just makes sense' to have the people that are funding your job
have access to your services, doesn't it? (in a University setting at
least)
Currently, several of the schools are setting up 802.11b wireless networks
in their building. For engineering, you have to register your MAC address
to be able to use it, for some others, you can't use it unless you have a
real need, and for yet others (the School of Education for example), there
is no real access controls.
While I'd say I don't necessarily agree with a complete lack of access
controls, it's a good thing to let students use the network. Heck,
they're the ones paying your salary!
-- Pat
> - all
machines legitimately using the network are known as well as
> their ethernet addresses,
> - assign all those legitimate machines an (basically fixed) IP via
> DHCP,
> - for all unregistered machines, offer them IP addresses in the
> 127.0.0.0 range as well as themself as their default router and other
> stuff to make their network connection a notwork connection
I kind of like that! No! I *REALLY* like it!
Have you tested this?
We have something like this at PLNU. Unknown MAC addresses get dropped into
a category where the network will only allow them to connect to the
registration server -- it drops packets bound elsewhere. To register for a
"fixed IP over DHCP" lease, they have to have their bills paid and their
student ID, SSN, etc., and then they get the DHCP lease for the year
wherever they go on campus. The system is now almost totally automated.
So, an unauthorised laptop connecting on campus basically doesn't work;
their packets end up in /dev/null. There are plenty of public terminals if
surfin der Veb's all they want to do.
8202
days inactive
8203
days old
6 comments
7 participants
participants (7)
-
als＠thangorodrim.de -
doc＠mdrconsult.com -
foo＠siconic.com -
jhellige＠earthlink.net -
mcguire＠neurotica.com -
pat＠purdueriots.com -
spectre＠stockholm.ptloma.edu