Re: port 16001 and 111
Tom Cook écrivait : What the What's wrong with 'lsof -i :111' and 'lsof -i :16001'? Nothing wrong with it! :) It tells you precisely what's attempting to connect... Yes, except in his case there is no connection since there is no installed daemon on this port, only some connection attempts he is trying to track. So my solution is just to provide a mini-daemon allowing connecting and so tracking. Use netstat or lsof in /root/spy.sh as you want. I just use to use netstat so I gave an example with netstat, but you can use lsof instead off course! :) Cheers, J.C. msg07566/pgp0.pgp Description: PGP signature
Re: port 16001 and 111
On Monday 28 October 2002 11:59 pm, Jean Christophe ANDRÉ wrote: Tom Cook écrivait : What the What's wrong with 'lsof -i :111' and 'lsof -i :16001'? Nothing wrong with it! :) It tells you precisely what's attempting to connect... Yes, except in his case there is no connection since there is no installed daemon on this port, only some connection attempts he is trying to track. So my solution is just to provide a mini-daemon allowing connecting and so tracking. Use netstat or lsof in /root/spy.sh as you want. I just use to use netstat so I gave an example with netstat, but you can use lsof instead off course! :) Cheers, J.C. way overkill. 16001 isn't being scanned and 111 is the most common target after 25. you're suggesting that the guy turn his server into a honeypot--to what end? disable portmap and nothing can get at 111. there's a difference between simply securing a box and assuming a role as cyber-detective. the former solves the problem, the latter has no end. ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: port 16001 and 111
Hi, ben écrivait : way overkill. 16001 isn't being scanned and 111 is the most common target after 25. you're suggesting that the guy turn his server into a honeypot--to what end? disable portmap and nothing can get at 111. there's a difference between simply securing a box and assuming a role as cyber-detective. the former solves the problem, the latter has no end. Please read the full thread before posting (or even only the first post). He actually *is* asking for tracking the *internal* process trying to connect *localy* to its port 111. He knows about such attempts because he had filtered them. But he can't guess which process attempt to connect to it. And he just *want* to know. Tracking connection attempts *is* part of security, since it allow you to know how things work, and better tune it once you understand it. Regards, J.C. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: port 16001 and 111
On Tuesday 29 October 2002 01:02 am, Jean Christophe ANDRÉ wrote: Hi, ben écrivait : way overkill. 16001 isn't being scanned and 111 is the most common target after 25. you're suggesting that the guy turn his server into a honeypot--to what end? disable portmap and nothing can get at 111. there's a difference between simply securing a box and assuming a role as cyber-detective. the former solves the problem, the latter has no end. Please read the full thread before posting (or even only the first post). He actually *is* asking for tracking the *internal* process trying to connect *localy* to its port 111. He knows about such attempts because he had filtered them. But he can't guess which process attempt to connect to it. And he just *want* to know. Tracking connection attempts *is* part of security, since it allow you to know how things work, and better tune it once you understand it. you're missing the point. running a portmap daemon is the only vulnerability that the 111 port scans are attempting to exploit. that attempted exploit is part of the weather of being hooked up, in the same way that 25 is attempted to be used as a mail relay. there are--to the best of my knowledge--no internal apps or daemons that will cause the fashion of log alarm that the op is concerned to address. you're assuming that internal apps attempt external connections. for that to be a possibility, you'd have to have a mighty weird local setup. if you, or anybody, can give me a real example to justify your hypothesis, please do. ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: port 16001 and 111
On 0, Jean Christophe ANDR? [EMAIL PROTECTED] wrote: Tom Cook ?crivait : What the What's wrong with 'lsof -i :111' and 'lsof -i :16001'? Nothing wrong with it! :) It tells you precisely what's attempting to connect... Yes, except in his case there is no connection since there is no installed daemon on this port, only some connection attempts he is trying to track. Ah I understand now... Tom -- Tom Cook Information Technology Services, The University of Adelaide Not to limit itself to play in a sand vat. - Google translation of, not to be stuck in a sandbox. Get my GPG public key: https://pinky.its.adelaide.edu.au/~tkcook/tom.cook-at-adelaide.edu.au msg07570/pgp0.pgp Description: PGP signature
Re: DHCP
On Tue, 29 Oct 2002 at 10:52:22AM +1100, Stewart James wrote: I had the very same thoughts, being a university you can imagine what physical security is like, plus management wants to give students the ability to walk on campus and plugin, plus start wireless services too. Be weary of wireless. I take an 802.11b card and can pick an addy even If I am just joe smo public. Draw a 1000 feet circle around your wireless AP and that is the range at which I can get an addy from your DHCP... -- Excuse #71: Someone is standing on the Ethernet cable causing a kink in the cable Phil PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.txt | gpg --import XP Source Code: #include win2k.h #include extra_pretty_things_with_bugs.h #include more_bugs.h #include require_system_activation.h #include phone_home_every_so_often.h #include remote_admin_abilities_for_MS.h #include more_restrictive_EULA.h #include sell_your_soul_to_MS_EULA.h //os_ver=Windows 2000 os_ver=Windows XP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DHCP
On Mon, 28 Oct 2002 at 11:18:23PM -0800, Brandon High wrote: On Mon, Oct 28, 2002 at 07:38:38PM -0600, Hanasaki JiJi wrote: Too bad there is no way to do a secure handshake w/ an id/password or even SecureID cards. That's the idea behind PPPoE. Yuck. Or you could do ipsec: Laptop (IPSEC CLient) - WAP - Server (DHCP AND IPSEC Host) - Local Network. In order to get inside the network you will have to get past the IPSEC Host, which of course will require a key that has a valid certificate from the local CA. Just a thought... -- Excuse #218: The co-locator cannot verify the frame-relay gateway to the ISDN server. Phil PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.txt | gpg --import XP Source Code: #include win2k.h #include extra_pretty_things_with_bugs.h #include more_bugs.h #include require_system_activation.h #include phone_home_every_so_often.h #include remote_admin_abilities_for_MS.h #include more_restrictive_EULA.h #include sell_your_soul_to_MS_EULA.h //os_ver=Windows 2000 os_ver=Windows XP msg07572/pgp0.pgp Description: PGP signature
RE: DHCP
We are currently looking into wireless where I work also. Just a few weeks ago, we had this company come in to give a demo of an appliance that enforces restrictions on the wireless network. http://www.verniernetworks.com/ It seems to be along the path of what we are looking for, YMMV. Oh, and we don't have any active relationship with this firm, they are just the first to demo anything here :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DHCP
On Tue, Oct 29, 2002 at 09:35:01AM -0500, Phillip Hofmeister wrote: Laptop (IPSEC CLient) - WAP - Server (DHCP AND IPSEC Host) - Local Network. In order to get inside the network you will have to get past the IPSEC Host, which of course will require a key that has a valid certificate from the local CA. IPsec has the added advantage that it can be used to protect all wireless traffic from eavesdroppers. At the USENIX Annual Technical Conference in Monterey, CA this past June, the company providing wireless network connectivity used such a system. Since it was IPsec, people using *BSD, Windows, Linux, etc were able to use it. They also had things configured in such a way that if you couldn't or didn't want to use IPsec, you could use guest mode, which didn't require anything other than basic 802.11b functionality, but meant that you could do only a limited amount of stuff on the network (i.e. most outgoing ports were filtered, especially ones that would have you sending your password in the clear over a wireless link). I forget the name of that company, but could dig it up if anybody wants it. Of course, all they really did was take a Linux box and configure it just right to get this functionality, so if time is more plentiful for you than money, you could likely build the same kind of system yourself. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html msg07574/pgp0.pgp Description: PGP signature
Re: DHCP - rootkit
hi ya rick yes... got that part ... ( the after breaking in part ) was exepecting to see it helps one to breakin and exploit the vulnerabilities so it didn't sink in at first when i was reading all the talk-backs ( didnt see what i wanted to see ;-) thanx alvin On Mon, 28 Oct 2002, Rick Moen wrote: Quoting Alvin Oga ([EMAIL PROTECTED]): i read all the talkbacks... - no definition of rootkit posted in the talkbacks Look again. Anyhow, a rootkit is not anything that allows an un-educated user to just run that tool to break into other peoples network and machines. It's something the intruder uses _after_ breaking in. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
questions about chrooting bind 8.3.3
Hi, I have a question about chrooting bind 8.3.3 I have used the setup as described in http://people.debian.org/~pzn/howto/chroot-bind.sh.txt ... but when I then start bind evrything looks right but when I do a lsof -p pid of named I see: command to start bind: start-stop-daemon --start --quiet --exec /usr/sbin/named -- -u named -g named -t /var/lib/chroot/named/ # lsof -p 22119 COMMAND PID USER FD TYPE DEVICESIZENODE NAME named 22119 named cwdDIR 8,224096 145479 /var/lib/chroot/named/var/cache/bind named 22119 named rtdDIR 8,224096 145467 /var/lib/chroot/named named 22119 named txtREG8,6 512088 130880 /usr/sbin/named named 22119 named memREG8,5 82503 30185 /lib/ld-2.2.5.so named 22119 named memREG8,5 1145456 30223 /lib/libc-2.2.5.so named 22119 named memREG8,5 32664 30232 /lib/libnss_files-2.2.5.so named 22119 named0u CHR1,3 145480 /var/lib/chroot/named/dev/null named 22119 named1u CHR1,3 145480 /var/lib/chroot/named/dev/null named 22119 named2u CHR1,3 145480 /var/lib/chroot/named/dev/null named 22119 named3u unix 0xe1086560 5375674 socket named 22119 named4u IPv45375686 UDP *:32943 named 22119 named5u unix 0xd9d1ec40 5375676 /var/run/ndc named 22119 named 20u IPv45375680 UDP localhost:domain named 22119 named 21u IPv45375681 TCP localhost:domain (LISTEN) and when I change the command to start bind to : start-stop-daemon --chroot /var/lib/chroot/named/ --start --pidfile /var/run/named.pid --exec /usr/sbin/named -- -u named -g named I see: # lsof -p 23433 COMMAND PID USER FD TYPE DEVICESIZENODE NAME named 23433 named cwdDIR 8,224096 145479 /var/lib/chroot/named/var/cache/bind named 23433 named rtdDIR 8,224096 145467 /var/lib/chroot/named named 23433 named txtREG 8,22 512088 145502 /var/lib/chroot/named/usr/sbin/named named 23433 named memREG 8,22 82503 145501 /var/lib/chroot/named/lib/ld-linux.so.2 named 23433 named memREG 8,22 1145456 145500 /var/lib/chroot/named/lib/libc.so.6 named 23433 named memREG 8,22 32664 146115 /var/lib/chroot/named/lib/libnss_files.so.2 named 23433 named0u CHR1,3 145480 /var/lib/chroot/named/dev/null named 23433 named1u CHR1,3 145480 /var/lib/chroot/named/dev/null named 23433 named2u CHR1,3 145480 /var/lib/chroot/named/dev/null named 23433 named3u unix 0xef055a80 5239772 socket named 23433 named4u IPv45239784 UDP *:32942 named 23433 named5u unix 0xeee6d140 5239774 /var/run/ndc named 23433 named 20u IPv45239778 UDP localhost:domain named 23433 named 21u IPv45239779 TCP localhost:domain (LISTEN) Look at the difference in the libraries, as I can see when I start named as stated in the script the libraries in the chrooted environment are not used Am I wrong here? -- J.J. van GorkumKnowledge Zone -- If UNIX isn't the solution, you've got the wrong problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DHCP - rootkit
A rootkit is a selection of modified standard programs that usually replace (among others) ls ps netstat users and pretty much everything else you would use to check your machine. It will also include a backdoor. Sometimes the primary part of the rootkit is either a module or a complete replacement of the kernel with one that does not respond to the normal users (root) with any info about the new owner. Rootkits are *INSTALLED* after a successful root exploit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DHCP - rootkit
hi ya dale Rootkits are *INSTALLED* after a successful root exploit. maybe i missing something here ... that i been wonderng about for years.. if they exploited a root vulnerability and got in... why modify silly binaries like ps, top, ls, find, etf ?? that gives themself away as having modified the system if they quietly do what they do, like run irc chat or spam bomb just a few a day ... nobody might notice ??? ( until sleepy admin watch the logs or see whats running - erasing the logs is a dead give away you got a problem ( that something happened there's more alarms going off when things are modified on a normal box ?? if only irc ran ... it might be overlooked till the load on the box is too high ?? - changing/trojaning all the binaries will definitely give yourself away - either way... to trojan the binaries or not .. etiher way the sleepy admin wont notice... - sharp ones will catch it within a few minutes/hours... or not happen (not exploited) at all .. -- guess i would do a minimum disturbance if i got into somebodys box and wanted to use their resources as opposed to tripping over everything c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DHCP - rootkit
hi ya dale if anybody modifies the typical binaries.. i'll know within the hour.. hourly/randomly system checks or instaneously if i happen to be reading emails at the time ... they are attacking... i say modifying files is a give away .. that says come find me which is trivial since its modified binaries see below On Wed, 30 Oct 2002, Dale Amon wrote: On Tue, Oct 29, 2002 at 03:28:20PM -0800, Alvin Oga wrote: if they exploited a root vulnerability and got in... why modify silly binaries like ps, top, ls, find, etf ?? that gives themself away as having modified the system No it doesn't. It makes them and everything they do vanish into thin air as if they weren't there. They can log into you computer, create files, run a Warez and you can sit on your remote terminal blithely unaware because nothing you do will show you anything they are doing. Their files don't show in your ls Their disk space usage doesn't show in your df Their processes don't show on your ps thats dumb if you use the hacked binaries to check for them c ya alvin - most of the machines now days... even if they did get into my customers boxes.. they might not be able to run the programs ... just depends on which rootkit ( usually i get a copy of their attempts to get in ( once a year or so ..but it fails to run .. - thats when it gets fun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DHCP - rootkit
On Tue, Oct 29, 2002 at 04:12:54PM -0800, Alvin Oga wrote: i say modifying files is a give away .. that says come find me which is trivial since its modified binaries If they do it right, it's not a giveaway. If they're quick, thorough, and accurate, they can certainly do it right. On the other hand, I've seen cracked Solaris boxes on which the rootkit installed a patched version of GNU's ls in place of the default ls. That was a pretty obvious giveaway. The thing with rootkits is that they're pretty target-specific. They're not usually robust enough to be installed on a different Linux distribution or even a different version of the intended target distro. Rootkits aren't what I usually worry about; It's the determined, knowledgeable attackers that I don't like. Fortunately there aren't as many of them to worry about. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html msg07581/pgp0.pgp Description: PGP signature
Re: DHCP - rootkit
hi ya noah On Tue, 29 Oct 2002, Noah L. Meyerhans wrote: On Tue, Oct 29, 2002 at 04:12:54PM -0800, Alvin Oga wrote: i say modifying files is a give away .. that says come find me which is trivial since its modified binaries If they do it right, it's not a giveaway. If they're quick, thorough, and accurate, they can certainly do it right. On the other hand, I've if they do get in... i wanna know within a second (wishfully) that they got in ( an email is sent elsewhere of who/where they came from ) - than if i am online ... i got um in the act ... i've done rm their_code.c while they are in the machine ... makes um wonder :-) and move files around on them .. :-) am not as worried about the determined hacker/crackers that can modify binaries such that md5sum matches my tripewire db and other security precautions (databases and baseline) of my servers - if they do come visiting ... we've got a serious problem and my clients aren't banks ( literally/figuratively ) i just want to make 90-95% of the attempts fail from the script kidies and local wanna be admins that goes around changing the lan network, config files, topology, passwds etc - 80-90% of all these attempts are users trying to bypass corp security policy - or just playing .. tripping all the alrms in the process of testing/learning what they can do - and they very quickly find dhcp is disallowed :-) and they cant send email that dhcp doesnt work :-) and they cant randomly or add +1 to their current assigned ip# to get online - always leave an easy guinne pig ( decoys ) for them to play with ... c ya alvin seen cracked Solaris boxes on which the rootkit installed a patched version of GNU's ls in place of the default ls. That was a pretty obvious giveaway. The thing with rootkits is that they're pretty target-specific. They're not usually robust enough to be installed on a different Linux distribution or even a different version of the intended target distro. Rootkits aren't what I usually worry about; It's the determined, knowledgeable attackers that I don't like. Fortunately there aren't as many of them to worry about. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
NIS
HI, I'm looking for any craft to secure YP: I'm working around shadow password and yp. shadow passwords are stupid if ypcat passwd give the encripted passwords ! Well, I use (in /etc/ypserv): * : passwd.byname: port : yes * : passwd.byuid : port : yes passwd are mangled , but the ftp server, on a YP-client machine, do not recognize any user. Any solution ? Francois -- Quelle Connerie la guerre (J. Prevert) Francois Sauterey Tel: +33 01 40 33 68 46 mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Re: DHCP
On Mon, Oct 28, 2002 at 07:38:38PM -0600, Hanasaki JiJi wrote: Too bad there is no way to do a secure handshake w/ an id/password or even SecureID cards. That's the idea behind PPPoE. Yuck. -B -- Brandon High [EMAIL PROTECTED] '98 Kawi ZX-7R Wasabi, '98 Kawi EX500 Harlot, '02 BMW R1150RS Things are more like they are today than they ever have been before. pgpgEktOnIcg4.pgp Description: PGP signature
Re: NIS
On Tue, 29 Oct 2002, Francois Sauterey wrote: HI, I'm looking for any craft to secure YP: I'm working around shadow password and yp. shadow passwords are stupid if ypcat passwd give the encripted passwords ! Well, I use (in /etc/ypserv): * : passwd.byname: port : yes * : passwd.byuid : port : yes passwd are mangled , but the ftp server, on a YP-client machine, do not recognize any user. Any solution ? If You are using ProFTPd, then using : PersistentPasswdoff in your /etc/proftpd.conf would do the trick -Daniel Lysfjord-
Re: port 16001 and 111
Tom Cook écrivait : What the What's wrong with 'lsof -i :111' and 'lsof -i :16001'? Nothing wrong with it! :) It tells you precisely what's attempting to connect... Yes, except in his case there is no connection since there is no installed daemon on this port, only some connection attempts he is trying to track. So my solution is just to provide a mini-daemon allowing connecting and so tracking. Use netstat or lsof in /root/spy.sh as you want. I just use to use netstat so I gave an example with netstat, but you can use lsof instead off course! :) Cheers, J.C. pgpnu6o5ILSxH.pgp Description: PGP signature
Re: port 16001 and 111
On Monday 28 October 2002 11:59 pm, Jean Christophe ANDRÉ wrote: Tom Cook écrivait : What the What's wrong with 'lsof -i :111' and 'lsof -i :16001'? Nothing wrong with it! :) It tells you precisely what's attempting to connect... Yes, except in his case there is no connection since there is no installed daemon on this port, only some connection attempts he is trying to track. So my solution is just to provide a mini-daemon allowing connecting and so tracking. Use netstat or lsof in /root/spy.sh as you want. I just use to use netstat so I gave an example with netstat, but you can use lsof instead off course! :) Cheers, J.C. way overkill. 16001 isn't being scanned and 111 is the most common target after 25. you're suggesting that the guy turn his server into a honeypot--to what end? disable portmap and nothing can get at 111. there's a difference between simply securing a box and assuming a role as cyber-detective. the former solves the problem, the latter has no end. ben
Re: port 16001 and 111
Hi, ben écrivait : way overkill. 16001 isn't being scanned and 111 is the most common target after 25. you're suggesting that the guy turn his server into a honeypot--to what end? disable portmap and nothing can get at 111. there's a difference between simply securing a box and assuming a role as cyber-detective. the former solves the problem, the latter has no end. Please read the full thread before posting (or even only the first post). He actually *is* asking for tracking the *internal* process trying to connect *localy* to its port 111. He knows about such attempts because he had filtered them. But he can't guess which process attempt to connect to it. And he just *want* to know. Tracking connection attempts *is* part of security, since it allow you to know how things work, and better tune it once you understand it. Regards, J.C.
Re: port 16001 and 111
On Tuesday 29 October 2002 01:02 am, Jean Christophe ANDRÉ wrote: Hi, ben écrivait : way overkill. 16001 isn't being scanned and 111 is the most common target after 25. you're suggesting that the guy turn his server into a honeypot--to what end? disable portmap and nothing can get at 111. there's a difference between simply securing a box and assuming a role as cyber-detective. the former solves the problem, the latter has no end. Please read the full thread before posting (or even only the first post). He actually *is* asking for tracking the *internal* process trying to connect *localy* to its port 111. He knows about such attempts because he had filtered them. But he can't guess which process attempt to connect to it. And he just *want* to know. Tracking connection attempts *is* part of security, since it allow you to know how things work, and better tune it once you understand it. you're missing the point. running a portmap daemon is the only vulnerability that the 111 port scans are attempting to exploit. that attempted exploit is part of the weather of being hooked up, in the same way that 25 is attempted to be used as a mail relay. there are--to the best of my knowledge--no internal apps or daemons that will cause the fashion of log alarm that the op is concerned to address. you're assuming that internal apps attempt external connections. for that to be a possibility, you'd have to have a mighty weird local setup. if you, or anybody, can give me a real example to justify your hypothesis, please do. ben
Re: port 16001 and 111
On 0, Jean Christophe ANDR? [EMAIL PROTECTED] wrote: Tom Cook ?crivait : What the What's wrong with 'lsof -i :111' and 'lsof -i :16001'? Nothing wrong with it! :) It tells you precisely what's attempting to connect... Yes, except in his case there is no connection since there is no installed daemon on this port, only some connection attempts he is trying to track. Ah I understand now... Tom -- Tom Cook Information Technology Services, The University of Adelaide Not to limit itself to play in a sand vat. - Google translation of, not to be stuck in a sandbox. Get my GPG public key: https://pinky.its.adelaide.edu.au/~tkcook/tom.cook-at-adelaide.edu.au pgpqIasj8hCS7.pgp Description: PGP signature
Re: DHCP
On Mon, 28 Oct 2002 at 11:18:23PM -0800, Brandon High wrote: On Mon, Oct 28, 2002 at 07:38:38PM -0600, Hanasaki JiJi wrote: Too bad there is no way to do a secure handshake w/ an id/password or even SecureID cards. That's the idea behind PPPoE. Yuck. Or you could do ipsec: Laptop (IPSEC CLient) - WAP - Server (DHCP AND IPSEC Host) - Local Network. In order to get inside the network you will have to get past the IPSEC Host, which of course will require a key that has a valid certificate from the local CA. Just a thought... -- Excuse #218: The co-locator cannot verify the frame-relay gateway to the ISDN server. Phil PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.txt | gpg --import XP Source Code: #include win2k.h #include extra_pretty_things_with_bugs.h #include more_bugs.h #include require_system_activation.h #include phone_home_every_so_often.h #include remote_admin_abilities_for_MS.h #include more_restrictive_EULA.h #include sell_your_soul_to_MS_EULA.h //os_ver=Windows 2000 os_ver=Windows XP pgpVX5yXo4lgm.pgp Description: PGP signature
RE: DHCP
We are currently looking into wireless where I work also. Just a few weeks ago, we had this company come in to give a demo of an appliance that enforces restrictions on the wireless network. http://www.verniernetworks.com/ It seems to be along the path of what we are looking for, YMMV. Oh, and we don't have any active relationship with this firm, they are just the first to demo anything here :)
Re: DHCP
On Tue, Oct 29, 2002 at 09:35:01AM -0500, Phillip Hofmeister wrote: Laptop (IPSEC CLient) - WAP - Server (DHCP AND IPSEC Host) - Local Network. In order to get inside the network you will have to get past the IPSEC Host, which of course will require a key that has a valid certificate from the local CA. IPsec has the added advantage that it can be used to protect all wireless traffic from eavesdroppers. At the USENIX Annual Technical Conference in Monterey, CA this past June, the company providing wireless network connectivity used such a system. Since it was IPsec, people using *BSD, Windows, Linux, etc were able to use it. They also had things configured in such a way that if you couldn't or didn't want to use IPsec, you could use guest mode, which didn't require anything other than basic 802.11b functionality, but meant that you could do only a limited amount of stuff on the network (i.e. most outgoing ports were filtered, especially ones that would have you sending your password in the clear over a wireless link). I forget the name of that company, but could dig it up if anybody wants it. Of course, all they really did was take a Linux box and configure it just right to get this functionality, so if time is more plentiful for you than money, you could likely build the same kind of system yourself. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpQZrZelUnL3.pgp Description: PGP signature
Re: DHCP - rootkit
hi ya rick yes... got that part ... ( the after breaking in part ) was exepecting to see it helps one to breakin and exploit the vulnerabilities so it didn't sink in at first when i was reading all the talk-backs ( didnt see what i wanted to see ;-) thanx alvin On Mon, 28 Oct 2002, Rick Moen wrote: Quoting Alvin Oga ([EMAIL PROTECTED]): i read all the talkbacks... - no definition of rootkit posted in the talkbacks Look again. Anyhow, a rootkit is not anything that allows an un-educated user to just run that tool to break into other peoples network and machines. It's something the intruder uses _after_ breaking in.
Re: DHCP - rootkit
A rootkit is a selection of modified standard programs that usually replace (among others) ls ps netstat users and pretty much everything else you would use to check your machine. It will also include a backdoor. Sometimes the primary part of the rootkit is either a module or a complete replacement of the kernel with one that does not respond to the normal users (root) with any info about the new owner. Rootkits are *INSTALLED* after a successful root exploit.
Re: DHCP - rootkit
hi ya dale Rootkits are *INSTALLED* after a successful root exploit. maybe i missing something here ... that i been wonderng about for years.. if they exploited a root vulnerability and got in... why modify silly binaries like ps, top, ls, find, etf ?? that gives themself away as having modified the system if they quietly do what they do, like run irc chat or spam bomb just a few a day ... nobody might notice ??? ( until sleepy admin watch the logs or see whats running - erasing the logs is a dead give away you got a problem ( that something happened there's more alarms going off when things are modified on a normal box ?? if only irc ran ... it might be overlooked till the load on the box is too high ?? - changing/trojaning all the binaries will definitely give yourself away - either way... to trojan the binaries or not .. etiher way the sleepy admin wont notice... - sharp ones will catch it within a few minutes/hours... or not happen (not exploited) at all .. -- guess i would do a minimum disturbance if i got into somebodys box and wanted to use their resources as opposed to tripping over everything c ya alvin
Re: DHCP - rootkit
On Tue, Oct 29, 2002 at 03:28:20PM -0800, Alvin Oga wrote: if they exploited a root vulnerability and got in... why modify silly binaries like ps, top, ls, find, etf ?? that gives themself away as having modified the system No it doesn't. It makes them and everything they do vanish into thin air as if they weren't there. They can log into you computer, create files, run a Warez and you can sit on your remote terminal blithely unaware because nothing you do will show you anything they are doing. Their files don't show in your ls Their disk space usage doesn't show in your df Their processes don't show on your ps The attack script, if it is a good one, will not only crack root, it will install the root kit and clean up signs of the entry. They're actions are only visible for a matter of minutes or more likely seconds. A successful attack can be detected by a good admin, often by anomalous traffic on the LAN, or by comparison with tripwire files (with the comparison done off line by booting from a CD to run the checks against a tripwire db that was also off line). It is also the case that a lot of exploit scripts are much less than perfect and will leave some evidence. I have a few other forensic tricks for checking but I won't share them with strangers :-) -- -- Nuke bin Laden: Dale Amon, CEO/MD improve the global Islandone Society gene pool. www.islandone.org --
Re: DHCP - rootkit
hi ya dale if anybody modifies the typical binaries.. i'll know within the hour.. hourly/randomly system checks or instaneously if i happen to be reading emails at the time ... they are attacking... i say modifying files is a give away .. that says come find me which is trivial since its modified binaries see below On Wed, 30 Oct 2002, Dale Amon wrote: On Tue, Oct 29, 2002 at 03:28:20PM -0800, Alvin Oga wrote: if they exploited a root vulnerability and got in... why modify silly binaries like ps, top, ls, find, etf ?? that gives themself away as having modified the system No it doesn't. It makes them and everything they do vanish into thin air as if they weren't there. They can log into you computer, create files, run a Warez and you can sit on your remote terminal blithely unaware because nothing you do will show you anything they are doing. Their files don't show in your ls Their disk space usage doesn't show in your df Their processes don't show on your ps thats dumb if you use the hacked binaries to check for them c ya alvin - most of the machines now days... even if they did get into my customers boxes.. they might not be able to run the programs ... just depends on which rootkit ( usually i get a copy of their attempts to get in ( once a year or so ..but it fails to run .. - thats when it gets fun
Re: DHCP - rootkit
On Tue, Oct 29, 2002 at 04:12:54PM -0800, Alvin Oga wrote: i say modifying files is a give away .. that says come find me which is trivial since its modified binaries If they do it right, it's not a giveaway. If they're quick, thorough, and accurate, they can certainly do it right. On the other hand, I've seen cracked Solaris boxes on which the rootkit installed a patched version of GNU's ls in place of the default ls. That was a pretty obvious giveaway. The thing with rootkits is that they're pretty target-specific. They're not usually robust enough to be installed on a different Linux distribution or even a different version of the intended target distro. Rootkits aren't what I usually worry about; It's the determined, knowledgeable attackers that I don't like. Fortunately there aren't as many of them to worry about. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpY6PFenwrHX.pgp Description: PGP signature
Re: DHCP - rootkit
hi ya noah On Tue, 29 Oct 2002, Noah L. Meyerhans wrote: On Tue, Oct 29, 2002 at 04:12:54PM -0800, Alvin Oga wrote: i say modifying files is a give away .. that says come find me which is trivial since its modified binaries If they do it right, it's not a giveaway. If they're quick, thorough, and accurate, they can certainly do it right. On the other hand, I've if they do get in... i wanna know within a second (wishfully) that they got in ( an email is sent elsewhere of who/where they came from ) - than if i am online ... i got um in the act ... i've done rm their_code.c while they are in the machine ... makes um wonder :-) and move files around on them .. :-) am not as worried about the determined hacker/crackers that can modify binaries such that md5sum matches my tripewire db and other security precautions (databases and baseline) of my servers - if they do come visiting ... we've got a serious problem and my clients aren't banks ( literally/figuratively ) i just want to make 90-95% of the attempts fail from the script kidies and local wanna be admins that goes around changing the lan network, config files, topology, passwds etc - 80-90% of all these attempts are users trying to bypass corp security policy - or just playing .. tripping all the alrms in the process of testing/learning what they can do - and they very quickly find dhcp is disallowed :-) and they cant send email that dhcp doesnt work :-) and they cant randomly or add +1 to their current assigned ip# to get online - always leave an easy guinne pig ( decoys ) for them to play with ... c ya alvin seen cracked Solaris boxes on which the rootkit installed a patched version of GNU's ls in place of the default ls. That was a pretty obvious giveaway. The thing with rootkits is that they're pretty target-specific. They're not usually robust enough to be installed on a different Linux distribution or even a different version of the intended target distro. Rootkits aren't what I usually worry about; It's the determined, knowledgeable attackers that I don't like. Fortunately there aren't as many of them to worry about.
