la manière standard est de les rendre" setuid " pour qu'ils démarrent en tant que root, et ensuite ils jettent ce privilège root dès qu'ils sont liés au port mais avant qu'ils commencent à accepter des connexions à celui-ci. Vous pouvez voir de bons exemples de cela dans le code source pour Apache et INN. On m'a dit que Lighttpd était un autre bon exemple.

un autre exemple est Postfix, qui utilise plusieurs démons qui communiquent à travers des pipes, et seulement un ou deux d'entre eux (qui font très peu à l'exception des octets accept ou emit) s'exécute en tant que root et le reste s'exécute avec un privilège inférieur.

Vous pouvez faire une redirection de port. C'est ce que je fais pour un serveur Politique Silverlight tournant sur une machine Linux

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 943 -j REDIRECT --to-port 1300

vous pouvez configurer un tunnel SSH local, par exemple si vous voulez que le port 80 touche votre application liée à 3000:

sudo ssh $USERNAME@localhost -L 80:localhost:3000 -N

Cela a l'avantage de travailler avec des scripts serveurs, et d'être très simple.

ne sont pas idéales, car elles peuvent se casser après une mise à jour du paquet.

la solution idéale, IMHO, devrait être une capacité à créer un shell avec un CAP_NET_BIND_SERVICE enchâssé.

Voici une façon quelque peu alambiquée de faire ceci:

sg $DAEMONUSER "capsh --keep=1 --uid=`id -u $DAEMONUSER` \
     --caps='cap_net_bind_service+pei' -- \
     YOUR_COMMAND_GOES_HERE"

capsh se trouve dans le paquet libcap2-bin des distributions Debian/Ubuntu. Voici ce qui se passe:

• sg change le numéro de groupe effectif en celui de l'utilisateur démon. Cela est nécessaire parce que capsh laisse GID inchangé et nous ne voulons certainement pas.
• définit le bit 'capacités de conservation sur changement D'UID'.
• change UID en $DAEMONUSER
• baisse tous les capuchons (à ce moment tous les capuchons sont encore présents à cause de --keep=1 ), sauf héritable cap_net_bind_service
• exécute votre commande ('--'est un séparateur)

le résultat est un processus avec l'utilisateur et le groupe spécifiés, et les privilèges cap_net_bind_service .

comme exemple, une ligne de ejabberd script de démarrage:

sg $EJABBERDUSER "capsh --keep=1 --uid=`id -u $EJABBERDUSER` --caps='cap_net_bind_service+pei' -- $EJABBERD --noshell -detached"

deux autres possibilités simples:

il y a une vieille solution (démodable) au "démon qui se lie sur un port bas et contrôle les mains à votre démon". Il s'appelle inetd (ou xinetd). Les contre sont:

• votre démon a besoin de parler sur stdin / stdout (si vous ne contrôlez pas le démon -- si vous n'avez pas la source -- alors c'est peut-être un showstopper, bien que certains services puissent avoir un drapeau de compatibilité inetd)
• un nouveau processus daemon est bifurqué pour chaque connexion
• c'est un maillon supplémentaire dans la chaîne

Pour:

• disponible sur tout ancien UNIX
• une fois que votre administrateur système a mis en place la configuration, vous êtes prêt à poursuivre votre développement (lorsque vous reconstruisez votre démon, pourriez-vous perdre les capacités de setcap? Et ensuite vous devrez retourner à votre administrateur " s'il vous plaît monsieur...")
• daemon n'a pas à s'inquiéter de ce truc de réseau, il suffit de parler sur stdin / stdout
• peut configurer pour exécuter votre démon en tant qu'utilisateur non root ,comme demandé

