Iptables Filtering Rules Question

Iptables Filtering Rules Question

Post by Yang xi » Wed, 25 Sep 2002 03:23:03



Hi all,
I have often seen the following output while port scanning other hosts

port   22 filtered

What kind of filering rule could result this? I have setup filters on
my machine and it only says "open", I'm wondering why.

Thanks,

Yang

 
 
 

Iptables Filtering Rules Question

Post by Ange » Wed, 25 Sep 2002 03:50:35



> Hi all,
> I have often seen the following output while port scanning other hosts

> port   22 filtered

> What kind of filering rule could result this? I have setup filters on
> my machine and it only says "open", I'm wondering why.

> Thanks,

> Yang

Preferably you would be denying _everything_ and only allow connections
you really need or want.  So in this case the point being don't allow ssh :)

Alternatively...
iptables -t filter -A INPUT -p tcp --dport 22 -j DENY
Pay attention to the order of the rules though, there is little point in
denying it specifically if you have already allowed it higher up the chain.

Stu

 
 
 

Iptables Filtering Rules Question

Post by Yang xi » Wed, 25 Sep 2002 10:48:48




> > Hi all,
> > I have often seen the following output while port scanning other hosts

> > port   22 filtered

> > What kind of filering rule could result this? I have setup filters on
> > my machine and it only says "open", I'm wondering why.

> > Thanks,

> > Yang

> Preferably you would be denying _everything_ and only allow connections
> you really need or want.  So in this case the point being don't allow ssh :)

> Alternatively...
> iptables -t filter -A INPUT -p tcp --dport 22 -j DENY
> Pay attention to the order of the rules though, there is little point in
> denying it specifically if you have already allowed it higher up the chain.

> Stu

I understand that part, for example
iptables -t filter -A INPUT -p tcp -m syn -dport 80 -j ALLOW
iptables -t filter -A INPUT -j DENY

will result denying everything but http connection initiated internally(?).
but will a port scan on port 80 display "filtered" instead of "open" ?

Thanks,

Yang

 
 
 

Iptables Filtering Rules Question

Post by Ange » Wed, 25 Sep 2002 17:29:56


Quote:>>Stu

> I understand that part, for example
> iptables -t filter -A INPUT -p tcp -m syn -dport 80 -j ALLOW
> iptables -t filter -A INPUT -j DENY

> will result denying everything but http connection initiated internally(?).
> but will a port scan on port 80 display "filtered" instead of "open" ?

> Thanks,

> Yang

Nah, it will display open, because well.. it is open :)
 
 
 

Iptables Filtering Rules Question

Post by Bryan Packe » Fri, 27 Sep 2002 13:31:35



> I understand that part, for example
> iptables -t filter -A INPUT -p tcp -m syn -dport 80 -j ALLOW
> iptables -t filter -A INPUT -j DENY

> will result denying everything but http connection initiated internally(?).
> but will a port scan on port 80 display "filtered" instead of "open" ?

A) That first rule will allow the first packet in the TCP connection
process to port 80. There is nothing there that would indicate that it
only allows "internally". It should accept packets from all source
addresses.

B) Normally, the machine will respond with a syn-ack packet (sychronize
acknowledge) if the port is open and there is a service listening, a
tcp-rst (reset) if the port is reachable but no service is listening,
and no response at all if the port is firewalled. I believe the filtered
is caused by the third option. In your example above, it should return
"open".

bryan

--
Earth first...we'll strip-mine the other planets later.

 
 
 

Iptables Filtering Rules Question

Post by James Veg » Sat, 28 Sep 2002 06:29:32



> Hi all,
> I have often seen the following output while port scanning other hosts

> port   22 filtered

> What kind of filering rule could result this? I have setup filters on
> my machine and it only says "open", I'm wondering why.

> Thanks,

> Yang

 From my understanding of firewalling and port scanning, you will see
the 'filtered' response when connections are being DENY'ed.  In order to
avoid this, one would use REJECT. This causes the comptuer to respond as
if nothing is running on the port, which a normal non-firewalled
computer would do.
 
 
 

Iptables Filtering Rules Question

