Crash course: Embedded programming with Arduino

Posted by Unknown Minggu, 25 Desember 2011 0 komentar

Try your hand at embedded programming with this project

Demand for embedded programming is growing like crazy, so anyone looking for some job security might consider becoming an ace embedded programmer. It helps to have some programming experience, but even raw beginners can get started inexpensively and learn on their own. One of the friendliest introductions to embedded coding is Arduino. Arduino is a popular open embedded hardware and software platform with hundreds of howtos and projects to try out. Today we review the basics of both electronics and Arduino coding in a fun holiday project, Singing Holiday Snowman.

Singing snowman

I'm going to take my old plastic snowman (figure 1) and outfit him to sing holiday songs whenever anyone approaches within a few feet, and to blink some festive red and green LEDs. (Half the fun of Arduino is blinky lights.) You, of course, may use any object you want. If you are new to electronics and embedded coding, give yourself a few days to put this together because it covers a lot of ground. This project gives hands-on experience in these essential fundamentals:

  • Soldering
  • Reading simple schematics
  • Loading and modifying Arduino programs


Figure 1: Plastic snowman before his operation, mute and unlit
Source: Carla Schroder

Prerequisites

The Singing Snowman is modeled on the Halloween Pumpkin project. Beginners should work through the first three of these excellent Arduino tutorials first. These will teach you how to install and use the Arduino software, and get acquainted with tools and Arduino parts. You'll be doing a fair bit of soldering; if you're not a good hand with a soldering iron, find some nothing-to-lose circuit boards and practice. The soldering page links to some good howtos.
Here is a handy hardware list. The first two items are nice kits that supply everything you need for Singing Snowman, plus leftovers for more projects.

  • Ladyada's Electronics Toolkit, $100. Includes a good adjustable temperature soldering iron, multimeter, snips, strippers, solder, solder sucker and braid, multimeter, vise, and other useful tools.
  • Adafruit ARDX - v1.3 Experimentation Kit. This includes red and green LEDs and matching resistors, printed howtos, breadboard, Arduino Uno, USB cable, wires, and other goodies for multiple projects. $85.
  • Adafruit Wave Shield for Arduino. This is the part that plays sounds. $22. You'll also need a SD/MMC card for storing audio files.
  • A small 8 ohm speaker, like an old PC speaker.
  • MaxBotix EZ1 sonar sensor. This will detect when someone is within a few feet of the snowman, and then it will play songs and animate the blinky lights. I use the MB1010 because it has a narrow sensitivity range to the front. There are three other versions with different sensitivity patterns.
  • Insulated 22-gauge solid-core wire in red, green, white, and black.
  • A magnifier and good light. I like magnifier lamps, and magnifier headlamps are nice too.
  • Wrist grounding strap. Arduino boards and accessories are pretty resilient to electrostatic discharge (ESD), but a strap is cheap insurance in a static-prone environment.
  • Drill and bits.
If you already have a well-equipped electronics workbench and don't need the two Adafruit kits, this is what you'll need for Singing Snowman:

  • Seven red and green LEDs with matching resistors
  • Arduino Uno
  • 9- or 12-volt power supply

Plus the other non-kit parts: Adafruit Wave Shield, MaxBotix EZ1, and wiring. Figure 2 shows my workbench with some of the tools and parts for this project.

Figure 2: Workbench for the singing holiday snowman project
Source: Carla Schroder

LEDs and resistors

You always need resistors with LEDs because resistors limit the current flowing to the LED to a safe level. Resistors are everywhere in electronics, and come in a huge variety of sizes and shapes. We are going to use through-hole carbon film resistors. A common beginner question is how do you know which resistors go with your LEDs? You need three pieces of information: The voltage of your power supply (Vs), and the voltage forward (Vf) and drive current (If) of the LED. Then calculate the resistor value (R), in ohms, like this: R = (Vs - Vf)/If.
For example, I have some of these 5mm red LEDs and a 9-volt power supply. So my equation is (9 - 1.85) / 0.02 = 357.5 ohms. The next highest standard resistor is 360 ohms at 1/2 watt, though most electronics gurus will go one higher and choose a 390 ohm resistor for a larger safety margin. A higher ohm value means more resistance and less current. You can damage LEDs with too much current. What does the watts value signify? That's how much power the resistor can handle. For low-power uses like our little blinky LEDS you'll see 1/8, 1/4, and 1/2 watt resistors. Try one of the many online LED calculators until you feel comfortable with your math, like this one.

Figure 3: The color-coding tells us this is a 390 ohm resistor
Source: Carla Schroder

That's for a single LED. We're using 7, so that changes our requirements. Again, there are handy online calculators to help us. The LED series/parallel array wizard calculates four different wiring layouts for you to choose from.
Resistors are color-coded. The color bars on the resistor in Figure 3 tell us this is rated at 390 ohms with 5% tolerance: Orange-White-Brown means 3-9- and one zero, or 390. The gold band = 5%. The tolerance rating is electronics-speak for plus/minus variance from the stated ohms.
Resistor color code tables are all over the place, on the Web and in books.

Assembly

