Posts Tagged ‘security’

Windows-Update and Proxies

Tuesday, April 7th, 2009

After a discussion on IRCnet, I decided this topic might be worth a blog-post: How do I get Windows Update on Windows XP Home to work with proxies?

Windows XP Professional seems to accept the Administrator's Proxy-Settings automagically, but Windows XP Home doesn't. If you have a network that only permits HTTP-Access through a configured proxy, you have a problem: Windows XP Home won't update, because it attempts a direct connection to Microsoft's servers.

My own setup at home is like this: I have a Cisco C836 Router, which ACL's prohibit any traffic not coming from the proxyhost, or being from certain selected reserved protocols. The proxyhost is a NetBSD 5.0 RC3 Box (see this page and this post), running a Squid 3.0 Web-Proxy.  Since I needed to update my XP-Home-running NetBook, I found a simple solution to this problem some time ago: each Windows comes with a small tool named "proxycfg". All you need to do is call it appropriately, and even Windows XP will update through the proxy like a charm.

This is the help-output from proxycfg:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\>proxycfg -?
Microsoft (R) WinHTTP Default Proxy Configuration Tool
Copyright (c) Microsoft Corporation. All rights reserved.

usage:

    proxycfg -?  : to view help information

    proxycfg     : to view current WinHTTP proxy settings

    proxycfg [-d] [-p <server-name> [<bypass-list>]]

        -d : set direct access
        -p : set proxy server(s), and optional bypass list

    proxycfg -u  : import proxy settings from current user's
                   Microsoft Internet Explorer manual settings
                   (in HKCU)

C:\>

If you have configured the Internet Explorer to use the proxy, you can simply call

 C:\> proxycfg -u

And the settings will be used. If you don't have the IE configured (which is a wise decision if you don't use it), you need to specify the proxy using the -p switch. In my case, this would look like this:

 C:\> proxycfg -p http://proxy.home.nifelheim.info:3128

After this, Windows Update will use these settings and you can update your machine.

Tags: , , , , , , , , ,
Posted in Configuration, Microsoft, Windows Update, XP, computer, connection, firewall, internet, network, operating system, proxy, update, windows | No Comments »

Nidhoegg: Updating a Security Host to NetBSD 5.0 RC3

Monday, April 6th, 2009

My network at home is secured against attacks from outside (and inside as well) by a strict set of ACLs within my Cisco C836 Router, and a SUN Ultra-5 serving as a proxy-host for several protocols. Until recently, this Machine was running a NetBSD 3.0.1 Userland with a self-compiled 3.1RC2 Kernel. It's pkgsrc-installed applications were also just as outdated, and so I decided to upgrade the whole box.

Usually, when computers engaged in securing your networks are to be upgraded, one goes for stability, security and definitely not for the newest OS-Version. In this case though, because of "RC" in NetBSD does not mean "development" (that would be "-current"), and because NetBSD 5.0 has certain features NetBSD 4.0.1 does not have, i.e. wapbl, I decided to really go and try NetBSD 5.0RC3. Following is a report about how the upgrade-process worked out...  :)

The Upgrade

Installing NetBSD 5.0RC3

I downloaded the bootable ISO-image from a french mirror-server, because either I was too blind, or the german mirrors currently do not have NetBSD-daily-images. After burning the image onto a CD, making some final backups, and sending a small prayer to /dev/null, the almighty Computer-God, I rebooted the machine. Starting from CD on a SPARC-box is usually as easy as nothing else. After System-Initialization (a.k.a POST on PCs), simply press Stop-A, and at the OK-Prompt enter

OK> boot cdrom

This time, however, the system told me that there was a problem reading the device. I remembered having had problems with the concurrent use of CD-ROM and Harddisk, and opened the Ultra-5. As I remembered, the CD-ROM-Drive was unplugged. I reattached it, and voila, now it worked.

