July 2004 - openSUSE Security - openSUSE Mailing Lists

what has become of the latest kernel hang/freeze bug?
by Andreas Bittner 04 Jul '04

04 Jul '04

hi there, the latest suse security announcement for the dhcp packages doesnt list any pending problems with the kernel packages. i was wondering if i have missed anything about ths discussion regarding the freezes and hangs many people experienced when this kernel updates was released for the floating point exception problem. how did people work around the freeze when booting this new kernel, or does suse have any plans on fixing/rereleasing another kernel that fixes this bug? thanks already for any hints. cheers andy

15 25

Re: [suse-security] DMZ Setup is killing me!!
by maarten van den Berg 04 Jul '04

04 Jul '04

On Friday 02 July 2004 21:05, you wrote: > > So let's examine scenario two, with non-reallife IP numbers. > > Here you have 22.22.22.10 on eth1, 192.168.0.x/24 on eth0 and you choose > > another net for the DMZ which MUST NOT be the same as on eth0 ! > > So, let's take 192.168.99.0/24 in this example. So eth2 becomes > > 192.168.99.1 > > > > >From there on it's simple; you make a series of rules like you had, > > > > FW_FORWARD_MASQ="0/0,192.168.99.4,tcp,80" if you have a webserver in the > > DMZ with IP 192.168.99.4. Add other statements for other ports and/or > > other servers to that same line, between those quotes, separated with > > space. You mustn't forget to set the right gateway on your DMZ boxes; > > they must have the IP you set to eth2 as their default gateway: > > 192.168.99.1. > > You may also have to make special arrangements so that internal hosts can > > connect to the DMZ IIRC, but I don't remember offhand. Just try it. > > > > > > Good luck, > > Maarten > > I tried this because it looked like what was needed a coulple of days > ago. it didn't seem to work but maybe I had something set up wrong. if > this indeed is the setup, it narrows the field of possible remaining > issues. > > is the eth on the firewall to the DMZ set as FW_DEV_DMZ or because it's > technically another masq'd net is it FW_DEV_INT ?? No no, its definitely FW_DEV_DMZ. Be careful how you test it; you will probably NOT be able to test the connection from within, so you'll have to have access to another internet connection to test from (or a remote host). Also, if you know halfway how to interpret it, a sniffer can be an invalueable help if things do not work from the start. Even if you can't interpret it, just seeing where the packet gets sent to (or not) can be enlighting. Tcpdump or Snort are your friends. You can start multiple sessions, each attached to the different eth's. Not very relevant now, but: The caveat I forgot to mention in comparing the first with the second scenario is that when masquerading as you will do now, you can only have 1 machine in your DMZ for each service, i.e. one webserver, one mailserver, etc, maximum. This stems from the fact that you cannot masquerade one port to two systems, whereas in the real-life IP numbers scenario you don't masquerade, just route. And that of course works just fine with multiple IP's. Another thing, if it wasn't already obvious, is that for the outside world, your server(s) appear to have the IP number your firewall has: the ISP address. But seen from the inside LAN this isn't so. From there, you just do plain routing, so you address the DMZ servers by their actual IP. This is only valid in scenario two, the masquerading one. Otherwise everything is just addressed by their actual IP number (22.22.22.18 etc.) Confusing ? Nah. ;-) One last advice: Keep it simple, and take small steps. For example, never test it with a browser / webpage. Test it with ping or ssh first and go on to other, more complex, services from there. Also, never ever use DNS names (unless it's really setup well, and triple-checked), instead always connect to the IP numbers. Don't know it this was too obvious but one never knows... Maarten > Thanks!! I'll give it another try. > > Mike -- Yes of course I'm sure it's the red cable. I guarante[^%!/+)F#0c|'NO CARRIER

3 2

Waiting for device /dev/900 to appear
by Werner Penz 03 Jul '04

03 Jul '04

OK, id did a complete new installation (same box) with the same disk-configuration: /dev/hda2 + /dev/hdb2 als raid1: /dev/md0 = / #root (ext3) /dev/hda1 = /boot from original CD SuSe 91prof. minimal System installed. all works fine until i upgrade the kernel 2.6.4 to 2.6.5 from the ftp.suse.com with YOU. The boot aborts with: raidautorun ... waiting for device /dev/900 to appear ...(short delay ) .... not found.... RAIDs never saved me from a "dilemma", for me, the always created one !