The Wave Shield requires assembly and there is a lot of soldering, so do that first. When it's all together it will plug in nicely on top of your Arduino board. Then you'll solder your speaker and sonar sensor to the Wave board; follow the Halloween Pumpkin howto to see where the wires go. Make their wires long enough to allow you to mount the speaker and sensor where you want them inside your own project.
Use the LED series/parallel array wizard to figure out your LED wiring, and then solder your wiring harness together. Make sure your positive and negative leads are in correct order. The Halloween Pumpkin page says to use a glue gun to fasten the LEDs in place, but I prefer to drill holes that hold them snugly because it's less messy and easy to make changes. Once they're in place, solder the leads to the appropriate analog inputs and ground on your Wave board, and again leave enough slack in your wiring so you can move and easily access the Arduino and Wave Shield.
The clever part about the Halloween Pumpkin project is it saves a lot of code-writing by using an analog input to capture the audio output, which creates a variable-strength signal, and using that to animate the LEDs. Solder analog input #1 to the R7 1.5k resistor on the Wave board.
Plug your SD card into a PC in the usual way, with a card reader or built-in slot, and transfer your audio files to it. They must be in 22KHz 16-bit mono or lesser quality WAV. Then plug the card into the Wave Shield. Now you're ready to connect your PC to the Arduino with a USB cable, fire up the Arduino software, edit your sketch, and load it into the Arduino. One of Arduino's advantages is the speed of iteration -- you can quickly make and test changes in your code. Figure 4 shows my Singing Holiday Snowman in action.

Figure 4: Singing holiday snowman lit up and singing
Source: Carla Schroder

Arduino code

I'm using the Halloween Pumpkin sketch (an Arduino program is called a sketch) with some minor changes. The Arduino programming language is pretty much a slimmed-down C/C++. You will have to make some changes to this sketch, so look for my comments in the sketch which are enclosed in the standard C multi-line comment symbols, /* */. Single-line comments, which start with //, are the original comments from the original sketch author.
We covered a lot of ground in this Crash Course, and hopefully your project blinks and sings just the way you want. If something doesn't work right, and you can't figure it out, go back to the Arduino tutorials and review the basics, and the Arduino forums are a good source of help.

Additional references


Singing snowman sketch


#include 
#include
#include "util.h"
#include "wave.h"

AF_Wave card;
File f;
Wavefile wave;

// save RAM by using program memory strings
#define playcomplete(x) ROM_playcomplete(PSTR(x))

#define servo 7
#define redled 9
#define eyeleds 18
#define mouthleds 17
#define midmouthleds 16
#define outermouthleds 19

// set up Serial library at 9600 bps
void setup() {
Serial.begin(9600);
Serial.println("Wave test!");

/* Setup the LEDs */

pinMode(2, OUTPUT);
pinMode(3, OUTPUT);
pinMode(4, OUTPUT);
pinMode(5, OUTPUT);
pinMode(redled, OUTPUT);
pinMode(servo, OUTPUT);
pinMode(eyeleds, OUTPUT);
pinMode(outermouthleds, OUTPUT);
pinMode(midmouthleds, OUTPUT);
pinMode(mouthleds, OUTPUT);

randomSeed(analogRead(0));

/* Useful feedback if the SD card is missing
* or cannot be read */

if (!card.init_card()) {
putstring_nl("Card init. failed!"); return;
}
if (!card.open_partition()) {
putstring_nl("No partition!"); return;
}
if (!card.open_filesys()) {
putstring_nl("Couldn't open filesys"); return;
}

if (!card.open_rootdir()) {
putstring_nl("Couldn't open dir"); return;
}

putstring_nl("Files found:");
ls();
}

void ls() {
char name[13];
int ret;

card.reset_dir();
putstring_nl("Files found:");
while (1) {
ret = card.get_next_name_in_dir(name);
if (!ret) {
card.reset_dir();
return;
}
Serial.println(name);
}
}


void pulseServo(uint8_t servopin, uint16_t p) {

digitalWrite(servopin, HIGH);
delayMicroseconds(600);
while (p--) {
delayMicroseconds(4);
}
digitalWrite(servopin, LOW);
delay(18);
}

/* typedef unsigned char "snowmanstate"
* You can change this name to something
* suitable for your own project
* Measures how close people are and plays
* audio files according to distance */

uint8_t snowmanstate = 0;

void loop() {
int distsensor, i;
long time;
/*
for (i=0; i<50; i++) {
pulseServo(servo,0);
}
for (i=0; i<50; i++) {
pulseServo(servo,400);
}
return;
*/
distsensor = 0;
for (i=0; i<8; i++) {
distsensor += analogRead(0);
delay(50);
}
distsensor /= 8;

// putstring("Sensor = ");
Serial.println(distsensor);

/* A reading of 500 = more than 6 meters away, so once
* every 200 times play one of of three scary sounds
* when no one is present */

if (distsensor<= 500) {
digitalWrite(eyeleds, HIGH);
}
if (distsensor > 500) {
digitalWrite(eyeleds, LOW);

// nobody there. one out of 200 times play one of
// the scary sounds (once every few minutes)

/* Substitute your own audio file names */

snowmanstate = 1;
i = random(200);
//Serial.println(i);
if (i == 0) {
i = random(3);
if (i == 0) {
playcomplete("merryxmas.wav");
} else if (i == 1) {
playcomplete("hollyjolly.wav");
} else {
playcomplete("jinglebellsbatmansmells.wav");
}
}

/* When someone comes closer play these files
* Substitute your own audio file names */

} else if ((distsensor > 300) && (distsensor < 400)) {
if (snowmanstate <= 1) {
playcomplete("rudolph.wav");
} else {
i = random(60);
//Serial.println(i);
if (i == 0) {
i = random(3);
if (i == 0) {
playcomplete("frosty.wav");
} else if (i == 1) {
playcomplete("kissingsanta.wav");
} else {
playcomplete("deckhalls.wav");
}
}
}
snowmanstate = 2;
} else if ((distsensor > 100) && (distsensor < 200)) {
if (snowmanstate <= 2) {
playcomplete("frosty.wav");
} else {
i = random(50); // more often
//Serial.println(i);
if (i == 0) {
i = random(3);
if (i == 0) {
playcomplete("gotell.wav");
} else if (i == 1) {
playcomplete("joyworld.wav");
} else {
playcomplete("letitsnow.wav");
}
}
}
snowmanstate = 3;
} else if (distsensor < 50) {
if (snowmanstate <= 3) {
playcomplete("linussong.wav");
} else {
i = random(30); // more often
//Serial.println(i);
if (i == 0) {
i = random(2);
if (i == 0) {
playcomplete("mrgrinch.wav");
} else if (i == 1) {
playcomplete("sleighride.wav");
}
}

}
snowmanstate = 4;
}
}

