From: Keith Whyte <keith@media-solutions.ie>
To: netfilter@lists.netfilter.org
Subject: Re: coming in through the outgoing hole?
Date: Tue, 22 Nov 2005 13:51:06 -0600 [thread overview]
Message-ID: <438376AA.5050507@media-solutions.ie> (raw)
In-Reply-To: <200511220507.jAM57qZu019084@mx.media-solutions.ie>
/dev/rob0 wrote:
> no, i am trying to prevent a remote root user from making a
> connection to my machine.
>I don't see the value in this, myself. Whilst it certainly would seem
>odd to have a privileged port on the client end of your httpd, how is
>that a threat to you?
>
>
>
1. i have a web based admin service running on port 7775, (for example)
2. I want to use iptables to restrict access to this web based admin
service to certain hosts.
3. but i have added rules to iptables to allow outgoing web traffic by
allowing all outgoing tcp packets to port 80 from ports > 1024
4. i have also added a rule to allow incoming tcp packets from port 80
to ports > 1024
5. If a packet arrives from port 80 to port 7775 it gets through, that
is (was) the threat, but using conntrack is better, my approach using
ports was flawed.
>Sometimes, I will admit, targeted OUTPUT filtering makes sense. But to
>rein in shell users, I am not sure. If you cannot trust these users to
>abide by your ToS and AUP, you don't want them in on shell accounts. :)
>
>
>
and their php enabled web account? it should be locked down by other
methods, i imagine you say.. but we irish like to be sure, to be sure,
to be sure....
>>I'm also using the rules for traffic counters, so I don't want to do
>>that, but yes, it would simplify things as lot.
>>
>>
>
>I'm not sure what you mean, but I think I have a good suggestion
>nonetheless. :) Put your --state RELATED,ESTABLISHED rule in a chain
>all by itself, and call that as a target after your counter rules.
>
>
>
Derick suggested using one rule to allow related, established.. i was
just pointing out that then i wouldn't have the traffic information
divided by service.. but that's easily enabled again, like either you or
Derick said.
>like file sharing, I can see where the presence of a hostile root user
>behind your firewall might be cause for worry. But I guess you have
>
>
>
he he, seems like everyone here is thinking in terms of firewalls.. This
is a co-lo box 100% exposed on the internet. there's no firewall to be
behind. every other host on the entire internet is a potential hostile
root user!
I want iptables to reject as much as is possible at the INPUT stage.
thanks!
next parent reply other threads:[~2005-11-22 19:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200511220507.jAM57qZu019084@mx.media-solutions.ie>
2005-11-22 19:51 ` Keith Whyte [this message]
2005-11-21 20:10 coming in through the outgoing hole? Derick Anderson
-- strict thread matches above, loose matches on Subject: below --
2005-11-21 18:58 Derick Anderson
2005-11-21 19:41 ` Keith Whyte
2005-11-21 20:16 ` /dev/rob0
2005-11-21 17:58 Keith Whyte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=438376AA.5050507@media-solutions.ie \
--to=keith@media-solutions.ie \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.