Post by Fredderi » Sat, 28 Sep 2002 01:57:14


Quote:> A) That first rule will allow the first packet in the TCP connection
> process to port 80. There is nothing there that would indicate that it
> only allows "internally". It should accept packets from all source
> addresses.

Some (all?) programs that only accept connections from certain sources do an
accept/close on connections they don't like, don't they?  I'm not aware of
any way to peek at an incomming connection, and tell the system to toss it
out without connecting.

If there is such a way, is it possible to change the responce to such
connections from REJECT to DROP.

And if not, is there any way to delay any responce (faking the connection to
the application) long enough to detect if there's any outbound traffic
attempts, then either allow the connection to proceed, or drop it entirely?
I'm guessing some kind of freaky proxy would be needed, or a TCP-wrapper
type deal.  But it still doesn't help with generating a DROP type responce.
If such a thing doesn't exist, but would be possible, any technical details
would be nice.  I may just be interested in trying to write such a beast.

 
 
 

Iptables Filtering Rules Question

Post by Ange » Sun, 29 Sep 2002 23:56:06


Quote:

> Some (all?) programs that only accept connections from certain sources do an
> accept/close on connections they don't like, don't they?  I'm not aware of
> any way to peek at an incomming connection, and tell the system to toss it
> out without connecting.

a firewall???  inspect and act on packets before they reach the
application.  Perhaps I'm missing your point completely.

Quote:

> If there is such a way, is it possible to change the responce to such
> connections from REJECT to DROP.

a firewall???  If it the packet matches certain criteria then drop it on
the floor, literally. ;)

Quote:> And if not, is there any way to delay any responce (faking the connection to
> the application) long enough to detect if there's any outbound traffic
> attempts, then either allow the connection to proceed, or drop it entirely?
> I'm guessing some kind of freaky proxy would be needed, or a TCP-wrapper
> type deal.  But it still doesn't help with generating a DROP type responce.
> If such a thing doesn't exist, but would be possible, any technical details
> would be nice.  I may just be interested in trying to write such a beast.

A firewall runs at lower OSI level than TCP-wrappers.  As such you
inspect and act upon packets before they even reach your applications.

Apologies if I'm completely missing your point, I think I must be.

angel

 
 
 

Iptables Filtering Rules Question

Post by Bryan Packe » Mon, 30 Sep 2002 12:07:20



> > And if not, is there any way to delay any responce (faking the connection to
> > the application) long enough to detect if there's any outbound traffic
> > attempts, then either allow the connection to proceed, or drop it entirely?
> > I'm guessing some kind of freaky proxy would be needed, or a TCP-wrapper
> > type deal.  

I don't quite get it. Of course there will be an outbound attempt.
That's how TCP works. The remote machine sends a packet with the SYN
flag set, the host computer replies with a packet with the SYN and ACK
flags set. They then go about their merry way of setting up a
connection. Either block the traffic coming in if you don't want it, or
let it through if you do. I don't see any point in delaying.


> Apologies if I'm completely missing your point, I think I must be.

That would make two of us.

bryan
--
Earth first...we'll mine the other planets later.

 
 
 

Iptables Filtering Rules Question

Post by Fredderi » Fri, 04 Oct 2002 23:04:19


Quote:> > > And if not, is there any way to delay any responce (faking the
> > > connection to the application) long enough to detect if there's any
> > > outbound traffic attempts, then either allow the connection to
> > > proceed, or drop it entirely? I'm guessing some kind of freaky
> > > proxy would be needed, or a TCP-wrapper type deal.
> I don't quite get it. Of course there will be an outbound attempt.
> That's how TCP works. The remote machine sends a packet with the
> SYN flag set, the host computer replies with a packet with the SYN
> and ACK flags set. They then go about their merry way of setting up
> a connection. Either block the traffic coming in if you don't want it, or
> let it through if you do. I don't see any point in delaying.

The point is, that I'm not about to add some 120-odd ACCEPT rules so I can
safely drop everything else.  I know who'll be connecting, I just don't want
to have to add them all to my iptables ruleset.  I also know who I don't
want to allow to connect, but I don't know where they'll be connecting from,
especially when they start using proxy's and the likes.

