Author: HASEGAWA Yosuke (translated by TAKAHASHI Motonobu)
Nimba Worm is infected through shared disks on a network, as well as through Microsoft IIS, Internet Explorer and mailer of Outlook series.
At this time, the worm copies itself by the name *.nws and *.eml on the shared disk, moreover, by the name of Riched20.dll in the folder where *.doc file is included.
To prevent infection through the shared disk offered by Samba, set up as follows:
[global] ... # This can break Administration installations of Office2k. # in that case, don't veto the riched20.dll veto files = /*.eml/*.nws/riched20.dll/
By setting the "veto files" parameter, matched files on the Samba server are completely hidden from the clients and making it impossible to access them at all.
In addition to it, the following setting is also pointed out by the samba-jp:09448 thread: when the "readme.txt.{3050F4D8-98B5-11CF-BB82-00AA00BDCE0B}" file exists on a Samba server, it is visible only as "readme.txt" and dangerous code may be executed if this file is double-clicked.
Setting the following,
veto files = /*.{*}/
any files having CLSID in its file extension will be inaccessible from any
clients.This technical article is created based on the discussion of samba-jp:09448 and samba-jp:10900 threads.
Contributor: Gerhard Zuber
Requirements:
| UNIX box (Linux preferred) with SAMBA and a faxmodem |
| ghostscript package |
| mgetty+sendfax package |
| pbm package (portable bitmap tools) |
First, install and configure the required packages. Be sure to read the mgetty+sendfax manual carefully.
Your incomed faxes are in: /var/spool/fax/incoming. Print it with:
for i in * do g3cat $i | g3tolj | lpr -P hp done
g3cat is in the tools-section, g3tolj is in the contrib-section for printing to HP lasers.
If you want to produce files for displaying and printing with Windows, use some tools from the pbm-package like the following command: g3cat $i | g3topbm - | ppmtopcx - >$i.pcx and view it with your favourite Windows tool (maybe paintbrush)
fetch the file mgetty+sendfax/frontends/winword/faxfilter and place it in /usr/local/etc/mgetty+sendfax/(replace /usr/local/ with whatever place you installed mgetty+sendfax)
prepare your faxspool file as mentioned in this file edit fax/faxspool.in and reinstall or change the final /usr/local/bin/faxspool too.
if [ "$user" = "root" -o "$user" = "fax" -o \
"$user" = "lp" -o "$user" = "daemon" -o "$user" = "bin" ]find the first line and change it to the second.
make sure you have pbmtext (from the pbm-package). This is needed for creating the small header line on each page.
Prepare your faxheader /usr/local/etc/mgetty+sendfax/faxheader
Edit your /etc/printcap file:
# FAX
lp3|fax:\
:lp=/dev/null:\
:sd=/usr/spool/lp3:\
:if=/usr/local/etc/mgetty+sendfax/faxfilter:sh:sf:mx#0:\
:lf=/usr/spool/lp3/fax-log:Now, edit your smb.conf so you have a smb based printer named "fax"
Now you have a printer called "fax" which can be used via TCP/IP-printing (lpd-system) or via SAMBA (windows printing).
On every system you are able to produce postscript-files you are ready to fax.
On Windows 3.1 95 and NT:
Install a printer wich produces postscript output, e.g. apple laserwriter
Connect the "fax" to your printer.
Now write your first fax. Use your favourite wordprocessor, write, winword, notepad or whatever you want, and start with the headerpage.
Usually each fax has a header page. It carries your name, your address, your phone/fax-number.
It carries also the recipient, his address and his *** fax number ***. Now here is the trick:
Use the text:
Fax-Nr: 123456789as the recipients fax-number. Make sure this text does not occur in regular text ! Make sure this text is not broken by formatting information, e.g. format it as a single entity. (Windows Write and Win95 Wordpad are functional, maybe newer versions of Winword are breaking formatting information).
The trick is that postscript output is human readable and the faxfilter program scans the text for this pattern and uses the found number as the fax-destination-number.
Now print your fax through the fax-printer and it will be queued for later transmission. Use faxrunq for sending the queue out.
[global]
printcap name = /etc/printcap
print command = /usr/bin/lpr -r -P %p %s
lpq command = /usr/bin/lpq -P %p
lprm command = /usr/bin/lprm -P %p %j
[fax]
comment = FAX (mgetty+sendfax)
path = /tmp
printable = yes
public = yes
writable = no
create mode = 0700
browseable = yes
guest ok = noWe wish to help those folks who wish to use the ISC DHCP Server and provide sample configuration settings. Most operating systems today come ship with the ISC DHCP Server. ISC DHCP is available from: ftp://ftp.isc.org/isc/dhcp
Incorrect configuration of MS Windows clients (Windows9X, Windows ME, Windows NT/2000) will lead to problems with browsing and with general network operation. Windows 9X/ME users often report problems where the TCP/IP and related network settings will inadvertantly become reset at machine start-up resulting in loss of configuration settings. This results in increased maintenance overheads as well as serious user frustration.
In recent times users on one mailing list incorrectly attributed the cause of network operating problems to incorrect configuration of Samba.
One user insisted that the only way to provent Windows95 from periodically performing a full system reset and hardware detection process on start-up was to install the NetBEUI protocol in addition to TCP/IP. This assertion is not correct.
In the first place, there is NO need for NetBEUI. All Microsoft Windows clients natively run NetBIOS over TCP/IP, and that is the only protocol that is recognised by Samba. Installation of NetBEUI and/or NetBIOS over IPX will cause problems with browse list operation on most networks. Even Windows NT networks experience these problems when incorrectly configured Windows95 systems share the same name space. It is important that only those protocols that are strictly needed for site specific reasons should EVER be installed.
Secondly, and totally against common opinion, DHCP is NOT an evil design but is an extension of the BOOTP protocol that has been in use in Unix environments for many years without any of the melt-down problems that some sensationalists would have us believe can be experienced with DHCP. In fact, DHCP in covered by rfc1541 and is a very safe method of keeping an MS Windows desktop environment under control and for ensuring stable network operation.
Please note that MS Windows systems as of MS Windows NT 3.1 and MS Windows 95 store all network configuration settings a registry. There are a few reports from MS Windows network administrators that warrant mention here. It would appear that when one sets certain MS TCP/IP protocol settings (either directly or via DHCP) that these do get written to the registry. Even though a subsequent change of setting may occur the old value may persist in the registry. This has been known to create serious networking problems.
An example of this occurs when a manual TCP/IP environment is configured to include a NetBIOS Scope. In this event, when the administrator then changes the configuration of the MS TCP/IP protocol stack, without first deleting the current settings, by simply checking the box to configure the MS TCP/IP stack via DHCP then the NetBIOS Scope that is still persistent in the registry WILL be applied to the resulting DHCP offered settings UNLESS the DHCP server also sets a NetBIOS Scope. It may therefore be prudent to forcibly apply a NULL NetBIOS Scope from your DHCP server. The can be done in the dhcpd.conf file with the parameter: option netbios-scope "";
While it is true that the Microsoft DHCP server that comes with Windows NT Server provides only a sub-set of rfc1533 functionality this is hardly an issue in those sites that already have a large investment and commitment to Unix systems and technologies. The current state of the art of the DHCP Server specification in covered in rfc2132.
SMB network clients need to be configured so that all standard TCP/IP name to address resolution works correctly. Once this has been achieved the SMB environment provides additional tools and services that act as helper agents in the translation of SMB (NetBIOS) names to their appropriate IP Addresses. One such helper agent is the NetBIOS Name Server (NBNS) or as Microsoft called it in their Windows NT Server implementation WINS (Windows Internet Name Server).
A client needs to be configured so that it has a unique Machine (Computer) Name.
This can be done, but needs a few NT registry hacks and you need to be able to speak UNICODE, which is of course no problem for a True Wizzard(tm) :) Instructions on how to do this (including a small util for less capable Wizzards) can be found at
http://www.unixtools.org/~nneul/sw/nt/dhcp-netbios-hostname.html
Jim barry has written an excellent drag-and-drop cr/lf converter for windows. Just drag your file onto the icon and it converts the file.
The utilities unix2dos and dos2unix(in the mtools package) should do the job under unix.
At the time of writing there is currently being worked on a wins replication implementation(wrepld).