So I ran the installer, partitioned my 8GB Harddisk in a single partition using FFSv2 with the option "log" enabled. This option was introduced by the wapbl-driver donated from Wasabi Systems Inc., and significantly improved by the NetBSD-developers. It provides a journalling filesystem on top of FFSv2, and improves the overall-performance of the filesystem as well. What I was ignorant of at this time of the process was the fact that the sparc64-port of NetBSD does not boot from FFSv2, because it has some issues with the different superblocks of FFSv2. Because I did not notice the culprit to be FFSv2, I tried several things, before finally using FFSv1 for the root-partition ("/"), and splitting up the partitions like this:

Filesystem        Size  Mounted on
/dev/wd0a         1.0G  /
/dev/wd0d         2.4G  /var
/dev/wd0g         2.9G  /usr
/dev/wd0e         482M  /home
mfs:165            62M  /tmp
/dev/wd1d          28G  /data

All partitions (except /tmp and / ) are using FFv2/wabbl (option log). The drive wd1 was added later after the installation process was finished and the CD-ROM drive was unplugged again. It's partition wd1d is using FFSv2 with wapbl, too, of course. :)

I added the log-option to the root-partition using FFSv1, too, just as a test.  mount(8) tells me, it is using the option, though I can hardly imagine that. wapbl(4) states about FFSv1 and the log-options this:

WAPBL requires the super block to be in the UFS2 format. Older FFSv1 file systems will need to be updated to the newer super block layout with the -c option to fsck_ffs(8).

Since I definitely did not update the superblocks (remember the booting-issue), and the machine definitely is booting now, I don't trust mount(8)'s output in this regard anymore, and have changed the option for the root-partition from log to softdep.

Note: log and softdep are mutual exclusive and lead in RC3 to a kernel-trap, though the kernel claims to ignore softdep. I have already submitted a problem report regarding this issue (kern/41161).

Configuring and Installing Packages

Now after the installation was completed, I started to download the pkgsrc-current tarball, again from the french-server since the german servers do not seem to mirror them as well. After untarring pkgsrc into /data, I set some CFLAGS, since I like to squeeze out every bit of performance available, as long as it does not break the system. My CFLAGS on the Ultra-5 look like this:

CFLAGS=-mcpu=ultrasparc -mtune=ultrasparc -m64 -mvis -O3 \
       -funroll-loops -fomit-frame-pointer

Of course the CXXFLAGS are equal to CFLAGS. :)

Now I bootstrapped pkgsrc (I know that on NetBSD this is not necessary, but out of a habit, and because the mk.conf is automatically generated and the tools are compiled with the above CFLAGS as well, I do it. It's a matter of taste, and according to some people probably of waste (of time) as well, but I don't mind :) ). Parallel to the bootstrapping, I configured the DHCP-, NTP- and SSH-server that came with NetBSD-base and launched them, so that those were already up and running again.

After that was done, I started installing the services I required:

  • misc/screen
  • net/bind9 - name-server
  • net/dante - socks-proxy
  • www/squid30 - webproxy
  • www/adzap - advertisement-zapper for squid
  • net/ra-rtsp-proxy - real-audio rtsp-proxy

With screen installed, I left the machine to itself and changed into the more comfortable living-room and my laptop. I ssh'ed to nidhoegg, launched screen, and continued from there with installing the apps in the list above. ntpd and named9 are running chrooted, btw.

I mentioned www/adzap in the list above, a squid-redirector I came to love over the last years while using squid 2.x . Sadly, it is incompatible to squid 3.0, obviously because the way squid talks to its redirectors has changed significantly. May be, if I find the time, I will look into this, and patch it so that is work with squid 3.0, too. Currently, adzap is not in use anymore, because the adzap-processes were dying so fast that browsing was impossible.

But before I could use the squid at all, I had to build my own NetBSD-kernel. Why, you might ask. The answer is simple: because I use diskd as storage-method, and diskd requires the following options set in the kernel, which aren't in GENERIC:

options         SYSVMSG         # System V-like message queues
options         SYSVSEM         # System V-like semaphores
options         SYSVSHM         # System V-like memory sharing

