[strongSwan] Is it possible to see which IP addresses the VPN users are accessing?
Noel Kuntze
noel.kuntze+strongswan-users-ml at thermi.consulting
Fri Apr 19 15:25:36 CEST 2019
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 at 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 at 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 at 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
> > >
> >
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20190419/7e94b324/attachment-0001.sig>
More information about the Users
mailing list