All of lore.kernel.org
 help / color / mirror / Atom feed
* making services invisible
@ 2002-10-10 13:13 Julio Cesar Ody
  2002-10-10 13:25 ` Ryan Daly
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Julio Cesar Ody @ 2002-10-10 13:13 UTC (permalink / raw)
  To: netfilter

Hello. I'm using Slackware 8.1, kernel 2.4.18 and iptables v1.2.7a. I 
blocked external acess to some services using the following rule:

iptables -A INPUT -i ! eth0 -p tcp -m multiport --destination-port 
<port1>,<port2>,<blablabla> -j REJECT

However, when I perform a stealth scan using nmap on my host, I still 
can see them running, but instead of "opened" I get them as "filtered". 
Is there a way to block these results, making the services literally 
invisible ? Appreciate any help, and also any technical information 
(links, docs) regarding the answer.



Julio Cesar Ody



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: making services invisible
  2002-10-10 13:13 making services invisible Julio Cesar Ody
@ 2002-10-10 13:25 ` Ryan Daly
  2002-10-10 13:46 ` Eric Leblond
  2002-10-10 14:24 ` making services invisible Kevin Dwyer
  2 siblings, 0 replies; 7+ messages in thread
From: Ryan Daly @ 2002-10-10 13:25 UTC (permalink / raw)
  To: Julio Cesar Ody, netfilter

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

Use DROP instead of REJECT.

REJECT action tells tables to send back an ICMP message indicating that
you're REJECTing the packet.  DROPing will just DROP with no further
action.

--

On Thu, 2002-10-10 at 09:13, Julio Cesar Ody wrote:

    Hello. I'm using Slackware 8.1, kernel 2.4.18 and iptables v1.2.7a. I 
    blocked external acess to some services using the following rule:
    
    iptables -A INPUT -i ! eth0 -p tcp -m multiport --destination-port 
    <port1>,<port2>,<blablabla> -j REJECT
    
    However, when I perform a stealth scan using nmap on my host, I still 
    can see them running, but instead of "opened" I get them as "filtered". 
    Is there a way to block these results, making the services literally 
    invisible ? Appreciate any help, and also any technical information 
    (links, docs) regarding the answer.
    
    
    
    Julio Cesar Ody

