Thanks.

The documentation link on the site is invalid. Would you know of any hping documentation.

Hi

Just google for hping3, there is loads around

and example if generating traffic with hping3 with udp is below:-

hping3 --udp -p 10000 --destport 10000 192.168.1.1

This is sending udp packets from your ip port 1000 to 192.168.1.1 port 10000

Here is the HTML man page for hping3

http://linux.die.net/man/8/hping3

hi,

When I try

hping --icmp 1.1.1.1

I see repetition of router_get() and 100% packet loss at the end. But plain ping works.

And on doing hping to myself, I can arp_get().

What do I need to do to make it work.

Works fine for me, your install must be broken

# /usr/sbin/hping3 --icmp 4.2.2.2

HPING 4.2.2.2 (eth0 4.2.2.2): icmp mode set, 28 headers + 0 data bytes

len=46 ip=4.2.2.2 ttl=240 DF id=40353 icmp_seq=0 rtt=16.9 ms

len=46 ip=4.2.2.2 ttl=240 DF id=40354 icmp_seq=1 rtt=16.9 ms

len=46 ip=4.2.2.2 ttl=240 DF id=40355 icmp_seq=2 rtt=16.9 ms

len=46 ip=4.2.2.2 ttl=240 DF id=40356 icmp_seq=3 rtt=16.6 ms

When I used NMAP, the 5555 UDP port showed as 'open|filtered'. But when I used 'hping 1.1.1.1 --udp -p 5555', I didn't get any response. Why is it so ?

I will try out Netcat as well.

I would guess that since udp is connectionless and you got no response back that it was NOT open, it would be shown as open|filtered in NMAP.

which means that no packets were recieved telling you that it is NOT open.

Since you get no packet back that is what Hping also is telling you.

The best way to test firewalls/access-lists IMHO is to install a sniffer on the target mashine and then test the type of communication with netcat and a scanner. The scanner to se if anything gets through and netcat to test the connection goes to the intended target mashine and back.

I tried netcat and it showed as 'open'. This is opposed to hping (no response) and nmap (open|filtered).

hing3 is not a port scanner, it's in essence a packet generator which you can use to (among other things) test firewall rules which is what you asked for is it not ?

If the firewall has blocked udp port, then Netcat shouldn't have worked. Is that correct understanding.

Not sure about the netcat output but I would trust nmap more, here is an explanation of the open|filtered

Nmap reports the state combinations open|filtered and closed|filtered when it cannot determine which of the two states describe a port

This suggests that the communication failed.

If you want real proof and have access to the firewall you can do the following.

IOS

Add a log entry to your ACL line and see if the counter goes up and if you are logging to console do sh log and you should see a denied syslog message like the following :-

%SEC-6-IPACCESSLOGP: list denied ->

if it's an ASA/PIX/FWSM you can use a similar approach or use the capture command to see if it is making it through the firewall.

Yes that is correct if i understand your question right.

since I am not shure i do understand exactly what you are explaining. I will give an example instead. in a windows environment.

sender(transmitter) ip 1.1.1.1

- I

Access-list

- I

reciever ip 2.2.2.2 udp port 12345

Sender is in a cmd window.

nc -u 2.2.2.2 12345

access-list 100 permit udp host 1.1.1.1 host 2.2.2.2 eq 12345

applied on the inbound of the interface connected to 1.1.1.1

reciever is in a cmd window.

nc -u -e cmd.exe -L -p 12345

this would give the result that NC after 2 enters in the senders cmd window will show up a "dos" promt of the 2.2.2.2 computer in the cmd window of 1.1.1.1

(do a ipconfig to be shure)

If the access-list is wrong and fails then nc would not have a connection.

if the access-list is correct and works it would let the udp traffic from 1.1.1.1 to 2.2.2.2 port 12345 pass and since the return traffic is not inspected it will (providing routes are correct) work just fine.

If you have a more complicated access-list I would put a monitor on the recieving port of the switch that goes to the target. then start a sniff and start hammering away with the nmap portscanner.

why sniff ?

well you want to know if the packets get there, if you only check connections then you might miss that you can have one way traffic going through.

you might not be able to get a tcp connection but still get information to a listener on the other side.

good luck