[strongSwan] Is it possible to see which IP addresses the VPN users are accessing?
Houman
houmie at gmail.com
Fri Apr 19 14:19:50 CEST 2019
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": 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[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>": 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>": "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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20190419/f512656b/attachment.html>
More information about the Users
mailing list