/* This part lights the LEDs according to
* the strength of the audio signal */

void ROM_playcomplete(const char *romname) {
char name[13], i;
uint8_t volume;
int v2;

for (i=0; i <13; i++) {
name[i] = pgm_read_byte(&romname[i]);
}
name[12] = 0;
Serial.println(name);
playfile(name);
while (wave.isplaying) {
volume = 0;
for (i=0; i<8; i++) {
v2 = analogRead(1) - 512;
if (v2< 0)
v2 *= -1;
if (v2 > volume)
volume = v2;
delay(5);
}
if (volume > 200) {
digitalWrite(outermouthleds, HIGH);
} else {
digitalWrite(outermouthleds, LOW);
}
if (volume > 150) {
digitalWrite(midmouthleds, HIGH);
} else {
digitalWrite(midmouthleds, LOW);
}
if (volume > 100) {
digitalWrite(mouthleds, HIGH);
} else {
digitalWrite(mouthleds, LOW);
}
//putstring("vol = "); Serial.println(volume, DEC);
}
card.close_file(f);
}

void playfile(char *name) {
f = card.open_file(name);
if (!f) {
putstring_nl(" Couldn't open file"); return;
}
if (!wave.create(f)) {
putstring_nl(" Not a valid WAV"); return;
}
// ok time to play!
wave.play();
}

Baca Selengkapnya ....

20 Iptables Examples For New SysAdmins

Posted by Unknown 0 komentar

Linux comes with a host based firewall called Netfilter. According to the official project site:
netfilter is a set of hooks inside the Linux kernel that allows kernel modules to register callback functions with the network stack. A registered callback function is then called back for every packet that traverses the respective hook within the network stack.
This Linux based firewall is controlled by the program called iptables to handles filtering for IPv4, and ip6tables handles filtering for IPv6. I strongly recommend that you first read our quick tutorial that explains how to configure a host-based firewall called Netfilter (iptables) under CentOS / RHEL / Fedora / Redhat Enterprise Linux. This post list most common iptables solutions required by a new Linux user to secure his or her Linux operating system from intruders.

IPTABLES Rules Example

  • Most of the actions listed in this post are written with the assumption that they will be executed by the root user running the bash or any other modern shell. Do not type commands on remote system as it will disconnect your access.
  • For demonstration purpose I've used RHEL 6.x, but the following command should work with any modern Linux distro.
  • This is NOT a tutorial on how to set iptables. See tutorial here. It is a quick cheat sheet to common iptables commands.

#1: Displaying the Status of Your Firewall

Type the following command as root:
# iptables -L -n -v
Sample outputs:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Above output indicates that the firewall is not active. The following sample shows an active firewall:
# iptables -L -n -v
Sample outputs:
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
394 43586 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
93 17292 ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0
1 142 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- br0 br0 0.0.0.0/0 0.0.0.0/0
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
0 0 TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 wanin all -- vlan2 * 0.0.0.0/0 0.0.0.0/0
0 0 wanout all -- * vlan2 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 425 packets, 113K bytes)
pkts bytes target prot opt in out source destination
Chain wanin (1 references)
pkts bytes target prot opt in out source destination
Chain wanout (1 references)
pkts bytes target prot opt in out source destination
Where,
  • -L : List rules.
  • -v : Display detailed information. This option makes the list command show the interface name, the rule options, and the TOS masks. The packet and byte counters are also listed, with the suffix 'K', 'M' or 'G' for 1000, 1,000,000 and 1,000,000,000 multipliers respectively.
  • -n : Display IP address and port in numeric format. Do not use DNS to resolve names. This will speed up listing.

#1.1: To inspect firewall with line numbers, enter:

# iptables -n -L -v --line-numbers
Sample outputs:
Chain INPUT (policy DROP)
num target prot opt source destination
1 DROP all -- 0.0.0.0/0 0.0.0.0/0 state INVALID
2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
4 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
2 DROP all -- 0.0.0.0/0 0.0.0.0/0 state INVALID
3 TCPMSS tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
4 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
5 wanin all -- 0.0.0.0/0 0.0.0.0/0
6 wanout all -- 0.0.0.0/0 0.0.0.0/0
7 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
Chain wanin (1 references)
num target prot opt source destination
Chain wanout (1 references)
num target prot opt source destination
You can use line numbers to delete or insert new rules into the firewall.

#1.2: To display INPUT or OUTPUT chain rules, enter:

# iptables -L INPUT -n -v
# iptables -L OUTPUT -n -v --line-numbers

