Intrusion Prevention System - core 131

General questions.
dnl
Posts: 374
Joined: June 28th, 2013, 11:03 am

Re: Intrusion Prevention System - core 131

Post by dnl » June 30th, 2019, 10:03 am

H&M wrote:
June 27th, 2019, 7:14 pm
Last thing: I have a big GeoIP filtering in place - less than 3 countries allowed in. So IPS gets little number of packets, vast majority are blocked by GeoIP chain.
This chain stops all netscan attempts from so many entities that does that regularly...
Wow, I block a lot of countries and have seen a dramatic reduction in scans and suspicious traffic, but I still allow more than 3! Is internet access from the IPFire system restricted by your configuration?
IPFire 2.x (Latest Update) on x86_64 Intel Bay Trail CPU, 4GiB RAM, RED + GREEN + BLUE + ORANGE

User avatar
H&M
Posts: 466
Joined: May 29th, 2014, 9:38 pm
Location: Europe

Re: Intrusion Prevention System - core 131

Post by H&M » July 1st, 2019, 8:23 pm

dnl wrote:
June 30th, 2019, 10:03 am

Wow, I block a lot of countries and have seen a dramatic reduction in scans and suspicious traffic, but I still allow more than 3! Is internet access from the IPFire system restricted by your configuration?

Not at all. The traffic toward internal network is close to zero: besides VPN there is no other ports allowed toward Ipfire or any other machine in LAN. The 3 countries allowed are those where I live or travel frecquently so I need to be able to reach my home network while traveling.

The exit trafic is also heavily filtered:
1. DNS filtering - Cisco Umbrela blocks any DNS requests toward so many domains categories (like malware, adversite, etc) but also some ccTLD ones like .cn. Ad Googletagmanager and other Google tracking services >:D
2. URL filtering - all advertising , all malware, all phishing sites are blocked. And again a bunch of ccTLD because Cisco Umbrela is free and does not allow me to add there all countries I need. So I added them in URL filtering
3. 80% of countries (GeoIP) are also blocked at exit -> less than 12 countries allowed as exit IP addresses(as defined in GeoIP database ipfire uses).

Point 3 above is a real challenge sometime for automated systems, including pakfire update, linux update, windows update.
But all software that does these automated service updates are smart to retry next server in the list until found one from countries allowed.
Example: for some strange reason, although i don't leave in italy, my Windows machines try to download patches/updates from italy first.
I have no reasonable explanation why this is happening. And does not have a logic either: my access to Germany is 10 times faster as bandwidth compared with Italy and BITS (windows background intelligent transfer service) should tell this to windows update service when Italy IP is received after an DNS querry... Note: windows updates are usually downloaded by BITS....if I remember correctly how this works

Bottom line: not only that it works but also helped me to see some real wird behaviors of some automated updates.
Look at Linux: as soon as speed tests are done, any Linux machine will remember that Germany distro servers have better speed and update will try first Germany...
Microsoft is a nother kind of animal...a weird one.

Hope it helps.

PS: pakfire seems to tray random servers always - it does not remember last server used. Some updates have to be ran 2-3 times until an server from allowed countries is chosen. But there is no problem - no rush in here, I can restart pakfire upgrade process 2-3 times ...

dnl
Posts: 374
Joined: June 28th, 2013, 11:03 am

Re: Intrusion Prevention System - core 131

Post by dnl » July 2nd, 2019, 10:48 am

H&M wrote:
July 1st, 2019, 8:23 pm
Not at all. The traffic toward internal network is close to zero: besides VPN there is no other ports allowed toward Ipfire or any other machine in LAN. The 3 countries allowed are those where I live or travel frecquently so I need to be able to reach my home network while traveling.
There really needs to be a facepalm emoticon in this forum!
After all this time I hadn't realised the GeoIP blocking was for incoming traffic only! D'oh! It's clearly stated at the bottom of the page also.

Thanks for the details!

If you've got a spare virtual machine, docker container or Raspberry Pi could you please do me a favour?
Please try the "pi-hole" software as your primary DNS server for a while and see if you notice any difference. It's really easy to use and the default blocklists are more effective at blocking tracking than any other network-wide blocking I've found.

I set it up on a spare Raspberry Pi as a test once and never wanted to get rid of it. I just use it as my primary DNS and have it forward requests to IPFire. (I kept IPFire running DHCP)

It will be much quicker (lower latency) to have ads/tracking requests resolved locally to a dummy IP than having to go to (slow) external Cisco DNS servers. (At least the Cisco DNS servers are slow where I am).

H&M wrote:
July 1st, 2019, 8:23 pm
3. 80% of countries (GeoIP) are also blocked at exit -> less than 12 countries allowed as exit IP addresses(as defined in GeoIP database ipfire uses).

Point 3 above is a real challenge sometime for automated systems, including pakfire update, linux update, windows update.
I can imagine that's hard!

Pakfire seems to do the same for me and I have far less of the internet blocked than you do!
IPFire 2.x (Latest Update) on x86_64 Intel Bay Trail CPU, 4GiB RAM, RED + GREEN + BLUE + ORANGE

