[Dshield] DShield.py

Rus, Peter peterr at gasullivan.com
Wed Nov 7 12:31:26 GMT 2001


Hi marten,
This is a so called private Ip range, class C to be precise. These ip
addresses are free for use in an internal netwerk and are non routable
ip addresses.
www.learnhowtosubnet.com will help you out more.


Peter Rus
Network Support Specialist
http://www.gasullivan.com
peterr at gasullivan.com
tel 0 (31)- (0) -73-6223213
MCP , MCSE 2000 + S

There is no such thing as a perpetually secure solution. There is no
such thing as an "install and forget" web application; not when security
is a goal.
Auto-updaters and the like may help, but they will not take the place of
a policy of management, audit, and continued education.

 -----Original Message-----
From: 	Pieter-Bas IJdens [mailto:pbijdens at emea.mi4.org.uk] 
Sent:	woensdag 7 november 2001 12:34
To:	dshield at dshield.org
Subject:	Re: [Dshield] DShield.py

 << File: atomic.c >> > > You could try hard linking the file, instead
of copying it.
>
> Isn't 'cp' supposed to be atomic? Or is only 'mv' safe?

The problem here is that there are updates taking place between the 'cp'
of
the old log file, and the rotation. In these cases, using hard linking
allows you to fill the time-gap between the copy and the unlink action
of
the old log file. Atomicity of cp plays no role here.

Hint: This is also very useful when backing up database files that get
replaced after a checkpoint has been sucessfully made to a shadow file.
If
you hard link the original first, then even if the file gets unlinked
and
replaced during the backup, you still consistently back up the old data
by
backing up the linked file instead.

All you do know with cp is that you never get trash (random data). But
that's just because the order of the cached write and the file length
update
is done correctly in the filesystem implementations. Atomicity is not
specified in the manual, nor in the info pages, so I would never assume
it
is atomic in any way.

The 'mv', 'rm' and 'ln' commands are safe because they don't have any
effect
on the file data. I tested a cross-filesystem move on linux 2.4.12 while
writing a 32MB file and the md5sum says mv is not atomic for the
persisent
data.

On the local fileysstem the results were always identical. Note that the
readback by the writing process detectes no anomalies ever. This is
because
while the file is open it always operates on the local data, regardless
of
what you do with the file [even if you unlink it]. You should maybe play
with this yourself. Please find attached the code I used to perform
these
quick experiments. That and two shell windows suffice to re-create them.

  Pieter-Bas




More information about the list mailing list