iptables rules can be easily import and export

iptables rules can be insert by command iptables itself.

iptables -A INPUT -p udp –dport 222 -j ACCEPT

The above line append (-A) a rule in table INPUT, which indicate to ACCEPT packets come from anyplace with protocol udp and destination port 222. Iptables capable to do a lots more. To master it, you may consider to search for a book.

To easily setup firewalls for those distro who do not have one, i have a trick. Search for the distro which have default iptables rules, copy out the rules and store into a file, like this.

iptables-save > iptables.conf

The rules will be copy out and looks like this

# Generated by iptables-save v1.3.3 on Sun Sep 24 11:23:35 2006
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [35:1959]
:RH-Firewall-1-INPUT – [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp -m icmp –icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p esp -j ACCEPT
-A RH-Firewall-1-INPUT -p ah -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp –dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state –state NEW -m tcp –dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m state –state NEW -m udp –dport 137 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m state –state NEW -m udp –dport 138 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state –state NEW -m tcp –dport 139 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state –state NEW -m tcp –dport 445 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT –reject-with icmp-host-prohibited
COMMIT
# Completed on Sun Sep 24 11:23:35 2006

Then you can copy this file and restore at the machine you would like to have the same firewall rules.

iptables-restore < iptables.conf

To list all the rules binds on the machine, simply do this

iptables -L

To flush all iptables rules, means you clear off all rules and remains nothing, do this

iptables -F

By: mysurface

kill $(ps aux | grep ‘[p]ython csp_build.py’ | awk ‘{print $2}’)
Details on its workings are as follows:

The ps gives you the list of all the processes.
The grep filters that based on your search string, [p] is a trick to stop you picking up the actual grep process itself.
The awk just gives you the second field of each line, which is the PID.
The $(x) construct means to execute x then take its output and put it on the command line. The output of that ps pipeline inside that construct above is the list of process IDs so you end up with a command like kill 1234 1122 7654.

Here’s a transcript showing it in action:

pax> sleep 3600 &
[1] 2225
pax> sleep 3600 &
[2] 2226
pax> sleep 3600 &
[3] 2227
pax> sleep 3600 &
[4] 2228
pax> sleep 3600 &
[5] 2229
pax> kill $(ps aux | grep ‘[s]leep’ | awk ‘{print $2}’)
[5]+ Terminated sleep 3600
[1] Terminated sleep 3600
[2] Terminated sleep 3600
[3]- Terminated sleep 3600
[4]+ Terminated sleep 3600
pax> _

and you can see it terminating all the sleepers.

Explaining the grep ‘[p]ython csp_build.py’ bit in a bit more detail:

When you do sleep 3600 & followed by ps -ef | grep sleep, you tend to get two processes with sleep in it, the sleep 3600 and the grep sleep (because they both have sleep in them, that’s not rocket science).

However, ps -ef | grep ‘[s]leep’ won’t create a process with sleep in it, it instead creates grep ‘[s]leep’ and here’s the tricky bit: the grep doesn’t find it because it’s looking for the regular expression “any character from the character class [s] (which is s) followed by leep.

In other words, it’s looking for sleep but the grep process is grep ‘[s]leep’ which doesn’t have sleep in it.

When I was shown this (by someone here on SO), I immediately started using it because

it’s one less process than adding | grep -v grep; and
it’s elegant and sneaky, a rare combination 🙂

By: paxd

What is Priority and Why Should I Care?

When talking about processes priority is all about managing processor time. The Processor or CPU is like a human juggling multiple tasks at the same time. Sometimes we can have enough room to take on multiple projects. Sometimes we can only focus on one thing at a time. Other times something important pops up and we want to devote all of our energy into solving that problem while putting less important tasks on the back burner.

In Linux we can set guidelines for the CPU to follow when it is looking at all the tasks it has to do. These guidelines are called niceness or nice value. The Linux niceness scale goes from -20 to 19. The lower the number the more priority that task gets. If the niceness value is high number like 19 the task will be set to the lowest priority and the CPU will process it whenever it gets a chance. The default nice value is zero.

By using this scale we can allocate our CPU resources more appropriately. Lower priority programs that are not important can be set to a higher nice value, while high priority programs like daemons and services can be set to receive more of the CPU’s focus. You can even give a specific user a lower nice value for all of his/her processes so you can limit their ability to slow down the computer’s core services.
Checking the Priority of Running Processes

The easiest way to get a quick picture of what the current niceness priority on a process is to open up the top processes with:
top

Top displaying nice value

Another way you can get the nice value is use ps:
ps -o pid,comm,nice -p 594

This will output the process ID, command, and nice value (marked as NI).

ps showing process priority
Setting priority on new processes

At this point you are probably wondering how you can set your own priority levels on processes. To change the priority when issuing a new command you do nice -n [nice value] [command]:
nice -n 10 apt-get upgrade

This will increment the default nice value by a positive 10 for the command, ‘apt-get upgrade‘ This is often useful for times when you want to upgrade apps but don’t want the extra process burden at the given time. Remember a positive number is gives less priority for a process.
Setting Priority on Existing Processes

Obviously at some point you are going to want to alter the nice value of something that is already running. Just the other day I was doing an upgrade to Ubuntu Jaunty and Firefox started to become unusably slow. A quick renice command rescheduled the upgrade to a lower priority and I was back to surfing in no time.

To change the priority of an existing process just do renice [nice value] -p [process id]:
renice 10 -p 21827

This will increment the priority of the process with an id of 21827 to 10.

Note: Only root can apply negative nice values.

renice
Setting Permanent Priority on all Processes for a Specific User

Sometimes it is helpful to give specific users lower priority than others to keep system resources allocated in the proper places like core services and other programs.

You can set the default nice value of a particular user or group in the /etc/security/limits.conf file.
/etc/security/limits.conf

It uses this syntax: [username] [hard|soft] priority [nice value]
backupuser hard priority 1

By Mark Sanborn

I was looking for an easy way to mount VMDK files on my Linux box so I could do forensic analysis on the images. Similar to how I’ve done things in the past with E01 files. I didn’t really want to image the VM and then analyze it, since most of the time I’m using VM’s for testing.

So this will be short and sweet, but first a couple of caveats:

1) I have not tested this against split VMDK files yet, but I’m thinking it should work.