2 1

Re: [suse-security] kernel update oddity on 9.0 Professional
by Robbert Eggermont 03 Jul '04

03 Jul '04

>I've noticed a peculiarity the last couple of times I tried to update the >kernel of my two SuSE 9.0 Pro machines via Yast. <cut> >I also got a message warning me to run /sbin/SuSEffective (which as >far as I can tell isn't installed on either of my SuSE computers.) I actually thought that part of the message was missing (because of the formatting). I never bothered to figure out what I had to run, and have not suffered any (direct) problems. Robbert Eggermont R.Eggermont(a)EWI.TUDelft.nl

3 2

SuSE 9.1 CDROM and DVD are different versions
by Simon Oliver 02 Jul '04

02 Jul '04

I recently purchased SuSE Linux Pro 9.1. As usual I copied the DVD to my NFS server so that I can do local minimal installs using CD1 and then once up and running machines can have extra packages installed via NFS as required. However, I find that the DVD bundled with 9.1 is RC1 whereas the CDs are RC2. This means loads of conflicts if one tries to install anything from the DVD (or network copy thereof) on a machine that was originally installed via CDROM (and vice versa)! The only fix I can see is to copy each CD to my NFS server and throw the DVD in the bin! -- Simon Oliver

5 4

kernel update oddity on 9.0 Professional
by Watson, Michael 02 Jul '04

02 Jul '04

