KCLUG

kclug@kclug.org

5 participants
3240 discussions

spamassassin question
by Brian Densmore 25 Oct '04

25 Oct '04

Ok today, I tried something to get spamassassin working on my box. The mail arrived in the regular mailbox, but I got this message back from the server: ************************************ This message was created automatically by mail delivery software (Exim). A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: pipe to |/usr/bin/procmail generated by brian(a)amason.net The following text was generated during the delivery attempt: ------ pipe to |/usr/bin/procmail generated by brian(a)amason.net ------ Could not lock /home/brian/Maildir/: File exists at /usr/share/perl5/Mail/SpamAssassin/NoMailAudit.pm line 381. procmail: Program failure (70) of "/usr/bin/spamassassin" procmail: Rescue of unfiltered data succeeded *********************************** So what have I done wrong here? Does the "rescue" message mean it sent it without filtering, and that is why I got the mail? my .forward looks like this for the time being: |/usr/bin/procmail /home/brian/Maildir I may have to do some tweaking in my ~/.procmailrc file, but it looks like procmail is functioning, but I need to tweak spamassassin. "The President is merely the most important among a large number of public servants. He should be supported or opposed exactly to the degree which is warranted by his good conduct or bad conduct, his efficiency or inefficiency in rendering loyal, able, and disinterested service to the Nation as a whole. Therefore it is absolutely necessary that there should be full liberty to tell the truth about his acts, and this means that it is exactly necessary to blame him when he does wrong as to praise him when he does right. Any other attitude in an American citizen is both base and servile. To announce that there must be no criticism of the President, or that we are to stand by the President, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. Nothing but the truth should be spoken about him or any one else. But it is even more important to tell the truth, pleasant or unpleasant, about him than about any one else." --Theodore Roosevelt, Kansas City Star, May 7, 1918

2 1

OT: Sun Micro tech needed -From Monster.com
by Oren Beck 24 Oct '04

24 Oct '04

OT : Job for Sun Micro tech . <http://jobsearch.monster.com/getjob.asp?JobID=24838138> Oren www.campdownunder.com

1 0

RE: It was bound to happen - suspected hack
by aaron hirsch 22 Oct '04

22 Oct '04

I'd modify the hosts.allow file a bit more... i.e. sshd: localhost 192.168.0.0/255.255.255.0 12.30.163.* ALL:ALL:DENY This is a "catch-all" that is a best practice just incase the hosts.deny is misconfigured or not configured at all, although the ALL:ALL in your hosts.deny is correct. It will deny access to all services that tcpd monitors to everything as a last resort. Hence, if it's not explicitly defined to be allowed, it is by default denied. Just an idea... -----Original Message----- From: Jon Moss [mailto:jon.moss@cnonline.net] Sent: Thursday, October 21, 2004 7:03 AM To: kclug(a)kclug.org Subject: Re: It was bound to happen - suspected hack I've been researching sshd and allowing/denying access and I think I have figured it out. Just please confirm that I'm on the right track. I edited my hosts.allow as follows: # # hosts.allow This file describes the names of the hosts which are # allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # sshd: localhost 192.168.0.0/255.255.255.0 12.30.163.* And then my hosts.deny as follows: # # hosts.deny This file describes the names of the hosts which are # *not* allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # # The portmap line is redundant, but it is left to remind you that # the new secure portmap uses hosts.deny and hosts.allow. In particular # you should know that NFS uses portmap! ALL : ALL However, I don't really have anyway to test this as I allowed access from everywhere that I am. :) Any suggestions and advice is still greatly appreciated. -- Thanks very much, Jon Moss jon.moss(a)cnonline.net _______________________________________________ Kclug mailing list Kclug(a)kclug.org http://kclug.org/mailman/listinfo/kclug

4 4

Who's going to man the booth at ITEC?
by Chris Bier 22 Oct '04

22 Oct '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, ~ So, who's going to man the booth at ITEC? I'm going to try and be there for one of the days. Chris - -- I digitally sign my emails. If you see an attachment with .asc, then that means your email client doesn't support PGP digital signatures. http://www.gnupg.org/(en)/documentation/faqs.html#q1.1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBdzbdE5xXU3JS1mQRAhOaAJ0QWwYBzjoOwlrTKMWm6ySqGfzdqQCghVPa /FS5JWSA7PY638AW+qZM8oY= =PyUv -----END PGP SIGNATURE-----

3 2

RE: Who's going to man the booth at ITEC?
by djgoku 21 Oct '04

21 Oct '04

I can on Thursday 8-2, what do we need to bring or get. JO On Wed, 20 Oct 2004 23:12:33 -0500, Chris Bier <chris.bier(a)cymor.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi All, > ~ So, who's going to man the booth at ITEC? I'm going to try and be > there for one of the days. > > Chris > - -- > I digitally sign my emails. If you see an attachment with .asc, then > that means your email client doesn't support PGP digital signatures. > http://www.gnupg.org/(en)/documentation/faqs.html#q1.1 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFBdzbdE5xXU3JS1mQRAhOaAJ0QWwYBzjoOwlrTKMWm6ySqGfzdqQCghVPa > /FS5JWSA7PY638AW+qZM8oY= > =PyUv > -----END PGP SIGNATURE----- > _______________________________________________ > Kclug mailing list > Kclug(a)kclug.org > http://kclug.org/mailman/listinfo/kclug > -- dj_goku -www.djgoku.com- -www.tektronic.org- -- dj_goku -www.djgoku.com- -www.tektronic.org-

