September 2004 - openSUSE Security - openSUSE Mailing Lists

capability dazuko stops named xntpd
by Christoph Hanslik 24 Sep '04

24 Sep '04

Dear listmembers, dear maintainers, the problem I want to be helped in is about the capability. After installing the dazuko.ko module for running virus-scanning with avguard the services of xntpd and named give up to operate complaining: named: capset failed: Operation not permitted and: ntpd[3932]: cap_set_proc() failed to drop root privileges: Operation not permitted I am running SuSE 9.1 with the latest kernel 2.6.5-7.108-default and tried different dazuko-versions, latest was dazuko-2.0.4-pre2. Even with the latest kernel.org 2.6.8.1 it produced the same poor results. There is a module commoncap.ko but it is not included in the Makefile of /usr/src/linux-2.6.5-7.108-default/security but the commoncap.c is still there, for what purpose ist it omitted? I tried a lot with the capability=0 and selinux=0 in the /boot/grub/menu.lst entry, but the selinux is not in the mentioned kernel. Does anyone have an idea how can I run dazuko/avguard and named and xntpd on one machine? greetings and thanks in advance Christoph p.s.: the virus-scanning is working properly! -- >> -- hanslik(a)hanslux.de -- << >> -- http://www.hanslux.de -- <<

1 0

Pay attention after apache2 patch!
by Bjorn Tore Sund 24 Sep '04

24 Sep '04

On my SuSE 9.0 boxes running fou4s to update apache2 caused the service to stop running. A simple restart of the service was enough to fix it. On SuSE 9.1 it kept running, but only on one of the two 9.1 boxes I have with apache2 running was the automatic 'kill -HUP' from the update successfull. Again, a manual restart and no problem. Not worth debugging, but it's worth looking twice to make sure your apache2 server is still running after the upgrade, especially if you're running fully automated updates... Bjørn -- Bjørn Tore Sund Phone: (+47) 555-84894 Stupidity is like a System administrator Fax: (+47) 555-89672 fractal; universal and Math. Department Mobile: (+47) 918 68075 infinitely repetitive. University of Bergen VIP: 81724 Support: system(a)mi.uib.no Contact: teknisk(a)mi.uib.no Direct: bjornts(a)mi.uib.no

2 1

OpenVPN and x.509 certs - HOWTO ?
by Philipp Rusch 23 Sep '04

23 Sep '04

Hi all, Anybody who knows about doing OpenVPNs with x.509 certificates ? Any hint welcome, Philipp

1 0

Re: [suse-security] SSH password attacks
by Peer Stefan 23 Sep '04

23 Sep '04

Hi, > From: Carl A. Schreiber [mailto:gooly@gmx.at] > Sent: Donnerstag, 23. September 2004 10:55 > To: suse-security(a)suse.com > Subject: Re: [suse-security] SSH password attacks > > Hello, > > a question about a (SuSE)Firewall-Login: > > Is there a possibility (most probably) to restrict the ssh-access (user > and root) to the firewall to certain (local) networks like 10.10.10.*? Yes, you can filter ssh (port 22) by ipchains (SuSE-Firewall: FW_SERVICES_INT="ssh" and remove it from FW_SERVICES_EXT). > Am I on the right way that I must change > /etc/ssh/sshd_config > > Here I should change > #ListenAddress 0.0.0.0 > to > ListenAddress 10.10.10.0 > (with this only from the 10.10.10.0 net a user can login, > root login is denied anyway) The ListenAddress is the binding address of the daemon. It binds to the adapter with the given address and port - so if you use your internal address like 10.10.10.254 or whatever it only listens to ssh requests for this address. To allow requests only from certain subnets have a look at hosts.allow and hosts.deny. But it should suffice to use a firewall and bind sshd to local addresses only. > But _only_ this? > For me there is no need to protect from 'inside' as it is only me. > > Thanks in advance, > Carl You're welcome, Stefan

1 0

Anti-Spam news letter
by suse＠karsites.net 23 Sep '04

23 Sep '04

Hi all. If anyone is interested I can email you off list the latest copy of Bigfoots anti-spam newsletter. Has alot of interesting info in the fight against spammers. Regards - Keith

2 1

Re: [suse-security] harden_suse
by tfulton9909＠comcast.net 23 Sep '04

23 Sep '04

I was told that this was a resource for security questions to be answered. Could someone please help me. thanks Tom Fulton Novell San Jose, CA > On Mon, 09 Aug 2004 22:44:42 +0000, tfulton9909(a)comcast.net > wrote: > > Hello, > > What is that status of harden_suse in SLES 9 in light of Bastille being > released? > > thanks > > -- > Check the headers for your unsubscription address > For additional commands, e-mail: suse-security-help(a)suse.com > Security-related bug reports go to security(a)suse.de, not here >

3 2

Re:[suse-security] SSH password attacks
by Dustin Knuttgen 23 Sep '04

23 Sep '04

