IDS is not as easy as that. Sometimes when there is an attack the IPS/IDS searches for the response to the attacker. An example of this is a brute force login attempt. Snort monitors for all the login failures returning to the attacker. In this case you are seen as the source and the attacker as the destination. This confuses the hell out of the graphics! I suspect really the webconfig needs recoding!
To disable a rule go to /etc/snort/scan.rules and look for the line with something like "sid: 2002995". Disable it by putting a # at the start of the line then restart snort.
I've no idea about debugging snort itself. It may be a query for your e-mail client provider.
To make the rule permanent, add it to the custom rules section of the firewall in the webconfig or add it directly to /etc/rc.d/rc.firewall.local. If you don't do this, any time the firewall restarts you ill lose your rule.
Odd. I am not too sure about snort. Were you connected internally or externally when it thought it was being brute-forced? For the moment you could try disabling the Scan rules and see if it helps.
Local queries should not go out into the internet. AFAIK mine are all blocked with the settings I gave. If it helps, this is my dnsmasq.conf:
Code:
# The "interface" parameter is set by the network policy (LAN/DMZ interfaces)
bogus-priv
bogus-priv
conf-file=/etc/dnsmasq/dhcp.conf
dhcp-authoritative
dhcp-lease-max=1000
dhcp-leasefile=/var/lib/misc/dnsmasq.leases
domain-needed
domain=howitts.lan
expand-hosts
local=/howitts.lan/
localise-queries
no-negcache
strict-order
user=nobody
There may be one or two difference with what you have.
The problem with OpenDNS is depending on your settings, a failed lookup will return an OpenDNS search. That is why you are getting a ping result. In my advanced settings I only have the Dynamic IP update checked. I also do not have the Guide Page, Block Page and Phishing Block Page selected. Try a combination of these.
Porteus developed from Slax and branched a bit over a year ago. They are the only distro's I know designed to run from a USB pen (which I am using to defeat my work laptop's restrictions - I can boot off USB and run a WiFi dongle in it so I can use it in hotels etc). I am not sure I would run it for a standard installation. Installing packages and tracking down dependencies can be a real pain. It took me all afternoon to get Ekiga installed and running and when it was failing it was not always obvious.
Surely for OpenVPN on Fedora it is a question of installing OpenVPN, downloading all the config and cert files from ClearOS into a directory and starting OpenVPN from that directory? If it does not work (and I'd do it anyway), install kvpnc and use that to manage OpenVPN - import your ClearOS configuration file then start the connection.
As well as. Input rules are for traffic directed to ClearOS. Forward rules are for traffic directed through ClearOS. The output rule should be unnecessary because you you have no input so you should get no output. If this does not work try removing the input rule as well.
Temporarily remove the MAC address line from the ifcfg-eth1 then bring the interface up. Then run an "ifconfig" to get the correct MAC address and put it back into the file.
ClearOS does not know where the 192.168.88.0/24 subnet is. You will need to add a route for it to route the whole subnet via your VPN. Try something like:
Code:
ip route add 192.168.88.0/24 dev tun0
There is also the "route" command which can achieve the same sort of thing.
I don't know fedora, but I'd go for OpenVPN. Can you not download the necessary packages in FC? I use OpenVPN in Porteus (a whacky distro) and for a GUI for it I use kvpnc. The only dependency I needed was iproute2 which is included in many distros. All I did to configure it was download the certificate and configuration files from ClearOS then import them into kvpnc. Put them all in one directory and the certificates are imported automatically when you import the .ovpn configuration file. In kvpnc I also modified the route option to keep my default route rather than replace it. I then start and stop OpenVPN through kvpnc. It can also be done from the command line but this was the easier solution for me.
Are you sure you want to add those lined to /etc/rc.d/rc.firewall.local? That file gets run every time the firewall is reloaded, e.g. when you change a firewall rule in the webconfig. If you want the line to just execute once on start up, add it to /etc/rc.d/rc.local.
I am surprised you need the "-m state" bit and without some more reading I am not sure it is correct. On the other hand if you block "new", you will never get an "established". I also so not see anything there to block outbound ssh as the destination in each rule is always your internal one. The "-m multiport" just stops you having to specify so many single port rules.
One thing, if this is for you to administer your system when away from it in specified locations, had you thought of using a VPN straight into your network? This would bypass the need for these firewall rules. A VPN would be best if you had a laptop or fixed machines in those locations which you are allowed to administer yourself.
iptables -I FORWARD -p tcp --dport 53 -j DROP
iptables -I FORWARD -p udp --dport 53 -j DROP
This means only lookups originating from ClearOS will get out, possibly except if you use a non-transparant proxy. You will then have people crying out that they can't access the internet.
Another possible way is to redirect their requests to ClearOS in the prerouting table with something like:
If you are connected but can't access resources, is your new LAN subnet the same as your old? If it is not the same, are the subnets different at each end of the tunnel?
@Tim,
I think that if you have a download failure and ping soon after, depending on the DNS cache expiry time you will get the same IP returned when you do the download and when you ping the server.