#2: Stop / Start / Restart the Firewall

If you are using CentOS / RHEL / Fedora Linux, enter:
# service iptables stop
# service iptables start
# service iptables restart

You can use the iptables command itself to stop the firewall and delete all rules:
# iptables -F
# iptables -X
# iptables -t nat -F
# iptables -t nat -X
# iptables -t mangle -F
# iptables -t mangle -X
# iptables -P INPUT ACCEPT
# iptables -P OUTPUT ACCEPT
# iptables -P FORWARD ACCEPT

Where,
  • -F : Deleting (flushing) all the rules.
  • -X : Delete chain.
  • -t table_name : Select table (called nat or mangle) and delete/flush rules.
  • -P : Set the default policy (such as DROP, REJECT, or ACCEPT).

#3: Delete Firewall Rules

To display line number along with other information for existing rules, enter:
# iptables -L INPUT -n --line-numbers
# iptables -L OUTPUT -n --line-numbers
# iptables -L OUTPUT -n --line-numbers | less
# iptables -L OUTPUT -n --line-numbers | grep 202.54.1.1

You will get the list of IP. Look at the number on the left, then use number to delete it. For example delete line number 4, enter:
# iptables -D INPUT 4
OR find source IP 202.54.1.1 and delete from rule:
# iptables -D INPUT -s 202.54.1.1 -j DROP
Where,
  • -D : Delete one or more rules from the selected chain

#4: Insert Firewall Rules

To insert one or more rules in the selected chain as the given rule number use the following syntax. First find out line numbers, enter:
# iptables -L INPUT -n --line-numbers
Sample outputs:
Chain INPUT (policy DROP)
num target prot opt source destination
1 DROP all -- 202.54.1.1 0.0.0.0/0
2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW,ESTABLISHED
To insert rule between 1 and 2, enter:
# iptables -I INPUT 2 -s 202.54.1.2 -j DROP
To view updated rules, enter:
# iptables -L INPUT -n --line-numbers
Sample outputs:
Chain INPUT (policy DROP)
num target prot opt source destination
1 DROP all -- 202.54.1.1 0.0.0.0/0
2 DROP all -- 202.54.1.2 0.0.0.0/0
3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW,ESTABLISHED

#5: Save Firewall Rules

To save firewall rules under CentOS / RHEL / Fedora Linux, enter:
# service iptables save
In this example, drop an IP and save firewall rules:
# iptables -A INPUT -s 202.5.4.1 -j DROP
# service iptables save

For all other distros use the iptables-save command:
# iptables-save > /root/my.active.firewall.rules
# cat /root/my.active.firewall.rules

#6: Restore Firewall Rules

To restore firewall rules form a file called /root/my.active.firewall.rules, enter:
# iptables-restore < /root/my.active.firewall.rules
To restore firewall rules under CentOS / RHEL / Fedora Linux, enter:
# service iptables restart

#7: Set the Default Firewall Policies

To drop all traffic:
# iptables -P INPUT DROP
# iptables -P OUTPUT DROP
# iptables -P FORWARD DROP
# iptables -L -v -n
#### you will not able to connect anywhere as all traffic is dropped ###
# ping cyberciti.biz
# wget http://www.kernel.org/pub/linux/kernel/v3.0/testing/linux-3.2-rc5.tar.bz2

#7.1: Only Block Incoming Traffic

To drop all incoming / forwarded packets, but allow outgoing traffic, enter:
# iptables -P INPUT DROP
# iptables -P FORWARD DROP
# iptables -P OUTPUT ACCEPT
# iptables -A INPUT -m state --state NEW,ESTABLISHED -j ACCEPT
# iptables -L -v -n
### *** now ping and wget should work *** ###
# ping cyberciti.biz
# wget http://www.kernel.org/pub/linux/kernel/v3.0/testing/linux-3.2-rc5.tar.bz2

#8:Drop Private Network Address On Public Interface

IP spoofing is nothing but to stop the following IPv4 address ranges for private networks on your public interfaces. Packets with non-routable source addresses should be rejected using the following syntax:
# iptables -A INPUT -i eth1 -s 192.168.0.0/24 -j DROP
# iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP

#8.1: IPv4 Address Ranges For Private Networks (make sure you block them on public interface)

  • 10.0.0.0/8 -j (A)
  • 172.16.0.0/12 (B)
  • 192.168.0.0/16 (C)
  • 224.0.0.0/4 (MULTICAST D)
  • 240.0.0.0/5 (E)
  • 127.0.0.0/8 (LOOPBACK)

#9: Blocking an IP Address (BLOCK IP)

To block an attackers ip address called 1.2.3.4, enter:
# iptables -A INPUT -s 1.2.3.4 -j DROP
# iptables -A INPUT -s 192.168.0.0/24 -j DROP

#10: Block Incoming Port Requests (BLOCK PORT)

To block all service requests on port 80, enter:
# iptables -A INPUT -p tcp --dport 80 -j DROP
# iptables -A INPUT -i eth1 -p tcp --dport 80 -j DROP

To block port 80 only for an ip address 1.2.3.4, enter:
# iptables -A INPUT -p tcp -s 1.2.3.4 --dport 80 -j DROP
# iptables -A INPUT -i eth1 -p tcp -s 192.168.1.0/24 --dport 80 -j DROP

#11: Block Outgoing IP Address

