arp-ping tool for windows

http://www.elifulkerson.com/projects/arp-ping.php

Rogue DHCP Server detection tool for windows

http://blogs.technet.com/b/teamdhcp/archive/2009/07/03/rogue-dhcp-server-detection.aspx

find unauthorized SUID and SGID system executables

The administrator should take care to ensure that no rogue set-UID programs have been introduced into the system. In addition, if possible, the administrator should attempt a Set-UID audit and reduction. To check for these run the following script:

#!/bin/bash
for part in `awk '($3 == "ext2" || $3 == "ext3") { print $2 }' /etc/fstab`
do
 find $part -xdev \( -perm -04000 -o -perm -02000 \) -type f -print
done

find unauthorized world writable files in linux

World writeable files can be modified by any user on the system. Generally 
removing write access for the "other" category (chmod o-w ) is advisable, but 
always consult the relevant documentation in order to avoid breaking any 
application dependencies on a particular file. Run the following script to print 
a list of world writeable files to screen. These files should then be reviewed 
and if possible the world writeable permissions removed. 

#!/bin/bash
for part in `awk '($3 == "ext2" || $3 == "ext3") { print $2 }' /etc/fstab`
do
 find $part -xdev -perm -0002 -type f -print | less
done

SELinux TFTP policy

If you have SELINUX running SELINUX won't allow you to PUT or upload files to your TFTP server. You can use "audit2allow" to allow you to create custom SELINUX policies
To use this you need to examine your servers audit logs. /var/log/audit/audit.log. This is where selinux logs errors. If you are receiving permission denied errors when uploading or puttiing files due to SELINUX have a check of this log. If SELINUX is causing the problem you will see an error log entry that looks like this:

type=AVC msg=audit(1245199930.280:31): avc: denied { write } for pid=2584 comm="in.tftpd" name="tftpboot" dev=dm-0 ino=1747009 scontext=system_u:system_r:tftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tftpdir_t:s0 tclass=dir
type=SYSCALL msg=audit(1245199930.280:31): arch=40000003 syscall=5 success=no exit=-13 a0=805e7a2 a1=8041 a2=1b6 a3=8041 items=0 ppid=2565 pid=2584 auid=4294967295 uid=99 gid=99 euid=99 suid=99 fsuid=99 egid=99 sgid=99 fsgid=99 tty=(none) ses=4294967295 comm="in.tftpd" exe="/usr/sbin/in.tftpd" subj=system_u:system_r:tftpd_t:s0-s0:c0.c1023 key=(null)
Using this error and the audit2allow tool we can create a policy that allows TFTP writes.

Step 1

Create some policy rules to load into SELINUX. Using the grep command input log entries which match our error from the audit file to the audit2allow tool. $ grep tftpd_t /var/log/audit/audit.log | audit2allow -M tftplocal

NOTE!

The audit2allow tool isn't infallible and sometimes you might want to check the rules that are contained in the output module the above command has created aren't too relaxed. These rules are kept in a file called tftplocal.te that gets created as a result of the above command. It should look something like this:

module tftplocal 1.0;

require {
        type tftpd_t;
        type tftpdir_t;
        class dir { write };
        class file { write };
}

#============= tftpd_t ==============
allow tftpd_t tftpdir_t:dir { write add_name };
allow tftpd_t tftpdir_t:file { write create };

Step 2

Import the selinux policy module created in step 1 $ semodule -i tftplocal.pp

checking the status of a service in linux

In this example I want to see if SMB is running

Check the status:
/etc/init.d/smb status

I can restart a service with
/etc/init.d/smb stop
/etc/init.d/smb start

or simply
/etc/init.d/smb restart

Check if the service is set to start on boot up
chkconfig --list | grep smb

SELinux

SElinux can stop samba (and other things) from working. You can turn it off by running the following command as root
"setenforce 0"
This is not recommended as it disables other security features but no one seems to know how to create exceptions for SElinux. SElinux will start again after a reboot. To stop it starting on reboot
sudo vi /etc/selinux/config
change the line SELINUX=enforcing to SELINUX=permissive
Save your changes and that should be it.

How many CPU sockets does my server have?

$ egrep "processor|physical id|core id" /proc/cpuinfo
processor   : 0
physical id  : 0
core id        : 0
processor   : 1
physical id  : 0
core id        : 0


