It does work...

Quote:

If the interface is already bound to that address then the kernel already knows where it is and will simply send the packets to itself - over the loopback.

This is true. Any packet destined to any address we own on any interface will be bounced to the loopback interface. But this interface won't rewrite any source and/or destination address. As you will see..

Quote:

IP addresses are properties of hosts *NOT* interfaces.

Strictly speaking, each network interface must have at least one IP address. Interfaces have addresses, and a machine must have interfaces... who's who?

Let's test things...
For this test to work, you must install netcat and hping2.

Setup an UDP server (any user may open a port on the system)

Code:

nc -l -p 8000 -u -v

Now, you need root to fake your source address with hping (as I did with 177...):

Code:

[root@localhost root]# hping2 -c 1 -2 -a 177.77.77.77 -p 8000  201.249.160.92
HPING 201.249.160.92 (ppp0 201.249.160.92): udp mode set, 28 headers + 0 data bytes

--- 201.249.160.92 hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

On the terminal you run netcat, you will see something like this:

Code:

[primo@localhost primo]$ nc -l -p 8000 -u -v
listening on [any] 8000 ...
177.77.77.77: inverse host lookup failed: Unknown host
connect to [201.249.160.92] from (UNKNOWN) [177.77.77.77] 1984

If you want to see netfilter working, setup rules which accept only 127.0.0.1 on the loopback interface, and use -j LOG

Quote:

If you want to scan your machine 'from the Internet' head over to one of the websites which offer this service such as http://grc.com

This is a waste of time. If you only want to see your open ports, run netstat. These things only have sense to test if your firewall is stealthy, and they don't feature all the possible scan types as nmap (nor nmap lets you do ACK|FIN or ACK|PSH scans which works too). The only worthy test is external traceroute, just to get the grip of how these things work. Tell a friend to nmap you. Take the time to learn these things, because they're fun.

For traceroute, even on your own host, beautiful things may be done with hping

Technically, interfaces do NOT need IP addresses. Take, for example, an ethernet bridge, or an ATA over Ethernet network. Sorry, I agree with most of what you say, but I just read an article on Ethernet Bridging that made a big deal of interfaces NOT requiring IP addresses, so I couldn't help myself.

I agree 110%.

So what's a good way to learn the powers of hping?

I think you've misunderstood what I was trying to say. Of course it works - as I said in the next sentence it just goes over the loopback interface...

And how does this test your firewall from the internet? Again you appear to have missed my point. I wasn't saying you couldn't spoof some packets over the loopback I was saying that doing so does nothing to verify or test what kind of firewalling you have for packets coming in from the net, which is what this thread is about.

netstat only shows you ports open by processes running at that time. It shows absolutely nothing about your firewall and wether those any of those bound ports can be accessed from the net. That's why you still need sites like grc.com (or getting a friend to nmap you) to actually verify your firewall rules.

Agreed - there's no substitute for an experienced friend nmap'ing your box from outside. However in the absence of such a person being there all the time for you sites like GRC provide a quick and easy way to verify that your firewall rules have turned out as you expected them to.

This is true, an Ethernet bridge doesn't need an IP address. It uses its own hardware address, although it's possible to implement in software. An interface is an abstraction used by the operating system which uses its own witchcraft to transfer data from a hardware device to/from memory.

Quote:

So what's a good way to learn the powers of hping?

Read the manpage one time to get some vision. Then try the many options (there is one for every possible field in TCP/UDP/IP/ICMP headers)

This program lacks the newer --packet_trace option to nmap, so it's better to set rules with -j LOG in iptables to see the packets as the firewall receives them

With hping it's possible to learn about iptables too (and of course TCP/IP).
For example, I discovered with it that "-m state --state ESTABLISHED" includes any reply too (which for TCP may be a SYN|ACK or RST), and not what the manpage says: "the packet is associated with a connection which has seen packets in both directions". So, this depends on interpretation: the packet is first associated with a connection attempt, and then it checks if it has been seen in both directions

Man, you MAY test your firewall with this... Try:
Then, nmap your ethernet/ppp/etc interfaces.

The -e option to nmap "Tells nmap what interface to send and receive packets on."

Why this works?:
Remember that netfilter may attach to any interface. Not all localhost traffic is accepted if you set up netfilter.

On testing or not testing from the outside:
If you're on a router or using NAT, this is a must...

No this doesn't work:
On the localhost:
Trying from a computer in the outside world reveals this port as closed. You can verify it too - try to ssh into www.registriesltd.com.au on port 22.

I'll repeat myself again. You cannot test your firewall rules for packets coming from the net on the local machine. You must use an external machine. It doesn't matter what clever IP spoofing or nmap interface options you use - it simply doesn't work. The kernel will always send the packets over the local loopback interface because there is logically (and physically) no where else for them to go.

This means that no matter what you do you are simply testing the iptables rules that apply to the local loopback which are almost always a simple 'let everything through' or 'let through everything from 127.0.0.1'. Irrespective of what these rules are you *ARE NOT* in any way testing the rules that apply to packets coming in from the net.

Didn't work? Why did it show the ssh port?
It appears open to you because you're accepting localhost traffic.

