Re: wierd connection attempt
Josh Frick wrote: Yes, I most definitely was confused. Thank you for the clarification. I'm not familiar with the RFCs. My question, however, remains: aren't network addresses in that range supposed to be prevented from crossing (i.e. being routed) the internet? If they are, then it's possible this traffic is local, is it not? I believe my DSL ISP assigns a private class IP address before connection. Would this then indicate that the connection attempt was made by another customer of the person's ISP? Exactly. Perhaps this person's ISP is not the filtering the bogus messages from reaching it's other customers, or perhaps the messages are passing through outside routers that are not complying with the RFC, and allowing them to travel so far. It's most likely that it is coming from another subscriber to the ISP's network. -Will Wesley, CCNA A prediction is worth twenty explanations. -- K. Brecher
Re: wierd connection attempt
Josh Frick wrote: Yes, I most definitely was confused. Thank you for the clarification. I'm not familiar with the RFCs. My question, however, remains: aren't network addresses in that range supposed to be prevented from crossing (i.e. being routed) the internet? If they are, then it's possible this traffic is local, is it not? I believe my DSL ISP assigns a private class IP address before connection. Would this then indicate that the connection attempt was made by another customer of the person's ISP? Exactly. Perhaps this person's ISP is not the filtering the bogus messages from reaching it's other customers, or perhaps the messages are passing through outside routers that are not complying with the RFC, and allowing them to travel so far. It's most likely that it is coming from another subscriber to the ISP's network. -Will Wesley, CCNA A prediction is worth twenty explanations. -- K. Brecher -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: syslog messages
Marcel Welschbillig wrote: Hi, Im getting these strange entries in my syslog file. Can anyone shed some light on what this means ? Feb 21 14:03:35 jbeam Feb 21 14:03:35 jbeam syslogd: Cannot glue message parts together Feb 21 14:03:35 jbeam /sbin/rpc.statd[198]: gethostbyname error for ^XF7FF BF^XF7FFBF^YF7FFBF^YF7FFBF^ZF7FFBF^ZF7FFBF^[F7 FFBF^[F7FFBF%8x%8x%8x%8x%8x%8x%8x%8x%8x%236x%n%137x%n%10x%n%192x%n\220 blah blah blah Thanks in advance ! Marcel Something along the lines of an old statd exploit. I believe this DSA[1] is the one that covers it, and also this CERT Advisory [2]. I would personally believe that the attack was unsuccessful, since it did write it to the log (rather than crash and give the attacker a shell), but the CERT advisory leads me to think otherwise. Check your version of nfs, 0.1.9.1-1 or better should be fixed. [1] http://www.debian.org/security/2000/2719a [2] http://www.cert.org/advisories/CA-2000-17.html Hope I have helped. - Will Wesley, CCNA Furious activity is no substitute for understanding. -- H.H. Williams -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: syslog messages
Marcel Welschbillig wrote: Hi, Im getting these strange entries in my syslog file. Can anyone shed some light on what this means ? Feb 21 14:03:35 jbeam Feb 21 14:03:35 jbeam syslogd: Cannot glue message parts together Feb 21 14:03:35 jbeam /sbin/rpc.statd[198]: gethostbyname error for ^XF7FF BF^XF7FFBF^YF7FFBF^YF7FFBF^ZF7FFBF^ZF7FFBF^[F7 FFBF^[F7FFBF%8x%8x%8x%8x%8x%8x%8x%8x%8x%236x%n%137x%n%10x%n%192x%n\220 blah blah blah Thanks in advance ! Marcel Something along the lines of an old statd exploit. I believe this DSA[1] is the one that covers it, and also this CERT Advisory [2]. I would personally believe that the attack was unsuccessful, since it did write it to the log (rather than crash and give the attacker a shell), but the CERT advisory leads me to think otherwise. Check your version of nfs, 0.1.9.1-1 or better should be fixed. [1] http://www.debian.org/security/2000/2719a [2] http://www.cert.org/advisories/CA-2000-17.html Hope I have helped. - Will Wesley, CCNA Furious activity is no substitute for understanding. -- H.H. Williams
Re: Debian security being trashed in Linux Today comments
Peter Cordes wrote: Agreed, weighted mean (by severity of vulnerability and popularity of package) would be better, if suitable weighting could be devised. Separate graphs would be more useful to more people. (not everybody's weighting would be the same as the weighting that would take a year of debate to not be settled anyway...) One graph for remote exploits, one for local priviledge escalation, one for remote holes in Important (according to pkg system), etc. Make a graph for anything someone might be interested in. Or even generate them on the fly with input from a set of checkboxes for which package to include; if someone wanted to write the code, it wouldn't be hard. (assuming there's a good way to see which package falls into which category... Hmm, that's probably not so easy with the data that is kept now.) Anyway, the most useful thing would be multiple graphs according to a few interesting criteria. Any kind of policy we create should easily applied to other distro's in order to combat FUD like the comments that started this thread. I agree in seperatring graphs and stats into different categories such as remote and local vulnerabilities, and Required (as in packages that are on virtually all systems, ie glibc, at and friends, etc.) But, we wouldn't be distinguishing on a package basis, IMHO, since one package could be vulnerable to a remote exploit, and also have a privledge escalation vuln. As for weighting the severity of exploits, this would definately be something that would need to be tailored to the individual whom seeks such information. Maybe a selection of different package types (ie Mail servers, web servers, ftp servers, user utils, admin utils, network utils, development tools, base, etc..), then include in the report whether specific packages are still vuln to known exploits, or details on how fast specific packages where fixed after a vuln was announced. The details would help advise as to which packages appear to be more secure in a specific use, while statistics would show how well the distro responds to fixes for a specific genre of packages, which would in turn help an admin decide what distro would be best for the kind of server he/she is creating. Maybe a package specific report would be easier, and more accurate. Anyone wanna flame me, add to my thoughts, or compliment me? I guess as a side note, I shouldn't say we since I doubt I am really eligible to be a major contributer to such a project... Just my two cents, anyhow. -Will Wesley Great way to learn about mknod... box:~# rm -rf /dev box:~# man mknod _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian security being trashed in Linux Today comments
Peter Cordes wrote: Agreed, weighted mean (by severity of vulnerability and popularity of package) would be better, if suitable weighting could be devised. Separate graphs would be more useful to more people. (not everybody's weighting would be the same as the weighting that would take a year of debate to not be settled anyway...) One graph for remote exploits, one for local priviledge escalation, one for remote holes in Important (according to pkg system), etc. Make a graph for anything someone might be interested in. Or even generate them on the fly with input from a set of checkboxes for which package to include; if someone wanted to write the code, it wouldn't be hard. (assuming there's a good way to see which package falls into which category... Hmm, that's probably not so easy with the data that is kept now.) Anyway, the most useful thing would be multiple graphs according to a few interesting criteria. Any kind of policy we create should easily applied to other distro's in order to combat FUD like the comments that started this thread. I agree in seperatring graphs and stats into different categories such as remote and local vulnerabilities, and Required (as in packages that are on virtually all systems, ie glibc, at and friends, etc.) But, we wouldn't be distinguishing on a package basis, IMHO, since one package could be vulnerable to a remote exploit, and also have a privledge escalation vuln. As for weighting the severity of exploits, this would definately be something that would need to be tailored to the individual whom seeks such information. Maybe a selection of different package types (ie Mail servers, web servers, ftp servers, user utils, admin utils, network utils, development tools, base, etc..), then include in the report whether specific packages are still vuln to known exploits, or details on how fast specific packages where fixed after a vuln was announced. The details would help advise as to which packages appear to be more secure in a specific use, while statistics would show how well the distro responds to fixes for a specific genre of packages, which would in turn help an admin decide what distro would be best for the kind of server he/she is creating. Maybe a package specific report would be easier, and more accurate. Anyone wanna flame me, add to my thoughts, or compliment me? I guess as a side note, I shouldn't say we since I doubt I am really eligible to be a major contributer to such a project... Just my two cents, anyhow. -Will Wesley Great way to learn about mknod... box:~# rm -rf /dev box:~# man mknod _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: I've been hacked by DevilSoul
Alan Aldrich wrote: Snip Of course I took it off the net and had to rebuild the whole system, and now I am not allowing ssh, rsh, telnet or ANY logins. It is not a machine that needs logins anyway, all it does is VPN proxy and authentication on certain ports. Snip The way it should be. No unnesescary services. Alan Aldrich also wrote: I wish I did know how the hacker got in, but I am pretty sure they won't be able to now. Someone mentioned tripwire. Is that a good monitor for hacker activity? alan tripwire monitors for changes. in example, say a cracker adds his own super user account to /etc/passwd, tripwire can notify you that there was a change to that file. this is good for recovering by the maybe it'll be safe once i remove all the changes method and/or identifying a break in. however if you have been following this thread, you will have noticed the discussions about subverting apps like tripwire, so it is certainly not fool-proof. and then even if the tactics involving the kernel are not used, there is still the possibilty of the tripwire system to be compromised also. Then, shortly thereafter, Alan Aldrich wrote: oh yeah.. by the way, that chkrootkit that someone mentioned pointed me right to the problems. that is a great tool. thanks alan I am curious as to how great of a tool it is. I haven't bothered looking yet, but I assume that it runs along the same lines as AV software for the lesser OS. Please correct me if I am wrong about this, but I see the update for each new virus approach to be horrible, and I would think that would be the same tactic used against root kits. Anybody have comments on this? -Will Wesley, CCNA For God's sake, stop researching for a while and begin to think! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I've been hacked by DevilSoul
Alan Aldrich wrote: Snip Of course I took it off the net and had to rebuild the whole system, and now I am not allowing ssh, rsh, telnet or ANY logins. It is not a machine that needs logins anyway, all it does is VPN proxy and authentication on certain ports. Snip The way it should be. No unnesescary services. Alan Aldrich also wrote: I wish I did know how the hacker got in, but I am pretty sure they won't be able to now. Someone mentioned tripwire. Is that a good monitor for hacker activity? alan tripwire monitors for changes. in example, say a cracker adds his own super user account to /etc/passwd, tripwire can notify you that there was a change to that file. this is good for recovering by the maybe it'll be safe once i remove all the changes method and/or identifying a break in. however if you have been following this thread, you will have noticed the discussions about subverting apps like tripwire, so it is certainly not fool-proof. and then even if the tactics involving the kernel are not used, there is still the possibilty of the tripwire system to be compromised also. Then, shortly thereafter, Alan Aldrich wrote: oh yeah.. by the way, that chkrootkit that someone mentioned pointed me right to the problems. that is a great tool. thanks alan I am curious as to how great of a tool it is. I haven't bothered looking yet, but I assume that it runs along the same lines as AV software for the lesser OS. Please correct me if I am wrong about this, but I see the update for each new virus approach to be horrible, and I would think that would be the same tactic used against root kits. Anybody have comments on this? -Will Wesley, CCNA For God's sake, stop researching for a while and begin to think! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