To block outgoing traffic to a particular host or domain such as cyberciti.biz, enter:
# host -t a cyberciti.biz
Sample outputs:
cyberciti.biz has address 75.126.153.206
Note down its ip address and type the following to block all outgoing traffic to 75.126.153.206:
# iptables -A OUTPUT -d 75.126.153.206 -j DROP
You can use a subnet as follows:
# iptables -A OUTPUT -d 192.168.1.0/24 -j DROP
# iptables -A OUTPUT -o eth1 -d 192.168.1.0/24 -j DROP

#11.1: Example - Block Facebook.com Domain

First, find out all ip address of facebook.com, enter:
# host -t a www.facebook.com
Sample outputs:
www.facebook.com has address 69.171.228.40
Find CIDR for 69.171.228.40, enter:
# whois 69.171.228.40 | grep CIDR
Sample outputs:
CIDR:           69.171.224.0/19
To prevent outgoing access to www.facebook.com, enter:
# iptables -A OUTPUT -p tcp -d 69.171.224.0/19 -j DROP
You can also use domain name, enter:
# iptables -A OUTPUT -p tcp -d www.facebook.com -j DROP
# iptables -A OUTPUT -p tcp -d facebook.com -j DROP

From the iptables man page:
... specifying any name to be resolved with a remote query such as DNS (e.g., facebook.com is a really bad idea), a network IP address (with /mask), or a plain IP address ...

#12: Log and Drop Packets

Type the following to log and block IP spoofing on public interface called eth1
# iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j LOG --log-prefix "IP_SPOOF A: "
# iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP

By default everything is logged to /var/log/messages file.
# tail -f /var/log/messages
# grep --color 'IP SPOOF' /var/log/messages

#13: Log and Drop Packets with Limited Number of Log Entries

The -m limit module can limit the number of log entries created per time. This is used to prevent flooding your log file. To log and drop spoofing per 5 minutes, in bursts of at most 7 entries .
# iptables -A INPUT -i eth1 -s 10.0.0.0/8 -m limit --limit 5/m --limit-burst 7 -j LOG --log-prefix "IP_SPOOF A: "
# iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP

#14: Drop or Accept Traffic From Mac Address

Use the following syntax:
# iptables -A INPUT -m mac --mac-source 00:0F:EA:91:04:08 -j DROP
## *only accept traffic for TCP port # 8080 from mac 00:0F:EA:91:04:07 * ##
# iptables -A INPUT -p tcp --destination-port 22 -m mac --mac-source 00:0F:EA:91:04:07 -j ACCEPT

#15: Block or Allow ICMP Ping Request

Type the following command to block ICMP ping requests:
# iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
# iptables -A INPUT -i eth1 -p icmp --icmp-type echo-request -j DROP

Ping responses can also be limited to certain networks or hosts:
# iptables -A INPUT -s 192.168.1.0/24 -p icmp --icmp-type echo-request -j ACCEPT
The following only accepts limited type of ICMP requests:
### ** assumed that default INPUT policy set to DROP ** #############
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
## ** all our server to respond to pings ** ##
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

#16: Open Range of Ports

Use the following syntax to open a range of ports:
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 7000:7010 -j ACCEPT

#17: Open Range of IP Addresses

Use the following syntax to open a range of IP address:
## only accept connection to tcp port 80 (Apache) if ip is between 192.168.1.100 and 192.168.1.200 ##
iptables -A INPUT -p tcp --destination-port 80 -m iprange --src-range 192.168.1.100-192.168.1.200 -j ACCEPT

## nat example ##
iptables -t nat -A POSTROUTING -j SNAT --to-source 192.168.1.20-192.168.1.25

#17: Established Connections and Restaring The Firewall

When you restart the iptables service it will drop established connections as it unload modules from the system under RHEL / Fedora / CentOS Linux. Edit, /etc/sysconfig/iptables-config and set IPTABLES_MODULES_UNLOAD as follows:
IPTABLES_MODULES_UNLOAD = no

#18: Help Iptables Flooding My Server Screen

Use the crit log level to send messages to a log file instead of console:
iptables -A INPUT -s 1.2.3.4 -p tcp --destination-port 80 -j LOG --log-level crit

#19: Block or Open Common Ports

The following shows syntax for opening and closing common TCP and UDP ports:
 
Replace ACCEPT with DROP to block port:
## open port ssh tcp port 22 ##
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 22 -j ACCEPT
 
## open cups (printing service) udp/tcp port 631 for LAN users ##
iptables -A INPUT -s 192.168.1.0/24 -p udp -m udp --dport 631 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -p tcp -m tcp --dport 631 -j ACCEPT
 
## allow time sync via NTP for lan users (open udp port 123) ##
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 123 -j ACCEPT
 
## open tcp port 25 (smtp) for all ##
iptables -A INPUT -m state --state NEW -p tcp --dport 25 -j ACCEPT
 
# open dns server ports for all ##
iptables -A INPUT -m state --state NEW -p udp --dport 53 -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp --dport 53 -j ACCEPT
 
## open http/https (Apache) server port to all ##
iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT
 
## open tcp port 110 (pop3) for all ##
iptables -A INPUT -m state --state NEW -p tcp --dport 110 -j ACCEPT
 
## open tcp port 143 (imap) for all ##
iptables -A INPUT -m state --state NEW -p tcp --dport 143 -j ACCEPT
 
## open access to Samba file server for lan users only ##
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 137 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 138 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 139 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 445 -j ACCEPT
 
## open access to proxy server for lan users only ##
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 3128 -j ACCEPT
 
## open access to mysql server for lan users only ##
iptables -I INPUT -p tcp --dport 3306 -j ACCEPT
 