I've noticed a peculiarity the last couple of times I tried to update the kernel of my two SuSE 9.0 Pro machines via Yast. Yast indicated that a kernel update was available, and downloaded it; but also advised me I needed to reboot after the update because the kernel might need to probe for hardware. Not necessarily a problem, but it worried me a bit, because I've never gotten this message on any of my previous kernel updates through YaST. I also got a message warning me to run /sbin/SuSEffective (which as far as I can tell isn't installed on either of my SuSE computers.) I would be less worried about all this except for the problems people have been reporting on this listserv with recent kernel updates. Did anyone else see these messages? If so, did you run into problems after running the update? Thanks, Mike Watson mwatso(a)lsuhsc.edu

1 0

DMZ Setup is killing me!!
by Mike Branda 02 Jul '04

02 Jul '04

Running SuSE 9.0 Pro. O.K. I'm about to give up. I've been messing with the setup for SuSEfirewall2 which is apparently a niced up front end to IPTABLES. I'm trying to get a DMZ up so when I have to fix something on our renderfarm at 3 AM I can do it from home through ssh. currently the firewall works with 2 NICs dividing my local net from the big bad ugly WWW. it is functioning properly and dropping everything that it should. now on to the DMZ. I've read a ton of stuff on how to set up internal DMZ's through FW_FORWARD_MASQ="0/0,10.0.1.2,tcp,80" which looks like it Masquerades and uses an inside IP on a third NIC that's not a "real world" IP. I can't get that working in any way. Then there's the preferred method of having a second, ISP issued "real world" IP, on the DMZ and It again resides on the third NIC but there is no masquerading and it looks like and it uses FW_FORWARD="127.0.0.1,127.0.0.2,tcp,1". The forelisted FW lines are straight out of the EXAMPLE included with SuSE so they really don't apply to my network directly. let me sum up what I have and maybe somebody can point me in the right direction. Firewall box: FW_DEV_INT="eth0" FW_DEV_EXT="eth1" FW_DEV_DMZ="eth2" the external has my first ISP assigned IP. the internal is the generic 192.168.2.0 network. what I'm not sure of is what IP needs to be on eth2 real or masq'd and any custom routing. I've tried everything I can think of. including a same and different internal IP, another of my real world IP's you name it. routes?? and maybe howto?? DMZ box eth0 tried internal IP, real world IP......all in pairs because AFAIK if the subnet isn't the same and the networks are different they wont ping. the only life out there I get is when I use and internal IP like 192.168.0.1 on eth2 for the firewall and 192.168.0.2 on the DMZ. then I can ping from firewall to DMZ and vice versa. but when I go from there to try and use the FW_FORWARD_MASQ, I still can't get in from home on the outside. the only reason I'm pursuing the masq setup is I can't get anything else to ping. I'd prefer to do it the other way but it's not getting anywhere. so here's the snip from the masq field: # Which services accessed from the internet should be allowed to masqueraded # servers (on the internal network or dmz)? # REQUIRES: FW_ROUTE # # With this option you may allow access to e.g. your mailserver. The # machines must be in a masqueraded segment and may not have public IP addesses! # Hint: if FW_DEV_MASQ is set to the external interface you have to set # FW_FORWARD from internal to DMZ for the service as well to allow access # from internal! # # Please note that this should *not* be used for security reasons! You are # opening a hole to your precious internal network. If e.g. the webserver there # is compromised - your full internal network is compromised!! # # Choice: leave empty (good choice!) or use the following explained syntax # of forward masquerade rules, seperated each by a space. # A forward masquerade rule consists of 1) source IP/net, 2) destination IP # (dmz/intern), 3) a protocol (tcp/udp only!) and 4) destination port, # seperated by a comma (","), e.g. "4.0.0.0/8,1.1.1.1,tcp,80" # Optional is a port after the destination port, to redirect the request to # a different destination port on the destination IP, e.g. # "4.0.0.0/8,1.1.1.1,tcp,80,81" # FW_FORWARD_MASQ="0/0,10.0.1.2,tcp,80" # Beware to use this! Any help would be appreciated. I'm feeling beat up by what should be so simple... :^( Mike

4 3

Re: [suse-security] Kernel update hangs system
by Ulrich Bernhard 02 Jul '04

02 Jul '04

I have upgraded from the default installed kernel 2.6.4-52-default to 2.6.4-75-default. When I read any data on my secondary disk (hdc) the system hangs. The messages in /var/log/messages are in the attached file kernel-2.6.4-75.txt. With the older kernel 2.6.4-52-default the same action produced the following messages in the errorlog: Jul 1 09:29:53 linux kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } Jul 1 09:29:53 linux kernel: hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } Jul 1 09:29:53 linux kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } Jul 1 09:29:53 linux kernel: hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } Jul 1 09:29:53 linux kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } Jul 1 09:29:53 linux kernel: hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } Jul 1 09:29:53 linux kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } Jul 1 09:29:53 linux kernel: hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } Jul 1 09:29:53 linux kernel: ide1: reset: success The sections from the boot.msg concerning the disks are: <6> ide0: BM-DMA at 0xa800-0xa807, BIOS settings: hda:DMA, hdb:pio <6> ide1: BM-DMA at 0xa808-0xa80f, BIOS settings: hdc:DMA, hdd:DMA <4>hda: IBM-DJNA-352030, ATA DISK drive <4>ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 <4>hdc: IBM-DPTA-372050, ATA DISK drive <4>hdd: ASUS CD-S500/A, ATAPI CD/DVD-ROM drive <4>ide1 at 0x170-0x177,0x376 on irq 15 <4>hda: max request size: 128KiB <6>hda: 39876480 sectors (20416 MB) w/1966KiB Cache, CHS=39560/16/63, UDMA(33) <6> hda: hda1 hda2 hda3 <4>hdc: max request size: 128KiB <6>hdc: 40088160 sectors (20525 MB) w/1961KiB Cache, CHS=39770/16/63, UDMA(66) <6> hdc: hdc1 .... <5>ReiserFS: hda3: found reiserfs format "3.6" with standard journal <5>ReiserFS: hda3: using ordered data mode <5>ReiserFS: hda3: journal params: device hda3, size 8192, journal first block 1 8, max trans len 1024, max batch 900, max commit age 30, max trans age 30 <5>ReiserFS: hda3: checking transaction log (hda3) <5>ReiserFS: hda3: Using r5 hash to sort names .... <5>ReiserFS: hdc1: found reiserfs format "3.5" with standard journal <5>ReiserFS: hdc1: using ordered data mode <5>ReiserFS: hdc1: journal params: device hdc1, size 8192, journal first block 1 8, max trans len 1024, max batch 900, max commit age 30, max trans age 30 <5>ReiserFS: hdc1: checking transaction log (hdc1) <5>ReiserFS: hdc1: Using r5 hash to sort names <5>ReiserFS: hdc1: using 3.5.x disk format Best regards Ulrich -- +-----------------------------------------------------------+ | Ulrich Bernhard | | Informatikdienste Tel: (+41-44) 635 67 73 | | Universitaet Zuerich Fax: (+41-44) 635 45 05 | | Winterthurerstr. 190 | | CH-8057 Zuerich Email: ulrich.bernhard(a)id.unizh.ch | | Switzerland | +-----------------------------------------------------------+ Jul 1 10:42:43 smb0 kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } Jul 1 10:42:43 smb0 kernel: hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } Jul 1 10:42:43 smb0 kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } Jul 1 10:42:43 smb0 kernel: hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } Jul 1 10:42:43 smb0 kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } Jul 1 10:42:43 smb0 kernel: hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } Jul 1 10:42:43 smb0 kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } Jul 1 10:42:43 smb0 kernel: hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } Jul 1 10:42:43 smb0 kernel: bad: scheduling while atomic! Jul 1 10:42:43 smb0 kernel: Call Trace: Jul 1 10:42:43 smb0 kernel: [schedule+1687/1744] schedule+0x697/0x6d0 Jul 1 10:42:43 smb0 kernel: [<c011cb37>] schedule+0x697/0x6d0 Jul 1 10:42:43 smb0 kernel: [schedule_timeout+86/176] schedule_timeout+0x56/0xb0 Jul 1 10:42:43 smb0 kernel: [<c01268e6>] schedule_timeout+0x56/0xb0 Jul 1 10:42:43 smb0 kernel: [process_timeout+0/16] process_timeout+0x0/0x10 Jul 1 10:42:43 smb0 kernel: [<c01260e0>] process_timeout+0x0/0x10 Jul 1 10:42:43 smb0 kernel: [ide_pin_hwgroup+52/96] ide_pin_hwgroup+0x34/0x60 Jul 1 10:42:43 smb0 kernel: [<c0243884>] ide_pin_hwgroup+0x34/0x60 Jul 1 10:42:43 smb0 kernel: [ide_set_xfer_rate+12/80] ide_set_xfer_rate+0xc/0x50 Jul 1 10:42:43 smb0 kernel: [<c0246b4c>] ide_set_xfer_rate+0xc/0x50 Jul 1 10:42:43 smb0 kernel: [check_dma_crc+46/80] check_dma_crc+0x2e/0x50 Jul 1 10:42:43 smb0 kernel: [<c024595e>] check_dma_crc+0x2e/0x50 Jul 1 10:42:43 smb0 kernel: [do_reset1+76/384] do_reset1+0x4c/0x180 Jul 1 10:42:43 smb0 kernel: [<c0245b2c>] do_reset1+0x4c/0x180 Jul 1 10:42:43 smb0 kernel: [idedisk_error+487/496] idedisk_error+0x1e7/0x1f0 Jul 1 10:42:43 smb0 kernel: [<c024ff07>] idedisk_error+0x1e7/0x1f0 Jul 1 10:42:43 smb0 kernel: [do_signal+1163/1488] do_signal+0x48b/0x5d0 Jul 1 10:42:43 smb0 kernel: [<c01075db>] do_signal+0x48b/0x5d0 Jul 1 10:42:43 smb0 kernel: [convert_fxsr_from_user+21/240] convert_fxsr_from_user+0x15/0xf0 Jul 1 10:42:43 smb0 kernel: [<c010ed45>] convert_fxsr_from_user+0x15/0xf0 Jul 1 10:42:43 smb0 kernel: [ide_dma_intr+120/128] ide_dma_intr+0x78/0x80 Jul 1 10:42:43 smb0 kernel: [<c024bc98>] ide_dma_intr+0x78/0x80 Jul 1 10:42:43 smb0 kernel: [ide_intr+256/400] ide_intr+0x100/0x190 Jul 1 10:42:43 smb0 kernel: [<c0244a00>] ide_intr+0x100/0x190 Jul 1 10:42:43 smb0 kernel: [ide_dma_intr+0/128] ide_dma_intr+0x0/0x80 Jul 1 10:42:43 smb0 kernel: [<c024bc20>] ide_dma_intr+0x0/0x80 Jul 1 10:42:43 smb0 kernel: [handle_IRQ_event+47/96] handle_IRQ_event+0x2f/0x60 Jul 1 10:42:43 smb0 kernel: [<c010a79f>] handle_IRQ_event+0x2f/0x60 Jul 1 10:42:43 smb0 kernel: [do_IRQ+136/416] do_IRQ+0x88/0x1a0 Jul 1 10:42:43 smb0 kernel: [<c010a858>] do_IRQ+0x88/0x1a0 Jul 1 10:42:43 smb0 kernel: [common_interrupt+24/32] common_interrupt+0x18/0x20 Jul 1 10:42:43 smb0 kernel: [<c0108d48>] common_interrupt+0x18/0x20 Jul 1 10:42:43 smb0 kernel: Jul 1 10:42:43 smb0 kernel: bad: scheduling while atomic! Jul 1 10:42:43 smb0 kernel: Call Trace: Jul 1 10:42:43 smb0 kernel: [schedule+1687/1744] schedule+0x697/0x6d0 Jul 1 10:42:43 smb0 kernel: [<c011cb37>] schedule+0x697/0x6d0 Jul 1 10:42:43 smb0 kernel: [schedule_timeout+86/176] schedule_timeout+0x56/0xb0 Jul 1 10:42:43 smb0 kernel: [<c01268e6>] schedule_timeout+0x56/0xb0 Jul 1 10:42:43 smb0 kernel: [process_timeout+0/16] process_timeout+0x0/0x10 Jul 1 10:42:43 smb0 kernel: [<c01260e0>] process_timeout+0x0/0x10 Jul 1 10:42:43 smb0 kernel: [ide_pin_hwgroup+52/96] ide_pin_hwgroup+0x34/0x60 Jul 1 10:42:43 smb0 kernel: [<c0243884>] ide_pin_hwgroup+0x34/0x60 Jul 1 10:42:43 smb0 kernel: [ide_set_xfer_rate+12/80] ide_set_xfer_rate+0xc/0x50 Jul 1 10:42:43 smb0 kernel: [<c0246b4c>] ide_set_xfer_rate+0xc/0x50 and so on .....