The output show is for a single socket dual core machine.  Each core has a different processor ID, but the same physical ID (The physical ID indicating they are in fact on the same socket.  A virtual machine will usually only show the processor line and not the physical or core id's.

subnet calculator tool

Good calculator here for dividing up larger subnets into smaller ones
http://www.davidc.net/sites/default/subnets/subnets.html

A /16 breaks up into two /17's, a /17 breaks up into two /18's and so on

As you break up a /16 you get more networks but less hosts

mask	networks	hosts
/16	1	65534
/17	2	32766
/18	4	16382
/19	8	8190
/20	16	4096
/21	32	2046
/22	64	1022
/23	128	510
/24	256	254
/25	512	126
/26	1024	62
/27	2048	30
/28	4096	14
/29	8192	6
/30	16384	2

memory leaks on checkpoint R70

I've had an ongoing issue with a checkpoint R70, the RAM usage creeps up on the management node of the cluster and needs to be rebooted every 4 months. The device is currently out of support contract so I can't get any support/hotfixes/updates from checkpoint.

I've noticed that the nodes in the cluster also have RAM usage creeping up over a much longer period of time, about 1 year. I had no idea how to check the ram usage on these device so I had to find out.

The cluster is checkpoints secure platform so its just the software installed on some HP servers. They run a sort of linux OS.

I was able to run top on the server. I could see the cpd process was taking up most of the RAM. I assume this is the check point daemon.

I ran the two following commands from checkpoint. Checkpoint documentation asks you to look for failed allocations. If you see that there is a problem. Otherwise it is most likely a memory leak.

# fw ctl pstat

Machine Capacity Summary:

  Memory used: 1% (29MB out of 1620MB) - below low watermark

  Concurrent Connections: 0% (58 out of 24900) - below low watermark

  Aggressive Aging is not active

Hash kernel memory (hmem) statistics:

  Total memory allocated: 20971520 bytes in 5115 4KB blocks using 5 pools

  Total memory bytes  used:  3217916   unused: 17753604 (84.66%)   peak:  504318                                                                             0

  Total memory blocks used:     1013   unused:     4102 (80%)   peak:     1351

  Allocations: 1213799129 alloc, 0 failed alloc, 1213766746 free

System kernel memory (smem) statistics:

  Total memory  bytes  used: 43472216   peak: 55769708

    Blocking  memory  bytes   used:  1403176   peak:  1440356

    Non-Blocking memory bytes used: 42069040   peak: 54329352

  Allocations: 220680 alloc, 0 failed alloc, 219982 free, 0 failed free

Kernel memory (kmem) statistics:

  Total memory  bytes  used: 25670260   peak: 39394220

        Allocations: 1214019254 alloc, 0 failed alloc, 1213986426 free, 0 failed                                                                              free

        External Allocations: 5124 for packets, 0 for SXL

# cpstat os -f memory

Total Virtual Memory (Bytes):  4271108096

Active Virtual Memory (Bytes): 1696493568

Total Real Memory (Bytes):     2123681792

Active Real Memory (Bytes):    1696399360

Free Real Memory (Bytes):      427282432

Memory Swaps/Sec:              -

Memory To Disk Transfers/Sec:  -

To clear the leak you can run the "CPSTOP;CPSTART" or reboot the device
Make sure you have DRAC/ILO or physical access to the box

when logging a call with CP support they will usually ask for a cpinfo
cpinfo -o mycpinfo.tgz

See which node is active in a cluster
cphaprob stat

Logs are usually in /var/log on the active node

From checkpoint documentation:

Presence of hmem failed allocations indicates that the hash kernel memory was full. This is not a serious memory problem but indicates there is a configuration problem. The value assigned to the hash memory pool, (either manually or automatically by changing the number concurrent connections in the capacity optimization section of a firewall) determines the size of the hash kernel memory. If a low hmem limit was configured it leads to improper usage of the OS memory. See „Capacity Optimization‟ in the „Firewall Health Checks‟ section for further information.

Presence of smem failed allocations indicates that the OS memory was exhausted or there are large non-sleep allocations. This is symptomatic of a memory shortage. If there are failed smem allocations and the memory is less than 2 GB, upgrading to 2GB may fix the problem. Decreasing the TCP end timeout and decreasing the number of concurrent connections can also help reduce memory consumption.

Section 1 – Physical Platform Checks

Performing a SecurePlatform Firewall Health Check Page 10

Presence of kmem failed allocations means that some applications did not get memory. This is

usually an indication of a memory problem; most commonly a memory shortage. The natural limit is

2GB, since the Kernel is 32bit.)

Memory shortage sometimes indicates a memory leak. In order to troubleshoot memory

shortage, stop the load you need to stop the load and let connections close. If the memory

consumption returns back to normal, you are not dealing with a memory leak. Such shortage might

happen when traffic volumes are too high for the device capacity. If the memory shortage happens

after a change in the system or the environment, undo the change, and check whether kmem

memory consumption goes down.

For optimum performance there should not be any failed memory allocations.