Re: Hacker Script Attempt
Gene, On Fri, 5 Oct 2001, Gene Grimm wrote: What is the best way to protect specific daemons (inet and standalone like proftpd and apache) from intrusion attempts? I am not that As for intrusion attempts be sure to keep your servers running the latest, bug-free versions. Subscribe to the appropriate bug/software update announcements mailing lists. With Apache, make sure you don't have vulnerable CGIs available. Also make sure inetd doesn't listen to an services you don't need. And be sure to stop other services you don't need. Is your web server running unnecessary software? http://apachetoday.com/news_story.php3?ltsn=2001-02-20-003-06-PS-LF-AD have hosts.deny with lines to block outside attacks to telnet, etc. but they don't seem to work. The lines read: doesn't seem to work for the specific daemons like telnet. My tests were using our own servers from one in ip.block.2. to one that does not have the last two blocks included in the telnet line. Use tcpdchk(8) and tcpdmatch(8) to check and test your TCP Wrapper rules. Some examples: $ tcpdchk warning: /etc/inetd.conf, line 65: incomplete line warning: /etc/hosts.allow, line 1: host address 192.168.1.1-name lookup failed warning: /etc/hosts.allow, line 1: host address 192.168.1.2-name lookup failed warning: /etc/hosts.deny, line 2: 110: no such process name in /etc/inetd.conf $ tcpdmatch ftpd 64.54.87.1 warning: /etc/inetd.conf, line 65: incomplete line client: address 64.54.87.1 server: process ftpd matched: /etc/hosts.deny line 1 access: denied $ tcpdmatch ftpd 192.168.0.5 warning: /etc/inetd.conf, line 65: incomplete line client: address 192.168.0.5 server: process ftpd matched: /etc/hosts.allow line 1 access: granted Jeremy C. Reed ... ISP-FAQ.com -- find answers to your questions http://www.isp-faq.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hacker Script Attempt
The following message was received by our admin account after finding an intrusion (followed by rotating shell account passwords). Can anyone tell me how to find out what devices are referenced in this message? - Original Message - User 501 tried to run dev 773 ino 278048 in place of dev 774 ino 310316! (Filename of set-id script was ./none , uid 501 gid 501.) Sincerely, perl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hacker Script Attempt
On Tue, Oct 16, 2001 at 10:17:17AM -0400, Gene Grimm wrote: The following message was received by our admin account after finding an intrusion (followed by rotating shell account passwords). Can anyone tell me how to find out what devices are referenced in this message? You could try ls -i /dev and look for those inode numbers, but I'm not sure what that will tell you. - Original Message - User 501 tried to run dev 773 ino 278048 in place of dev 774 ino 310316! (Filename of set-id script was ./none , uid 501 gid 501.) Sincerely, perl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Michael Wood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hacker Script Attempt
Gene Grimm wrote: The following message was received by our admin account after finding an intrusion (followed by rotating shell account passwords). Can anyone tell me how to find out what devices are referenced in this message? - Original Message - User 501 tried to run dev 773 ino 278048 in place of dev 774 ino 310316! (Filename of set-id script was ./none These aren't devices. To uniquely identify a file in unix you need provide only the device it is on and the inode of the device that the file occupies, and that's what the numbers are. Comes right out of stat(2). This is suidperl detecting an attempt to exploit a common unix race condition dealing with executing suid scripts. Or they might have really been trying to exploit an old security hole in suidperl's checks for that race condition. perlsec(1) under Security Bugs for details. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hacker Script Attempt
Thankx. I did manage to find out which file they were trying to reference. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hacker Script Attempt
What is the best way to protect specific daemons (inet and standalone like proftpd and apache) from intrusion attempts? I am not that familiar with Linux firewalling rules yet and am in the process of obtaining a comprehensive administrator's study guide. I presently have hosts.deny with lines to block outside attacks to telnet, etc. but they don't seem to work. The lines read: ALL: PARANOID ALL: .dial.domain1.com ALL: .dialup.domain2.net sshd: ALL EXCEPT 127. ip.block.1. ip.block.2. ip.block.3. in.fingerd: ALL EXCEPT 127. ip.block.1. ip.block.2. ip.block.3. in.telnetd: ALL EXCEPT 127. ip.block.1. ip.block.2. ip.block.3. portmap: ALL EXCEPT 127. ip.block.1. ip.block.2. ip.block.3. Two of the hosts omitted ip.block.2. and ip.block.3. in the hosts.deny file. This configuration successfully repels attempts from the specified domains, but it doesn't seem to work for the specific daemons like telnet. My tests were using our own servers from one in ip.block.2. to one that does not have the last two blocks included in the telnet line. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
