[4.744] IDS Not Detecting Attacks

A couple more things.
The time is off in the webadmin by +5 hours. During setup I did choose the proper time zone for my area (America, New_York).

The HISTORY environment variable is set to 500. Is this just for beta?? Personally, for security, I would like to have it to where no previous shell commands are saved, or at least during logoff clearing the ~/.bash_history file.

When I turned on the HTTP proxy (no URL Filtering) I was getting an error that said "it is a deny only profile. it is a tough life". (or something close to that) I could turn it off and I could get out with no problem...I had set for the internal network allowed access.

I rebooted the ASL and retried the HTTP proxy (transparent, no URL filtering, using Mozilla 1.6 on WinXP). This time I was able to get out but I instantly received an alert e-mail that contained the following:
[1:620:0] D SCAN Proxy Port 8080 attempt [Classification: Attempted Information Leak] [Priority: 2]:  {PROTO006} 192.168.123.10:1506 -> 192.168.123.5:8080

I also ran the same Nessus scan as before. Still all ports were discovered, but this time I did receieve (a ton!!) alert mails and the hit counts went up in the IDS -> Rules. I did not receive any PSD alert mails, and yes, PSD is turned on.

Other misc./cosmetic things:
PPTP out the Internal net is not working...I have PPTP setup to be allowed out of the LAN to anywhere...in 4.021, have no problem. I tried it with PPTP both in and out of the connection tracking helper.
If I need to modify an existing network/service group that contains alot of items and I dont hold down the control key it wipes out all my previous entries and I have to hit cancel and start over.
There is something about the network defintion screen that just looks cluttered to me. Maybe breaking up groups from hosts would clean that up.
Manipulating rule positions in the packet filter rules does not work correctly.
Under HTTP Proxy -> Content Filtering  -> Profiles if you modify the Default Surf Protection Category to Locomotion for example, you can not change it back to ::none::.
Under Reporting -> Content Filter it appears to be only SMTP content filtering..will this also contain URL unauthorized hits?

Great job with this and thank you for the community involvement!!
  

The current beta has a bug in Intrusion Protection: when changing a configuration item (like enabling/disabling the port scan detection), the intrusion rules are not being activated. As a workaround, disable and enable the Intrusion Protection system after you have made changes. This will be fixed in the next snapshot.

Portscan detection is still broken in latest beta, therefore you don't see any alerts.

Concerning PPTP: can you check with lsmod whether the kernel module ip_nat_proto_gre.o is loaded?

Thanks,
Stephan
    

Stephan,
    Just checked...and that module is not loaded.  

Brent,

try a modprobe ip_nat_proto_gre and check if it works then. I assume that you are in a NAT environment?!

Regards,
Stephan
  

Did that and still no success:
asl5:/root # lsmod | grep gre
ip_nat_proto_gre        1316   0  (unused)
iptable_nat            16888   6  [ip_nat_proto_gre ipt_REDIRECT ipt_MASQUERADE ip_nat_mms ip_nat_h323 ip_nat_irc ip_nat_ftp]

The module is loaded now but after I attempt a PPTP connection to a known working host after about 15-25 seconds of the 'Verfiying Username and Password" I get an error 619.  And yes, my internal net is NAT'ed behind the ASL's external interface.

Brent,

Do you see what's happening on the network? Are the GRE packets getting through? Can you enable debugging on the PPTP server and post the results?

Thanks,
Stephan
  

The GRE packets do not appear to be getting through...a tcpdump on the external interface is showing the following:

18:59:12.859027 REMOTE_IP > MY_IP: gre [KSv1] ID:0000 S:2 ppp: Conf-Req(1), MRU=1490, ACCM=00000000, Auth-Prot CHAP/MSCHAPv2, Magic-Num=9b4d952a, PFC, ACFC, MRRU=1490, End-Disc MAC=00:e0:29:6f:9d:9b (DF)

18:59:12.859211 MY_IP > REMOTE_IP: icmp: 24.144.65.196 protocol 47 unreachable [tos 0xc0]

Let me know where any other logs are that would be usefull to you.  

The GRE packets do not appear to be getting through...a tcpdump on the external interface is showing the following:

18:59:12.859027 REMOTE_IP > MY_IP: gre [KSv1] ID:0000 S:2 ppp: Conf-Req(1), MRU=1490, ACCM=00000000, Auth-Prot CHAP/MSCHAPv2, Magic-Num=9b4d952a, PFC, ACFC, MRRU=1490, End-Disc MAC=00:e0:29:6f:9d:9b (DF)

18:59:12.859211 MY_IP > REMOTE_IP: icmp: 24.144.65.196 protocol 47 unreachable [tos 0xc0]

Let me know where any other logs are that would be usefull to you.  

Brent,

can you check where exactly the packets are being dropped? Could this be a problem on the client side? Do you see entries in the packet filter log of the gateway?

Stephan
  

PPTP is now working in 4.770!!

The IDS is still not detecting portscans or instrusions using Nessus against it. Snort service is running.

The NIC descriptions are still swapped...wrong manufacturer compared to MAC.

Webadmin time is still wrong.

Where is the 4.x style HTTP Proxy report so we can see where users are going and at what times? I may just be overlooking it.

Dell Dimension, 2.x GHz, 256MB RAM, Dell Integrated NIC, and Linksys NIC.  

Brent,

unfortunately a bug concerning Intrusion Protection (and therefore also portscan detection) sneaked into the shapshot. The netfilter rules are not set for Intrusion Protection, therefore the traffic bypasses the IPS engine.

Stephan