ICMP packets

ICMP packets

[P theodorou]

Im new into iptables world

now regarding icmp packets . Is it
applicable to drop inbound echo requests (so otherts cannot see me )

but i will be able to send  icmo echo request to WEB and receive
replies too .

Sorry if it looks very basic but im confused

Thanks

Re: ICMP packets

[Marc Haber]

On Tue, Sep 20, 2005 at 02:10:30PM +0000, P theodorou wrote:
> now regarding icmp packets . Is it
> applicable to drop inbound echo requests (so otherts cannot see me )

You're free to do this, but it'll show as "there is something that
is desperately trying not to be seen" to the educated attacker.

> Sorry if it looks very basic but im confused

This is _very_ basic, asked (and answered) a gazillion of times. If
this is for a business environment, I'd like to urgently recommend
hiring somebody who knows what to do.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Re: ICMP packets

[Gabriel]

--- P theodorou <props666999@hotmail.com> wrote:

> Im new into iptables world
> 
> now regarding icmp packets . Is it
> applicable to drop inbound echo requests (so otherts
> cannot see me )
> 
> but i will be able to send  icmo echo request to WEB and
> receive
> replies too .
> 
> Sorry if it looks very basic but im confused
> 
> Thanks

This rule should do the trick:
iptables -A OUTPUT -p icmp --icmp-type echo-reply -j DROP

It won't allow outgoing echo replies (pongs), but will
allow outgoing echo requests (pings) and their replies.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: ICMP packets

[/dev/rob0]

On Tuesday 20 September 2005 09:10, P theodorou wrote:
> now regarding icmp packets . Is it
> applicable to drop inbound echo requests (so otherts cannot see me )

This is a policy question, not, strictly speaking, an iptables / 
netfilter issue. Personally I don't see much point in hiding. It's a 
knee-jerk insecurity reaction of people who don't understand what makes 
(or breaks) security.

You will of course avoid some ping sweeps if you do that, and some of 
those ping sweeps may in fact be preludes to lame attack attempts.

> but i will be able to send icmo echo request to WEB and receive
> replies too .

Yes, if your rules permit. Typically you use a rule like "-m state 
--state RELATED,ESTABLISHED -j ACCEPT" to allow your replies back in. 
Whether that goes in INPUT or FORWARD depends on the network layout. 
(Generally goes in both.)

Um, "Web" is a term which refers to HTTP. HTTP is a high-level protocol 
which runs over TCP. ICMP has nothing to do with HTTP, except that both 
happen to use TCP/IP.

> Sorry if it looks very basic but im confused

I think what you need most is basic TCP/IP understanding. Where to 
start, to find that? I'm not sure. Rusty wrote a basic networking 
HOWTO, the specific name of which I can't recall, but it's among the 
netfilter.org HOWTOs.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

icmp packets

[cc]

Hi,

I have a 'weird' problem that's most likely attributed to a
bad netfilter rules policy.  

I am trying to ping from an internal machine to an external
site.  

$IPTB -A INPUT -i $INET_IF -p icmp -s $EXT_SITE -j ACCEPT
$IPTB -A OUTPUT -o $INET_IF -p icmp -d $EXT_SITE -j ACCEPT

$IPTB -A FORWARD -i $DMZ_IF -o $INET_IF -p icmp -d $EXT_SITE -j ACCEPT
$IPTB -t nat -A POSTROUTING -o $INET_IF -p icmp -d $EXT_SITE \
              -j SNAT --to-source $INET_IP

Now when I ping from an internal IP, I do not get a response
until the nth icmp_seq, where n > 100 (so far my testing). 
Is there something wrong with the above rules?

Apparently I'm not getting a echo reply until n > 100?  
I feel my understanding of ICMP packets requires some
further expanding.

Thanks

Ed