3 2

RE: It was bound to happen - suspected hack
by Jon Moss 21 Oct '04

21 Oct '04

That's what I found in the config file comments. I'm implementing it now. Thanks again - Jon > > You can (and should) accomplish this in /etc/ssh/sshd_config via: > PermitRootLogin no > > Dustin > -- Thanks very much, Jon Moss jon.moss(a)cnonline.net

2 1

RE: It was bound to happen - suspected hack
by Brian Kelsay 21 Oct '04

21 Oct '04

That all sounds cool. I wasn't 100% sure there was a way to do that. Brian Kelsay >>> "Dustin Decker" <> 10/21/04 12:27PM >>> > -----Original Message----- > From: On Behalf Of Brian Kelsay > > You said you can "playback" the intrusion. What exactly do you mean by > that? Do you setup a test network and resend the packets and data, or are > you just viewing the packets from the log? I'm wondering about the > ability to do a full-scale recreation, say for a demo in a court or at a > customer site or something. In reality, if I "possess" the packets, I can do whatever I want with them. Generally, I use the term "replay" loosely, implying that I pass the binary file to Snort, and it does analysis on it and produces whatever the output I'm after is. There are of course other fun things one can do with these files. Tcpreplay is a program I use frequently, in testing environments. It allows me to replay files back onto the wire, or as I'm fond of, loop back. What's great about tcpreplay is the ability to take known traffic (good or bad) and toss it at my IDS to test my signatures. I can flood the sh*t outta my sensor and determine if it will suffer packet loss, etc. as well. So the answer is yes across the board. In court, you generally want the lawyers to lead you - give 'em what they're looking for and nothing more. If they want a dog and pony show, I would suggest Ethereal if in depth analysis, bit by bit, is required. If the prosecution is merely looking to get things to the jury plainly (packet analysis will fsck 'em up), you can do a replay while Etherape displays a pseudo-real-time gui which clearly indicates what you want. The waters get murky here. Placing information in context is extremely important. If I have 396,984 packets in a file, it would behoove me to replay only those packets relevant to the issue at hand. Otherwise, folks wonder, "Hey, what's all that other traffic I see buzzing past?" This is venue specific as far as I know - some judges will allow this, but others consider pulling the packets out of the stream alone is tantamount to evidence tampering, etc. A great reference for this, if I had time to dig through it for you, would be the "Cybersecurity Operations Handbook" by John W. Rittinghouse and William M. Hancock. (Elsevier Digital Press - ISBN: 1-55558-306-7) This one is more like $125.00-$150.00 IIRC. As I consider how I would like to perhaps do a demo of this at a meeting some time (did something similar for ILUG couple of years ago with snort+mysql+acid), now I wonder if it wouldn't be a great thing to show off at ITEC? If so, I'd need some help. (Think "tons of {SCAREY} exploits you can throw at sensors I have in place" while I provide output via Etherape [just network traffic as it passes on the wire ala "Wow, look what Hacker Joe is doing, red and blue and green images!"] on one monitor, and snort analysis information ["See, Hacker Joe is busy, but we SEE him and are onto his ilk."] on another monitor.) I have a pair of P4 beige boxes and my trusty Dell laptop which can support this. Thoughts, heckles, hysterical laughter anyone? Dustin

1 0

RE: It was bound to happen - suspected hack
by Brian Kelsay 21 Oct '04

21 Oct '04

You said you can "playback" the intrusion. What exactly do you mean by that? Do you setup a test network and resend the packets and data, or are you just viewing the packets from the log? I'm wondering about the ability to do a full-scale recreation, say for a demo in a court or at a customer site or something. Brian Kelsay

2 1

Re: It was bound to happen - suspected hack
by Brian Kelsay 21 Oct '04

21 Oct '04

Block the IPs of the attackers specifically in your iptables rules. Make sure the users that they attempted to log on w/ are disabled, password changed or non-real users. Change root password. It looks like you are already working to allow only your IP to ssh, that's good. Check the other boxes and see if they have been compromised. You should also contact the ISP they are coming from and inform them of the break-in if they did in fact get in to your server. This is where a separate logging firewall w/ snort would help you. You could see how many and what kind of attack attempts were made before they got in. Brian Kelsay

4 5

Re: It was bound to happen - suspected hack
by Brian Kelsay 21 Oct '04

21 Oct '04

On some systems you limit the users that can "su" in the sudoers file, correct? On Debian and Gentoo, I think, the user must be in the "wheel" group to be able to "su root". Brian Kelsay >>> "Jon Moss" <> 10/21/04 10:55AM >>> I thought I could configure ssh to prevent root access (I never login root remotely anyway). I will also limit su to a single user.

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

KCLUG