[-- Attachment #2: Type: text/html, Size: 2035 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: making services invisible
  2002-10-10 13:13 making services invisible Julio Cesar Ody
  2002-10-10 13:25 ` Ryan Daly
@ 2002-10-10 13:46 ` Eric Leblond
  2002-10-10 14:41   ` Leonardo Rodrigues ( listas )
  2002-10-10 14:24 ` making services invisible Kevin Dwyer
  2 siblings, 1 reply; 7+ messages in thread
From: Eric Leblond @ 2002-10-10 13:46 UTC (permalink / raw)
  To: netfilter

On Thu, 2002-10-10 at 15:13, Julio Cesar Ody wrote:
> Hello. I'm using Slackware 8.1, kernel 2.4.18 and iptables v1.2.7a. I 
> blocked external acess to some services using the following rule:
> 
> iptables -A INPUT -i ! eth0 -p tcp -m multiport --destination-port 
> <port1>,<port2>,<blablabla> -j REJECT

Use DROP not REJECT, with REJECT you send an ICMP message, so it's
filtered, not close

-- 
Éric Leblond
courriel : eleblond@init-sys.com



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: making services invisible
  2002-10-10 13:13 making services invisible Julio Cesar Ody
  2002-10-10 13:25 ` Ryan Daly
  2002-10-10 13:46 ` Eric Leblond
@ 2002-10-10 14:24 ` Kevin Dwyer
  2 siblings, 0 replies; 7+ messages in thread
From: Kevin Dwyer @ 2002-10-10 14:24 UTC (permalink / raw)
  To: Julio Cesar Ody; +Cc: netfilter

On Thu, 10 Oct 2002, Julio Cesar Ody transmitted the following:

> Hello. I'm using Slackware 8.1, kernel 2.4.18 and iptables v1.2.7a. I
> blocked external acess to some services using the following rule:
>
> iptables -A INPUT -i ! eth0 -p tcp -m multiport --destination-port
> <port1>,<port2>,<blablabla> -j REJECT
>
> However, when I perform a stealth scan using nmap on my host, I still
> can see them running, but instead of "opened" I get them as "filtered".
> Is there a way to block these results, making the services literally
> invisible ? Appreciate any help, and also any technical information
> (links, docs) regarding the answer.

You need to reply with an RST.

Something like: --reject-with tcp-reset


/* Kevin Dwyer                                Allegiance Internet */
/* network security engineer                   Commerce Center II */
/* email: Kevin.Dwyer@algx.net                7601 Ora Glen Drive */
/* phone: 240-616-2075                        Greenbelt, MD 20770 */
/*      >++++++++++[<++++++++++>-]<.+++++.----.[-]++++++++++.     */




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: making services invisible
  2002-10-10 13:46 ` Eric Leblond
@ 2002-10-10 14:41   ` Leonardo Rodrigues ( listas )
  2002-10-11 16:54     ` Nick Drage
  0 siblings, 1 reply; 7+ messages in thread
From: Leonardo Rodrigues ( listas ) @ 2002-10-10 14:41 UTC (permalink / raw)
  To: Eric Leblond, netfilter


    DROP would make nmap ( or any other scanner ) mark that port as filtered
too. To make services closed and 'invisible' to scanners, you should use '-j
REJECT --reject-with tcp-reset'.

    Sincerily,
    Leonardo Rodrigues

----- Original Message -----
From: "Eric Leblond" <eleblond@init-sys.com>
To: <netfilter@lists.netfilter.org>
Sent: Thursday, October 10, 2002 10:46 AM
Subject: Re: making services invisible


On Thu, 2002-10-10 at 15:13, Julio Cesar Ody wrote:
> Hello. I'm using Slackware 8.1, kernel 2.4.18 and iptables v1.2.7a. I
> blocked external acess to some services using the following rule:
>
> iptables -A INPUT -i ! eth0 -p tcp -m multiport --destination-port
> <port1>,<port2>,<blablabla> -j REJECT

Use DROP not REJECT, with REJECT you send an ICMP message, so it's
filtered, not close




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: making services invisible
  2002-10-10 14:41   ` Leonardo Rodrigues ( listas )
@ 2002-10-11 16:54     ` Nick Drage
  2002-10-12 15:57       ` How will stop follwoing service Sundaram Ramasamy
  0 siblings, 1 reply; 7+ messages in thread
From: Nick Drage @ 2002-10-11 16:54 UTC (permalink / raw)
  To: netfilter

On Thu, Oct 10, 2002 at 11:41:32AM -0300, Leonardo Rodrigues ( listas ) wrote:
> 
>     DROP would make nmap ( or any other scanner ) mark that port as filtered
> too. To make services closed and 'invisible' to scanners, you should use '-j
> REJECT --reject-with tcp-reset'.

Spot on :)

Isn't this one in an FAQ somewhere by now, seeing as no-one ever reads the
rather good nmap man page.

I haven't checked but last time I looked the TTL will be different with RSTs
sent from iptables rather than those sent because there's no listener on the
port.  There are ways around this too, depends how invisible you want to
be...

-- 
FunkyJesus System Administration Team



^ permalink raw reply	[flat|nested] 7+ messages in thread

* How will stop follwoing service
  2002-10-11 16:54     ` Nick Drage
@ 2002-10-12 15:57       ` Sundaram Ramasamy
  0 siblings, 0 replies; 7+ messages in thread
From: Sundaram Ramasamy @ 2002-10-12 15:57 UTC (permalink / raw)
  To: Nick Drage, netfilter


Hi,

I am running Redhat Linux, How will I stop following process. I checked in
chkconfig and /etc/xinetd. directory, I don't get any information.

111/tcp    open        sunrpc
1024/tcp   open        kdm
1025/tcp   open        listen

Thanks
Sundaram



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2002-10-12 15:57 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-10-10 13:13 making services invisible Julio Cesar Ody
2002-10-10 13:25 ` Ryan Daly
2002-10-10 13:46 ` Eric Leblond
2002-10-10 14:41   ` Leonardo Rodrigues ( listas )
2002-10-11 16:54     ` Nick Drage
2002-10-12 15:57       ` How will stop follwoing service Sundaram Ramasamy
2002-10-10 14:24 ` making services invisible Kevin Dwyer

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.