2 1

Latest Tripwire Update Borked
by suse＠rio.vg 02 Jul '04

02 Jul '04

Just like the first release of tripwire for SuSE 9.0, the recent security update, 2.3.1-184 segfaults. [ root@shadow ] ~# rpm -q tripwire tripwire-2.3.1-184 [ root@shadow ] ~# tripwire --check Parsing policy file: /etc/tripwire/tw.pol *** Processing Unix File System *** Performing integrity check... Software interrupt forced exit: Segmentation Fault Abort I get the same results on two separate machines, one 2x/P2-333 and one P4-1.7. Both systems had been using the previous version of tripwire without any problems, and both are running 9.0. (I haven't purchased 9.1 due to issues I have with th 2.6 kernel that are outside SuSE's control) I am not going to update any of my production servers with this borked version of tripwire, so those are the only two systems tested.

1 1

Strange log: apache succesfull access
by Manuel Balderrábano 02 Jul '04

02 Jul '04

Hi, list. I have just seen this strange entrys in my apache logs: ... 203.86.166.95 - - [29/Jun/2004:03:45:42 +0200] "CONNECT 205.158.62.146:25 HTTP/1.0" 200 8307 203.86.166.95 - - [29/Jun/2004:03:45:55 +0200] "PUT http://205.158.62.146:25/ HTTP/1.0" 200 8307 203.86.166.95 - - [29/Jun/2004:03:45:56 +0200] "POST http://205.158.62.146:25/ HTTP/1.0" 200 8307 217.34.125.65 - - [29/Jun/2004:19:10:27 +0200] "CONNECT 1.3.3.7:1337 HTTP/1.0" 200 8307 ... 213.4.22.177 - - [30/Jun/2004:21:05:44 +0200] "POST http://194.224.58.61:25/ HTTP/1.0" 200 8307 213.4.22.177 - - [30/Jun/2004:21:56:04 +0200] "PUT http://194.224.58.61:25/ HTTP/1.0" 200 8307 They were all succesfull!!!! My snort logs did not detect anything strange, wich seems logical, since they are just smtp accesses. Is anyone using my web server to send spam? Thanks. -- --------------------------------------------------------------------------------- Manuel Balderrábano e-mail: garibolo(a)wanadoo.es ---------------------------------------------------------------------------------

2 1