lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f9dabe22050720142729349ef@mail.gmail.com>
Date: Wed Jul 20 22:28:00 2005
From: maxxess at gmail.com (Niklas)
Subject: Snatching IP on LAN,
	how to DoS/block such machines?

Oh forgot to mention this is a univeristy, open around the clock, with
thousands of users with physical access to whatever.

But I  thank you kindly, Marc No Mad. You really helped out on the subject. :p

Addon: I don't have access to the  DHCP, or any other central
services. So we're back the "how do i DoS my clients" on my  subnet,
based on ip/MAC?

No 802.1x available here .... probably won't be in 2005....

/n

On 7/20/05, Madison, Marc <mmadison@...i.com> wrote:
> Physical security.....   ;)
> 
> -----Original Message-----
> From: full-disclosure-bounces@...ts.grok.org.uk
> [mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Niklas
> Sent: Wednesday, July 20, 2005 2:25 PM
> To: FD-mailing
> Subject: [Full-disclosure] Snatching IP on LAN, how to DoS/block such
> machines?
> 
> Consider the following scenario:
> 
> Your are running a decent network (say a couple of c-net) with a non
> anonymous DHCP. It is not possible to have smart switches to each
> endpoint. In the last stage the clients are connected to dumb switches.
> 
> Everything is fine until a user shutdown a (DHCP:ed) computer and use
> its IP on the private portable that the user just connected to the same
> outlet, or on an outlet on the same subnet (user hardcodes IP and may be
> located.. anywhere where this subnet is available)
> 
> This is noticed pretty quickly since such a computer is bound to show up
> in internal systems (inventory can't log on, software can't be deployed,
> viruses are reported from this IP, snort finds interesting traffic etc
> etc)
> 
> The network admin then blocks the users MAC at routerlevel. The user can
> have an IP (hardcoded), but won't be able to do external traffic at all
> beyond default gateway, this is pretty useless to the hijacking user.
> 
> User then modifies his MAC to match a valid PC's MAC. User is instantly
> DHCP:ed/allowed at router level. User still ends up in logs, but since
> user has firewall enabled admin can do nothing on the net against the
> local machine (at least not automatically) aside from start blocking
> valid MACs.
> 
> 
> How do you "shut down" such hijackers? Blocking MAC at router level is
> not an option since the real machine might be turned on later
> (unblocking, as well as blocking, involves net admin, thoose changes
> doesn't happen in real time, probably week time :))
> 
> The intrusion itself is sooner or later detected by systems
> automatically, in most cases almost instantly since we are talking about
> P2P-users. There is a possibilty to script stuff on the subnet when this
> happens, but how to proceed?
> 
> I'm thinking something like TFN in the good old days (for a short period
> of time, until hijacker gives up), or a smart ARP-poisoning. In other
> words, how do I DoS "my own" clients? I don't mind bringing a switch on
> it knees since this type of incident always occurs after office hours. I
> have full control of all of the clients on the subnet except the
> hijackers', but no access to the router.
> 
> Any suggestions are most welcome -- if your answer considers the above
> "It is not possible to have smart switches to each endpoint" :)
> 
> /n
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> 
> 
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