Setting specific IP address?

Discussion in 'Computer Security' started by trs80, May 9, 2005.

  1. trs80

    trs80 Guest

    How do you go about setting a specific IP address for a PC thats using XP?
    I see where to do the settings but here are several field to fill in in
    addition to the IP..such as:

    IP:
    Subnet:
    Default Gateway:

    Preferred DNS server
    Alternate DN server

    I know what the IP should be, but what about the rest of the fields?

    thank you
    trs80, May 9, 2005
    #1
    1. Advertising

  2. trs80

    Bit Twister Guest

    On Sun, 8 May 2005 16:39:49 -0700, trs80 wrote:
    > How do you go about setting a specific IP address for a PC thats using XP?
    > I see where to do the settings but here are several field to fill in in
    > addition to the IP..such as:


    Clickup a CMD terminal and do a
    ipconfig /all
    for examples.


    >
    > IP:
    > Subnet:
    > Default Gateway:
    >
    > Preferred DNS server
    > Alternate DN server
    >
    > I know what the IP should be, but what about the rest of the fields?


    gateway is the ip addy of next node on the way to the internet.
    sub net would be something like
    192.168.2.0 if your ip is something like 192.168.2.10

    DNS is ip address of the Domain Name Server which you want to change
    names into ip address like yahoo.com into 66.94.234.13 for you to see
    the web page.
    Bit Twister, May 9, 2005
    #2
    1. Advertising

  3. trs80

    Jim Watt Guest

    On Sun, 8 May 2005 16:39:49 -0700, "trs80" <> wrote:

    >How do you go about setting a specific IP address for a PC thats using XP?


    it rather depends what its connected to.
    --
    Jim Watt
    http://www.gibnet.com
    Jim Watt, May 9, 2005
    #3
  4. trs80

    andy smart Guest

    trs80 wrote:
    > How do you go about setting a specific IP address for a PC thats using XP?
    > I see where to do the settings but here are several field to fill in in
    > addition to the IP..such as:
    >
    > IP:
    > Subnet:
    > Default Gateway:
    >
    > Preferred DNS server
    > Alternate DN server
    >
    > I know what the IP should be, but what about the rest of the fields?
    >
    > thank you
    >
    >

    Why do you need to provide a fixed IP address for this machine? If it's
    on a network you might as well let DHCP handle it for you (if it's on a
    network but still needs a fixed IP then you can reserve an address in
    DHCP so it always gets the same one). Is this because you have a small
    network of peer-to-peer machines which does not have DHCP so you must IP
    each machine individually? How will the network connect to the Internet,
    if it has to?
    andy smart, May 9, 2005
    #4
  5. trs80

    Talker Guest

    If you cannot get to the internet or contact other computers on your
    network, I suggest that you contact your system admin and let him know your
    TCP/IP settings are incorrect
    Talker, May 9, 2005
    #5
  6. trs80

    Moe Trin Guest

    In article <d5nul3$22l$>, andy smart wrote:

    >Why do you need to provide a fixed IP address for this machine? If it's
    >on a network you might as well let DHCP handle it for you


    Some organizations feel that using DHCP is a quite unnecessary security
    risk. If your network has an adequate number of IP addresses for the
    number of computers connected, then the only real advantage of DHCP is
    when you have computers being disconnected and moved here and there.
    That's another security risk not needed.

    >(if it's on a network but still needs a fixed IP then you can reserve
    >an address in DHCP so it always gets the same one).


    What is the difference in the effort to set up a static IP address on
    the DHCP (D is for Dynamic), then to set it on the host? If, like an
    ISP (cable/DSL), you have smart people administering a server, and all
    of the people "administering" the clients have the computer knowledge
    of a toadstool, and you can tolerate the security risks, then DHCP may
    be a sensible solution. On the other hand (particularly when the same
    people are administering the servers AND clients), you need to balance
    the effort to configure the server, verses the effort to configure the
    individual hosts, and factor in security issues.

    >Is this because you have a small network of peer-to-peer machines which
    >does not have DHCP so you must IP each machine individually?


    2131 Dynamic Host Configuration Protocol. R. Droms. March 1997.
    (Format: TXT=113738 bytes) (Obsoletes RFC1541) (Updated by RFC3396)
    (Status: DRAFT STANDARD)

    and you can trace that standard back to BOOTP (RFC0951 in September 1985).
    The DHCP standards have always had a 'Section 7' entitled "Security
    Considerations", the first paragraph of that section reads:

    7. Security Considerations

    DHCP is built directly on UDP and IP which are as yet inherently
    insecure. Furthermore, DHCP is generally intended to make
    maintenance of remote and/or diskless hosts easier. While perhaps
    not impossible, configuring such hosts with passwords or keys may be
    difficult and inconvenient. Therefore, DHCP in its current form is
    quite insecure.

    Thanks, but DHCP has never been authorized here.

    Old guy
    Moe Trin, May 10, 2005
    #6
  7. Moe Trin wrote:

    > In article <d5nul3$22l$>, andy smart wrote:
    >
    >>Why do you need to provide a fixed IP address for this machine? If it's
    >>on a network you might as well let DHCP handle it for you

    >
    > Some organizations feel that using DHCP is a quite unnecessary security
    > risk. If your network has an adequate number of IP addresses for the
    > number of computers connected, then the only real advantage of DHCP is
    > when you have computers being disconnected and moved here and there.
    > That's another security risk not needed.


    The problem is that whether you configure your hosts with static IP
    (manually on the PC) or use DHCP you really never know if IP x.y.z.1 is
    REALLY who it is supposed to be. This is because IP never had any
    verification scheme built into it. 802.1x attempts to fix this.

    >>(if it's on a network but still needs a fixed IP then you can reserve
    >>an address in DHCP so it always gets the same one).


    Under some scenarios this does make sense. I have a sales guy that is
    rumored to go to some, how shall I say it, questionable web sites. Now, My
    DHCP servers have a 3 day cache time. Since he is often gone for a week or
    two at a time. I have setup the DHCP server to always give him the same IP
    address. This helps me to track his web activies without him knowing....

    > What is the difference in the effort to set up a static IP address on
    > the DHCP (D is for Dynamic), then to set it on the host? If, like an
    > ISP (cable/DSL), you have smart people administering a server, and all
    > of the people "administering" the clients have the computer knowledge
    > of a toadstool, and you can tolerate the security risks, then DHCP may
    > be a sensible solution. On the other hand (particularly when the same
    > people are administering the servers AND clients), you need to balance
    > the effort to configure the server, verses the effort to configure the
    > individual hosts, and factor in security issues.
    >
    >>Is this because you have a small network of peer-to-peer machines which
    >>does not have DHCP so you must IP each machine individually?

    >
    > 2131 Dynamic Host Configuration Protocol. R. Droms. March 1997.
    > (Format: TXT=113738 bytes) (Obsoletes RFC1541) (Updated by RFC3396)
    > (Status: DRAFT STANDARD)
    >
    > and you can trace that standard back to BOOTP (RFC0951 in September 1985).
    > The DHCP standards have always had a 'Section 7' entitled "Security
    > Considerations", the first paragraph of that section reads:
    >
    > 7. Security Considerations
    >
    > DHCP is built directly on UDP and IP which are as yet inherently
    > insecure. Furthermore, DHCP is generally intended to make
    > maintenance of remote and/or diskless hosts easier. While perhaps
    > not impossible, configuring such hosts with passwords or keys may be
    > difficult and inconvenient. Therefore, DHCP in its current form is
    > quite insecure.
    >
    > Thanks, but DHCP has never been authorized here.
    >
    > Old guy



    802.1x has a lot of promise. Currently, Cisco is implementing it in their
    wireless products. However, not everyone supports it currently.

    Michael
    --
    "Trusted Computing" is a SCAM
    http://www.gnu.org/philosophy/can-you-trust.html

    Protect your rights
    http://www.eff.org/
    http://www.publicknowledge.org/
    Michael Pelletier, May 11, 2005
    #7
  8. trs80

    Winged Guest

    Moe Trin wrote:
    > In article <d5nul3$22l$>, andy smart wrote:
    >
    >
    >>Why do you need to provide a fixed IP address for this machine? If it's
    >>on a network you might as well let DHCP handle it for you

    >
    >
    > Some organizations feel that using DHCP is a quite unnecessary security
    > risk. If your network has an adequate number of IP addresses for the
    > number of computers connected, then the only real advantage of DHCP is
    > when you have computers being disconnected and moved here and there.
    > That's another security risk not needed.
    >
    >
    >>(if it's on a network but still needs a fixed IP then you can reserve
    >>an address in DHCP so it always gets the same one).

    >
    >
    > What is the difference in the effort to set up a static IP address on
    > the DHCP (D is for Dynamic), then to set it on the host? If, like an
    > ISP (cable/DSL), you have smart people administering a server, and all
    > of the people "administering" the clients have the computer knowledge
    > of a toadstool, and you can tolerate the security risks, then DHCP may
    > be a sensible solution. On the other hand (particularly when the same
    > people are administering the servers AND clients), you need to balance
    > the effort to configure the server, verses the effort to configure the
    > individual hosts, and factor in security issues.
    >
    >
    >>Is this because you have a small network of peer-to-peer machines which
    >>does not have DHCP so you must IP each machine individually?

    >
    >
    > 2131 Dynamic Host Configuration Protocol. R. Droms. March 1997.
    > (Format: TXT=113738 bytes) (Obsoletes RFC1541) (Updated by RFC3396)
    > (Status: DRAFT STANDARD)
    >
    > and you can trace that standard back to BOOTP (RFC0951 in September 1985).
    > The DHCP standards have always had a 'Section 7' entitled "Security
    > Considerations", the first paragraph of that section reads:
    >
    > 7. Security Considerations
    >
    > DHCP is built directly on UDP and IP which are as yet inherently
    > insecure. Furthermore, DHCP is generally intended to make
    > maintenance of remote and/or diskless hosts easier. While perhaps
    > not impossible, configuring such hosts with passwords or keys may be
    > difficult and inconvenient. Therefore, DHCP in its current form is
    > quite insecure.
    >
    > Thanks, but DHCP has never been authorized here.
    >
    > Old guy
    >

    Of course you can allow only registered MACs to gain an address and use
    DHCP. Is it required, probably not, but it can make life easier
    especially with geographically dispersed networks. Since you also have
    to register the host to the domain this information can be easily
    gathered at the same time you are setting certificates and gathering
    host, license and inventory information within your netinit script.

    In a large network it is sometimes fun finding that duplicate IP that
    someone (I won't pick on our help desk personnel) set erroneously.
    Especially if the subnet is geographically dispersed across several
    buildings. Usually requires trapping the IP to trace the IP through the
    switch and identify the wire and cable box the wire is attached to.
    Information can be gathered through SMS though with groups moving around
    frequently static IP's can be a hassle. It can be managed, but DHCP can
    be used relatively securely an reduces the management overhead and the
    pain in movement. By relying on MAC management, instead of IP
    management, it can make certain misbehaviors easier to identify. Aliens
    on the network issues disappear. While for various reasons certain
    hosts must have IPs reserved we have never had a serious security issue
    with DHCP, not saying it couldn't happen....

    Winged
    Winged, May 11, 2005
    #8
  9. trs80

    nemo_outis Guest

    Winged <> wrote in
    news:897b6$42815b5e$18d6d844$:

    ....snip...
    > Of course you can allow only registered MACs to gain an address and
    > use DHCP. Is it required, probably not, but it can make life easier
    > especially with geographically dispersed networks. Since you also
    > have to register the host to the domain this information can be easily
    > gathered at the same time you are setting certificates and gathering
    > host, license and inventory information within your netinit script.
    >
    > In a large network it is sometimes fun finding that duplicate IP that
    > someone (I won't pick on our help desk personnel) set erroneously.
    > Especially if the subnet is geographically dispersed across several
    > buildings. Usually requires trapping the IP to trace the IP through
    > the switch and identify the wire and cable box the wire is attached
    > to. Information can be gathered through SMS though with groups moving
    > around frequently static IP's can be a hassle. It can be managed, but
    > DHCP can be used relatively securely an reduces the management
    > overhead and the pain in movement. By relying on MAC management,
    > instead of IP management, it can make certain misbehaviors easier to
    > identify. Aliens on the network issues disappear. While for various
    > reasons certain hosts must have IPs reserved we have never had a
    > serious security issue with DHCP, not saying it couldn't happen....
    >
    > Winged
    >



    Every bit helps. However, it is trivial to spoof MACs.

    Regards,
    nemo_outis, May 11, 2005
    #9
  10. nemo_outis wrote:

    > Winged <> wrote in
    > news:897b6$42815b5e$18d6d844$:
    >
    > ...snip...
    >> Of course you can allow only registered MACs to gain an address and
    >> use DHCP. Is it required, probably not, but it can make life easier
    >> especially with geographically dispersed networks. Since you also
    >> have to register the host to the domain this information can be easily
    >> gathered at the same time you are setting certificates and gathering
    >> host, license and inventory information within your netinit script.
    >>
    >> In a large network it is sometimes fun finding that duplicate IP that
    >> someone (I won't pick on our help desk personnel) set erroneously.
    >> Especially if the subnet is geographically dispersed across several
    >> buildings. Usually requires trapping the IP to trace the IP through
    >> the switch and identify the wire and cable box the wire is attached
    >> to. Information can be gathered through SMS though with groups moving
    >> around frequently static IP's can be a hassle. It can be managed, but
    >> DHCP can be used relatively securely an reduces the management
    >> overhead and the pain in movement. By relying on MAC management,
    >> instead of IP management, it can make certain misbehaviors easier to
    >> identify. Aliens on the network issues disappear. While for various
    >> reasons certain hosts must have IPs reserved we have never had a
    >> serious security issue with DHCP, not saying it couldn't happen....
    >>
    >> Winged
    >>

    >
    >
    > Every bit helps. However, it is trivial to spoof MACs.
    >
    > Regards,


    True both MAC and IP spoofing is quite trivial...and quite lethal if you
    know what you are doing...

    ....the long term solution is 802.1x but vendor support has been slow...

    Michael
    --
    "Trusted Computing" is a SCAM
    http://www.gnu.org/philosophy/can-you-trust.html

    Protect your rights
    http://www.eff.org/
    http://www.publicknowledge.org/
    Michael Pelletier, May 11, 2005
    #10
  11. Winged wrote:

    > Michael Pelletier wrote:
    > Under some scenarios this does make sense. I have a sales guy that is
    > rumored to go to some, how shall I say it, questionable web sites. Now, My
    > DHCP servers have a 3 day cache time. Since he is often gone for a week or
    > two at a time. I have setup the DHCP server to always give him the same IP
    > address. This helps me to track his web activies without him knowing....
    >
    > Of course as part of the login script you can just capture the IP
    > address and the machine name and append it to a network file somewhere
    > with date/time. You can grep the ip addy fairly easily from a central
    > file location. We used to do it this way..hrrm think we still do though
    > I seldom use that file to find users these days...SMS can also tracks
    > historical IP assignments to authenticated user. With IDS usually
    > catching sin in real time these days, it usually just looking up the
    > machine name then crossing it to the user. Though your way works, he
    > prolly not the wiser.
    >
    > Luckily we don't usually have users doing stupid more than once or
    > twice, after that they are finding other employment. We are pretty
    > liberal, but all users have a signed user agreement that specifies what
    > will make them dance the Danny Deaver, that is 2 pages of specific
    > prohibited activities. It is amazing the effectiveness of written
    > policy with real world defined consequences for abuse, and management
    > support for enforcement.
    >
    > Winged


    I am in the first phase. I have heard rumors and before anyone starts
    accusing anyone I want to gather proof. Since it is first time I am sure he
    will be only warned...Anyway, he should know better....

    --
    "Trusted Computing" is a SCAM
    http://www.gnu.org/philosophy/can-you-trust.html

    Protect your rights
    http://www.eff.org/
    http://www.publicknowledge.org/
    Michael Pelletier, May 11, 2005
    #11
  12. trs80

    Winged Guest

    Michael Pelletier wrote:
    Under some scenarios this does make sense. I have a sales guy that is
    rumored to go to some, how shall I say it, questionable web sites. Now, My
    DHCP servers have a 3 day cache time. Since he is often gone for a week or
    two at a time. I have setup the DHCP server to always give him the same IP
    address. This helps me to track his web activies without him knowing....

    Of course as part of the login script you can just capture the IP
    address and the machine name and append it to a network file somewhere
    with date/time. You can grep the ip addy fairly easily from a central
    file location. We used to do it this way..hrrm think we still do though
    I seldom use that file to find users these days...SMS can also tracks
    historical IP assignments to authenticated user. With IDS usually
    catching sin in real time these days, it usually just looking up the
    machine name then crossing it to the user. Though your way works, he
    prolly not the wiser.

    Luckily we don't usually have users doing stupid more than once or
    twice, after that they are finding other employment. We are pretty
    liberal, but all users have a signed user agreement that specifies what
    will make them dance the Danny Deaver, that is 2 pages of specific
    prohibited activities. It is amazing the effectiveness of written
    policy with real world defined consequences for abuse, and management
    support for enforcement.

    Winged
    Winged, May 11, 2005
    #12
  13. trs80

    Winged Guest

    nemo_outis wrote:
    > Winged <> wrote in
    > news:897b6$42815b5e$18d6d844$:
    >
    > ....snip...
    >
    >>Of course you can allow only registered MACs to gain an address and
    >>use DHCP. Is it required, probably not, but it can make life easier
    >>especially with geographically dispersed networks. Since you also
    >>have to register the host to the domain this information can be easily
    >>gathered at the same time you are setting certificates and gathering
    >>host, license and inventory information within your netinit script.
    >>
    >>In a large network it is sometimes fun finding that duplicate IP that
    >>someone (I won't pick on our help desk personnel) set erroneously.
    >>Especially if the subnet is geographically dispersed across several
    >>buildings. Usually requires trapping the IP to trace the IP through
    >>the switch and identify the wire and cable box the wire is attached
    >>to. Information can be gathered through SMS though with groups moving
    >>around frequently static IP's can be a hassle. It can be managed, but
    >>DHCP can be used relatively securely an reduces the management
    >>overhead and the pain in movement. By relying on MAC management,
    >>instead of IP management, it can make certain misbehaviors easier to
    >>identify. Aliens on the network issues disappear. While for various
    >>reasons certain hosts must have IPs reserved we have never had a
    >>serious security issue with DHCP, not saying it couldn't happen....
    >>
    >>Winged
    >>

    >
    >
    >
    > Every bit helps. However, it is trivial to spoof MACs.
    >
    > Regards,
    >

    Indeed, however certain things must be married. To date this has been
    beyond the will of our users. If a duplicate registered MAC appeared or
    appeared on the wrong subnet, the detection would be equally trivial.
    Yes the certificate keys could be copied, and AD name duplicated, but
    when certain things didn't marry properly, there is a very high
    probability that activity would be noticed. With net forensics in
    place, activity would be tracked. While it is possible that the
    "intruder" would have the intrinsic knowledge of operations to spoof
    what would be required, to get it right, the first time would be
    remarkable. It is far simpler to compromise a box in place than use an
    alien.

    I believe it is far less trivial to spoof a MAC than an IP. It does
    tend to stop the routine visitor from plugging in and running without
    authorization. It would not stop a determined inside hacker with the
    intrinsic knowledge of operations. It is reasonably effective. Like all
    things no one security layer can be trusted to secure operations.

    There have been folks whose business is intrusion who have found some of
    our methods problematic to get around. Their access was gained simply
    placing a key logger on a keyboard port gain a user login, the following
    day they broke the PC simply by removing user files had a help desk
    technician with elevated permissions log in to look at the device, then
    an admin.... Who even looks at the keyboard plug ...... mutters.

    Winged
    Winged, May 11, 2005
    #13
  14. trs80

    Moe Trin Guest

    In article <897b6$42815b5e$18d6d844$>, Winged wrote:

    >Of course you can allow only registered MACs to gain an address and use
    >DHCP. Is it required, probably not, but it can make life easier
    >especially with geographically dispersed networks. Since you also have
    >to register the host to the domain this information can be easily
    >gathered at the same time you are setting certificates and gathering
    >host, license and inventory information within your netinit script.


    We're not using windoze. Still, when anyone logs in to the computer,
    there are records because we're using a central authentication scheme.
    However, if you are going to go through the effort of registering MACs,
    and plugging that into a DHCP server, why not set static addresses? For
    us, this is the difference of 3 verses 7 entries of text in one
    configuration file.

    >In a large network it is sometimes fun finding that duplicate IP that
    >someone (I won't pick on our help desk personnel) set erroneously.


    As it takes root (administrator) rights to change the address, and we don't
    hand out root to that many people, we don't have this problem to often.
    ALL of the system come in through the IT support shop, and software is
    installed and configured there, so we can catch this pretty easy. As part
    of the bookkeeping, such information as MAC address is recorded before the
    systems are connected to the network.

    >Especially if the subnet is geographically dispersed across several
    >buildings. Usually requires trapping the IP to trace the IP through the
    >switch and identify the wire and cable box the wire is attached to.


    Managed switches, and documentation when the wires/fiber was installed.
    Another factor is the layout of the networks. I have 19 subnets in four
    buildings, and know pretty much were the exact break points are without
    having to refer to documents.

    >Information can be gathered through SMS though with groups moving around
    >frequently static IP's can be a hassle.


    What with new systems coming in, people being moved, repairs and whatnot,
    I don't think I see more than one percent of the hardware changing in any
    given week. For user moves, it's an easy enough job that we use a student
    intern. In the relatively rare occasions where the IP address is going
    to change, an admin SSHs in and changes the configuration file ahead of
    time. The student has a sudo authorization to run '/sbin/shutdown -h now',
    and that's all that's needed for a move.

    >It can be managed, but DHCP can be used relatively securely an reduces the
    >management overhead and the pain in movement. By relying on MAC management,
    >instead of IP management, it can make certain misbehaviors easier to
    >identify.


    The problem with MAC addresses (and IPs for that matter) is that they can
    be altered on the older network cards - it's a command line option, but
    you need to be root. We avoid that by limiting the number of root users.
    I also notice that the new Gigabit cards we're getting in won't accept
    MAC changes. Not surprising, as that function was really only needed on
    Token Ring networks, and I haven't seen one of those in _years_ (we never
    had any here). Sure, the old adage is 'physical access beats five aces',
    but the cases are locked, so that is _somewhat_ less of a problem.

    >Aliens on the network issues disappear.


    BIG signs on all entrances prohibiting visiting computers with dire
    punishments. Actually the last alien we caught was the corporate president
    who came out for a visit shortly after the policy was put in place. He was
    to busy to notice the signs (since enlarged), and brought his new lapdog
    with him. At some point in the visit, he decides to check his mail on the
    East coast, and plugs into the network in the division president's office.
    WTF are those thundering herds of the guards, system and network admins
    running around for, and why doesn't the network work? The funny was that
    he had signed the corporate level policy bulletin less than a month earlier.

    Old guy
    Moe Trin, May 11, 2005
    #14
  15. trs80

    Moe Trin Guest

    In article <27cb0$4281edfd$18d6d844$>, Winged wrote:

    >nemo_outis wrote:


    >> Every bit helps. However, it is trivial to spoof MACs.


    Yes, but it's getting harder. Only a few of the 100 Megabit NICs we have
    will allow this, and the Gigabit cards we're getting lack this capability.
    I suppose you could hack try hacking the driver...

    >To date this has been beyond the will of our users. If a duplicate
    >registered MAC appeared or appeared on the wrong subnet, the detection
    >would be equally trivial.


    Yup - we were monitoring the ARP caches of servers and routers back when
    we were on thicknet even before we started adding 10BaseT. When we added
    switches to break up collision domains, we started monitoring them too.

    >With net forensics in place, activity would be tracked. While it is
    >possible that the "intruder" would have the intrinsic knowledge of
    >operations to spoof what would be required, to get it right, the first
    >time would be remarkable. It is far simpler to compromise a box in
    >place than use an alien.


    Users have always been the weak link. Our admin accounts are all using
    security token cards, but the regular user still depends on username and
    password (we've separated usernames from email addresses, so the username
    actually does provide a tiny bit of security). Shoulder surfing is still
    a perceived problem.

    >I believe it is far less trivial to spoof a MAC than an IP.


    Especially if the NIC won't accept this

    >It does tend to stop the routine visitor from plugging in and running
    >without authorization.


    They'd have to unplug an existing computer and spoof that, because we
    really do try to de-activate unused network drops. Adding a hub or
    switch to an existing drop might work in some areas, but you're stuck in
    that the alien wouldn't be allowed to speak, because they can't use an
    existing MAC, and would be detected immediately if it used any other.

    >It would not stop a determined inside hacker with the intrinsic knowledge
    >of operations. It is reasonably effective. Like all things no one security
    >layer can be trusted to secure operations.


    Absolutely.

    >There have been folks whose business is intrusion who have found some of
    >our methods problematic to get around. Their access was gained simply
    >placing a key logger on a keyboard port gain a user login, the following
    >day they broke the PC simply by removing user files had a help desk
    >technician with elevated permissions log in to look at the device, then
    >an admin.... Who even looks at the keyboard plug ...... mutters.


    That would work here against ordinary users. Our help desk usually
    works over the net, so that's out. If an admin type does have to visit,
    the security token card also avoids that problem.

    Old guy
    Moe Trin, May 11, 2005
    #15
  16. trs80

    nemo_outis Guest

    (Moe Trin) wrote in
    news::

    > In article <27cb0$4281edfd$18d6d844$>, Winged wrote:
    >
    >>nemo_outis wrote:

    >
    >>> Every bit helps. However, it is trivial to spoof MACs.

    >
    > Yes, but it's getting harder. Only a few of the 100 Megabit NICs we
    > have will allow this, and the Gigabit cards we're getting lack this
    > capability. I suppose you could hack try hacking the driver...
    >


    Easy to spoof in software (use smacs, arpspoof, etc.) but hardware is
    better. The lazy will just "repeat" the desired MAC using a router, but my
    preference is the Speeddemon line with true hardware MAC programmability
    (including gigabit):

    http://www.sd330.com/products.htm

    It is almost always possible to find a computer that is down to spoof
    (especially good are little-used isolated machines at legacy pooled
    scanners, etc.). The brutal will "force" another target computer offline
    before stealing its MAC (yes, this risks detection but is surprisingly
    effective if done right)

    Not that this cannot be countered - anything can! - but professional tools
    are a joy to use :)

    Regards,
    nemo_outis, May 11, 2005
    #16
  17. trs80

    andy smart Guest

    Moe Trin wrote:
    > In article <d5nul3$22l$>, andy smart wrote:
    >
    >
    >>Why do you need to provide a fixed IP address for this machine? If it's
    >>on a network you might as well let DHCP handle it for you

    >
    >
    > Some organizations feel that using DHCP is a quite unnecessary security
    > risk. If your network has an adequate number of IP addresses for the
    > number of computers connected, then the only real advantage of DHCP is
    > when you have computers being disconnected and moved here and there.
    > That's another security risk not needed.
    >
    >
    >>(if it's on a network but still needs a fixed IP then you can reserve
    >>an address in DHCP so it always gets the same one).

    >
    >
    > What is the difference in the effort to set up a static IP address on
    > the DHCP (D is for Dynamic), then to set it on the host? If, like an
    > ISP (cable/DSL), you have smart people administering a server, and all
    > of the people "administering" the clients have the computer knowledge
    > of a toadstool, and you can tolerate the security risks, then DHCP may
    > be a sensible solution. On the other hand (particularly when the same
    > people are administering the servers AND clients), you need to balance
    > the effort to configure the server, verses the effort to configure the
    > individual hosts, and factor in security issues.


    Actually, and of course I speak for me and my experience, its a lot
    faster to do via DHCP (with reservations if required) than to set client
    IP. We have 200+ stations here which often need rebuilding, I would say
    that most get a total re-installation at least once if not twice a year.
    I can start it going via PXE and go off and leave it knowing that it
    will get its OS installed, all the apps deployed via AD and an IP
    assigned via DHCP and I need not go back to it at any stage unless
    something goes wrong! I used to work somewhere where we used to do fixed
    IP, so we had to have an accurate listing of which machines got which
    IP, then we had to set them up one at a time; they've now gone onto DHCP
    (they also now re-build every one of their machines at least once a
    month which solves most of the problems we used to have in my day)


    >
    >
    >>Is this because you have a small network of peer-to-peer machines which
    >>does not have DHCP so you must IP each machine individually?

    >
    >
    > 2131 Dynamic Host Configuration Protocol. R. Droms. March 1997.
    > (Format: TXT=113738 bytes) (Obsoletes RFC1541) (Updated by RFC3396)
    > (Status: DRAFT STANDARD)
    >
    > and you can trace that standard back to BOOTP (RFC0951 in September 1985).
    > The DHCP standards have always had a 'Section 7' entitled "Security
    > Considerations", the first paragraph of that section reads:
    >
    > 7. Security Considerations
    >
    > DHCP is built directly on UDP and IP which are as yet inherently
    > insecure. Furthermore, DHCP is generally intended to make
    > maintenance of remote and/or diskless hosts easier. While perhaps
    > not impossible, configuring such hosts with passwords or keys may be
    > difficult and inconvenient. Therefore, DHCP in its current form is
    > quite insecure.
    >
    > Thanks, but DHCP has never been authorized here.
    >
    > Old guy
    >
    andy smart, May 12, 2005
    #17
  18. trs80

    Moe Trin Guest

    In article <Xns965394CFD407Fabcxyzcom@127.0.0.1>, nemo_outis wrote:
    > (Moe Trin) wrote in
    >news::


    >> Yes, but it's getting harder. Only a few of the 100 Megabit NICs we
    >> have will allow this, and the Gigabit cards we're getting lack this
    >> capability. I suppose you could hack try hacking the driver...

    >
    >Easy to spoof in software (use smacs, arpspoof, etc.) but hardware is
    >better.


    Again, we're not using windoze. Actually, if the card and driver are
    capable of setting the address, no extra software is needed - it's an
    standard option to the configuration tool since the early-1980s.

    >The lazy will just "repeat" the desired MAC using a router, but my
    >preference is the Speeddemon line with true hardware MAC programmability
    >(including gigabit):
    >
    >http://www.sd330.com/products.htm


    Who's making the hardware/software? The website is aimed at consumers,
    and I certainly hope their technical specs are actually a lot more
    realistic than what is shown on the web pages. Doing a google search,
    I turn up a grand total of six hits, including one from you in 2003.

    Looking at the domain registration gives me ZERO confidence. Someone who
    wants to hide behind godaddy, and DomainsByProxy.com obviously isn't
    quite what my management would want to hear. Heck, there are literally 43
    "manufacturers" listed in the OUI list whose place of business is a "room"
    on some floor of a large building in Taiwan or elsewhere. What's with these
    people? The guarantee is also rather lame - 30 days from date of invoice to
    them receiving it back in cherry condition - AFTER you manage to get an RMA?

    They advertise it for several versions of windoze, and tell people to see
    the 'download' page for more information. There, they mention such
    definitive information that is works with Novell (and don't bother to
    mention which version - which may indicate a problem because the SD430
    section talks about ODI, but not HAM), SCO Open server (again, versions?),
    Artisoft LANtastic (is anyone still using that ancient crap), and Redhat
    (which implies some version of Linux, but not which of over fifty releases
    of Red Hat, never mind if this might apply to any of the hundred plus
    other distributions of Linux - they might have given some clue by
    mentioning a RH version, or more appropriately a Linux kernel version, but
    it's pretty obvious they're not aware of these subtleties,). There might
    be a clue in the download area, but the top of that page says "Only
    customers are authorized to download". On the other hand, if you still
    have someone running windoze for workgroups (3.11 from 1993) they claim to
    have a driver. Another thing that gives non-windoze users real confidence
    is that the "driver" is only available in a .zip file download - which is a
    dos/windoze file format. Sorry, where is the gzip'ed tarball, or even a
    tar.Z file.

    The FAQ page at http://www.sd330.com/faq.txt also gives zero confidence.
    The question "Is there another way to change MAC address?" is absolute
    FUD. So is the third section of "I want to change MAC address, should I buy
    a SpeedDemon network card?" It may scare windoze lusers, but it shows that
    the page was written under strict instructions from the sales weasels,
    rather than anyone who has ANY technical knowledge. Truth? WTF is that?

    Old guy
    Moe Trin, May 12, 2005
    #18
  19. trs80

    Moe Trin Guest

    In article <d5vig4$laa$>, andy smart wrote:
    >Moe Trin wrote:


    >> What is the difference in the effort to set up a static IP address on
    >> the DHCP (D is for Dynamic), then to set it on the host?


    >Actually, and of course I speak for me and my experience, its a lot
    >faster to do via DHCP (with reservations if required) than to set client
    >IP.


    For us, it's the difference between filling in three entries in a text file,
    and seven - seconds. Our network masks are standardized, so one need only
    look at the paperwork that comes with the system to get hostname and IP.
    The rest of the data is 'fingers on autopilot'. For an install or re-install,
    it's not even that much, as the install program (about a 250 line shell
    script) asks for the hostname, and does a lookup and then configures based
    on that.

    >We have 200+ stations here which often need rebuilding,


    The only systems we rebuild are those going in or out of the facility,
    which is extremely few.

    >I would say that most get a total re-installation at least once if not
    >twice a year.


    When we do a re-install, it always is a 'wipe and install' operation,
    as we do them as a security measure. But this effects well under one
    percent of the system in any given week.

    >I can start it going via PXE and go off and leave it knowing that it
    >will get its OS installed, all the apps deployed via AD and an IP
    >assigned via DHCP and I need not go back to it at any stage unless
    >something goes wrong!


    Installations aren't my regular job, but we're doing something similar.
    We install a floppy drive (only a handful of systems have a removable
    media drive - NONE of the workstations), and insert a floppy with the
    installer. It comes up on the net using an installation IP, connects to
    the file server, and just pours the bits straight to disk. Part of the
    initial setup asks for hostname (which it looks up to get parameters) and
    the type of install (workstation, <mumble>server, etc) and things are then
    pretty much automatic. The paperwork takes longer than the work at the
    keyboard. On new systems, the initial stage is slightly different,
    because the install guy does an inventory (serial numbers, etc.), and
    boots the system using a burn-in program (which is a heavy-duty compiling
    program to flog the hardware to limits) which is run for a minimum of 48
    hours to weed out the preme's..

    >I used to work somewhere where we used to do fixed IP, so we had to have
    >an accurate listing of which machines got which IP, then we had to set
    >them up one at a time;


    Part of the "customer service" our install crew does in to make and
    attach an embossed tape (Dymo) label on the upper left of each computer
    and monitor giving the hostname. As for accurate lists, thats why
    we run DNS which is updated by a 'makefile' from the central database.
    The registrar makes all the data entry into that as part of the system
    registration process (which serves a multitude of processes, including
    how the individual cost centers get billed for computer services).

    >they've now gone onto DHCP (they also now re-build every one of their
    >machines at least once a month which solves most of the problems we used
    >to have in my day)


    Cue the standard joke about how to fix any problem on a windoze box
    'reboot', 'reload' 'reformat and reload' for increasing seriousness
    of the problem. We don't use windoze, so we don't have that problem.

    Old guy
    Moe Trin, May 12, 2005
    #19
  20. trs80

    nemo_outis Guest

    (Moe Trin) wrote in
    news::
    ....snip...
    >>http://www.sd330.com/products.htm

    >
    > Who's making the hardware/software? The website is aimed at consumers,
    > and I certainly hope their technical specs are actually a lot more
    > realistic than what is shown on the web pages. Doing a google search,
    > I turn up a grand total of six hits, including one from you in 2003.
    >
    > Looking at the domain registration gives me ZERO confidence. Someone
    > who wants to hide behind godaddy, and DomainsByProxy.com obviously
    > isn't quite what my management would want to hear. Heck, there are
    > literally 43 "manufacturers" listed in the OUI list whose place of
    > business is a "room" on some floor of a large building in Taiwan or
    > elsewhere. What's with these people? The guarantee is also rather
    > lame - 30 days from date of invoice to them receiving it back in
    > cherry condition - AFTER you manage to get an RMA?
    >
    > They advertise it for several versions of windoze, and tell people to
    > see the 'download' page for more information. There, they mention
    > such definitive information that is works with Novell (and don't
    > bother to mention which version - which may indicate a problem because
    > the SD430 section talks about ODI, but not HAM), SCO Open server
    > (again, versions?), Artisoft LANtastic (is anyone still using that
    > ancient crap), and Redhat (which implies some version of Linux, but
    > not which of over fifty releases of Red Hat, never mind if this might
    > apply to any of the hundred plus other distributions of Linux - they
    > might have given some clue by mentioning a RH version, or more
    > appropriately a Linux kernel version, but it's pretty obvious they're
    > not aware of these subtleties,). There might be a clue in the download
    > area, but the top of that page says "Only customers are authorized to
    > download". On the other hand, if you still have someone running
    > windoze for workgroups (3.11 from 1993) they claim to have a driver.
    > Another thing that gives non-windoze users real confidence is that the
    > "driver" is only available in a .zip file download - which is a
    > dos/windoze file format. Sorry, where is the gzip'ed tarball, or even
    > a tar.Z file.
    >
    > The FAQ page at http://www.sd330.com/faq.txt also gives zero
    > confidence. The question "Is there another way to change MAC address?"
    > is absolute FUD. So is the third section of "I want to change MAC
    > address, should I buy a SpeedDemon network card?" It may scare windoze
    > lusers, but it shows that the page was written under strict
    > instructions from the sales weasels, rather than anyone who has ANY
    > technical knowledge. Truth? WTF is that?
    >
    > Old guy




    The speeddemon site and folks are flaky and disreputable, true. But WTF
    would one expect when buying hacker tools? (and that's what they clearly
    are despite the "nudge, nudge, wink, wink" stuff to give - a very thin -
    veneer of legitimacy). Actually, their longevity is amazing given their
    "business model."

    Moreover, their boards do work fine (at least mine has). As for the
    software, I agree the "works under this or that OS" stuff is vague but it
    only really means that their software front end(s) can access their
    hardware to program it - and that's not very OS-version dependent. So,
    yeah, they're vague and sloppy, but their interfacing software does what
    it claims. In short, their hardware and software work.

    Net result: 1/10 for style points, 10/10 for effectiveness. (Well, maybe
    a 2-point deduction for being grossly overpriced.)

    Now as for whether you run windoze, Unix, Linux, *BSD, or whatever on
    server - or client - machines, none of this matters for someone who
    simply wishes to hang an unauthorized machine on the network by spoofing
    a legitimate MAC (he gets to pick his preferred OS :) Yes, he can spoof
    the MAC in software, but a hardware-programmable NIC card is much more
    convenient and versatile.

    As for hijacking legitimate but (temporarily) unused MACs, there are a
    million methods. One of the handiest is to have someone (other than
    oneself) send out a general email notice regarding something or other
    (corporate charity drive, etc.) and see who comes back with autoreply
    emails of the form "I will be out of the office until June 23" or
    whatever. Bingo! (Traditionalists like me prefer instead to inspect the
    paper holiday schedule :)

    Regards,

    PS For those who prefer to spoof MACs in software there are readily-
    available tools for virtually every OS out there. This works because the
    hardware MAC is (almost) invariably mediated through a software driver
    before being put out over the network and the driver can be - ahem!
    "misinformed" regarding the MAC. SMAC is convenient with windows,
    arpspoof for Linux, but there are many alternatives and variants. Before
    SMAC I used to patch the windows registries on client machines - SMAC
    just made it a tad handier.
    nemo_outis, May 12, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    541
  2. mimiseh
    Replies:
    3
    Views:
    832
  3. Albie
    Replies:
    1
    Views:
    467
    Walter Roberson
    Nov 15, 2005
  4. Scott Smith
    Replies:
    5
    Views:
    1,156
    Darrell Gorter[MSFT]
    Oct 17, 2007
  5. ttripp
    Replies:
    5
    Views:
    2,192
    Thrill5
    Feb 5, 2010
Loading...

Share This Page