#20: Restrict the Number of Parallel Connections To a Server Per Client IP

You can use connlimit module to put such restrictions. To allow 3 ssh connections per client host, enter:
# iptables -A INPUT -p tcp --syn --dport 22 -m connlimit --connlimit-above 3 -j REJECT
Set HTTP requests to 20:
# iptables -p tcp --syn --dport 80 -m connlimit --connlimit-above 20 --connlimit-mask 24 -j DROP
Where,
  1. --connlimit-above 3 : Match if the number of existing connections is above 3.
  2. --connlimit-mask 24 : Group hosts using the prefix length. For IPv4, this must be a number between (including) 0 and 32.

#21: HowTO: Use iptables Like a Pro

For more information about iptables, please see the manual page by typing man iptables from the command line:
$ man iptables
You can see the help using the following syntax too:
# iptables -h
To see help with specific commands and targets, enter:
# iptables -j DROP -h

#21.1: Testing Your Firewall

Find out if ports are open or not, enter:
# netstat -tulpn
Find out if tcp port 80 open or not, enter:
# netstat -tulpn | grep :80
If port 80 is not open, start the Apache, enter:
# service httpd start
Make sure iptables allowing access to the port 80:
# iptables -L INPUT -v -n | grep 80
Otherwise open port 80 using the iptables for all users:
# iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
# service iptables save

