Thanks all, that seemed to be the problem (the suid bit). :)
On 25 February 2016 at 06:03, Valeri Galtsev <galtsev@xxxxxxxxxxxxxxxxx>
wrote:
> On Wed, February 24, 2016 12:25 pm, Alexander Dalloz wrote:
> > Am 24.02.2016 um 16:07 schrieb Sylvain CANOINE:
> >> Hello,
> >> ----- Mail original -----
> >>> De: "John Cenile" <jcenile1983@xxxxxxxxx>
> >>> À: "centos" <centos@xxxxxxxxxx>
> >>> Envoyé: Mercredi 24 Février 2016 15:42:36
> >>> Objet: IPtables block user from outbound ICMP
> >>> Is it possible at all to block all users other than root from sending
> outbound ICMP packets on an interface?
> >>> At the moment we have the following two rules in our IPtables config:
> iptables -A OUTPUT -o eth1 -m owner --uid-owner 0 -j ACCEPT
> >>> iptables -A OUTPUT -o eth1 -j DROP
> >>> But this still allows ICMP for some reason (but *does* block other
> TCP/UDP
> >>> packets, which is what we want, as well as ICMP).
> >> According to the iptables documentation
> >> (http://ipset.netfilter.org/iptables.man.html), not specifying "-p" is
> equivalent to specifying "-p all", which matches with all protocols,
> icmp included. So these rules are good. BUT... I suppose /bin/ping has
> a
> >> suid bit set, no ?
> >> Sylvain.
> >> Pensez ENVIRONNEMENT : n'imprimer que si ncessaire
> >
> > Blocking the complete ICMP protocol is stupid and should not be
> > recommended.
> >
> > ICMP echo request and echo reply are just 2 types of a bigger set of
> necessary ICMP types. It is safe to block those 2 while that does not
> really serve a purpose. A system not replying on ICMP echo request does
> not hide it from others.
>
> Indeed. Not replying ping is rather Windows-ish behavior (still standard
> Windows behavior out of box. They still must have rather low opinion about
> their own programmers I guess and still are scared of [in]famous "ping of
> death").
>
> If one doesn't trust local users to the extent one doesn't allow them to
> send outbound pings, then one has rather large restriction imposing on
> users work to do IMHO. I do have some boxes like that, and on these boxes
> I indeed have rather restricted set of tools/commands accessible for
> users. In addition, users though can build or download stuff, they can not
> execute anything of their own. In other words, all places users can write
> to are mounted with "nosuid, nosgid, noexec" options, the last one is the
> one I mean here (do your own thinking why other two are also there). Once
> that is done, you can remove "others" read and execute bits from ping
> command (and other commands you don't want the to be able to use). Sending
> ping in particular requires opening raw socket, which only root (and group
> wheel) can do, that's why ping command has SGID set. But again, with that
> level of trust to local users, outbound ping is tiny small thing out of
> big list one has to do. I found this too tiresome to maintain this as a
> real host, for this reason when I need something like that (awfully
> restricted users, still having local access to the system), I just - hm,
> somebody hopefully will chime in how to do similar thing on Linux; I'm
> doing this on FreeBSD, and I just start separate jail, specifically
> configured for users logins and local access to the system (which is not a
> system, and which contains only tools I want to give users, the services
> of this same host run in different jails, mostly one service per jail).
> Hopefully, someone will tell how he/she does similar thing in CentOS.
>
> Just my $0.02.
>
> Valeri
>
> ++++++++++++++++++++++++++++++++++++++++
> Valeri Galtsev
> Sr System Administrator
> Department of Astronomy and Astrophysics
> Kavli Institute for Cosmological Physics
> University of Chicago
> Phone: 773-702-4247
> ++++++++++++++++++++++++++++++++++++++++
>
>
>
>
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> https://lists.centos.org/mailman/listinfo/centos
>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