Hi all, I am, of course, seeing the same thing. I wonder if it might be because of SuSE now being owned by novell. Admin is a typical Novell server user account. Maybe someone is trying the attacks against the SuSE servers that they were using for Novell servers. Just a thought. Dustin Hi, by me the same: ... Sep 13 14:53:25 tempi sshd[7383]: Failed password for invalid user test from 220.73.215.151 port 52864 ssh2 Sep 13 14:53:28 tempi sshd[7385]: Failed password for invalid user guest from 220.73.215.151 port 52992 ssh2 Sep 13 14:53:30 tempi sshd[7387]: Failed password for admin from 220.73.215.151 port 53128 ssh2 Sep 13 14:53:33 tempi sshd[7393]: Failed password for admin from 220.73.215.151 port 53260 ssh2 Sep 13 14:53:36 tempi sshd[7396]: Failed password for invalid user user from 220.73.215.151 port 53392 ssh2 Sep 13 14:53:39 tempi sshd[7398]: Failed password for root from 220.73.215.151 port 53539 ssh2 Sep 13 14:53:41 tempi sshd[7400]: Failed password for root from 220.73.215.151 port 53678 ssh2 Sep 13 14:53:44 tempi sshd[7406]: Failed password for root from 220.73.215.151 port 53814 ssh2 Sep 13 14:53:47 tempi sshd[7408]: Failed password for invalid user test from 220.73.215.151 port 53948 ssh2 ... what I can do, is to block the addresses and read less logs :) On Mon, 20 Sep 2004 11:40:23 -0400, suse wrote > This may not be strictly SuSE related, but what the heck: Lately, > I've been getting tons of attempts to login via ssh for "guest", > "test", "user", and "admin". Plenty others for root, and even one > that seemed to have been a list of some script kiddie's /etc/passwd. > The root ones are pretty obvious and always blocked, but I've found > the others rather curious. > > Does anyone running a unix server really use "guest", "test", "user", > or "admin" as real accounts? Judging by the volume of attempts I'm > getting, there has to be something causing this. Was a borked > version of ssh server released for windows, or something? Or is > this trying to connect to zombie machines? From what I understand, > ssh server isn't common on windows, and those accounts certainly > aren't common to unix... Anyone know what's going on here? > > (I'm not worried about my machines, root is blocked by sshd and I > don't have the other accounts, I'm just curious.) > > -- > Check the headers for your unsubscription address > For additional commands, e-mail: suse-security-help(a)suse.com > Security-related bug reports go to security(a)suse.de, not here -- Yes of course I'm sure it's the red cable. I guarante[^%!/+)F#0c|'NO CARRIER -- STTS -- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help(a)suse.com Security-related bug reports go to security(a)suse.de, not here

2 2

Postfix Backscatter
by Uwe Debacher 22 Sep '04

22 Sep '04

Hi, my postfix-Mailserver on a SuSE9.1 system ist flooded by backscatter mails which are undeliverable (random addresses). At the moment it is nearly impossible to sent a mail to this system. Yesterday it handled (rejected) about 12.000 of such mails. This seems to be too slow. So i changed my configuration setting: smtpd_error_sleep_time = 0, stopped all RBL usage and increased the number of smtp processes from 2 to 80. Now my system seems to handle about 40.000/day but this is not enough, there is still only a small chance to send a normal mail. Is there any chance to optimize postfix so that it can handle much more mails/connections each day? Or any other idea to solve such backscatter problems? Best Uwe

5 8

Re: [suse-security] Postfix Backscatter
by Marc Samendinger 22 Sep '04

22 Sep '04

I'm sorry for the private mail that i accidentally sent to you Uwe. > -----Original Message----- > From: Uwe Debacher [mailto:suse@hsan.hh.schule.de] > Sent: Wednesday, September 22, 2004 2:29 PM general tuning tips can be found on www.postfix.org/TUNING_README.html www.stahl.bau.tu-bs.de/~hildeb/postfix/postfix_bottleneck.shtml > Am Mi, den 22.09.2004 schrieb Sven 'Darkman' Michels um 12:50: > > What Hardware and Setup do you use? Virtual Users? Database > it is a standard SuSE9.1 system only with real (Linux) users. > > the hardware memory/processor should be good enough. PC Hardware > (500MByte/5000bogomips) and the WAN connectivity is about 5MBit. > > > maybe bad hardware. If possible a post of postconf -n would > i attached the output, but i cut the domain/host information unknown_local_recipient_reject_code = 450 you definitely should change this to 550 I can't see anything that shold slow down your system that much. 40.000 Mails a day should be a joke to postfix. can you please show your uncommented master.cf entries > Best > Uwe marc

3 2

Re: [suse-security] IPSEC - SuSE 9.1 - Shorewall 2.x
by t.henneberger＠hcs-computer.de 22 Sep '04

22 Sep '04

Hello again ;) Subject: Re: [suse-security] IPSEC - SuSE 9.1 - Shorewall 2.x (22-Sep-2004 10:46) From: philipp.rusch(a)rusch-edv.de To: suse-security(a)suse.com > I got one step nearer to my goals: > > ISAKMP SA is established, so key-exchange seems to work and > encryption is not the reason. > But pluto complains, that he cannot find a connection for that SA, > although everything else is *exactly* like on 9.0 before. Hm, you may want to check the archive of the Openswan Mailinglist (http://lists.openswan.org/mailman/listinfo/), maybe someone else encountered that problem. > I did define my roadwarriors like that: > > # /etc/ipsec.conf - FreeS/WAN IPsec configuration file > version 2.0 # conforms to second version of ipsec.conf specification > > # basic configuration > config setup > interfaces=%defaultroute > klipsdebug=all > plutodebug=all > nat_traversal=yes > > Any hint appreciated, > Philipp I don't think it is related to your problem, but you can delele the interfaces line, as Native-IPsec doesn't use them anymore, and I think the debugging levels are a bit high. Best regards Thomas

1 0