Hi Houman, Yes, you're doing it wrong. The iptables conntrack module is not the conntrack that we are talking about. It is only the match module for conntrack in iptables. conntrack itself is the connection tracking part of Netfilter and by default, it's always active. It's not an iptables module. You also do not need that nflog rule. It does nothing in this regard. ulogd in this configuration gets conntrack events via netlink socket, not packets. If you check the json structure carefully, you see a src_ip, dest_ip, reply.ip.saddr.str and reply.ip.daddr.str. You see the connection's layer three and layer four data before and after NAT, which is exactly what you need.
Kind regards Noel Am 19.04.19 um 14:19 schrieb Houman: > Hello Noel, > > Thank you for the link. The article is amazing. I went through it and was > able to follow all the steps successfully. However, it is a shame that the > article has missed to mention how to setup iptables with conntrack. > > Am I using the conntrack correctly? You mentioned don't use NFLOG, but I'm > not sure if this is what you meant me to do: > > sudo iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j NFLOG > --nflog-group 1 --nflog-prefix "prefix: ESTABLISHED,RELATED" > > The result of this is that I still get the destination IP but the source > shows as 10.10.10.8. > > *vim http:///var/log/ulogd_nfct.json* > > {"timestamp": "2019-04-19T11:00:35", "dvc": "Netfilter", "orig.ip.protocol": > 6, "orig.l4.sport": 57939, "orig.l4.dport": 443, "orig.raw.pktlen": 2364, > "orig.raw.pktcount": 21, "reply.ip.protocol": 6, "reply.l4.sport": 443, > "reply.l4.dport": 57939, "reply.raw.pktlen": 6438, "reply.raw.pktcount": 13, > "ct.mark": 0, "ct.id <http://ct.id>": 43142912, "ct.event": 4, > "flow.start.sec": 1555671512, "flow.start.usec": 962666, "flow.end.sec": > 1555671635, "flow.end.usec": 803910, "oob.family": 2, "oob.protocol": 0, > "src_ip": "10.10.10.8", "dest_ip": "185.76.64.174", "reply.ip.saddr.str": > "185.76.64.174", "reply.ip.daddr.str": "172.31.4.4"} > > I tried once more by deleting the rule above and replacing it with this: > > sudo iptables -I FORWARD -m conntrack --ctstate NEW,RELATED,ESTABLISHED > > But with the same result. > > Am I on the right path or do you think I going into circles with this? > > Many Thanks, > Houman > > > On Wed, 17 Apr 2019 at 16:27, Noel Kuntze > <noel.kuntze+strongswan-users-ml@thermi.consulting> wrote: > > Hi Houman, > > > Use the conntrack input instead, not the nflog one. It solves all your > issues. Take a look at the article at regit.org <http://regit.org>[1]. > And please don't use iptables -L. Use iptables-save instead. > > Kind regards > > Noel > > [1] > https://home.regit.org/2014/02/logging-connection-tracking-event-with-ulogd/ > > Am 17.04.19 um 12:06 schrieb Houman: > > Hello Noel, > > > > Thank you for the tip. I will definitely look into RELP. For now, I > finally got it working with a JSON output for testing purposes only. > > > > I added this to the iptables: > > *sudo iptables -I FORWARD ! -i lo -p tcp -m tcp --tcp-flags > FIN,SYN,RST,ACK SYN -m state --state NEW -j NFLOG --nflog-prefix "Web 80" > --nflog-group 1* > > > > Chain INPUT (policy ACCEPT) > > num target prot opt source destination > > 1 ACCEPT all -- anywhere anywhere > state RELATED,ESTABLISHED > > 2 ACCEPT tcp -- anywhere anywhere tcp > dpt:https > > 3 ACCEPT tcp -- anywhere anywhere tcp > dpt:2022 > > 4 ACCEPT all -- anywhere anywhere > > 5 DROP all -- anywhere anywhere > state INVALID > > 6 ACCEPT udp -- anywhere anywhere udp > dpt:isakmp > > 7 ACCEPT udp -- anywhere anywhere udp > dpt:ipsec-nat-t > > 8 DROP all -- anywhere anywhere > > > > Chain FORWARD (policy ACCEPT) > > num target prot opt source destination > > 1 NFLOG tcp -- anywhere anywhere tcp > flags:FIN,SYN,RST,ACK/SYN state NEW nflog-prefix "Web 80" nflog-group 1 > > 2 ACCEPT all -- ip-10-10-10-0.eu-west-2.compute.internal/24 > anywhere policy match dir in pol ipsec proto esp > > 3 ACCEPT all -- anywhere > ip-10-10-10-0.eu-west-2.compute.internal/24 policy match dir out pol ipsec > proto esp > > 4 DROP all -- anywhere anywhere > > > > Chain OUTPUT (policy ACCEPT) > > num target prot opt source destination > > > > It works nicely. BUT the source IP shows as 10.10.10.8 > > I was expecting to see my real IP address. What am I missing, please? > > > > I know I can't add it to the INPUT because the VPN is masquerading. I > have to put the rule against FORWARD, otherwise, I get no entries in the log. > So what to do? > > > > { > > "timestamp": "2019-04-17T09:37:40.502387", > > "dvc": "My awesome Netfilter firewall", > > "raw.pktlen": 64, > > "raw.pktcount": 1, > > "oob.prefix": "Web 80", > > "oob.time.sec": 1555493860, > > "oob.time.usec": 502387, > > "oob.mark": 0, > > "oob.ifindex_in": 2, > > "oob.ifindex_out": 2, > > "oob.hook": 2, > > "raw.mac_len": 14, > > "oob.family": 2, > > "oob.protocol": 2048, > > "action": "allowed", > > "raw.type": 1, > > "raw.mac.addrlen": 6, > > "ip.protocol": 6, > > "ip.tos": 0, > > "ip.ttl": 63, > > "ip.totlen": 64, > > "ip.ihl": 5, > > "ip.csum": 44141, > > "ip.id <http://ip.id> <http://ip.id>": 0, > > "ip.fragoff": 16384, > > "src_port": 55560, > > "dest_port": 80, > > "tcp.seq": 1199851582, > > "tcp.ackseq": 0, > > "tcp.window": 65535, > > "tcp.offset": 0, > > "tcp.reserved": 0, > > "tcp.urg": 0, > > "tcp.ack": 0, > > "tcp.psh": 0, > > "tcp.rst": 0, > > "tcp.syn": 1, > > "tcp.fin": 0, > > "tcp.res1": 0, > > "tcp.res2": 3, > > "tcp.csum": 26423, > > "oob.in <http://oob.in> <http://oob.in>": "eth0", > > "oob.out": "eth0", > > "src_ip": "10.10.10.8", > > "dest_ip": "52.85.70.228", > > "mac.saddr.str": "xx", > > "mac.daddr.str": "xx", > > "mac.str": "xx" > > } > > > > Many Thanks, > > Houman > > > > On Tue, 16 Apr 2019 at 21:40, Noel Kuntze > <noel.kuntze+strongswan-users-ml@thermi.consulting> wrote: > > > > Hello Houman, > > > > I'd keep the logs as text only and stream them to a logging service > via RELP (don't use syslog over tcp. It can loose messages. RELP ensures > delivery by design.). > > Unless you really got a boatload of clients (> 4000) on a single > system, I doubt you'll run into problems. > > > > Kind regards > > > > Noel > > > > Am 16.04.19 um 22:19 schrieb Houman: > > > Hello Noel, > > > > > > Thank you very much for your detailed answer. I started looking > into ulogd2. Tutorials and documentation seem a bit scarce, but I'm sure I > will find my way around it eventually. If you have a good recommendation > please let me know. > > > > > > Do you recommend keeping ulogd2's logs locally or rather feed > them into a local LogStash? I wonder which one is faster and less resource > hungry. > > > > > > Many Thanks, > > > Houman > > > > > > > > > > > > > > > > > > > > > On Mon, 15 Apr 2019 at 19:26, Noel Kuntze > <noel.kuntze+strongswan-users-ml@thermi.consulting> wrote: > > > > > > Hello Houman, > > > > > > No, that is not a layer that strongSwan or freeradius does > have access to. You need to log (and account) the user's traffic using, for > example, a netflow collector or ulogd2 (which can use Linux's native > conntrack connection tracking system) to capture the relevant data. Using > ulogd2 is advised, because unless you disabled conntrack for the relevant > connections, you are basically guaranteed to get all information from > conntrack (unless ulogd2 can't keep up, but then you don't have enough > resources, so you have another issue already). > > > > > > Kind regards > > > > > > Noel > > > > > > Am 15.04.19 um 20:13 schrieb Houman: > > > > Hello, > > > > > > > > We got a notification from the German Federal Office for > Information Security that one of our users has been using a website with > malware to steal personal information and commit online-banking fraud. To > cover their tracks they have been using our StrongSwan VPN. > > > > > > > > > > > > We have now blocked the IPs that resolve to the given > website to prevent this from happening. Unfortunately, The freeRadius logs > and syslog we have in place are not enough to pinpoint it to the exact > culprit. > > > > > > > > > > > > Is there a way to run strongswan with maximum verbose logs > to see which EAP-Radius user has been accessing which IP address at what > time? We would like to ban users like this in future. > > > > > > > > > > > > From Freeradius we get to see the acctstartdate, > acctupdatedate and acctstopdate but there is no way to relate this to their > activities. > > > > > > > > > > > > > > > > Many Thanks, > > > > > > > > Houman > > > > > >
signature.asc
Description: OpenPGP digital signature