And so I need to convert a "remote host dropped connection", as is generated
by the TCP wrappers, into a simple DROP.  And the only way I can concieve of
to accomplish that, is to implement a delay to detect an application doing
an accept/close.

 
 
 

Iptables Filtering Rules Question

Post by Rick L » Sat, 05 Oct 2002 00:51:09


Quote:> The point is, that I'm not about to add some 120-odd ACCEPT rules so I can
> safely drop everything else.  I know who'll be connecting, I just don't
want
> to have to add them all to my iptables ruleset.  I also know who I don't
> want to allow to connect, but I don't know where they'll be connecting
from,
> especially when they start using proxy's and the likes.

> And so I need to convert a "remote host dropped connection", as is
generated
> by the TCP wrappers, into a simple DROP.  And the only way I can concieve
of
> to accomplish that, is to implement a delay to detect an application doing
> an accept/close.

Maybe I'm missing something, but if you're going to rely on tcp wrappers to
protect your machine, that box is as good as owned.  tcp wrappers is a joke
and extremely easy to hack.  You can do what you like, but if you don't want
your box to be hacked, I would spend the time to set up a good iptables rule
set - that's just me though because I don't feel like re-installing every
few weeks due to a hacked machine.
 
 
 

Iptables Filtering Rules Question

Post by Tim Hayne » Sat, 05 Oct 2002 01:44:20



> The point is, that I'm not about to add some 120-odd ACCEPT rules so I
> can safely drop everything else. I know who'll be connecting, I just
> don't want to have to add them all to my iptables ruleset. I also know
> who I don't want to allow to connect, but I don't know where they'll be
> connecting from, especially when they start using proxy's and the likes.

Erm, why not? I have a little for-loop in my firewall script that adds all
the IP#s for our secondary nameservers; you only have to choose an optimal
way to group these things (e.g. by-serivce) and split into chains within
the relevant table (e.g. for use with "-j DNS"), and script it... That way
you can optimize the path traversed by each & every kind of packet so's to
minimize, or at least priority-match against the most frequent kinds of
packet.

~Tim
--

Came the tranquil and the calm,             |http://spodzone.org.uk/
On the ridge of the mighty Atlantic.        |

 
 
 

Iptables Filtering Rules Question

Post by Michael Erski » Sat, 05 Oct 2002 11:24:49


You piggie...  :)

-m-

 
 
 

Iptables Filtering Rules Question

Post by Tim Hayne » Sat, 05 Oct 2002 17:27:14




> You piggie...  :)

Allegedly so? :)

~Tim
--
       09:27:10 up 14:15,  2 users,  load average: 0.57, 0.47, 0.30

http://piglet.is.dreaming.org     |Soar above the singing river

 
 
 

1. IPTables, forwarded ports are not filtered by previous rules, how to fix?

I am using an older Monmotha script that I have heavily modified myself,
and I have a list of hosts that are explicitly denied from connecting to
my server as well as some ports that are fowarded into another server on
the inside of the firewall (opennap servers, don't have the ram in the
first machine to run as many users as I like, so I run one on each machine)

Anyway, I have a set of ports fowarded inside and my deny rules that
work fine for the server itself are ignored on the forwards, denied
hosts are going right through the port forwards!  I thought that the
host had to pass the firewall before it could be forwarded?

How can I fix this?  Thanks!

--
Walter Francis
http://theblackmoor.net                  Powered by Red Hat Linux 7.2

2. Mounting MacIntosh 3'5" Disks

3. iptables rule to filter out nimda?

4. Slackware 1.04 missing /usr/local/lib/menus files

5. iptables: rule with RETURN target just after a rule with ACCEPT target

6. OpenBSD | Windows98

7. Converting ipchains rules to iptables rules?

8. GNU uucp

9. iptables: rule with RETURN target after a rule with the ACCEPT target

10. Looking for iptables applications code (iptables.c) to run some rules to forward packets

11. iptables v1.2.2: can't initialize iptables table `filter': Table does not exist

12. iptables "can't initialize iptables table `filter'"

13. filter-rules question