headers
Alex Pelts | 12 Sep 2006 23:33
Favicon

Interesting security discovery.

Hi,
I was trying to improve on my banhosts utility and while searching for 
possible features I found this page 
http://tdot.blog-city.com/securing_ssh_with_denyhosts.htm

Spawning of deny hosts from hosts.deny is interesting. So I was trying 
to experiment and spawned "sleep 20" command. By accident I forgot to 
remove it and later checking my logs I found that no breakin attempts 
were made. I had several ports scanning attempts but no breakin attempts 
after.

Having this command in tcp wrappers file delays prompt by 20 seconds and 
I guess automated scripts timeout before getting the prompt. I think I 
will leave this command in my file just to see how many attempts I would 
get.

This solution maybe not appropriate for hosts with high number of ssh 
users but for http/ftp/game servers it will make password guessing very 
time consuming.

Any opinions?

Thanks,
Alex
Permalink | Reply | 1 comment |
headers
Hubert Feyrer | 13 Sep 2006 10:07
Picon
Favicon

Re: Interesting security discovery.

On Tue, 12 Sep 2006, Alex Pelts wrote:
> Any opinions?

This doesn't seem to be specific to the Cobalt port, and may
be better be posted to tech-security <at> NetBSD.org for proper focus & 
feedback.

  - Hubert
Permalink | Reply | 0 comments |
headers
Brian McEwen | 13 Sep 2006 20:59
Picon

nut-ups or other UPS monitoring package


Anyone built ups-nut (is there another ups-monitoring util?) lately?   
I read on netbsd-users that the pkgsrsc version was not right and the  
util was built from outside code, recently.

I have a NEC chipset card which I think will work OK in the Qube 2,  
but I have no reason to install it other than to talk with a UPS.

I just build ups-nut and ups-nut-usb fine; but can't see anything  
anywhere in the system that say how to run it/them; and the .sh.  
files aren't commented, at least the ones I saw.  So I'm not sue this  
is something I want to mess with after all, but it would be a good  
capability to have working.

Thanks--

Brian
Permalink | Reply | 0 comments |
headers
bmcewen | 13 Sep 2006 21:20
Picon

Re: nut-ups or other UPS monitoring package


 -------------- Original message ----------------------
From: Brian McEwen <bmcewen <at> comcast.net>
> 
> Anyone built ups-nut (is there another ups-monitoring util?) lately?   
> I read on netbsd-users that the pkgsrsc version was not right and the  
> util was built from outside code, recently.
> 
> I have a NEC chipset card which I think will work OK in the Qube 2,  
> but I have no reason to install it other than to talk with a UPS.

Actually, the UPS I have spare are APCs, and I found apcupsd, which does have some man pages and docs.  Great.

If anyone can confirm it is working nicely with their gear that would be a big plus.

thanks!

Brian
Permalink | Reply | 0 comments |
headers
KIYOHARA Takashi | 19 Sep 2006 20:08
Picon

sharing IRQ

Hi! tsutsui-san,

My Qube2 panicing when boot time since May 31 2006.  Because that has
shared IRQs at PCI-card.  However current icu_intr_establish() denied
sharing IRQs.  (However, I feel old icu_intr_establish() strange... ;-)

    http://mail-index.netbsd.org/port-cobalt/2004/01/10/0001.html

    e.g.
      uhci2: interrupting at irq 0
      ehci0: interrupting at irq 0
      fwohci0: interrupting at irq 0

I was very embarrassed.  X-<

Have you any idea.  ;-)

Thanks,
--
kiyohara
Permalink | Reply | 2 comments |
headers
Izumi Tsutsui | 20 Sep 2006 11:07
Picon
Gravatar

Re: sharing IRQ

kiyohara <at> kk.iij4u.or.jp wrote:

> My Qube2 panicing when boot time since May 31 2006.  Because that has
> shared IRQs at PCI-card.  However current icu_intr_establish() denied
> sharing IRQs.  (However, I feel old icu_intr_establish() strange... ;-)

It should be trivial to implement shared IRQ support on ICU (aka PIC).
Just prepare a intrtab LIST and check IST types on the intr_establish()
function like sys/arch/algor/pci/pcib.c does.

