Sure, Thanks!
OK, here is what a GOOD login looks like:
2006-08-10 19:22:40: INFO: respond new phase 1 negotiation:
111.111.111.194[500]<=>83.36.51.44[500]
2006-08-10 19:22:40: INFO: begin Aggressive mode.
2006-08-10 19:22:40: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-
ike-02
2006-08-10 19:22:41: INFO: ISAKMP-SA established 111.111.111.194
[500]-83.36.51.44[500] spi:3ac2d5023f433d3e:e2d682b6f4fc4830
2006-08-10 19:22:42: INFO: respond new phase 2 negotiation:
111.111.111.194[0]<=>83.36.51.44[0]
2006-08-10 19:22:42: INFO: no policy found, try to generate the
policy : 10.0.1.5/32[0] 10.15.13.224/27[0] proto=any dir=in
2006-08-10 19:22:42: INFO: IPsec-SA established: ESP/Tunnel
83.36.51.44->111.111.111.194 spi=188599340(0xb3dcc2c)
2006-08-10 19:22:42: INFO: IPsec-SA established: ESP/Tunnel
111.111.111.194->83.36.51.44 spi=19221256(0x1254b08)
2006-08-10 19:22:42: ERROR: such policy does not already exist:
10.0.1.5/32[0] 10.15.13.224/27[0] proto=any dir=in
2006-08-10 19:22:42: ERROR: such policy does not already exist:
10.0.1.5/32[0] 10.15.13.224/27[0] proto=any dir=fwd
2006-08-10 19:22:42: ERROR: such policy does not already exist:
10.15.13.224/27[0] 10.0.1.5/32[0] proto=any dir=out
This line indicates that the initial phase 1 auth (pskeys or
certificates) have been exchanged correctly:
2006-08-10 19:22:41: INFO: ISAKMP-SA established 111.111.111.194
[500]-83.36.51.44[500] spi:3ac2d5023f433d3e:e2d682b6f4fc4830
The other two lines to notice, and the ones that definetly say we
have a new VPN established are:
2006-08-10 19:22:42: INFO: IPsec-SA established: ESP/Tunnel
83.36.51.44->111.111.111.194 spi=188599340(0xb3dcc2c)
2006-08-10 19:22:42: INFO: IPsec-SA established: ESP/Tunnel
111.111.111.194->83.36.51.44 spi=19221256(0x1254b08)
(there are two, one for incomming traffic, another for outgoing
traffic).
Strangely enough the last 3 errror lines are NOT errors. They are
caused because I am using a "roadwarrior" configuration where
connections are allowed from variable IP addresses as opposed to the
tipical VPN between two static IPs. They simply indicate that racoon
as automatically created security policies for those IPs (and both
sides are behind NAT).
------
Another sample of GOOD login (in this case between two static IPs)
2006-02-19 11:09:25: INFO: respond new phase 1 negotiation:
80.34.246.154[500]<=>217.127.190.50[500]
2006-02-19 11:09:25: INFO: begin Identity Protection mode.
2006-02-19 11:09:26: WARNING: ignore INITIAL-CONTACT notification,
because it is only accepted after phase1.
2006-02-19 11:09:26: INFO: ISAKMP-SA established 80.34.246.154
[500]-217.127.190.50[500] spi:bc013ca51d1a8745:9b95e47f6705088b
2006-02-19 11:09:26: INFO: respond new phase 2 negotiation:
80.34.246.154[0]<=>217.127.190.50[0]
2006-02-19 11:09:27: INFO: IPsec-SA established: ESP/Tunnel
217.127.190.50->80.34.246.154 spi=87487840(0x536f560)
2006-02-19 11:09:27: INFO: IPsec-SA established: ESP/Tunnel
80.34.246.154->217.127.190.50 spi=1290938215(0x4cf22767)
As you can see the last two lines are identical as the first case.
WARNING: in both samples they represent a "tunnel" configuration. I
do not know what they would look like in "transport" mode....
----------------------------
Now here are some samples of FAILLED logins from hackers trying to
get in:
2006-08-08 01:42:08: INFO: respond new phase 1 negotiation:
111.111.111.194[500]<=>222.155.15.88[500]
2006-08-08 01:42:08: INFO: begin Identity Protection mode.
2006-08-08 01:42:08: INFO: received Vendor ID: MS NT5 ISAKMPOAKLEY
2006-08-08 01:42:09: ERROR: couldn't find the pskey for 222.155.15.88.
2006-08-08 01:42:09: ERROR: failed to process packet.
2006-08-08 01:42:09: ERROR: phase1 negotiation failed.
2006-08-08 01:43:12: ERROR: unknown Informational exchange received.
The interesting line is:
2006-08-08 01:42:09: ERROR: couldn't find the pskey for 222.155.15.88.
also, there is no INFO: ISAKMP-SA established... line because phase 1
has failed.
Here is another case of invalid login, this time the errors are
caused because the hacker has used different settings for the many
options that need to be set the same way on both sides to establish a
VPN
2006-07-22 08:19:43: INFO: respond new phase 1 negotiation:
111.111.111.194[500]<=>209.83.102.10[500]
2006-07-22 08:19:43: INFO: begin Identity Protection mode.
2006-07-22 08:19:43: INFO: received Vendor ID: MS NT5 ISAKMPOAKLEY
2006-07-22 08:19:43: ERROR: invalid attribute type 32001.
2006-07-22 08:19:43: ERROR: invalid attribute type 32001.
2006-07-22 08:19:43: ERROR: invalid attribute type 32001.
2006-07-22 08:19:43: ERROR: invalid attribute type 32001.
2006-07-22 08:19:43: ERROR: rejected authmethod: DB
(prop#1:trns#1):Peer(prop#1:trns#2) = pre-shared key:GSS-API on
Kerberos 5
2006-07-22 08:19:43: ERROR: rejected authmethod: DB
(prop#1:trns#1):Peer(prop#1:trns#4) = pre-shared key:GSS-API on
Kerberos 5
2006-07-22 08:19:43: ERROR: rejected hashtype: DB(prop#1:trns#1):Peer
(prop#1:trns#4) = SHA:MD5
2006-07-22 08:19:43: ERROR: rejected enctype: DB(prop#1:trns#1):Peer
(prop#1:trns#6) = 3DES-CBC:DES-CBC
2006-07-22 08:19:43: ERROR: rejected authmethod: DB
(prop#1:trns#1):Peer(prop#1:trns#6) = pre-shared key:GSS-API on
Kerberos 5
2006-07-22 08:19:43: ERROR: rejected dh_group: DB(prop#1:trns#1):Peer
(prop#1:trns#6) = 1024-bit MODP group:768-bit MODP group
2006-07-22 08:19:43: ERROR: rejected enctype: DB(prop#1:trns#1):Peer
(prop#1:trns#8) = 3DES-CBC:DES-CBC
2006-07-22 08:19:43: ERROR: rejected authmethod: DB
(prop#1:trns#1):Peer(prop#1:trns#8) = pre-shared key:GSS-API on
Kerberos 5
2006-07-22 08:19:43: ERROR: rejected hashtype: DB(prop#1:trns#1):Peer
(prop#1:trns#8) = SHA:MD5
2006-07-22 08:19:43: ERROR: rejected dh_group: DB(prop#1:trns#1):Peer
(prop#1:trns#8) = 1024-bit MODP group:768-bit MODP group
2006-07-22 08:19:43: ERROR: no suitable proposal found.
2006-07-22 08:19:43: ERROR: failed to get valid proposal.
2006-07-22 08:19:43: ERROR: failed to process packet.
Let me know if you need anything else.
Thanks,
Charles
On Aug 10, 2006, at 19:37 , Daniel Cid wrote:
Yes,
If you can show us a few log samples from racoon (failed logins,
sucessful logins and anything else you may have), we can help you with
that :)
--
Daniel B. Cid
dcid ( at ) ossec.net
On 8/10/06, kef_list <[EMAIL PROTECTED]> wrote:
Yeah, that would be a need step, but I would also need to add info to
the decode.xml file, as well as a rules file, right?
I was wondering if anyone was working on this.
On Aug 10, 2006, at 16:39 , <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
wrote:
>
>
> I suppose you must add the following lines to the ossec.conf
>
> <localfile>
> <log_format>racoon</log_format>
> <location>/var/log/racoon.log</location>
> </localfile>
>
> Ruurd Bakker
> Network engineer
> SECQuard.nl
>
____________________________________________________
Institut Balear de Comunicacions, S.L.
Gremio Tejedores 22, 1
07009 Palma de Mallorca, Spain
Tel: +34 971.45.90.99 | Mobile: +34 607.87.12.77
Fax: +34 971.43.08.18 | E-mail: [EMAIL PROTECTED]
URL: http://www.ibacom.es/
____________________________________________________
____________________________________________________
Institut Balear de Comunicacions, S.L.
Gremio Tejedores 22, 1
07009 Palma de Mallorca, Spain
Tel: +34 971.45.90.99 | Mobile: +34 607.87.12.77
Fax: +34 971.43.08.18 | E-mail: [EMAIL PROTECTED]
URL: http://www.ibacom.es/
____________________________________________________