To really test your firewall from your localhost, delete the rule that accepts packets on the loopback interface... I always run this script before I scan myself:

Code:

#!/bin/sh

ip=$(ifconfig ppp0 | grep addr: | gawk '{ print $2 }' | gawk -F : '{ print $2 }')

echo $ip

[ -z $ip ] && echo Exiting... && exit 1

iptables -I INPUT -i lo ! -d $ip -j ACCEPT
iptables -I OUTPUT -o lo ! -s $ip -j ACCEPT
iptables -D INPUT -i lo -j ACCEPT
iptables -D OUTPUT -o lo -j ACCEPT

Quote:

I'll repeat myself again. You cannot test your firewall rules for packets coming from the net on the local machine. You must use an external machine. It doesn't matter what clever IP spoofing or nmap interface options you use - it simply doesn't work. The kernel will always send the packets over the local loopback interface because there is logically (and physically) no where else for them to go.

This is because the rules for localhost traffic are different. This is what you're saying here:

Quote:

This means that no matter what you do you are simply testing the iptables rules that apply to the local loopback which are almost always a simple 'let everything through' or 'let through everything from 127.0.0.1'. Irrespective of what these rules are you *ARE NOT* in any way testing the rules that apply to packets coming in from the net.

Well, the fact is that it is possible to scan yourself but, if you're running a firewall, you have to setup some rules... if you're not, then all packets are accepted and it's perfectly valid.
One possible pitfall of scanning from the outside is that some packets may get dropped at intermediate routers...

Because the rules for localhost traffic are different, one would think it is advisable to scan from the outside world. All kinds of rules, other than accept from localhost, could also be affected by this handling of packets, such as rules that compare netmasks and the interface to check for spoofed LAN ips.

Well, to get the real vision, it must be done. I always try first from localhost. Some packets are dropped in the internet, so the only way for me to test all possible cases is to try it from my machine.

I still think that it's worthless to scan yourself from grc.com (or any such site) if you're not running a firewall.

What I don't like about these sites is that they concentrate security on open ports only. Anyway, this site really scares me: http://gemal.dk/browserspy/
It's a good complement to online testing and they include a traceroute

Exactly my point - it showed open for the local loopback but its not open on the net, therefore scanning the local loopback is not a way to test which ports are open on the internet interface.

What are you talking about? Of course its possible to scan yourself but you're only scanning your local loopback interface. This gives absolutely *NO* indication of the firewall rules active on your internet facing interface.

Its completely irrelevant. There is no security added by having any firewall rules on the local loopback and therefore as long as your local loopback is working there is no point scanning it.

Obviously, when has anyone ever said any different?

No, you aren't scanning the loopback interface. Have you ever tried the tests above?
One thing is the loopback interface (inet addr: 127.0.0.1), and another is the driver for this loopback interface. Packets destined to any host's interfaces are passed to this driver only to avoid copying data between buffers in your TCP/IP stack. Filtering is done and, as far as I know, this works on Solaris and BSD too... It's a very logic thing, since the Operating System does not have to accept localhost traffic if you're filtering it.


Untrue. You may access ANY local interface you own.

Of course. This test serves only the purpose of accessing it as if you're accessing from the net. Also, testing from any host of the internet won't give you the same information everytime...

Why it works (again, one more time):
Filtering is done based on rules. These rules let you specify interfaces, source & destination addresses, ports, and so on... Depending on these rules, it may be easy or not to test these firewall rules from your own host: with Linux it's easy if you define chains and later make these rules for interfaces to traverse these chains. It's not so easy in a router when you have +2 interfaces but it's possible too...

The filtering rules, even if you specify -e eth0, will see it as a 'lo' connection. Yes, IPs will not be 127.0.0.1, but it still doesn't make it a perfect test.

It's not a perfect test if you have 3+ interfaces.

However, when filtering is done specifying interfaces, you may still test these chains and rules from within your localhost just attaching these chains to the loopback interface, or changing "eth1" for "lo". This may be done.

If you just have 2 interfaces (one loopback and another ethernet/dialup/etc), it's easier if you just setup rules for the loopback interface and let the remaining rules be applied for "all".

Rules that accept everything on the loopback interface are almost set everytime. If you just set it up to accept only 127.0.0.1 then you may test these remaining rules.

I, personally, do have a convoluted gateway setup, but that's just me... three ethernet cards, so it can become a bit confusing from an interface point of view. But that's what I get for the complexity

Exactly what I've been saying - any packets sent to a local IP (wether its your internet IP or not) will be sent through the local loopback. You're just restating it in a different way.

I never said you couldn't. I said you couldn't scan it as though the packets you send in your scan come from an external source, such as the net.

How many times does this have to be said before you'll get it. Sending packets over the local loopback interface, which is what your doing when you send *ANY* packets to your own IP address, *DOES NOT* test the rules you have for packets coming in from the net. No matter what options you use to programs like nmap or hping the kernel sees the packets as coming over the loopback and applies the firewall rules that you have set for the local loopback interface, NOT the ones you have for the internet facing interface.

Well der, you've just described how iptables works. What's your point?

Exactly. Except I'd add that it only tests the rules you have for the local loopback interface, which on almost all setups will simply let everything through and usually have no relation to the rules you have for your internet connected interface.