2) I haven’t even considered testing this against VM snapshot images, but I’m guessing that will not work.

3) You need to have AFFLIB installed and working

sudo apt-get install afflib-tools

That being said, this post was inspired by Sketchymoose’s post…

She talks about downloading the Virtual Disk Development kit, but one item in the post caught my eye:

“I first discovered I had to add the ‘-i aff’ parameter to get mmls to determine the disk structure of the vmdk file.”

I thought hey, there’s affuse!

Step 1:

affuse <vmdk file> /mount/point

ex: affuse windows7.vmdk /mnt/aff

Step 2:

mmls -t dos <mount point>/<vmdk file name>.raw

ex: mmls -t dos /mnt/aff/windows7.vmdk.raw

Step 3:

mount -o ro,loop,show_sys_files,streams_interface=windows,offset=<offset> <mount point>/<vmdk file>.raw /mount/point

ex: mount -o ro,loop,show_sys_files,streams_interface=windows,offset=1048576 /mnt/aff/windows7.vmdk.raw /mnt/windows

And voila! /mnt/windows now contains the file structure of the VMDK image!

I’m sure someone else figured this out, but a google search didn’t come up with anything when I added AFF to the search query (for me at least). So I thought I would share…

Also, keep in mind you can still use the -i AFF with TSK and VMDK images if you don’t need to mount it…

By: ramslack

The physical geometry of modern hard drives is no longer directly accessible by the operating system. Early hard drives were simple enough that it was possible to address them according to their physical structure, cylinder-head-sector. Modern drives are much more complex and use systems like zone bit recording , in which not all tracks have the same amount of sectors. It’s no longer practical to address them according to their physical geometry.

from the fdisk man page:

If possible, fdisk will obtain the disk geometry automatically. This is not necessarily the physical disk geometry (indeed, modern disks do not really have anything like a physical geometry, certainly not something that can be described in simplistic Cylinders/Heads/Sectors form)

To get around this problem modern drives are addressed using Logical Block Addressing, which is what the operating system knows about. LBA is an addressing scheme where the entire disk is represented as a linear set of blocks, each block being a uniform amount of bytes (usually 512 or larger).

About Files

In order to understand where a “file” is located on a disk (at the LBA level) you will need to understand what a file is. This is going to be dependent on what file system you are using. In Unix style file systems there is a structure called an inode which describes a file. The inode stores all the attributes a file has and points to the LBA location of the actual data.

Ubuntu Example

Here’s an example of finding the LBA location of file data.

First get your file’s inode number

$ ls -i
659908 test.txt

Run the file system debugger. “yourPartition” will be something like sda1, it is the partition that your file system is located on.

$sudo debugfs /dev/yourPartition
debugfs: stat <659908>

Inode: 659908 Type: regular Mode: 0644 Flags: 0x80000
Generation: 3039230668 Version: 0x00000000:00000001
…
…
Size of extra inode fields: 28
EXTENTS:
(0): 266301

The number under “EXTENTS”, 266301, is the logical block in the file system that your file is located on. If your file is large there will be multiple blocks listed. There’s probably an easier way to get that number, I couldn’t find one.

To validate that we have the right block use dd to read that block off the disk. To find out your file system block size, use dumpe2fs.

dumpe2fs -h /dev/yourPartition | grep “Block size”

Then put your block size in the ibs= parameter, and the extent logical block in the skip= parameter, and run dd like this:

sudo dd if=/dev/yourPartition of=success.txt ibs=4096 count=1 skip=266301

success.txt should now contain the original file’s contents.

By: Chandler and Peter