User avatar
H&M
Posts: 466
Joined: May 29th, 2014, 9:38 pm
Location: Europe

Re: Intrusion Prevention System - core 131

Post by H&M » July 9th, 2019, 11:32 pm

I got more Talos hits on top of ET ones wich are so many.
With both Talos and ET rules (all of them) loaded the memory consumption is steady at 780MB for suricata processess - past 50 days usage!

Code: Select all

 cat /var/log/suricata/fast.log | awk  '{sub(/.*\[1:/,"",$SID);print $2}' | grep "^[^EG]"
MALWARE-CNC
PROTOCOL-SCADA
MALWARE-CNC
MALWARE-CNC
PROTOCOL-SCADA
PROTOCOL-SCADA
Scada and Malware-CNC hits:

Code: Select all

07/07/2019-01:07:09.139571  [Drop] [**] [1:42016:2] PROTOCOL-SCADA Moxa discovery packet information disclosure attempt [**] [Classification: Attempted Information Leak] [Priority: 2] {UDP} 120.52.152.16:50585 -> a.b.c.d:4800
07/09/2019-14:25:19.392773  [Drop] [**] [1:42016:2] PROTOCOL-SCADA Moxa discovery packet information disclosure attempt [**] [Classification: Attempted Information Leak] [Priority: 2] {UDP} 122.228.19.80:40750 -> a.b.c.d:4800
07/09/2019-15:03:37.611695  [Drop] [**] [1:42016:2] PROTOCOL-SCADA Moxa discovery packet information disclosure attempt [**] [Classification: Attempted Information Leak] [Priority: 2] {UDP} 82.221.105.7:28855 -> a.b.c.d:4800
07/07/2019-00:51:55.925685  [Drop] [**] [1:31136:2] MALWARE-CNC Win.Trojan.ZeroAccess inbound connection [**] [Classification: A Network Trojan was Detected] [Priority: 1] {UDP} 151.53.61.153:1024 -> a.b.c.d:16464
07/07/2019-23:57:34.882411  [Drop] [**] [1:31136:2] MALWARE-CNC Win.Trojan.ZeroAccess inbound connection [**] [Classification: A Network Trojan was Detected] [Priority: 1] {UDP} 79.11.71.157:57378 -> a.b.c.d:16464
07/08/2019-21:13:16.802804  [Drop] [**] [1:31136:2] MALWARE-CNC Win.Trojan.ZeroAccess inbound connection [**] [Classification: A Network Trojan was Detected] [Priority: 1] {UDP} 151.53.61.153:1024 -> a.b.c.d:16464

dnl
Posts: 374
Joined: June 28th, 2013, 11:03 am

Re: Intrusion Prevention System - core 131

Post by dnl » July 13th, 2019, 4:16 am

H&M wrote:
July 9th, 2019, 11:32 pm
With both Talos and ET rules (all of them) loaded the memory consumption is steady at 780MB for suricata processess - past 50 days usage!
Ouch! It is not wise to use an IPS with all the rules enabled. It's only creating spam alerts and wasting your power. How do you know what alerts to act on?

Have you noticed since the change to Suricata that you get IPS alerts for countries who are blocked in your GeoIP settings?
The developers never announced it, but in a bugzilla ticket with Michael he talked about how he does not see the point of GeoIP blocking at all. I think he is being short-sighed as GeoIP blocking used to dramatically reduce the amount of noise I had with my IDS.
IPFire 2.x (Latest Update) on x86_64 Intel Bay Trail CPU, 4GiB RAM, RED + GREEN + BLUE + ORANGE

User avatar
H&M
Posts: 466
Joined: May 29th, 2014, 9:38 pm
Location: Europe

Re: Intrusion Prevention System - core 131

Post by H&M » August 8th, 2019, 7:47 pm

dnl wrote:
July 2nd, 2019, 10:48 am

If you've got a spare virtual machine, docker container or Raspberry Pi could you please do me a favour?
Please try the "pi-hole" software as your primary DNS server for a while and see if you notice any difference. It's really easy to use and the default blocklists are more effective at blocking tracking than any other network-wide blocking I've found.

I set it up on a spare Raspberry Pi as a test once and never wanted to get rid of it. I just use it as my primary DNS and have it forward requests to IPFire. (I kept IPFire running DHCP)

It will be much quicker (lower latency) to have ads/tracking requests resolved locally to a dummy IP than having to go to (slow) external Cisco DNS servers. (At least the Cisco DNS servers are slow where I am).
Hello,
Just did that - temporary because I have one Pi only.

I had to google for a bigger, aggregated list of domains but was not hard: I am blocking now an staggering ~600K domains.
I can sau Pi-Hole is awesome -> Youtube ads are history by the way..

Thanks, I'll have to go in the attic to find some old Pi, or to invest some time to follow up the tutorial for Debian install on APU.

One picture on how much domains Pi-Hole knows after adding this aggregated list:
Pi-Hole After adding additional blocking lists.PNG
Thanks!
H&M

dnl
Posts: 374
Joined: June 28th, 2013, 11:03 am