Use the telnet command to see if firewall allows to connect to port 80:
$ telnet www.cyberciti.biz 80
Sample outputs:
Trying 75.126.153.206...
Connected to www.cyberciti.biz.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
You can use nmap to probe your own server using the following syntax:
$ nmap -sS -p 80 www.cyberciti.biz
Sample outputs:
Starting Nmap 5.00 ( http://nmap.org ) at 2011-12-13 13:19 IST
Interesting ports on www.cyberciti.biz (75.126.153.206):
PORT STATE SERVICE
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 1.00 seconds
I also recommend you install and use sniffer such as tcpdupm and ngrep to test your firewall settings.

Conclusion:

This post only list basic rules for new Linux users. You can create and build more complex rules. This requires good understanding of TCP/IP, Linux kernel tuning via sysctl.conf, and good knowledge of your own setup. Stay tuned for next topics:
  • Stateful packet inspection.
  • Using connection tracking helpers.
  • Network address translation.
  • Layer 2 filtering.
  • Firewall testing tools.
  • Dealing with VPNs, DNS, Web, Proxy, and other protocols.

Baca Selengkapnya ....

tcpdump fu

Posted by Unknown 0 komentar

Packet capture is one of the most fundamental and powerful ways to do network analysis. You can learn virtually anything about what is going on within a network by intercepting and examining the raw data that crosses it. Modern network analysis tools are able to capture, interpret and describe this network traffic in a human-friendly manner.
tcpdump is one of the original packet capture (or "sniffing") tools that provide these analysis capabilities, and even though it now shares the field with many other utilities, it remains one of the most powerful and flexible.
If you think that tcpdump has been made obsolete by GUI tools like Wireshark, think again. Wireshark is a great application; it's just not the right tool for the job in every situation. As a refined, universal, lightweight command-line utility—much like cat, less and hexdump—tcpdump satisfies a different type of need.
One of tcpdump's greatest strengths is its convenience. It uses a "one-off-command" approach that lends itself to quick, on-the-spot answers. It works through an SSH session, doesn't need X and is more likely to be there when you need it. And, because it uses standard command-line conventions (such as writing to STDOUT, which can be redirected), tcpdump can be used in all sorts of creative, interesting and extremely useful ways.
In this article, I introduce some of the basics of packet capture and provide a breakdown of tcpdump syntax and usage. I show how to use tcpdump to zero in on specific packets and reveal the useful information they contain. I provide some real-world examples of how tcpdump can help put the details of what's happening on your network at your fingertips, and why tcpdump is still a must-have in any admin's toolbox.

Essential Concepts

Before you can begin to master tcpdump, you should understand some of the fundamentals that apply to using all packet sniffers:
  • Packet capturing is passive—it doesn't transmit or alter network traffic.
  • You can capture only the packets that your system receives. On a typical switched network, that excludes unicast traffic between other hosts (packets not sent to or from your machine).
  • You can capture only packets addressed to your system, unless the network interface is in promiscuous mode.
It is assumed that you're interested in seeing more than just your local traffic, so tcpdump turns on promiscuous mode automatically (which requires root privileges). But, in order for your network card to receive the packets in the first place, you still have to be where the traffic is, so to speak.

Anatomy of a tcpdump Command

A tcpdump command consists of two parts: a set of options followed by a filter expression (Figure 1).
Figure 1. Example tcpdump Command
The expression identifies which packets to capture, and the options define, in part, how those packets are displayed as well as other aspects of program behavior.

Options

tcpdump options follow the standard command-line flag/switch syntax conventions. Some flags accept a parameter, such as -i to specify the capture interface, while others are standalone switches and can be clustered, such as -v to increase verbosity and -n to turn off name resolution.
The man page for tcpdump lists all available options, but here are a few of the noteworthy ones:
  • -i interface: interface to listen on.
  • -v, -vv, -vvv: more verbose.
  • -q: less verbose.
  • -e: print link-level (Ethernet) headers.
  • -N: display relative hostnames.
  • -t: don't print timestamps.
  • -n: disable name lookups.
  • -s0 (or -s 0): use the max "snaplen"—capture full packets (default in recent versions of tcpdump).
None of these are required. User-supplied options simply modify the default program behavior, which is to capture from the first interface, and then print descriptions of matching packets on the screen in a single-line format.

Filter Expression

The filter expression is the Boolean (true or false) criteria for "matching" packets. All packets that do not match the expression are ignored.
The filter expression syntax is robust and flexible. It consists primarily of keywords called primitives, which represent various packet-matching qualifiers, such as protocol, address, port and direction. These can be chained together with and/or, grouped and nested with parentheses, and negated with not to achieve virtually any criteria.
Because the primitives have friendly names and do a lot of the heavy lifting, filter expressions are generally self-explanatory and easy to read and construct. The syntax is fully described in the pcap-filter man page, but here are a few example filter expressions:
  • tcp
  • port 25 and not host 10.0.0.3
  • icmp or arp or udp
  • vlan 3 and ether src host aa:bb:cc:dd:ee:ff
  • arp or udp port 53
  • icmp and \(dst host mrorange or dst host mrbrown\)
Like the options, filter expressions are not required. An empty filter expression simply matches all packets.

Understanding tcpdump Output

How much sense the output makes depends on how well you understand the protocols in question. tcpdump tailors its output to match the protocol(s) of the given packet.
For example, ARP packets are displayed like this when tcpdump is called with -t and -n (timestamps and name lookups turned off):

arp who-has 10.0.0.1 tell 10.0.0.2
arp reply 10.0.0.1 is-at 00:01:02:03:04:05

ARP is a simple protocol used to resolve IPs into MAC addresses. As you can see above, tcpdump describes these packets in a correspondingly simple format. DNS packets, on the other hand, are displayed completely different:

IP 10.0.0.2.50435 > 10.0.0.1.53: 19+ A? linuxjournal.com. (34)
IP 10.0.0.1.53 > 10.0.0.2.50435: 19 1/0/0 A 76.74.252.198 (50)

This may seem cryptic at first, but it makes more sense when you understand how protocol layers work. DNS is a more complicated protocol than ARP to begin with, but it also operates on a higher layer. This means it runs over top of other lower-level protocols, which also are displayed in the output.
Unlike ARP, which is a non-routable, layer-3 protocol, DNS is an Internet-wide protocol. It relies on UDP and IP to carry and route it across the Internet, which makes it a layer-5 protocol (UDP is layer-4, and IP is layer-3).
The underlying UDP/IP information, consisting of the source and destination IP/port, is displayed on the left side of the colon, followed by the remaining DNS-specific information on the right.
Even though this DNS information still is displayed in a highly condensed format, you should be able to recognize the essential elements if you know the basics of DNS. The first packet is a query for linuxjournal.com, and the second packet is an answer, giving the address 76.74.252.198. These are the kind of packets that are generated from simple DNS lookups.
See the "OUTPUT FORMAT" section of the tcpdump man page for complete descriptions of all the supported protocol-specific output formats. Some protocols are better served than others by their output format, but I've found that tcpdump does a pretty good job in general of showing the most useful information about a given protocol.

Capture Files

In addition to its normal behavior of printing packet descriptions to the screen, tcpdump also supports a mode of operation where it writes packets to a file instead. This mode is activated when the -w option is used to specify an output capture file.
When writing to a file, tcpdump uses a completely different format from when it writes to the screen. When writing to the screen, formatted text descriptions of packets are printed. When writing to a file, the raw packets are recorded as is, without analysis.
Instead of doing a live capture, tcpdump also can read from an existing capture file as input with the -r option. Because tcpdump capture files use the universally supported "pcap" format, they also can be opened by other applications, including Wireshark.
This gives you the option to capture packets with tcpdump on one host, but perform analysis on a different host by transferring and loading the capture file. This lets you use Wireshark on your local workstation without having to attach it to the network and location you need to capture from.

Analyzing TCP-Based Application Protocols

tcpdump is a packet-based analyzer, and it works great for connectionless, packet-based protocols like IP, UDP, DHCP, DNS and ICMP. However, it cannot directly analyze "connection-oriented" protocols, such as HTTP, SMTP and IMAP, because they work completely different.
They do not have the concept of "packets". Instead, they operate over the stream-based connections of TCP, which provide an abstracted communications layer. These application protocols are really more like interactive console programs than packet-based network protocols.
TCP transparently handles all of the underlying details required to provide these reliable, end-to-end, session-style connections. This includes encapsulating the stream-based data into packets (called segments) that can be sent across the network. All of these details are hidden below the application layer.
In order to capture TCP-based application protocols, an extra step is needed beyond capturing packets. Because each TCP segment is only a slice of application data, it can't be used individually to obtain any meaningful information. You first must reassemble TCP sessions (or flows) from the combined sets of individual segments/packets. The application protocol data is contained directly within the sessions.
tcpdump doesn't have an option to assemble TCP sessions from packets directly, but you can "fake" it by using what I call "the tcpdump strings trick".

The tcpdump Strings Trick

Usually when I'm capturing traffic, it's just for the purpose of casual analysis. The data doesn't need to be perfect if it shows me what I'm looking for and helps me gain some insight.
In these cases, speed and convenience reign supreme. The following trick is along these lines and is one of my favorite tcpdump techniques. It works because:
  1. TCP segments usually are sent in chronological order.
  2. Text-based application protocols produce TCP segments with text payloads.
  3. The data surrounding the text payloads, such as packet headers, is usually not text.
  4. The UNIX command strings filters out binary data from streams preserving only text (printable characters).
  5. When tcpdump is called with -w - it prints raw packets to STDOUT.
Put it all together, and you get a command that dumps real-time HTTP session data:

tcpdump -l -s0 -w - tcp dst port 80 | strings

The -l option above turns on line buffering, which makes sure data gets printed to the screen right away.
What is happening here is tcpdump is printing the raw, binary data to the screen. This uses a twist on the -w option where the special filename - writes to STDOUT instead of a file. Normally, doing this would display all kinds of gibberish, but that's where the strings command comes in—it allows only data recognized as text through to the screen.
There are few caveats to be aware of. First, data from multiple sessions received simultaneously is displayed simultaneously, clobbering your output. The more refined you make the filter expression, the less of a problem this will be. You also should run separate commands (in separate shells) for the client and server side of a session:

tcpdump -l -s0 -w - tcp dst port 80 | strings
tcpdump -l -s0 -w - tcp src port 80 | strings

Also, you should expect to see a few gibberish characters here and there whenever a sequence of binary data also happens to look like text characters. You can cut down on this by increasing min-len (see the strings man page).
This trick works just as well for other text-based protocols.

HTTP and SMTP Analysis

Using the strings trick in the previous section, you can capture HTTP data even though tcpdump doesn't actually understand anything about it. You then can "analyze" it further in any number of ways.
If you wanted to see all the Web sites being accessed by "davepc" in real time, for example, you could run this command on the firewall (assume the internal interface is eth1):

tcpdump -i eth1 -l -s0 -w - host davepc and port 80 \
| strings | grep 'GET\|Host'

In this example, I'm using a simple grep command to display only lines with GET or Host. These strings show up in HTTP requests and together show the URLs being accessed.
This works just as well for SMTP. You could run this on your mail server to watch e-mail senders and recipients:

tcpdump -l -s0 -w - tcp dst port 25 | strings \
| grep -i 'MAIL FROM\|RCPT TO'

These are just a few silly examples to illustrate what's possible. You obviously could take it beyond grep. You could go as far as to write a Perl script to do all sorts of sophisticated things. You probably wouldn't take that too far, however, because at that point, there are better tools that actually are designed to do that sort of thing.
The real value of tcpdump is the ability to do these kinds of things interactively and on a whim. It's the power to look inside any aspect of your network whenever you want without a lot of effort.

Debugging Routes and VPN Links

tcpdump is really handy when debugging VPNs and other network connections by showing where packets are showing up and where they aren't. Let's say you've set up a standard routable network-to-network VPN between 10.0.50.0/24 and 192.168.5.0/24 (Figure 2).
illustration of a standard routable network-to-network VPN Figure 2. Example VPN Topology
If it's operating properly, hosts from either network should be able to ping one another. However, if you are not getting replies when pinging host D from host A, for instance, you can use tcpdump to zero in on exactly where the breakdown is occurring:

tcpdump -tn icmp and host 10.0.50.2

In this example, during a ping from 10.0.50.2 to 192.168.5.38, each round trip should show up as a pair of packets like the following, regardless of from which of the four systems the tcpdump command is run:

IP 10.0.50.2 > 192.168.5.38: ICMP echo request,
↪id 46687, seq 1, length 64
IP 192.168.5.38 > 10.0.50.2: ICMP echo reply,
↪id 46687, seq 1, length 64

If the request packets make it to host C (the remote gateway) but not to D, this indicates that the VPN itself is working, but there could be a routing problem. If host D receives the request but doesn't generate a reply, it probably has ICMP blocked. If it does generate a reply but it doesn't make it back to C, then D might not have the right gateway configured to get back to 10.0.50.0/24.
Using tcpdump, you can follow the ping through all eight possible points of failure as it makes its way across the network and back again.

Conclusion

I hope this article has piqued your interest in tcpdump and given you some new ideas. Hopefully, you also enjoyed the examples that barely scratch the surface of what's possible.
Besides its many built-in features and options, as I showed in several examples, tcpdump can be used as a packet-data conduit by piping into other commands to expand the possibilities further—even if you do manage to exhaust its extensive "advertised" capabilities. The ways to use tcpdump are limited only by your imagination.
tcpdump also is an incredible learning tool. There is no better way to learn how networks and protocols work than from watching their actual packets.
Don't forget to check out the tcpdump and pcap-filter man pages for additional details and information.

The tcpdump/libpcap Legacy

tcpdump has been the de facto packet capture tool for the past 25 years. It really did spawn the whole genre of network utilities based on sniffing and analyzing packets. Prior to tcpdump, packet capture had such high processing demands that it was largely impractical. tcpdump introduced some key innovations and optimizations that helped make packet capture more viable, both for regular systems and for networks with a lot of traffic.
The utilities that came along afterward not only followed tcpdump's lead, but also directly incorporated its packet capture functionality. This was possible because very early on, tcpdump's authors decided to move the packet capture code into a separate portable library called libpcap.
Wireshark, ntop, snort, iftop, ngrep and hundreds of other applications and utilities available today are all based on libpcap. Even most packet capture applications for Windows are based on a port of libpcap called WinPcap.

Resources

tcpdump and libpcap: http://www.tcpdump.org
Wireshark: http://www.wireshark.org
TCP/IP Model: http://en.wikipedia.org/wiki/TCP/IP_model


Baca Selengkapnya ....
Trik SEO Terbaru support Online Shop Baju Wanita - Original design by Bamz | Copyright of android blackberry.