une autre alternative: un proxy piraté (netcat ou même quelque chose de plus plus robuste ) à partir du port privilégié vers un port hautement numéroté arbitraire où vous pouvez exécuter votre démon cible. (Netcat n'est évidemment pas une solution de production, mais "juste ma boîte de dev", à droite?). De cette façon, vous pouvez continuer à utiliser une version réseau-capable de votre serveur, n'aurait besoin que de root/sudo pour démarrer proxy (au démarrage), ne compterait pas sur les capacités complexes/potentiellement fragiles.

ma "solution de contournement standard" utilise socat comme redirecteur de l'espace utilisateur:

socat tcp6-listen:80,fork tcp6:8080

méfiez-vous que ce ne sera pas échelle, bifurcation est cher, mais c'est la façon dont la socat fonctionne.

ou corrigez votre noyau et retirez le chèque.

(option de dernier recours, non recommandée).

TLDR: Pour "la réponse" (comme je le vois), sauter vers le >>TLDR<< la partie dans cette réponse.

OK, je l'ai compris (pour de vrai cette fois), la réponse à cette question, et cette réponse de la mienne est également une façon de s'excuser pour promouvoir une autre réponse (à la fois ici et sur twitter) que je pensais être "le meilleur", mais après l'avoir essayé, découvert que je me suis trompé à ce sujet. Apprendre de mes erreurs les enfants: ne faites pas la promotion de quelque chose jusqu'à ce que vous avez réellement essayé vous-même!

encore une fois, j'ai passé en revue toutes les réponses ici. J'ai essayé certains d'entre eux (et choisi de ne pas essayer d'autres parce que je n'ai tout simplement pas aimé les solutions). Je pensais que la solution était d'utiliser systemd avec ses paramètres Capabilities= et CapabilitiesBindingSet= . Après avoir lutté avec cela pendant un certain temps, j'ai découvert que ce n'est pas la solution parce que:

sont destinées à restreindre les processus racine!

comme L'OP sagement déclaré, Il est toujours mieux d'éviter que (pour tous vos démons si possible!).

vous ne pouvez pas utiliser les options liées aux capacités avec User= et Group= dans systemd fichiers d'unité, parce que les capacités sont toujours reset lorsque execev (ou ce que la fonction est appelée. En d'autres termes, lorsque systemd fourche et laisse tomber ses perms, les capacités sont réinitialisées. Il n'y a aucun moyen de contourner cela, et toute cette logique de liaison dans le noyau est basique autour d'uid=0, pas de capacités. Cela signifie qu'il est peu probable que les capacités soient jamais la bonne réponse à cette question (du moins dans un avenir proche). D'ailleurs, setcap , comme d'autres l'ont mentionné, n'est pas une solution. Il n'a pas de travail pour moi, ça ne marche pas très bien avec les scripts, et ils sont réinitialisés de toute façon à chaque fois que le fichier change.

dans ma maigre défense, j'ai déclaré (dans le commentaire que j'ai maintenant supprimé), que la suggestion de James iptables (que l'OP mentionne également), était la"deuxième meilleure solution". :- P

>>TLDR<<

La solution est de combiner systemd avec à la volée iptables commandes, comme ceci ( tiré de DNSChain ):

[Unit]
Description=dnschain
After=network.target
Wants=namecoin.service

[Service]
ExecStart=/usr/local/bin/dnschain
Environment=DNSCHAIN_SYSD_VER=0.0.1
PermissionsStartOnly=true
ExecStartPre=/sbin/sysctl -w net.ipv4.ip_forward=1
ExecStartPre=-/sbin/iptables -D INPUT -p udp --dport 5333 -j ACCEPT
ExecStartPre=-/sbin/iptables -t nat -D PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333
ExecStartPre=/sbin/iptables -A INPUT -p udp --dport 5333 -j ACCEPT
ExecStartPre=/sbin/iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333
ExecStopPost=/sbin/iptables -D INPUT -p udp --dport 5333 -j ACCEPT
ExecStopPost=/sbin/iptables -t nat -D PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333
User=dns
Group=dns
Restart=always
RestartSec=5
WorkingDirectory=/home/dns
PrivateTmp=true
NoNewPrivileges=true
ReadOnlyDirectories=/etc

# Unfortunately, capabilities are basically worthless because they're designed to restrict root daemons. Instead, we use iptables to listen on privileged ports.
# Capabilities=cap_net_bind_service+pei
# SecureBits=keep-caps

[Install]
WantedBy=multi-user.target

ici, nous accomplissons ce qui suit:

• le démon écoute sur 5333, mais les connexions sont acceptées avec succès sur 53 grâce à iptables
• nous pouvons inclure les commandes dans le fichier Unité lui-même, et ainsi nous sauvons les maux de tête des gens. systemd nettoie les règles du pare-feu pour nous, en s'assurant de supprimer quand le démon n'est pas en cours d'exécution.
• nous ne courons jamais en tant que root, et nous rendons l'escalade des privilèges impossible (au moins systemd prétend), même si le démon est compromis et fixe uid=0 .

iptables est encore, malheureusement, tout à fait laid et difficile à utiliser utilité. Si le démon écoute eth0:0 au lieu de eth0 , par exemple, les commandes sont légèrement différentes .

Linux supporte capacités pour supporter plus de permissions à grain fin que juste "cette application est exécutée en tant que root". Une de ces capacités est CAP_NET_BIND_SERVICE qui est sur la liaison à un port privilégié (<1024).

malheureusement je ne sais pas comment l'exploiter pour exécuter une application comme non-root tout en lui donnant CAP_NET_BIND_SERVICE (probablement en utilisant setcap , mais il y a forcément une solution. pour cette).

je sais que c'est une vieille question, mais maintenant avec les noyaux récents (>= 4.3) il y a finalement une bonne réponse à cela - les capacités ambiantes.

la réponse rapide est de prendre une copie de la dernière version (non encore publiée) de libcap de git et de la compiler. Copiez le résultat progs/capsh binaire quelque part ( /usr/local/bin est un bon choix). Puis, en tant que root, démarrez votre programme avec

/usr/local/bin/capsh --keep=1 --user='your-service-user-name' \
    --inh='cap_net_bind_service' --addamb='cap_net_bind_service' \ 
    -- -c 'your-program'

Dans l'ordre, nous sont

• , Déclarant que quand on passe des utilisateurs, nous voulons garder notre capacité de courant de jeux de
• Commutation de l'utilisateur et du groupe de 'votre-service-nom d'utilisateur"
• ajout de la capacité cap_net_bind_service aux ensembles hérités et ambiants
• Forking bash -c 'your-command' (puisque capsh démarre automatiquement bash avec les arguments après -- )

il y a beaucoup se cache sous le capot ici.

tout d'abord, nous exécutons en tant que root, donc par défaut, nous obtenons un ensemble complet de capacités. Cela inclut la possibilité de changer uid & gid avec les appels setuid et setgid . Cependant, habituellement quand un programme fait cela, il perd son ensemble de capacités - c'est ainsi que l'ancienne façon de laisser tomber root avec setuid fonctionne toujours. Le drapeau --keep=1 indique capsh pour émettre le prctl(PR_SET_KEEPCAPS) syscall, qui désactive l'abandon des capacités lors du changement d'utilisateur. Le changement réel des utilisateurs par capsh se produit avec le drapeau --user , qui exécute setuid et setgid .

le prochain problème que nous devons résoudre est comment définir les capacités d'une manière qui continue après nous exec nos enfants. Le système de capacités a toujours eu un ensemble de capacités "héritées", qui est "un ensemble de capacités préservées dans un execve (2)" [ capabilities (7) ]. Bien que cela ressemble à cela résout notre problème (vient de mettre la capacité cap_net_bind_service à héréditaire, Non?), cela ne s'applique en fait qu'aux processus privilégiés - et notre processus n'est plus privilégié, car nous avons déjà changé d'utilisateur (avec le drapeau --user ).

La nouvelle ambiante ensemble des capacités de travaux autour de ce problème - il est "un ensemble de fonctionnalités qui sont conservés à travers d'un execve(2) d'un programme qui n'est pas privilégié." Par en mettant cap_net_bind_service dans l'ensemble d'ambiance, lorsque capsh exec est notre programme Serveur, notre programme héritera de cette capacité et sera en mesure de lier les auditeurs aux ports bas.

si vous êtes intéressé à en savoir plus, les capacités page de manuel explique cela en détail. Courir capsh à strace est aussi très instructif!

mise à Jour 2017:

Utiliser authbind

• CAP_NET_BIND_SERVICE accorde la confiance au binaire mais ne fournit pas contrôle de l'accès par port.
  
  

• Authbind subventions confiance à l' utilisateur / groupe et assure le contrôle de l'accès par port, et supporte à la fois IPv4 et IPv6 (le support IPv6 a été ajouté récemment).

  1. Installation: apt-get install authbind

  2. configurer l'accès aux ports pertinents, p.ex. 80 et 443 pour tous les utilisateurs et groupes:

sudo touch / etc/authbind/byport / 80

sudo touch / etc / authbind/byport / 443

sudo chmod 777 / etc / authbind / byport / 80

sudo chmod 777 / etc / authbind / byport/443

3. exécutez votre commande via authbind
   
   (en spécifiant optionnellement --deep ou d'autres arguments, voir la page de manuel):

   authbind --deep /path/to/binary command line args
   

   p.ex.

   authbind --deep java -jar SomeServer.jar
   

comme suite à la recommandation fabuleuse de Joshua (=non recommandé sauf si vous savez ce que vous faites) de hacker le noyau:

j'ai d'abord posté ici .

Simple. Avec un noyau normal ou ancien, vous ne le faites pas.

Comme d'autres l'ont souligné, iptables peut rediriger un port.

Comme D'autres l'ont également souligné, CAP_NET_BIND_SERVICE peut également faire le travail.

Bien sûr, CAP_NET_BIND_SERVICE échouera si vous lancez votre programme à partir d'un script, à moins que vous ne positionniez le cap sur l'interpréteur de commandes, ce qui est inutile, vous pourriez tout aussi bien exécuter votre service en tant que root...

par exemple pour Java, vous devez l'appliquer à la JAVA JVM

sudo /sbin/setcap 'cap_net_bind_service=ep' /usr/lib/jvm/java-8-openjdk/jre/bin/java

évidemment, cela signifie Alors toute le programme peut lier les ports du système.

Dito pour mono/.NET.

je suis aussi assez sûr que xinetd n'est pas la meilleure des idées.

Mais puisque les deux méthodes sont des piratages, pourquoi ne pas simplement lever la limite en levant la restriction ?

Personne n'a dit que vous deviez exécuter un noyau normal, donc vous pouvez exécuter le vôtre.

vous venez de télécharger la source pour le dernier noyau (ou le même que vous actuellement avoir.) Après, vous allez à:

/usr/src/linux-<version_number>/include/net/sock.h:

là vous cherchez cette ligne

/* Sockets 0-1023 can't be bound to unless you are superuser */
#define PROT_SOCK       1024

et le remplacer par

#define PROT_SOCK 0

si vous ne voulez pas avoir une situation SSH non sécurisée, vous la modifiez en ceci: # define PROT_SOCK 24

en général, j'utiliserais le paramètre le plus bas dont vous avez besoin, E. g 79 pour http, ou 24 pour SMTP sur le port 25.

C'est déjà tout.

Compiler le noyau, et l'installer.

Redémarrer.

Fini - cette limite stupide est partie, et cela fonctionne aussi pour les scripts.

Voici comment compiler un noyau:

https://help.ubuntu.com/community/Kernel/Compile

# You can get the kernel-source via package linux-source, no manual download required
apt-get install linux-source fakeroot

mkdir ~/src
cd ~/src
tar xjvf /usr/src/linux-source-<version>.tar.bz2
cd linux-source-<version>

# Apply the changes to PROT_SOCK define in /include/net/sock.h

# Copy the kernel config file you are currently using
cp -vi /boot/config-`uname -r` .config

# Install ncurses libary, if you want to run menuconfig
apt-get install libncurses5 libncurses5-dev

# Run menuconfig (optional)
make menuconfig

# Define the number of threads you wanna use when compiling (should be <number CPU cores> - 1), e.g. for quad-core
export CONCURRENCY_LEVEL=3
# Now compile the custom kernel
fakeroot make-kpkg --initrd --append-to-version=custom kernel-image kernel-headers

# And wait a long long time

cd ..

En un mot, utilisez iptables si vous voulez rester sécurisé, compilez le noyau si vous voulez être sûr que cette restriction ne vous dérange plus.

systemd est un remplacement sysvinit qui a une option pour lancer un démon avec des capacités spécifiques. Options Capacités=, CapabilityBoundingSet= systemd.exec(5) page de manuel.

redirection de Port était la plus logique pour nous, mais nous avons rencontré un problème où notre application résoudrait une url locale qui devait aussi être ré-acheminée; (cela signifie que vous shindig ).

cela vous permettra également d'être redirigé lors de l'accès à l'url sur la machine locale.

iptables -A PREROUTING -t nat -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -A OUTPUT -t nat -p tcp --dport 80 -j REDIRECT --to-port 8080

au démarrage:

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

, Alors vous pouvez lier au port vous attend.

avec systemd, vous avez juste besoin de modifier légèrement votre service pour accepter des sockets pré-activés.

vous pouvez utiliser plus tard systemd socket activate .

aucune capacité, iptables ou autres trucs ne sont nécessaires.

c'est le contenu des fichiers systemd pertinents de cet exemple de simple Python http server

Fichier httpd-true.service

[Unit]
Description=Httpd true 

[Service]
ExecStart=/usr/local/bin/httpd-true
User=subsonic

PrivateTmp=yes

Fichier httpd-true.socket

[Unit]
Description=HTTPD true

[Socket]
ListenStream=80

[Install]
WantedBy=default.target

pour une raison quelconque, personne ne parle d'abaisser le sysctl net.ipv4.ip_unprivileged_port_start à la valeur dont vous avez besoin. Exemple: nous devons lier notre application au port 443.

sysctl net.ipv4.ip_unprivileged_port_start=443

certains diront, il y a un problème de sécurité potentiel: les utilisateurs non privilégiés peuvent maintenant se lier aux autres ports privilégiés (444-1024). Mais vous pouvez résoudre ce problème facilement avec iptables, en bloquant d'autres ports:

iptables -I INPUT -p tcp --dport 444:1024 -j DROP
iptables -I INPUT -p udp --dport 444:1024 -j DROP

Comparaison avec d'autres méthodes. Ce méthode:

• d'un certain point est (IMO) encore plus sûr que de définir CAP_NET_BIND_SERVICE/setuid, depuis une application ne setuid pas du tout, même en partie (les capacités sont effectivement). Par exemple, pour attraper un coredump d'une application dotée de capacités, vous devrez changer sysctl fs.suid_dumpable (ce qui entraîne d'autres problèmes de sécurité potentiels)) De plus, lorsque CAP/suid est défini, le répertoire /proc/PID appartient à root, de sorte que votre utilisateur non-root n'aura pas de répertoire complet. information / contrôle du processus d'exécution, par exemple, l'utilisateur ne sera pas en mesure (dans le cas courant) de déterminer quelles connexions appartiennent à l'application via /proc/PID/fd/ (netstat-aptn | grep PID).
• a un inconvénient de sécurité: alors que votre application (ou toute autre application qui utilise les ports 443-1024) est en panne pour une raison quelconque, une autre application pourrait prendre le port. Mais ce problème pourrait aussi être appliqué à CAP/suid (dans le cas où vous l'avez mis sur interpréteur, par exemple java / nodejs) et iptables-redirect. Utiliser la méthode systemd-socket pour exclure ce problème. Utilisez la méthode authbind pour n'autoriser que la liaison utilisateur spéciale.
• ne nécessite pas de calage/suid chaque fois que vous déployez une nouvelle version d'application.
• ne nécessite pas de support/modification d'application, comme la méthode systemd-socket.
• ne nécessite pas de reconstruction du noyau (si la mise en route de la version prend en charge ce paramètre sysctl)
• ne fait pas LD_PRELOAD comme authbind/privbind méthode, cela pourrait affecter la performance, la sécurité, le comportement (est-ce? n'ai pas testé). Dans le reste authbind est vraiment flexible et sécurisée.
• sur-exécute la méthode iptables REDIRECT/DNAT, car elle ne nécessite pas de traduction d'adresse, de suivi d'état de connexion, etc. Cela ne se remarque que sur les systèmes à haute charge.

selon la situation, je choisirais entre sysctl, CAP, authbind et iptables-redirect. Et c'est grand que nous avons tellement d'options.

il y a aussi la 'voie djb'. Vous pouvez utiliser cette méthode pour lancer votre processus en tant que root sur n'importe quel port sous tcpserver, puis il contrôlera le processus à la main à l'utilisateur que vous spécifiez immédiatement après le début du processus.

#!/bin/sh

UID=`id -u yourusername`
GID=`id -g yourusername`
exec tcpserver -u $UID -g $GID -RHl0 0 portnumber   /path/to/your/process &

pour plus d'informations, voir: http://thedjbway.b0llix.net/daemontools/uidgid.html

comme L'OP n'est qu'un développement / test, moins que des solutions simples peuvent être utiles:

setcap peut être utilisé sur l'interpréteur d'un script pour accorder des capacités aux scripts. Si setcaps sur l'interpréteur binaire global n'est pas acceptable, faites une copie locale du binaire (n'importe quel utilisateur peut) et obtenez root pour setcap sur cette copie. Python2 (au moins) fonctionne correctement avec une copie locale de l'interpréteur dans votre arborescence de développement de script. Aucun suid n'est nécessaire pour que l'utilisateur root puisse contrôle des capacités auxquelles les utilisateurs ont accès.

si vous devez suivre les mises à jour à l'échelle du système vers l'interpréteur, utilisez un script shell comme celui-ci pour exécuter votre script:

#!/bin/sh
#
#  Watch for updates to the Python2 interpreter

PRG=python_net_raw
PRG_ORIG=/usr/bin/python2.7

cmp $PRG_ORIG $PRG || {
    echo ""
    echo "***** $PRG_ORIG has been updated *****"
    echo "Run the following commands to refresh $PRG:"
    echo ""
    echo "    $ cp $PRG_ORIG $PRG"
    echo "    # setcap cap_net_raw+ep $PRG"
    echo ""
    exit
}

./$PRG $*

utilise l'utilitaire privbind : il permet à une application non privilégiée de se lier aux ports réservés.

j'ai essayé la méthode de redirection iptables PREROUTING. Dans les noyaux plus anciens, il semble que ce type de règle n'était pas supporté pour IPv6 . Mais apparemment, il est maintenant pris en charge dans ip6tables v1.4.18 et Linux kernel v3.8.

j'ai aussi trouvé que la redirection pré-routage ne fonctionne pas pour les connexions initialisées dans la machine. Pour travailler pour conections à partir de la machine locale, ajouter une règle de sortie aussi-voir iptables redirection du port ne fonctionne pas pour localhost . Par exemple: quelque chose comme:

iptables -t nat -I OUTPUT -o lo -p tcp --dport 80 -j REDIRECT --to-port 8080

j'ai aussi trouvé que la redirection pré-routage affecte aussi les paquets transmis . En d'autres termes, si la machine transmet également des paquets entre interfaces (par exemple si elle agit comme un point D'accès Wi-Fi connecté à un réseau Ethernet), alors la règle iptables capturera également les connexions des clients connectés à des destinations Internet, et les redirigera vers la machine. Ce n'est pas ce que je voulais, je ne voulait rediriger les connexions qui étaient dirigées vers la machine elle-même. J'ai trouvé que je peux faire en sorte qu'il affecte seulement les paquets adressés à la boîte, en ajoutant -m addrtype --dst-type LOCAL . Par exemple: quelque chose comme:

iptables -A PREROUTING -t nat -p tcp --dport 80 -m addrtype --dst-type LOCAL -j REDIRECT --to-port 8080

une autre possibilité est d'utiliser le transfert de port TCP. Par exemple: en utilisant socat :

socat TCP4-LISTEN:www,reuseaddr,fork TCP4:localhost:8080

cependant un inconvénient avec cette méthode est, l'application qui est à l'écoute sur le port 8080 alors ne sait pas l'adresse source des entrants connexions (par exemple pour la journalisation ou d'autres fins d'identification).

réponse à 2015 / sept:

ip6tables supporte maintenant IPv6 NAT: http://www.netfilter.org/projects/iptables/files/changes-iptables-1.4.17.txt

vous aurez besoin du noyau 3.7+

preuve:

[09:09:23] root@X:~ ip6tables -t nat -vnL
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REDIRECT   tcp      eth0   *       ::/0                 ::/0                 tcp dpt:80 redir ports 8080
    0     0 REDIRECT   tcp      eth0   *       ::/0                 ::/0                 tcp dpt:443 redir ports 1443

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 6148 packets, 534K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 6148 packets, 534K bytes)
 pkts bytes target     prot opt in     out     source               destination