options         SHMMAXPGS=8192
options         MSGMNB=16384
options         MSGSSZ=64
options         MSGTQL=512

Ok, since NetBSD 4.99.35 this could be set through sysctl(8) and the kern.ipc.* variables, but I was not aware of that before writing this post. And besides, it was a good test / experiment to cross-compile a SPARC64-Kernel on an x86-System (I used my primergy-monster to compile the kernel). The kernel was build in about half an hour. Here is the report:

===> Summary of results:
         build.sh command: ./build.sh -m sparc64 -u -N 2 -U   \
                -T obj.sparc64/tooldir -D obj.sparc64/destdir \
                -R obj.sparc64/releasedir -V OBJMACHINE=1 -j8 \
                kernel=NIDHOEGG
         build.sh started: Sun Apr  5 18:16:21 CEST 2009
         NetBSD version:  5.0_RC3
         MACHINE:         sparc64
         MACHINE_ARCH:    sparc64
         Build platform:  NetBSD 4.0 i386
         HOST_SH:         /bin/sh
         TOOLDIR path:    /usr/build/src/obj.sparc64/tooldir
         DESTDIR path:    /usr/build/src/obj.sparc64/destdir
         RELEASEDIR path: /usr/build/src/obj.sparc64/releasedir
         makewrapper:     /usr/build/src/obj.sparc64/tooldir/
                                           bin/nbmake-sparc64
         Updated /usr/build/src/obj.sparc64/tooldir/bin/
                                          nbmake-sparc64
         Building kernel without building new tools
         Building kernel:  NIDHOEGG
         Build directory:  /usr/build/src/sys/arch/sparc64/
                               compile/obj.sparc64/NIDHOEGG
         Kernels built from NIDHOEGG:
          /usr/build/src/sys/arch/sparc64/compile/
                       obj.sparc64/NIDHOEGG/netbsd
         build.sh ended:   Sun Apr  5 18:42:30 CEST 2009
===> .

Of course the building of the toolchain is not included in this report, it's solely the kernel. I forgot to log how long that took, but from experiences with earlier NetBSD 5.0 builds (though for x86-platform), I can say that is usually takes about an hour.

The compilation went through without incident, and the kernel booted like a charm.

Squid was started and after the adzap-issue was identified and the adzap-call was removed from squid's configuration, all worked fine.

Conclusion

All in all it was a smooth process. The small problems that came up were quickly solved, some of them were caused by me being tired and inattentive, others because I had to learn that things do not always work as I wished them to (e.g. booting from FFSv2 and squid-3.0/adzap).

Since sunday, nidhoegg is running stable and fast, and yes, while copying files between disks, I do really think that wapbl's performance-improvements are recognizable. I copied several large files, and though I did not have measured the time, it felt way faster than on FFSv1, which was used on nidhoegg while running NetBSD 3.1RC2.

For all interest in the dmesg-output, read nidhoegg's page.

Tags: , , , , , , , , , , , , , , , , , ,
Posted in BSD, FFS, Kernel, NetBSD 5.0RC3, SPARC, SPARC64, SPARCstation, Sun, Ultra 5, computer, firewall, netbsd, network, opensource, operating system, pkgsrc, server, update, upgrade, wapbl | No Comments »

Hardening Sendmail - supplement

Tuesday, March 31st, 2009

In my last post I wrote about hardening sendmail against DDoS-Attacks. As someone has pointed out to me, I have missed an important option:

define(`confMAX_DAEMON_CHILDREN', `count')dnl

This option defines the maximum number of sendmail-processes allowed, before sendmail start rejecting incoming connections with a temporary error.

count should be chosen with great care. I recommend to check the average number of sendmail-processes per second on a "standard" day, and triple that number. This way, you ensure that even in peak-times you will have a high enough limit, but in case of real trouble the number of processes won't explode, and the machine will remain operable.

Example: If you have an average of 20 concurrent sendmail-processes, set count to 60.  I would never recommend a value below 30, though.

Tags: , , , , , ,
Posted in Configuration, DDoS, denial-of-service, distributed denial-of-service, hardening, mail-server, security, sendmail, server | No Comments »

Hardening Sendmail against DDoS

Sunday, March 29th, 2009

For some time now, I was experiencing a strange behavior of my server: from time to time, without an ascertainable pattern, the server would stop reacting to network-requests. The teamspeak-server, which runs on it, would kick anyone connected to it, and nothing particular special could be found in the logs. When this happened last Thursday, and I was kicked out of the teamspeak-server myself, I tried to ssh onto my server - which took about 30 seconds. This was irritating, and I run "uptime" to check the server's load - it was way beyond 70. The next thing was a call to top, and here I saw the culprit: sendmail. A call to ps verified the sendmail was running with way too many processes, all in "RCPT TO:" state or something similar. I stopped sendmail and killed remaining processes manually, so that I could work again in real time. Looking through maillog, I began to understand what going on: spammers were DDoSing my mail-server. Though I already had some settings in my sendmail.mc that would make the server unattractive for spammers, they were obviously not sufficient, and especially not against DDoS-attacks. So I changed my configuration a bit.

Connection Controlling

FEATURE(`access_db')dnl
FEATURE(`delay_checks', `friend')dnl
FEATURE(`ratecontrol', `nodelay',`terminate')dnl
FEATURE(`conncontrol', `nodelay',`terminate')dnl

After the already existing line "FEATURE(`access_db')dnl" I added the lines to enable rate and connection-controlling.

The option "nodelay" is important, because I am using the delay-checks-feature, and these checks are not to be delayed.

The "terminate"-option tells sendmail to kill all connections exceeding the later defined limits with a temporary error-message. The properly configured and standard-compliant smtp-client will try again later, spammers usually don't.

The rate-control feature enables control over how often a single host is allowed to connect per a defined window. It was introduce by sendmail version 8.13.0, and uses the access.db for defining the limits for single hosts, groups of hosts or all hosts.

The window-size is defined using the this option:

define(`confCONNECTION_RATE_WINDOW_SIZE',`window')dnl

with a default-value for window of "60s" (60 seconds).

My access.db-entries for the rate-control-feature look like this:

ClientRate:localhost                    0
ClientRate:localhost.localdomain        0
ClientRate:127.0.0.1                    0
ClientRate:                             5

The first three lines tell sendmail to ingore rate-limits for the localhost, and the last line imposes a limit of 5 connections per window for all hosts.

In cases of a DDoS, it might not be sufficient to limit the connections of a single host per minute, because a DDoS comes from multiple hosts at the same time. This is why Sendmail come with another option:

define(`confCONNECTION_RATE_THROTTLE', `5')dnl

This defines the overall number of concurrent connection the server accepts per second, before queuing incoming connection-request regardless of the host. The connections will not be rejected but stalled until the next second. This means that for the above example that when 20 connection-requests arrive, the first five (1-5) are processed in second one, the second five (6-10) in second two, the third five (11-15) in second three, and the final five (16-20) in second four.

The conn-control feature enables control over the number of concurrent connections a single host is allowed to run simultaneously. Like rate-control, this feature was introduced with Sendmail 8.13, and the access.db is used to define settings for single-hosts, host-ranges and "all hosts", too.

My access.db-entries for the conn-control-feature look like this:

ClientConn:localhost                    0
ClientConn:localhost.localdomain        0
ClientConn:127.0.0.1                    0
ClientConn:                             3

The entries are read similar to rate-control. The last line defines a default of 3 concurrent connections, the first three disable the feature for localhost.

Greeting Pause

A common technique of spammers, trojans and viruses is the so-called slamming. The SMTP-Standard requires the client to wait with the HELO/EHLO-Command until the server has sent its greeting line. Slamming is to ignore this, and to start sending immediately.

FEATURE(`greet_pause', `2000')dnl

With the above feature, Sendmail can be configured to delay the sending of this greeting. The value is in milliseconds, so in the example above, the greeting-pause would be two seconds. A client issuing the HELO/EHLO during this pause will cause Sendmail to answer with

554 smtp.nifelhei.info not accepting messages

and the greeting will not be send. Sendmail will log such attempts with a message like

rejecting messages from <host> due to pre-greeting traffic.

and terminate the connection.

You can use the access.db again to define host-specific greeting-pause times, or to exclude certain hosts from the pause. The following example would exclude localhost from the delay. You can use this to whitelist smtp-servers who do slamming but are otherwise "friendly".

GreetPause:localhost                    0
GreetPause:localhost.localdomain        0
GreetPause:127.0.0.1                    0

Please note:

RFC 2821 specifies 5 minutes as the maximum timeout for the initial connection greeting. Therefore, if you specify a time longer than 300000 milliseconds (i.e. 5 minutes), sendmail will not wait longer than 5 minutes, to maintain RFC compliance.

Recipient-Controlling

After setting up the controlling mechanisms for incoming connections, there is a another level of control that can be applied. Many spammers try to send a single mail with hundreds of recipients. This is also known as "recipient flooding". Sendmail can be configured to limit the number of recipients a message may have, as well throttling down all those clients who try to add more recipient than a certain threshold by pausing a hardcoded full second between each accepted recipient. The options are as follows:

define(`confBAD_RCPT_THROTTLE', `2')dnl
define(`confMAX_RCPTS_PER_MESSAGE', `25')dnl

BAD_RCPT_THROTTLE sets the threshold which invokes the one-second-delay. For the example above this means that with the third RCPT TO: sendmail will pause one full second, before sending the response.

MAX_RCPTS_PER_MESSAGE limits the absolute maximum number of recipients for each message to the value given (25 for the above example). Every RCPT TO: exceeding this number will be rejected with an appropriate message. The standard-compliant server will collect the rejected RCPT TOs and requeue the message for all yet outstanding recipients. (Yes, spammers won't.)

Timeouts

Sendmail, in order to get as many as possible mails through, has very generous timeout-defaults. These values are often measured in days, where today seconds or minutes would suffice. Long timeouts mean long bound resources for probably unsolicited connections. I have defined much shorter values for several timeouts:

define(`confTO_INITIAL', `30s')dnl
define(`confTO_CONNECT', `30s')dnl
define(`confTO_ACONNECT', `1m')dnl
define(`confTO_ICONNECT', `30s')dnl
define(`confTO_HELO', `30s')dnl
define(`confTO_MAIL', `30s')dnl
define(`confTO_RCPT', `30s')dnl
define(`confTO_DATAINIT', `1m')dnl
define(`confTO_DATABLOCK', `1m')dnl
define(`confTO_DATAFINAL', `1m')dnl
define(`confTO_RSET', `30s')dnl
define(`confTO_QUIT', `30s')dnl
define(`confTO_MISC', `30s')dnl
define(`confTO_COMMAND', `30s')dnl
define(`confTO_CONTROL', `30s')dnl
define(`confTO_LHLO', `30s')dnl
define(`confTO_AUTH', `30s')dnl
define(`confTO_STARTTLS', `30s')dnl

I won't go into much detail about each timeout, because that would be beyond the scope of this posting, but these values are much more reasonable than the defaults.

Other means of protecting your server agains spammers:

TCPWrappers

Besides everything sendmail can be configured to do and not to do, sendmail has another advantage: It can be compiled to use TCP Wrapper.

While scanning the logs for the causes of the astronomous load, I noticed millions of attempts from hosts of dial-in providers, which usually strongly indicates spam-bot afflicted private hosts.

I have added theses networks to my /etc/hosts.deny file, with the effect that the number of connections to the server was reduced almost immediately. While one might ask for the wisdom of blocking whole networks, think about this: by what necessity does a private dial-in host have to have its own smtp-server attempting to connect to your smtp-server? Usually, a private person can use the mail-server of his/her provider,  and that one won't be blocked, because I am blocking the dial-in-subnets specifically.

Here is the current (March 29, 2009) list of blocked networks:

sendmail: .adsl.alicedsl.de
sendmail: .tukw.qwest.net
sendmail: .internetdsl.tpnet.pl
sendmail: .dynamicIP.rima-tde.net
sendmail: .staticIP.rima-tde.net
sendmail: .home.otenet.gr
sendmail: .pppoe.mtu-net.ru
sendmail: .static.link.com.eg
sendmail: .adsl-1.sezampro.yu
sendmail: .speedy.telkom.net.id
sendmail: .pool.ukrtel.net
sendmail: .taiwanmobile.net
sendmail: .veloxzone.com.br
sendmail: .bielskpodlaski.mm.pl
sendmail: .bb-static.vsnl.net.in
sendmail: .dynamic.163data.com.cn
sendmail: .vsnl.net.in
sendmail: .adsl.tpnet.pl
sendmail: .airtelbroadband.in
sendmail: .ip.adsl.hu
sendmail: .tktelekom.pl
sendmail: .radiocom.ro
sendmail: .static.asianet.co.th
sendmail: .static.versatel.nl
sendmail: .dsl.telesp.net.br
sendmail: .cable.telstraclear.net
sendmail: .bb.netvision.net.il
sendmail: .ip.fastwebnet.it
sendmail: .pppoe.avangarddsl.ru
sendmail: .adsl.proxad.net
sendmail: .adsl.sta.mcn.ru
sendmail: .adsl.paltel.net
sendmail: .iam.net.ma
sendmail: .mobile.playmobile.pl
sendmail: .broadband3.iol.cz
sendmail: .business.telecomitalia.it
sendmail: .sonora.tx.cebridge.net
sendmail: .3g.claro.net.br
sendmail: .wi.res.rr.com
sendmail: .mtnl.net.in
sendmail: .static.gvt.net.br
sendmail: .dynamic.orange.es
sendmail: .ttnet.net.tr
sendmail: .ip.cybergrota.com.pl
sendmail: .static.user.ono.com
sendmail: .dsl.brasiltelecom.net.br
sendmail: .bk21-dsl.surnet.cl

Conclusion

After changing the configuration using the above described possibilities, the load of the sever decreased enormously, and there are far less sendmail-processes now running at the same time, thus binding far less resources. DDoS-spam-attacks are still not impossible, but they will have a harder time to get the machine down now. :)

Tags: , , , , , ,
Posted in Configuration, DDoS, denial-of-service, distributed denial-of-service, hardening, mail-server, security, sendmail, server | 5 Comments »

My Cisco-Router

Tuesday, March 10th, 2009

For a really long time, I was a convinced user of a linux-firewall with quite a complex (other people might say "unnecessary paranoid") ip-tables setup. Then, some days ago, initiated by the rather primitive and really stupid attempt to take over my DynDNS.org-Account and hack into my network by probably some neonazi-scum-folks, I felt obliged to harden and tighten security and update the firewall from debian sarge to debian lenny.

Uh-oh, you might say, grave mistake.

Yes, I reply, you are damn right. It was a grave mistake. The update broke my kernel-setup, by installing the new kernel, but only half. It broke my libs by installing the libs required by the kernel (that's why the kernel-update broke in the first place), because the libs required the kernel, and it broke my MBR by updating lilo - again, only half.

Yes, now I know that there's an update-howto around, and no, I haven't read it before. Anyway, as long the computer would not reboot, everything continued to work.

For about a year now, I had a Cisco 836 lying in a shelf, waiting to be used. I took the misery of the firewall as a possibility, and activated the router. I am a Cisco-Newby, have never seen a Cisco-device from the inside before. Those of you, who have worked with Ciscos before, know, what that means. Luckily, I am a connected modern person of the 21st century, the age of information, and since I am on several IRC-Networks (especially IRCnet itself), I found two friendly guys who helped me quite some hours to get the machine working.

Now it is up and running, has been nmapped by myself and a friend, and I am quite satisfied with the result: nmap showed less information with the new router than with the linux-firewall before. This I consider a great success.

Here's some information about the router:

Cisco IOS Software, C836 Software (C836-K9O3S8Y6-M), Version 12.4(23), RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Sun 09-Nov-08 07:02 by prod_rel_team

ROM: System Bootstrap, Version 12.2(11r)YV3, RELEASE SOFTWARE (fc2)

muspell uptime is 2 days, 1 hour, 42 minutes
System returned to ROM by power-on
System restarted at 20:32:50 MET Sun Mar 8 2009
Cisco C836 (MPC857T) processor (revision 0x300) with 62260K/3276K bytes of memory.
Processor board ID FCZ092442LG (2286254431), with hardware revision 0000
CPU rev number 7
2 Ethernet interfaces
4 FastEthernet interfaces
1 ISDN Basic Rate interface
1 ATM interface
128K bytes of NVRAM.
12288K bytes of processor board System flash (Read/Write)
2048K bytes of processor board Web flash (Read/Write)

I was able to rebuild the iptables-setup with the ACLs in the router, of course only the already mentioned help. I will post them and examples for easier scenarios over the next days each in an own posting.

Tags: , , , , , , , , , ,
Posted in C836, Cisco, Debian, Linux, Router, firewall, hardware, lenny, sarge, security, update | No Comments »

Future prospects: Plans for NetBSD 5.0

Friday, October 31st, 2008

In his latest mail to the netbsd-announcement mailinglist, Alistair G. Crooks give a heads-up about the plans for NetBSD 5.0 . The 5.0-release-branch has been created, being considered "quite stable" after an official "freeze period". As with every piece of software, there are still a number of problems to be fixed before a final release, but that's what the current phase is all about. Being "feature-complete", the developers can now concentrate on addressing those problems.

Several new features will be introduced with NetBSD 5.0:

  • a new kernel threading model, with better performance than the previous implementation
  • file system journalling (WAPBL by Wasabi Systems Inc.)
  • the Xen port has updated to Xen 3.3, and has support for PAE domains and amd64 domains (both dom0 and domU)
  • Xorg is now a part of our base system
  • our contributed external software has moved to a new framework, so as to make license issues clearer
  • all security-critical software is now compiled by default with stack protection; this makes stack overflow and stack smashing attacks more difficult to exploit

Of course, as Alistair Crooks writes in his mail with the words "We'd really like to encourage you to help us out by running code from the 5.0 branch, and to help us by shaking bugs out - send-pr is our friend in this - any and all bug reports gratefully received.", everyone interested in helping to test NetBSD 5.0 is welcome. You can retrieve the sources for NetBSD 5.0 from the CVS-branch called "netbsd-5" (see this guide for how to do it). Precompiled binary packages will be available, shortly, too.

Tags: , , ,
Posted in BSD, netbsd, opensource, operating system | No Comments »

NetBSD 4.0.1 released!

Wednesday, October 15th, 2008

On Tue, October 14, 2008 23:36, I received an announcement-mail, declaring that NetBSD 4.0.1 has been released, addressing a number security and stability issues. No new features have been added, but everyone running an exposed NetBSD 4.0 machine will be good advised to run the update.

See more here: http://www.netbsd.org/releases/formal-4/NetBSD-4.0.1.html

Changes in 4.0.1

The following changes mention only the security-fixes, and are copied from the link above. There are, of course, more changes. For a complete list see CHANGES-4.0.1

Security Advisory Fixes:

  • NetBSD-SA2008-004, multiple issues (CVE-2008-1372 and CVE-2005-0953), has been fixed by upgrading to bzip2 to 1.0.5
  • NetBSD-SA2008-005, OpenSSH Multiple issues (CVE-2008-1483 and CVE-2008-1657), has been fixed by applying patches from upstream.
  • NetBSD-SA2008-006, integer overflow in strfmon(3) function (CVE-2008-1391), has been fixed.
  • NetBSD-SA2008-008, OpenSSL Montgomery multiplication (CVE-2007-3108), has been fixed.
  • NetBSD-SA2008-009, BIND cache poisoning (CVE-2008-1447 and CERT VU#800113), has been fixed by updating BIND to 9.4.2-P2. Note there are two related changes to this advisory:
    • The default behavior of ipfilter's Port Address Translation has been changed to using random port allocation rather than sequential mappings, to avoid decreasing the randomness of source ports used for DNS queries which affects the BIND cache poisoning problem.
    • A `query-source' statement, which could allow the BIND cache poisoning attack, has been commented out in the default named.conf(5) file.
  • NetBSD-SA2008-010, malicious PPPoE discovery packet can overrun a kernel buffer (CVE-2008-3584), has been fixed.
  • NetBSD-SA2008-011, ICMPv6 MLD query (CVE-2008-2464), has been fixed.
  • NetBSD-SA2008-012, Denial of Service issues in racoon(8) (CVE-2008-3652), has been fixed by upgrading ipsec-tools to release 0.7.1. Note this also fixes CVE-2008-3651.
  • upcoming NetBSD-SA2008-013, IPv6 Neighbor Discovery Protocol routing vulnerability (CVE-2008-2476), has been fixed.
  • upcoming NetBSD-SA2008-014, remote cross-site request forgery attack issue in ftpd(8) (CVE-2008-4247), has been fixed.
  • upcoming NetBSD-SA2008-015, remove kernel panics on IPv6 connections (CVE-2008-3530), has been fixed

Other Security Fixes:

  • Fix a buffer overrun which could crash a FAST_IPSEC kernel.
  • tcpdump(8): fix CVE-2007-1218, CVE-2007-3798 and CAN-2005-1278 in base-tcpdump.
  • Fix a buffer overflow of PCF font parser in X11 libXfont library (CVE-2008-0006).
  • Fix a buffer overflow of Tektronix Hex Format support in binutils (CVE-2006-2362).
  • machfb(4) and voodoofb(4): introduce two missing KAUTH_GENERIC_ISSUSER checks in the mmap(2) code.

Tags: , , ,
Posted in BSD, netbsd, operating system, security | No Comments »

lighttpd <= 1.4.19 has a denial of service vulnerability

Monday, April 7th, 2008

On Thursday, March 27th 2008, a DoS-vulnerability in lighttpd 1.4.19 and lower versions was reported on cve.mitre.org. It has been confirmed through lighttpd's bug-tracking system. As of this writing, there is no official bugfix-release of lighttpd, yet, but according to the bug-tracking system, the issue is closed and marked as fixed. This suggests that there might be a new release soon, especially as this has been discussed in several comments on the bug-tracking system.

The problem as described in the bug-tracker: "if a user killed his ssl connection, lighttpd would kill another ssl connection as it didn't clear the ssl error queue."

Tags: , , , , , ,
Posted in Bug, connection, denial-of-service, lighttpd, security, ssl, vulnerability | No Comments »

GCC 4.3.0 exposes a kernel bug

Wednesday, March 19th, 2008

Earlier this month, lwn.net reported about a change to GCC, exposing a bug in Linux and BSD Kernels. GCC does not clear the direction flag anymore but assumes it to be done by the kernel, as specified by the x86-/x86-64 ABI. This is a major security risk, but as it seems after flying through the article, there is already a patch available that addresses this problem in the Linux Kernel.

Tags: , , , , ,
Posted in BSD, Bug, Kernel, Linux, Patch, netbsd, opensource, operating system, programming, security | No Comments »

Tech-blog opened

Thursday, March 13th, 2008

Welcome to this blog. It is dedicated to computer-technologies with focus on programming, opensource-topics, operating systems, it-security, embedded gadgets like smartphones, etc.  You can read more about this on the about-page.

Stay tuned.

Tags: , , , , , , ,
Posted in computer, gadgets, network, operating system, programming, security, smartphone, tech | No Comments »