Re: Intrusion Prevention System - core 131

Post by dnl » August 11th, 2019, 10:40 am

H&M wrote:
August 8th, 2019, 7:47 pm
Hello,
Just did that - temporary because I have one Pi only.

I had to google for a bigger, aggregated list of domains but was not hard: I am blocking now an staggering ~600K domains.
I can sau Pi-Hole is awesome -> Youtube ads are history by the way..

Thanks, I'll have to go in the attic to find some old Pi, or to invest some time to follow up the tutorial for Debian install on APU.

One picture on how much domains Pi-Hole knows after adding this aggregated list:

Pi-Hole After adding additional blocking lists.PNG

Thanks!
H&M
Nice!

I find that, by default, smartphones can cause you to see 50% of domains blocked in normal usage!
I ended up getting sick of having my privacy compromised while I wasn't on my home network and so have installed a DNS ad-blocker on our Android devices too! However this means that the Pi-Hole is now not blocking as much.
IPFire 2.x (Latest Update) on x86_64 Intel Bay Trail CPU, 4GiB RAM, RED + GREEN + BLUE + ORANGE

User avatar
cbrown
Posts: 38
Joined: December 29th, 2017, 11:54 pm
Location: Texas

Re: Intrusion Prevention System - core 131

Post by cbrown » August 13th, 2019, 1:44 am

Curious about net setup up for Pi-Hole. Can I hang the RP/Pi-Hole box off my green net with a fixed address and then assign my IPFire DNS Server Address to be the Pi-Hole?
Image

User avatar
Arne.F
Core Developer
Core Developer
Posts: 8449
Joined: May 7th, 2006, 8:57 am
Location: BS <-> NDH
Contact:

Re: Intrusion Prevention System - core 131

Post by Arne.F » August 13th, 2019, 6:13 am

I think not, because dns-filtering and DNSSec validation are inkompatible.
On a signed zone you cannot fake a dns answer without knowing the secret key of the zone.
Arne

Support the project on the donation!

Image

Image

Image
PS: I will not answer support questions via email and ignore IPFire related messages on my non IPFire.org mail addresses.

dnl
Posts: 374
Joined: June 28th, 2013, 11:03 am

Pi-Hole with IPFire

Post by dnl » August 13th, 2019, 9:28 am

cbrown wrote:
August 13th, 2019, 1:44 am
Curious about net setup up for Pi-Hole. Can I hang the RP/Pi-Hole box off my green net with a fixed address and then assign my IPFire DNS Server Address to be the Pi-Hole?
I use the IPFire as my second DNS resolver, which the Pi-Hole uses.
I think the Pi-Hole is DNSSEC aware, but haven't checked.

A few people have sent me PMs asking, so here it is for the record. If I get time I'll write a wiki page:

All systems on my network use DHCP (most with static leases). I have configured the primary DNS server in my DHCP configuration on IPFire as the pi-hole and have the secondary as the IPFire DNS service. This way if the pi-hole is down systems can still resolve DNS and use the internet.

To be clear I don't use DHCP served from the Pi-hole.

The pi-hole itself is mostly a default installation and is configured to use IPFire as the only "Upstream DNS server". This makes the pi-hole the primary DNS server for everything internally. The pi-hole responds with a special IP for blocked domains (0.0.0.0 - a way to explicitly specify that the target is unavailable) which means the clients will not ever fall back to the secondary DNS server, unless the pi-hole is down.

The only other configuration on the pi-hole is to configure "Conditional Forwarding" with the IPFire IP as DNS server with the local domain name set. This allows the pi-hole to resolve local hosts and IPs.

Like IPFire, the pi-hole itself is a caching DNS server. It will query IPFire for every DNS domain or IP which it doesn't have a cache entry for. Over time I find that less than 25% of DNS queries are being answered by IPFire, with the rest being resolved by the pi-hole cache or from the blocklist.

The disadvantage of this set-up is that IPFire cannot see where all the DNS queries are coming from (they come from the pi-hole). However IPFire does not log DNS queries (without modification) and the Pi-Hole has a much better interface with clear overview graphs and easy to search DNS logs, with a number of filters.


I seem to remember someone in the past wanting DNS blocking on IPFire, but Michael didn't like the idea. I think he thought it was ineffective.
He's right if the issue is blocking porn from a determined human (who for example, might go to an "unsafe" image search on any search engine). However for blocking privacy-compromising sites from apps DNS blocking is very effective. I mostly care about privacy and use the (semi-effective) URL Filter in IPfire for blocking porn, etc.

Hope that helps.

EDIT: Note that you will need to also add firewall rules to allow other networks to query the Pi-Hole. Unlike IPFire it won't have an interface in every network. So for example, I have a rule like
  • Source, Standard networks: BLUE
  • Destination, Hosts: pi-hole
  • Protocol, - Preset, Service Groups: DNS (a service group with 853 TCP, 53 TCP and 53 UDP)
  • ACCEPT
IPFire 2.x (Latest Update) on x86_64 Intel Bay Trail CPU, 4GiB RAM, RED + GREEN + BLUE + ORANGE

Post Reply