Very Computer

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

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

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

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 :)

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.

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.

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.

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

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.

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.

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.

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. |

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

You piggie... :)

-m-

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

Very Computer

Iptables Filtering Rules Question

Iptables Filtering Rules Question

Iptables Filtering Rules Question

Iptables Filtering Rules Question

Iptables Filtering Rules Question

Iptables Filtering Rules Question

Iptables Filtering Rules Question

Iptables Filtering Rules Question

Iptables Filtering Rules Question

Iptables Filtering Rules Question

Iptables Filtering Rules Question

Iptables Filtering Rules Question

Iptables Filtering Rules Question

Iptables Filtering Rules Question

Iptables Filtering Rules Question