Malicious code that was recently classified as a worm, surfaced in October 2008 and exploits MS08-067 vulnerability in the Microsoft Windows family Operating System (surprise surprise !!). The worm is known by various names Downup, Downadup, Kido, and the most popular being Conficker.
Conflicker has gone through various stages of development that make it harder to understand; credits to the use of P2P mechanism encrypting the traffic using the latest and greatest MIT MD6 algorithm. A noteworthy mention about the client on an infected machine is that, it uses an intelligent algorithm that creates a daily list of 250 random domain names to communicate with its mother ship that advertises different domain names each day. Guess what, it gets even better, the newer variant Conflicker. C just upped that number from 250 to 50,000.
What makes this one extra special is that no one seems to still know what its gonna do on “D day”. Experts guess that April 1 could probably be that D day, but we never know…
Let the guessing games continue; in the meantime, if you don’t have the habit of installing Microsoft Windows security fixes or keep you Windows auto update OFF, it’d be a good idea to get to the Symantec website and attempt a removal of a possible infection.
Cheers, and have a SAFE April 1.
A pinhole camera works on a simple principle where light enters a small hole to produce an image on the film/sensor. This image is usually sharp, but since only a small amount of light is entering the pinhole, longer exposure times would be required. A pinhole can never replace your camera lens, but such a setup can be used simply for artistic purpose or just to have some fun 😉
The two main formats for file archiving are tar and cpio. Both a used in tandem with compression utilities like the gzip and bzip. The archive formats were initially used for tape and other sequential access devices for backup purposes, it is now commonly used to collate collections of files into one larger file, for distribution or archiving, while preserving file system information such as user and group permissions, dates, and directory structures.
An important point you need to consider while using these archives to create backups is that, in the unfortunate event where a portion of the archive gets corrupted, tar will skip a corrupted archive portion and proceed to the next whereas cpio is going to quit with an error.
Tar accepts explicit file names to make the archive whereas cpio seems to give better control on the files that need to be archived.
# find . -type f -name '*.txt' -print | cpio -o | gzip >all_my_txt.cpio.gz
A useful way to use archives and transfer multiple files and directories to a target directory/machine is to create an archive in stdout and then, in the target directory/machine, extracting the tar file from the piped stdin.
# using cpio
# find . -type f -name '*.txt' -print | cpio -o | ssh target_machine "cd /target_dir && cpio -idum"
# using a tarpipe
# tar -cf - "source_dir" | ( cd "target_dir" && tar -xvf - )
Many software vendors like RedHat and Oracle ship their products in cpio file format. Eg, RPM uses cpio and can be extracted using the rpm2cpio utility
# rpm2cpio rpm_name | cpio -ivd
The Linux kernel implements two separate priority ranges.
The first is the nice value, a number from –20 to 19 with a default of zero. Larger nice values correspond to a lower priority (you are being nice to the other processes on the system). Processes with a lower nice value (higher priority) run before processes with a higher nice value (lower priority). The nice value also helps determine how long a processor timeslice the process receives. A process with a nice value of –20 receives the maximum timeslice, whereas a process with a nice value of 19 receives the minimum timeslice. Nice values are the standard priority range used in all Unix systems.
The second range is the real-time priority (
rtprio). By default, it ranges from zero to 99. All real-time processes are at a higher priority than normal processes. Linux implements real-time priorities in accordance with POSIX.
In order to select a process to run, the Linux scheduler must consider the priority of each process. Actually, there are two kinds of priority:
This kind is assigned by the users to real-time processes and ranges from 1 to 99 (highest). It is never changed by the scheduler. The
sys_sched_get_priority_max( ) routine returns the static priority of the process, it returns 0 for non-realtime processes.
This kind applies only to conventional processes (non realtime processes)
Processes have an initial priority specified as the nice value. This value is stored in the
static_prio member of the process’s
task_struct. The value is called the static priority because it does not change from what the user specifies. The scheduler, in turn, bases its decisions on the dynamic priority that is stored in
prio. The dynamic priority is calculated as a function of the static priority and the task’s interactivity
The static priority of a real-time process is always higher than the dynamic priority of a conventional one: the scheduler will start running conventional processes only when there is no real-time process in a
Do experiment with the
~$ ps -eo pid,rtprio,ni,pri,comm
PID RTPRIO NI PRI COMMAND
1 - 0 19 init
2 - -5 24 kthreadd
3 99 - 139 migration/0
4 - -5 24 ksoftirqd/0
This scale could probably illustrate priorities better
HIGH PRIORITY – – – – – > – – – – – > – – – – – > – – – – – > – – – – LEAST PRIORITY
……..real time priority (static priority)…….| …. nice value (dynamic priority) …..
99 ……………………….. 50 ……………………… 1 | -20 …….. -10 …….. 0 …….. 10 ……. 19
The wordpress wysiwug editor seems to remove the <br> tag from the posts and prevents me from adding line breaks to format posts better.
I found this piece of code that can be used to induce a linebreak in the wordpress post.
<p align=”left”><span style=”color:#ffffff;”>.</span></p>
Source [ via xarj ]
login program is used when signing onto a system. It can also be used to switch from one user to another at any time (most modern shells have support for this feature built into them, however).
If an argument is not given, login prompts for the username.
If the user is not
root, and if
/etc/nologin exists, the contents of this file are printed to the screen, and the login is terminated. This is typically used to prevent logins when the system is being taken down.
If special access restrictions are specified for the user in
/etc/usertty, these must be met, or the log in attempt will be denied and a
syslog message will be generated.
If the user is
root, then the login must be occurring on a tty listed in
/etc/securetty. Failures will be logged with the
syslog facility. If the file does not exist, root is allowed to log in on any tty.
After these conditions have been checked, the password will be requested and checked (if a password is required for this username). Ten attempts are allowed before login dies, but after the first three, the response starts to get very slow. Login failures are reported via the
syslog facility. This facility is also used to report any successful root logins.
If the file
.hushlogin exists, then a “quiet” login is performed (this disables the checking of mail and the printing of the last login time and message of the day). Otherwise, if /var/log/lastlog exists, the last login time is printed (and the current login is recorded).
Random administrative things, such as setting the
GID of the tty are performed. The
TERM environment variable is preserved, if it exists (other environment variables are preserved if the -p option is used). Then the
HOME, PATH, SHELL, TERM, MAIL, and
LOGNAME environment variables are set.
PATH defaults to /usr/local/bin:/bin:/usr/bin for normal users, and to /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin for root. Last, if this is not a “quiet” login, the message of the day is printed and the file with the user’s name in /var/spool/mail will be checked, and a message printed if it has non-zero length.
The user’s shell is then started. If no shell is specified for the user in
/bin/sh is used. If there is no directory specified in
/ is used (the home directory is checked for the
.hushlogin file described above).
Software is probably the fastest thing that undergoes change, and its standardization is an important method for both software development and maintenance.
Since its development in 1969, Unix has undergone a lot of changes and has evolved over the years. Here are a few of the efforts towards standardizing Unix.
Probably the first step was in 1980 when BSD 4.1 was developed which included vi, job control and improvements in signals. Subsequently came AT&Ts draft standards which also included TCP/IP networking with BSD4.2 in 1983.
In 1985, AT&T released the System V Interface Definition (SVID) whose description included system calls, C libraries, available programs and devices.
In 1985 Institute of Electrical and Electronic Engineers (IEEE) committee developed a series of standards generally known as POSIX. These went beyond describing merely systems calls and C library facilities; they specified detailed semantics of a shell and a minimum command set, and also detailed bindings for various non-C programming languages. The first release in 1990 was followed by a second edition in 1996.
Key POSIX standards include the following:
- 1003.1 (released 1990): Library procedures. Described the C system call API, much like Version 7 except for signals and the terminal-control interface.
- 1003.2 (released 1992): Standard shell and utilities. Shell semantics strongly resemble those of the System V Bourne shell.
- 1003.4 (released 1993): Real-time Unix. Binary semaphores, process memory locking, memory-mapped files, shared memory, priority scheduling, real-time signals, clocks and timers, IPC message passing, synchronized I/O, asynchronous I/O, real-time files.
And then in 2001, the X/Open (The Open Group) framed the Single UNIX Specification which specified four important things.
- Base Definitions – a list of definitions and conventions used in the specifications and a list of C header files which must be provided by compliant systems
- Shell and Utilities – a list of utilities and a description of the shell, sh
- System Interfaces – a list of available C system calls which must be provided
- Rationale – the explanation behind the standard