But I didn't implement it because I was not sure it was
really required on any cobalt machines.

>       uhci2: interrupting at irq 0
>       ehci0: interrupting at irq 0
>       fwohci0: interrupting at irq 0

All these devices are behind the PCI-PCI bridge, but
what interrupt PINs (A-D) are used for their interrupts?
"irq 0" just means "invalid," which is returned from
current sys/arch/cobalt/pci/pci_machdep.c:pci_intr_map().
It just returns "line" values, but I don't think these
values for PIN B-D are initilized properly by the firmware,
nor pci_conf_interrupt().

So, before implemente shared IRQ support code, we should
know hardware specification around cobalt PCI, i.e.
we should know which IRQ pins each PIN A-D lines are
connected to. If each PIN A-D lines of the PCI slot
are connected to independent ICU irq pins, we don't
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alex Pelts | 23 Sep 2006 19:33
Favicon

Bug in the kernel

There is a bug in the kernel which I believe is caused by heavy network 
traffic. Not even so much heavy as concurrent. I usually have few http 
connections going when kernel panics. The connections must be from 
different IP addresses or the panic does not happen.  The qube is 
serving http over dsl line so the traffic itself is not heavy. It seems 
to go away from build to build and latest build I did on Sep 17 has the 
problem.
I just did cvs update and it seems that sources did not change since sep 
17. Could someone tell me if kernel can drop in the debugger on trap? I 
could not make that work. I can investigate further next time it 
happens. Below are the lines that cause the panic along with the date of 
build and cvs update.

Thanks,
Alex

NetBSD 3.1_RC3 (SERVER) #14: Sun Sep 17 15:43:17 UTC 2006

panic: lockmgr: no context
syncing disks... 1 1 trap: TLB miss (load or instr. fetch) in kernel mode
status=0xa403, cause=0x8, epc=0x8016d9ec, vaddr=0xcb4d4000
curlwp == NULL ksp=0xcb48f0e0
panic: trap
Permalink | Reply | 1 comment |
headers
KIYOHARA Takashi | 24 Sep 2006 02:26
Picon

dangerous for initialize of MIPS timer

Hi! all,

I think serious dangerous for initialization of MIPS timer.  My Cobalt
Qube panic() in hardclock().  It reason for hardclock() is called before
softclock is initialized. 

sys/arch/MACHINE/MACHINE/autoconf.c::cpu_configure() call _splnone().
_splnone() set to enable all interrupt.  However softclock_si not
initialized yet.  That is after initialize in sys/kern/kern_clock.c::
initclock().  

Thanks,
--
kiyohara
Permalink | Reply | 16 comments |
headers
Izumi Tsutsui | 24 Sep 2006 02:52
Picon
Gravatar

Re: dangerous for initialize of MIPS timer

kiyohara <at> kk.iij4u.or.jp wrote:

> I think serious dangerous for initialization of MIPS timer.  My Cobalt
> Qube panic() in hardclock().  It reason for hardclock() is called before
> softclock is initialized. 

Yes, it could happen on my RaQ2 while it would be some timing dependent.

Maybe we should move _splnone() from autoconf.c:cpu_configure() to
mips/mips3_clockintr():cpu_initclocks(), but I wonder
we should still enable other interrupts than INT5 in
cpu_configure() or not. (since initclocks() is called
right after cpu_configure() in subr_autoconf.c).
---
Izumi Tsutsui
Permalink | Reply | 14 comments |
headers
Izumi Tsutsui | 24 Sep 2006 04:52
Picon
Gravatar

Re: Bug in the kernel

alexp <at> broadcom.com wrote:

> I just did cvs update and it seems that sources did not change since sep 
> 17. Could someone tell me if kernel can drop in the debugger on trap? I 
> could not make that work. I can investigate further next time it 
> happens. Below are the lines that cause the panic along with the date of 
> build and cvs update.

Does you kernel have options DDB and options SOSEND_NO_LOAN?
Could you get some more info with options DIAGNOSTIC?

Anyway, trying GENERIC is worth to narrow down the problem.
---
Izumi Tsutsui
Permalink | Reply | 0 comments |

Gmane