Bug#409815: Every upgrade requires editing the configuration file
Hello Franck Franck Joncourt schrieb: For any new upstream release, the psad.conf file is added to /etc/psad/ and then overwrite the current setup. __apt-get upgrade__ prompts the user to know what to do. I do not think that would be a good idea to ask questions during the upgrade process if this is not needed. But if you have this values in debconf you should be asked again (as far as I remember), just new ones get asked. Or am I wrong? -- Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277457: There is no man page for fwcheck_psad
Franck Joncourt schrieb: This man page will be available in the next upstream release (2.1.5). Great, thanks. -- Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497574: Purging psad does not stop the current psad process.
Hello Franck Franck Joncourt schrieb: Use of the -v option with the start-stop-daemon command, give us a clue. Great, thanks, I always looked at dpkg with verbose... The mistake is in the pre-removal script psad.prerm that removes the pid files from /var/run/psad/ before the daemon is stopped. That should be done in the post-removal script. I noticed another thing: The pid files are never removed by the initscript. Then, even if psad is not running we can find them in /var/run/psad. Would you like me to open a new post to explain this more thoroughly ? No, thanks, I will test this tomorrow. -- Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497574: Purging psad does not stop the current psad process.
Hello Franck Franck Joncourt schrieb: then if I remove it, the current psad process it still running: [code] [EMAIL PROTECTED]:/home/thialme[0]# apt-get remove --purge psad [...] Stopping Port Scan Attack Detector: Shutting down the psadwatchd monitoring daemon: psadwatchd. Shutting down the psad daemon: psad. Shutting down the kmsgs daemon: kmsgs. psad. [...] This is really funny, it says shutting down psad but nothing happens. If I shut the psad daemon down I am not getting any log messages (via syslog), do you know any way to get some messages when shutting down psad? -- Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465412: psad: Please add LSB formatted dependency info in init.d script
Hello Petter Petter Reinholdtsen schrieb: Hi. Any hope of having this fixed soon? I can NMU to solve it. I am just to busy these days, please NMU, thank you. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464006: Acknowledgement (psad: Missing alternatived dependency on system-log-daemon)
Hello Michael Michael Biebl schrieb: could you give me a status update on this bug report? psad is the only package which makes rsyslog uninstallable. I will soon (hopefully tomorrow) upload a new version and I will include this changes, sorry for the delay. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412446: psad: Please clarify how to enable UDP logging
Francois Marier schrieb: On 2007-03-28 at 06:26:55, Daniel Gubser wrote: Can you please send me the output of the following command: # psad -D --fw-dump Sorry for the very long delay in getting back to you. I hadn't tried this for a while and now it looks like the problem is gone (in unstable at least). Can you please confirm that this bug is gone? Thanks. -- Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418777: [Fwd: Re: Bug#418777: psad: snort_rule_dl ignored ?!?]
FYI. Daniel ---BeginMessage--- Hi Daniel - Yes, indeed this is a bug. It will be fixed in the 2.0.7 release of psad. Thanks, -- Michael Rash http://www.cipherdyne.org/ Key fingerprint = 53EA 13EA 472E 3771 894F AC69 95D8 5D6B A742 839F On Apr 12, 2007, Daniel Gubser wrote: Hello Mike Can you please help with this bug? Thanks Daniel Richard A Nelson schrieb: Package: psad Version: 2.0.6-1 Severity: normal The recent psad upgrade decided to start blocking my AIX boxes because of their large ping size (even though the content/size was not malicious). No problem, I thought, I'll update /etc/psad/snort_rule_dl to include SIDs 384(ping), and 499 (large packet) with danger level 0: - #384: ICMP PING 384 0; #499: ICMP Large ICMP Packet 499 0; I then cleared the currently blocked machines and started psad Unfortunately, psad still wants to block, for the same two SIDs For the nonce, I just commented out those two rules in snort_rules/*icmp* and so far that seems to be doing the trick -- System Information: Debian Release: lenny/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages psad depends on: ii iptables1.3.6.0debian1-5 administration tools for packet fi ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libcarp-clan-perl 5.8-1Perl enhancement to Carp error log ii libdate-calc-perl 5.4-5Perl library for accessing dates ii libnetwork-ipv4addr-per 0.10-1.1 The Net::IPv4Addr perl module API ii libunix-syslog-perl 0.100-5 Perl interface to the UNIX syslog( ii perl5.8.8-7 Larry Wall's Practical Extraction ii psmisc 22.3-1 Utilities that use the proc filesy ii sysklogd [syslogd] 1.4.1-20 System Logging Daemon ii whois 4.7.21 the GNU whois client Versions of packages psad recommends: ii bastille 1:2.1.1-13 Security hardening tool -- no debconf information ---End Message---
Bug#412446: psad: Please clarify how to enable UDP logging
Hello Francois Francois Marier schrieb: Package: psad Version: 2.0.4-1 Severity: wishlist Everytime psad starts up, the following warning mesage is emailed to me: Can you please send me the output of the following command: # psad -D --fw-dump Thanks. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409815: psad: Every upgrade requires editing the configuration file
Hello Francois Francois Marier schrieb: Package: psad Version: 2.0.4-1 Severity: normal I've made changes to /etc/psad/psad.conf to set the machine name and my dshield userid but everytime the package is upgraded, a new version is installed on top of it and I have to make these same changes again. Of course, I could say No, keep my own version of the config file but typically that doesn't work and psad refuses to start because some values (for newly added options) are not set. Wouldn't it be better to use the debconf for this? I am having (since some time) this on my todo list. What fields do you which to configure? - hostname - email address - DShield alerts - ??? Thanks Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403566: psad doesn't start because /usr/lib/psad doesn't exist
Hello Mau Mau schrieb: Yes, exactly the same error. Tried to purge and re-install, tried all I can without success, so I reverted again to 1.4.8-1. Adding --Lib-dir /var/lib/psad in /etc/init.d/psad solves, but an identical error is then raised by fwcheck_psad. I will shortly upload a new version (2.0.3) which should fix this problem. Could you please test it and let me know if it work for you? Thanks Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403566: psad doesn't start because /usr/lib/psad doesn't exist
Hello Mau Mau schrieb: although this issue appears as fixed, as far as I can see it seems still unfixed in 2.0.2-1: please don't close this bug report. What, do you still get the same error after upgrading? Since this bug renders psad unusable I think that the severity should be raised to grave. OK, I will do that. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403566: psad doesn't start because /usr/lib/psad doesn't exist
Hello Mau Mau schrieb: my $psad_lib_dir = '/usr/lib/psad'; while in /etc/psad/psad.conf at line 360 I found: PSAD_LIB_DIR /var/lib/psad; Finally I see it: /usr/.. is not equal to /var/.. I will ask Mike Rash about this. Thanks for your enlightenment! ;-) Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403566: psad doesn't start because /usr/lib/psad doesn't exist
Francois Marier schrieb: $ ls -l /var/lib/ ... drwxr-xr-x 2 root root 4.0K 2006-03-11 17:49 psad/ ... $ ls -l /var/lib/psad prw--- 1 root root 0 2006-12-18 08:36 psadfifo| Hmm, thanks, this looks good. Did you update? Does it work now with this update? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403566: psad doesn't start because /usr/lib/psad doesn't exist
Mau schrieb: Daniel Gubser [EMAIL PROTECTED] wrote: Please read the README.Debian file in /usr/share/doc/psad/. We do not want to change the /etc/syslog.conf file so you have to edit it manually or use the script provieded in the README.Debian. My /etc/syslog.conf already contained the directive kern.info |/var/lib/psad/psadfifo but the failure Starting Port Scan Attack Detector and associated daemons: [*] psad lib directory: /usr/lib/psad does not exist, use --Lib-dir dir at /usr/sbin/psad line 2509. Funny, the /usr/lib/psad should be generated in the postinst script (see /var/lib/dpkg/info/psad.postinst ). Do you have this file? Did during the installation any error occur? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403566: psad doesn't start because /usr/lib/psad doesn't exist
Hello Francois Francois Marier schrieb: $ sudo /etc/init.d/psad restart [snip] Starting Port Scan Attack Detector and associated daemons: [*] psad lib directory: /usr/lib/psad does not exist, use --Lib-dir dir at /usr/sbin/psad line 2509. The /usr/lib/psad directory doesn't exist on my machine. The kern.info |/var/lib/psad/psadfifo line was already in my /etc/syslog.conf and running the script from README.Debian only adds it one more time to the end of the file. I don't think that was the problem because I still can't start psad (I get the same error message). So this was a update of psad? Could you deinstall install psad on this machine? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403566: psad doesn't start because /usr/lib/psad doesn't exist
Francois Marier schrieb: Yes, I've had this problem since I upgraded the package. I have just purged and reinstalled the package and I am still having the same problem. Is there supposed to be anything in /usr/lib/psad ? Because that directory doesn't exist for me... Yes, it should contain the psadfifo file. open IP options file /etc/psad/ip_options: No such file or directory at /usr/sbin/psad line 2918. Ohh, please update to the news psad version *-2, I did forget the ip_options file in the -1 version. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403566: psad doesn't start because /usr/lib/psad doesn't exist
Francois Marier schrieb: That file is in /var/lib/psad on my machine, not /usr/lib/psad. Is the config wrong? please send me the output of ls -l /var/lib/ and ls -l /var/lib/psad Ohh, please update to the news psad version *-2, I did forget the ip_options file in the -1 version. Ok, I will try that once it hits unstable. Should be in unstable now: http://packages.qa.debian.org/p/psad/news/20061218T090210Z.html Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389834: diff for 1:0.3.7-3.1 NMU
merge 389834 388314 -- Thanks Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351191: [Fwd: Re: Bug#351191: /usr/lib/perl5/IPTables/ChainMgr.pm: no cause given on failure]
FYI Daniel Forwarded Message From: Michael Rash [EMAIL PROTECTED] To: Daniel Gubser [EMAIL PROTECTED] Subject: Re: Bug#351191: /usr/lib/perl5/IPTables/ChainMgr.pm: no cause given on failure Date: Tue, 27 Jun 2006 10:01:52 -0400 I'll take a look at this as well for the next release. I'll probably release 1.4.7 to fix this and the previous bug as well. Thanks, -- Michael Rash http://www.cipherdyne.org/ Key fingerprint = 53EA 13EA 472E 3771 894F AC69 95D8 5D6B A742 839F On Jun 27, 2006, Daniel Gubser wrote: Hello Mike And an other bug which got forgotten, sorry. Daniel On Fri, 2006-02-03 at 12:15 +0700, Jeroen Vermeulen wrote: Package: psad Version: 1.4.5-1 Severity: normal File: /usr/lib/perl5/IPTables/ChainMgr.pm Another bug in psad (which I'll report separately) caused the iptables invocation(s) in add_ip_rule() to fail. The only error message reported by ChainMgr was Table: filter, chain: PSAD_BLOCK_INPUT, could not add DROP rule for [...] - [...] After hacking ChainMgr to display the command it had tried to run, I was able to reproduce the failed command line and it turns out that iptables was giving a perfectly useful error message. Is it not possible to include this in the error message returned by add_ip_table()? -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages psad depends on: ii ipchains 1.3.10-15 Network firewalling for Linux 2.2. ii iptables 1.3.1-2 Linux kernel 2.4+ iptables adminis ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libcarp-clan-perl 5.3-3 Perl enhancement to Carp error log ii libdate-calc-perl 5.4-3 Perl library for accessing dates ii libnetwork-ipv4addr-perl 0.10-1.1 The Net::IPv4Addr perl module API ii libunix-syslog-perl0.100-4 Perl interface to the UNIX syslog( ii perl 5.8.4-8sarge3 Larry Wall's Practical Extraction ii psmisc 21.6-1Utilities that use the proc filesy ii sysklogd [syslogd] 1.4.1-17 System Logging Daemon ii whois 4.7.5 the GNU whois client -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351196: [Fwd: Re: Bug#351196: psad: IPTABLES_AUTO_RULENUM hazard]
FYI
Daniel
Forwarded Message
From: Michael Rash [EMAIL PROTECTED]
To: Daniel Gubser [EMAIL PROTECTED]
Subject: Re: Bug#351196: psad: IPTABLES_AUTO_RULENUM hazard
Date: Tue, 27 Jun 2006 09:34:36 -0400
Thanks for the bug report. Yes, I need to fix the IPTABLES_AUTO_RULENUM
functionality as it is currently broken. I will most likely do the
following:
- Extend the IPT_AUTO_CHAIN{n} symantics so that the placement of the
jump rule can be specified as well as the placement of the rules
within the auto-chain itself. This will make the
IPTABLES_AUTO_RULENUM functionality obselete.
- Add better diagnostic messages so that the admin is better informed
about what is happening with auto-generated rule placement.
- If the values for the placement of the rules (either the jump rule or
the auto-generated rules) don't make sense, i.e. they are too high
because there aren't enough other rules in the chain, then a warning
will be generated and the values will be re-interpreted to mean the
highest possible _valid_ values.
Note that the IPTABLES_AUTO_RULENUM functionality is mostly only useful
if the admin decides to manually add rules to the AUTO chains (probably
not a good idea, but I wanted psad to be compatible with this just in
case).
--
Michael Rash
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F AC69 95D8 5D6B A742 839F
On Jun 27, 2006, Daniel Gubser wrote:
Hello Mike
Forgot to forward this bug to you, can you help?
Daniel
On Fri, 2006-02-03 at 12:49 +0700, Jeroen Vermeulen wrote:
Package: psad
Version: 1.4.5-1
Severity: normal
The IPTABLES_AUTO_RULENUM is documented as follows in the default
configuration file:
### Specify the position or rule number within the iptables
### policy where auto block rules get added.
There then follows a configurable list of chains IPT_AUTO_CHAIN{n} that
can be created automatically to hold the per-host blocking rules created
by psad. Each auto-chain line has a field to specify which existing
chain should jump to that auto-chain, but no field to say where in the
calling chain the jump should be inserted.
My impression was that this was what IPTABLES_AUTO_RULENUM did. I was
wrong. It turns out that IPTABLES_AUTO_RULENUM determines where a new
blocking rule for an offensive host should be inserted into the
applicable auto-chain itself.
The real gotcha is this: IPTABLES_AUTO_RULENUM becomes a boobytrap when
auto-chains are used. If an auto-chain is empty initially, the *only*
setting for IPTABLES_AUTO_RULENUM that makes any sense at all is 1.
Anything else and rule insertion will simply not work, because the given
index will be out of range. (A log message will say that it isn't
working, but fail to give any indication of what goes wrong--that's in a
separate bug report).
Some things that I imagine could be done:
* Add a warning to the IPTABLES_AUTO_RULENUM documentation about the
dangers in combination with IPT_AUTO_CHAIN.
* Fail to start when auto-chains are used and IPTABLES_AUTO_RULENUM is
not set to 1.
* Add an optional insertion index to IPT_AUTO_CHAIN entries to take
away any confusion about what IPTABLES_AUTO_RULENUM means.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (50, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages psad depends on:
ii ipchains 1.3.10-15 Network firewalling for
Linux 2.2.
ii iptables 1.3.1-2 Linux kernel 2.4+ iptables
adminis
ii libc6 2.3.2.ds1-22 GNU C Library: Shared
libraries an
ii libcarp-clan-perl 5.3-3 Perl enhancement to Carp
error log
ii libdate-calc-perl 5.4-3 Perl library for accessing
dates
ii libnetwork-ipv4addr-perl 0.10-1.1 The Net::IPv4Addr perl
module API
ii libunix-syslog-perl0.100-4 Perl interface to the UNIX
syslog(
ii perl 5.8.4-8sarge3 Larry Wall's Practical
Extraction
ii psmisc 21.6-1Utilities that use the proc
filesy
ii sysklogd [syslogd] 1.4.1-17 System Logging Daemon
ii whois 4.7.5 the GNU whois client
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350953: uptimed: upstream maintainership changed, new versions available
Hello On Sun, 2006-04-09 at 13:12 +0200, Thibaut VARENE wrote: I was wondering what's up with the packaging of the new version? Umm, to much work, but it is still pending... sorry.. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357253: [Fwd: Re: Bug#357253: psad: kmsgsd segfaults]
Hello Jürgen
Can you please send us your kmsgsd.conf file?
Thanks
Daniel
Forwarded Message
From: Michael Rash [EMAIL PROTECTED]
To: Daniel Gubser [EMAIL PROTECTED]
Subject: Re: Bug#357253: psad: kmsgsd segfaults
Date: Thu, 16 Mar 2006 10:55:08 -0500
Hmm, strange. Do you happen to have the /etc/psad/kmsgsd.conf file?
It might be because the FW_MSG_SEARCH variable is not defined correctly
(some defensive code has been added since the 1.4.1 release to handle
this case, so in later versions it would not be a problem). I'll try
to reproduce it if you have the file handy...
Thanks,
--
Michael Rash
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F AC69 95D8 5D6B A742 839F
On M?r 16, 2006, Daniel Gubser wrote:
Hello Mike
Do you have any clue about this segfault?
Thanks
Daniel
On Thu, 2006-03-16 at 13:19 +0100, Juergen Richtsfeld wrote:
Package: psad
Version: 1.4.1-1
Severity: grave
Justification: renders package unusable
strace kmsgsd
execve(/usr/sbin/kmsgsd, [kmsgsd], [/* 8 vars */]) = 0
uname({sys=Linux, node=troubadix, ...}) = 0
brk(0) = 0x804b000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7fd2000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.preload, O_RDONLY)= -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=11553, ...}) = 0
old_mmap(NULL, 11553, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fcf000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/tls/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`Z\1\000...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1254468, ...}) = 0
old_mmap(NULL, 1264780, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0xb7e9a000
old_mmap(0xb7fc4000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0x129000) = 0xb7fc4000
old_mmap(0xb7fcd000, 7308, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fcd000
close(3)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7e99000
set_thread_area({entry_number:-1 - 6, base_addr:0xb7e99460,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0xb7fcf000, 11553) = 0
brk(0) = 0x804b000
brk(0x806c000) = 0x806c000
brk(0) = 0x806c000
open(/etc/psad/kmsgsd.conf, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1427, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7fd1000
read(3, #\n##..., 4096) = 1427
read(3, , 4096) = 0
close(3)= 0
munmap(0xb7fd1000, 4096)= 0
open(/etc/psad/fw_search.conf, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1593, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7fd1000
read(3, ### The FW_SEARCH_ALL variable c..., 4096) = 1593
read(3, , 4096) = 0
close(3)= 0
munmap(0xb7fd1000, 4096)= 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
please execuse the number of reports, but my email wasn't correct.
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.15.21
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages psad depends on:
ii iptables 1.2.11-10 Linux kernel 2.4+ iptables
adminis
ii libc6 2.3.2.ds1-22 GNU C Library: Shared
libraries an
ii libcarp-clan-perl 5.3-3 Perl enhancement to Carp
error log
ii libdate-calc-perl 5.4-3 Perl library for accessing
dates
ii libnetwork-ipv4addr-perl 0.10-1.1 The Net::IPv4Addr perl
module API
ii libunix-syslog-perl0.100-4 Perl interface to the UNIX
syslog(
ii perl 5.8.4-8sarge3 Larry Wall's Practical
Extraction
ii psmisc 21.5-1Utilities that use the proc
filesy
ii syslog-ng 1.6.5-2.2 Next generation logging
daemon
ii whois 4.7.5 the GNU whois client
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357253: [Fwd: RE: [Fwd: Re: Bug#357253: psad: kmsgsd segfaults]]
Hello Mike
Strange, should be one out of the box...
Daniel
Forwarded Message
From: Juergen Richtsfeld [EMAIL PROTECTED]
To: Daniel Gubser [EMAIL PROTECTED]
Subject: RE: [Fwd: Re: Bug#357253: psad: kmsgsd segfaults]
Date: Thu, 16 Mar 2006 17:03:58 +0100
here it is. it's the default as delivered in debian sarge
#
###
#
# This is the configuration file for psad kmsgsd daemon (for more
# information, read the kmsgsd man page). Normally this file gets
# installed at /etc/psad/kmsgsd.conf, but can be put anywhere in the
# filesystem and then the path can be specified on the command line
# argument -c file to kmsgsd. The syntax of this file is as follows:
#
# -Each line has the form variable namevalue;. Note the semi-
# colon after the value. All characters after the semicolon will be
# ignored to provide space for comments.
#
###
#
# $Id: kmsgsd.conf,v 1.3 2003/09/13 01:36:53 mbr Exp $
#
### The following variables can be modified to look for logging messages
### that are specific to your firewall configuration (specified by the
### --log-prefix for iptables firewalls). For example, if your firewall
### uses the string Audit for packets that have been blocked, then you
### could set FW_MSG_SEARCH = Audit;
FW_MSG_SEARCH DROP;
SNORT_SID_STR SID; ### for snort sid values generated
### by fwsnort or snort2iptables
### Files
FW_DATA_FILE/var/log/psad/fwdata;
KMSGSD_PID_FILE /var/run/psad/kmsgsd.pid;
PSAD_FIFO /var/lib/psad/psadfifo;
hth,
juergen
-Original Message-
From: Daniel Gubser [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 16, 2006 5:02 PM
To: Juergen Richtsfeld; [EMAIL PROTECTED]
Subject: [Fwd: Re: Bug#357253: psad: kmsgsd segfaults]
Hello Jürgen
Can you please send us your kmsgsd.conf file?
Thanks
Daniel
Forwarded Message
From: Michael Rash [EMAIL PROTECTED]
To: Daniel Gubser [EMAIL PROTECTED]
Subject: Re: Bug#357253: psad: kmsgsd segfaults
Date: Thu, 16 Mar 2006 10:55:08 -0500
Hmm, strange. Do you happen to have the /etc/psad/kmsgsd.conf file?
It might be because the FW_MSG_SEARCH variable is not
defined correctly
(some defensive code has been added since the 1.4.1 release
to handle
this case, so in later versions it would not be a problem).
I'll try
to reproduce it if you have the file handy...
Thanks,
--
Michael Rash
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F AC69 95D8 5D6B A742 839F
On M?r 16, 2006, Daniel Gubser wrote:
Hello Mike
Do you have any clue about this segfault?
Thanks
Daniel
On Thu, 2006-03-16 at 13:19 +0100, Juergen Richtsfeld wrote:
Package: psad
Version: 1.4.1-1
Severity: grave
Justification: renders package unusable
strace kmsgsd
execve(/usr/sbin/kmsgsd, [kmsgsd], [/* 8 vars */]) = 0
uname({sys=Linux, node=troubadix, ...}) = 0
brk(0) = 0x804b000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7fd2000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No
such file or
directory)
open(/etc/ld.so.preload, O_RDONLY)= -1 ENOENT (No
such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=11553, ...}) = 0
old_mmap(NULL, 11553, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fcf000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No
such file or
directory)
open(/lib/tls/libc.so.6, O_RDONLY)= 3
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`Z\1\000...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1254468, ...}) = 0
old_mmap(NULL, 1264780, PROT_READ|PROT_EXEC,
MAP_PRIVATE, 3, 0) =
0xb7e9a000
old_mmap(0xb7fc4000, 36864, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED,
3, 0x129000) = 0xb7fc4000
old_mmap(0xb7fcd000, 7308, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fcd000
close(3)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7e99000
set_thread_area({entry_number:-1 - 6, base_addr:0xb7e99460,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0xb7fcf000, 11553) = 0
brk(0) = 0x804b000
brk(0x806c000) = 0x806c000
brk(0
Bug#323203: Bug#323206: psad: iptables method fails for unclear reasons
On Mon, 2006-01-23 at 17:15 +0700, Jeroen Vermeulen wrote: Adding the setting got things to work. The daemon is running, though I haven't had any email from it yet and it hasn't banned anyone. It's set up not to be oversensitive, so that may explain it. So this is working now for you? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350953: uptimed: upstream maintainership changed, new versions available
On Thu, 2006-02-02 at 00:35 +0100, Thibaut VARENE wrote: AFAICT, uptimed has been taken over upstream, see: http://www.robertjohnkaper.com/software/uptimed/download.html it says: Note: Uptimed is now maintained by Radek Podgorny. Up-to-date releases can be found at: http://podgorny.cz/uptimed/ Latest version is there 0.3.5 (released 2006-01-27) This upstream channel seems still lively, it'd probably be a good thing to keep tracking it... Great, thanks for the link, will do it soon. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323203: Bug#323206: psad: iptables method fails for unclear reasons
On Mon, 2006-01-23 at 13:58 +0700, Jeroen Vermeulen wrote: On Fri, Jan 20, 2006 at 08:15:51AM +0100, Daniel Gubser wrote: There is a new version of PSAD out, 1.4.5, can you please try it? I just tried, but it dies with the complaint that there is no ENABLE_FW_LOGGING_CHECK variable in th config file /etc/psad/psad.conf. Hmm, what did you answer in the update when you were asked if you like to, aahh, how is it spelled: update your config file? overwrite, leave it alone, abort?? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323203: Bug#323206: psad: iptables method fails for unclear reasons
Hello There is a new version of PSAD out, 1.4.5, can you please try it? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323203: Bug#323206: psad: iptables method fails for unclear reasons
On Fri, 2005-08-26 at 14:12 +0700, Jeroen Vermeulen wrote: On Thu, Aug 25, 2005 at 03:00:37PM +0200, Daniel Gubser wrote: Here is a quick answer from Mike Rash: Note that the upcoming psad-1.4.3 release should have much improved auto- blocking capabilities. The new version can now be found at http://www.gutreu.ch/debian/ Can you please test it? -- Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323206: psad: iptables method fails for unclear reasons
Hello Jeroen Am Montag, den 15.08.2005, 19:34 +0700 schrieb Jeroen Vermeulen: The iptables auto-IDS method does not work for me. In /var/log/messages I find that psad has logged errors of the form: could not add iptables block rule for: address Table: filter, chain: PSAD_BLOCK_INPUT, could not add DROP rule for address - 0.0.0.0/0 Here is a quick answer from Mike Rash: try executing psad -F before starting psad. I think the reason psad could not add the blocking rule is because the IP is already blocked. Psad may have lost track of the IP because of a bug with the auto-blocking time outs. Executing psad -F should restore things to normal. Note that the upcoming psad-1.4.3 release should have much improved auto- blocking capabilities. Does this solve your problem (psad -F)? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323203: psad: Ignores IPTABLES_AUTO_RULENUM
Hello Jeroen Am Montag, den 15.08.2005, 19:21 +0700 schrieb Jeroen Vermeulen: I'm experimenting with the audo-IDS feature, and it does create the new netfilter chain and does insert a jump rule from the INPUT chain to the newly created chain. The new rule, however, is inserted at the first position--not the position I configured for it. Here the answer from Mike Rash: if the IPTABLES_AUTO_RULENUM keyword in psad.conf is set to, say, 3, then it should work as advertised, but I need to test this to be sure. Could you please test this? Thanks Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#274635: uptimed does not send E-Mails
Hello Michelle Am Mittwoch, den 04.05.2005, 11:07 +0200 schrieb Michelle Konzack: Now I have used 1:0.3.3-3 and the Error is gone, but the changement between From: root to From: daemon should be documented for those which upgrade from WOODY... I just checked this in the source but I can't find a change in this, it must be something in your MTA or configuration. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307124: alternative translation
Hello Am Donnerstag, den 26.05.2005, 16:46 -0300 schrieb Gustavo Noronha Silva: I'd like to ask that you consider the attached translation for inclusion instead; it fixes semantic problems and improves the translation overall. Thank you for your work but which is the better translation? Or can I use both (Brasil AND Portoguese) version? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300841: Documentation contains outdated email and webpage addresses
Am Samstag, den 18.06.2005, 18:57 +1000 schrieb ADFH: It seems Mr Kaper has now redirected his old site to his new domain. A page can now be found for uptimed at: http://www.robertjohnkaper.com/software/uptimed/ unixcode.org (the old domain) redirects to the above.. Great, thanks for the link, I will update the dokumation Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#274635: uptimed does not send E-Mails
Hello Am Freitag, den 29.04.2005, 15:40 +0200 schrieb Michelle Konzack: Will this BUG not be fixed before SARGE release ? I do not know, upstream is MIA and I do not have enough time to fix it. Could you send me a patch for this? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306367: psad: update depends, metalog should be a valid choice.
Am Montag, den 25.04.2005, 21:24 -0700 schrieb Yazz D. Atlas: ### Set the type of syslog daemon that is used. The SYSLOG_DAEMON ### variable accepts three possible values: syslogd, syslog-ng, or ### metalog. Support for metalog is in psad not good supported, see: http://sourceforge.net/mailarchive/message.php?msg_id=11452184 I would like to use metalog since it can do some regex matching and execute scripts... Does it now support logging to named pipes? -- Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300841: uptimed: Documentation contains outdated email and webpage addresses
Am Die, den 22.03.2005 schrieb ADFH um 08:19: unixcode.org mentioned in /usr/share/doc/uptimed appears to have been taken down by its owner. Where, if anywhere, does upstream exist now? I contacted upstream several times but got so far no answer! Perhaps the /usr/share/doc information needs to be updated or removed? I will change it as soon as I know if Rob is missing or have a new Homepage. I acknowledge this is a minor issue - but still one worth attention eventually. You are right. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#280701: Bug #280701 - uptimed: Fails to email when passing top ten record runtimes
Problem is, the test is backward - the expression should read: (!position || (position = mail_min_position) I just tried this but still not receive any mails... Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#259477: missing bug?
Am Sam, den 05.02.2005 schrieb Robert Millan um 05:52: Did you say you'd fix this on next upload? Looks like you forgot #259477. Ahhh, I did your #259472 but got struck by the email problem, I unfortunatly will not have time this week, please NMU... Sorry Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
