Snort blocks WAN IP….!
-
(http_inspect) IIS UNICODE CODEPOINT ENCODING - 02/26-02:05:57
ET POLICY Suspicious inbound to MSSQL port 1433 - 02/26-15:40:10
ET CIARMY Collective Intelligence Security Poor Reputation IP (TCP) - 02/26-14:14:52
ET DROP Dshield Block Listed Source - 02/25-10:41:59
(ssp_ssl) Invalid Client HELLO after Server HELLO Detected - 02/23-09:06:35
PSNG_TCP_PORTSWEEP_FILTERED - 01/27-11:52:07
ET POLICY Suspicious inbound to mySQL port 3306 - 02/26-15:19:19
ET SCAN Potential SSH Scan - 02/26-13:53:43
ET WEB_SERVER DFind w00tw00t GET-Requests - 02/11-14:26:19
ET SCAN Sipvicious User-Agent Detected (friendly-scanner) - 02/26-05:04:20
ET SCAN Modified Sipvicious User-Agent Detected (sundayddr) - 02/24-09:43:21
ET SCAN Modified Sipvicious Sundayddr Scanner (sipsscuser) - 02/24-09:43:21
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (5) - 01/27-10:10:19
ET TOR Known Tor Exit Node TCP Traffic (76) - 01/27-11:43:16
ET TROJAN Double HTTP/1.1 Header Inbound - Likely Hostile Traffic - 01/27-11:50:23
ET SCAN Potential VNC Scan 5900-5920 - 02/26-13:32:27
ET RBN Known Russian Business Network IP TCP (356) - 01/28-18:40:58
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (3) - 01/28-20:23:10
ET POLICY Suspicious inbound to Oracle SQL port 1521 - 01/28-22:16:38
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (55) - 01/29-17:45:36
ET SCAN Sipvicious Scan - 02/23-04:30:02
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (33) - 01/29-09:39:48
ET CIARMY Collective Intelligence Security Poor Reputation IP (UDP) - 02/22-16:09:57
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (36) - 02/24-12:13:05
ET SCAN Cisco Torch SNMP Scan - 02/26-02:50:49
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (35) - 02/24-07:14:34
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (27) - 01/31-14:31:11
ET WEB_SERVER PHP Attack Tool Morfeus F Scanner - 02/22-16:07:21
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (54) - 02/01-17:46:48
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (46) - 02/01-22:47:29
ET RBN Known Russian Business Network IP TCP (217) - 02/01-22:47:29
ET RBN Known Russian Business Network IP TCP (221) - 02/12-11:06:26
ET RBN Known Russian Business Network IP TCP (435) - 02/04-10:10:23
ET RBN Known Russian Business Network IP TCP (437) - 02/03-04:26:04
ET SCAN ZmEu Scanner User-Agent Inbound - 02/03-04:31:30
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (6) - 02/26-10:45:29
ET CURRENT_EVENTS DNS Amplification Attack Inbound - 02/21-21:10:44
ET RBN Known Russian Business Network IP TCP (423) - 02/25-16:20:38
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (29) - 02/05-07:54:44
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (38) - 02/25-11:18:38
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (7) - 02/16-10:43:25
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (19) - 02/07-20:19:08
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (41) - 02/16-16:42:22
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (56) - 02/09-20:48:58
ET RBN Known Russian Business Network IP TCP (90) - 02/08-19:43:25
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (28) - 02/25-16:46:15
ET RBN Known Russian Business Network IP TCP (424) - 02/08-20:52:34
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (45) - 02/09-21:12:54
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (48) - 02/10-16:40:20
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (39) - 02/15-01:48:42
ET RBN Known Russian Business Network IP TCP (209) - 02/20-09:19:46
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (20) - 02/14-13:25:02
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (50) - 02/22-10:16:37
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (12) - 02/15-23:42:50
ET RBN Known Russian Business Network IP TCP (200) - 02/17-05:20:54
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (42) - 02/17-06:50:01
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (61) - 02/17-16:53:28
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (60) - 02/18-16:31:31
ET RBN Known Russian Business Network IP TCP (352) - 02/18-23:11:33
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (44) - 02/19-18:23:31
ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (1) - 02/20-09:54:47
ET RBN Known Russian Business Network IP TCP (436) - 02/25-11:47:09This is what I get in the blocked tab on one of my WAN ip's. Anybody can tell me why??
Server has been tested and found clean.
-
Supermule:
You have more than one WAN IP on this box? In our previous discussions about this issue I always assumed just one WAN IP. If you told me before, I confess I missed it.
How many WAN IPs? Are you doing some sort of CARP (or VRRP in other circles)? This might figure into your problem. As I've stated previously, I am running the same Snort code and it has never ever blocked my WAN IP. However, since I'm on residential cable modem service, I have only a single WAN IP.
Bill
-
Hi Bill. I have 64 IP available. Its running on a VIP.
I suspect that SNORT doesnt whitelist VIP's but only the WAN IP of the interface itself.
Can that be changed?
-
I don't know. I'm not familiar enough with the guts of the Snort binary. I do know that the whitelist is really just a text file passed via a command-line argument to the snort2c program that handles the actual blocking by Snort.
Have you tried adding your VIP to the whitelist tab? You would have to create an alias for it. The current GUI code, when constructing the default whitelist, ask the FreeBSD kernel code for the current IP address of the WAN. That will return, I'm guessing, the actual IP and not the VIP.
Bill
-
Will try that and see if it works. Weird that it doesnt include VIP in WAN IP…
Update: investigating further. It is supposed to include VIP as well.
-
Open up and look at the actual whitelist file in the /usr/local/etc/snort_xxx directory appropriate for your WAN interface. The file is a plain text file. You can open and view it from the Diagnostics…Edit File menu choice in the pfSense menu bar. See if the correct IP addresses are in that file. Also, while there in the same directory, open up and look at the snort.conf file. Near the bottom you will see the output plugin line for the blocker. In that line will be some parameters such as "output alert_pf:" and then some other parameters. Here is what mine looks like for the WAN interface:
output alert_pf: /usr/local/etc/snort/snort_59991_re1/DNSForwardersAndDefaults,snort2c,src,killThe DNSForwardersAndDefaults entry is my whitelist file. That's the file you want to open up and examine to be sure it contains all the IP addresses it is supposed to have.
-
Despite beeing checked in the GUI, there is NO VIP included in the files. Only GW and the physical WAN interface IP.
-
At least now we know what the problem is … :-[
We might have to look to Ermal for this fix. I am not too familiar with the details of that part of the code. I know it makes calls into other areas of pfSense to get IP address info for the interfaces.
You can try to workaround the issue for now by manually adding an Alias for your VIP and then putting that Alias into your whitelist.
Bill
-
I have both edited the Friendly_ip whitelist to include the IP range /26 but it doesnt get updated in the Snort code.
Other ranges are there no problem.
Update: I updated the friendlyip list manually and put in the range. Restarted Snort and it didnt give errors.
But there is definately something wrong in PFSense regarding this package and the way it is controlled by the GUI.
If I edit the friendlyIP alias in PfSense, then it doesnt update the list in Snort even though its an alias.
-
Did the new IP Range Alias show up in the Whitelist tab properly in the GUI after entering it via the GUI? Trying to establish if the code might be having a problem with the slash during the PHP post/get operations (maybe not properly URL-encoding the slash).
-
I edited an allready existing alias….and put it in there.
It has 3 IP ranges in there allready with /....
-
Still blocks the WAN IP….............!!
-
Possibly dumb question, but is the WAN VIP in the same subnet as the actual WAN IP of the box? It might be the "snort2c" and "pfctl" modules that are getting confused and not Snort directly. In pfSense the actual blocking by Snort is done by a third-party plug-in patched into the Snort code. That plug-in might be where the problem is, and if so, will be much harder to troubleshoot.
Bill
-
yes it is :) All part of the same range.
-
The last troubleshooting step to hopefully isolate the culprit:
If the whitelist file referenced in the snort.conf file for the interface on the "output alert_pf" line actually contains a properly constructed setting for your virtual IP, then in my view that narrows the problem down to the third-party plugin and not really with Snort itself. The values in that file are pulled out and compared to "offending" IP addresses, and if there is a match, then the offender IP is NOT put in the blocking table.
Someone with a lot more knowledge of the packet filtering engine in FreeBSD may have to take it from there.
EDIT: just one last clarifying question (I apologize if you have answered this previously) – is Snort blocking the WAN VIP, the WAN interface IP, or both?
Bill
-
Only WAN VIP. NOT the interface IP.
-
I am kind of leaning toward this being a problem with the snort2c plug-in that actually puts the temp rule in the packet filter engine. But as I've said a few times, I am not the subject-matter expert in this area.
Maybe one of the core pfSense developers can chime in here with an idea.
A general call out to the public using Snort on pfSense:
Does anyone else out there using virtual IPs in pfSense with Snort in blocking mode have a problem with Snort blocking the WAN virtual IP?Bill
-
Update: It blocks WAN interface IP as well. But that happened only after the addition of the /26 range in Snort including the /
When Alias is edited and /26 range is removed, SNORT DOESNT GET UPDATED in the txt file in /usr/local/snort/interfacexxx/
So there is definately a bug in the system!
-
I guess I need to setup a dual-firewall system in VMware Workstation with pfSense to play around with this. However, I've never set up CARP with pfSense. I have configure VRRP in Check Point firewalls, though. Should be similar in concept, just not identical in form and procedure.
Can you say when this issue started for you? Was it prior to January 1st this year, or only later? This might help pin down any changes in the PHP code that might be related.
Bill
-
Thats a good question… It has been a long journey with Snort since it has a lot of problems with PfSense. You helped to make the package significantly better and that helped a lot!
A fair guess would be after we had the last discussion and I implemented your fixes.
