1: %% LyX 1.3 created this file.  For more info, see http://www.lyx.org/.

2: %% Do not edit unless you really know what you are doing.

3: \documentclass[english]{article}

4: \usepackage[T1]{fontenc}

5: \usepackage[latin1]{inputenc}

6: 

7: \makeatletter

8: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Textclass specific LaTeX commands.

9:  \newenvironment{lyxcode}

10:    {\begin{list}{}{

11:      \setlength{\rightmargin}{\leftmargin}

12:      \setlength{\listparindent}{0pt}% needed for AMS classes

13:      \raggedright

14:      \setlength{\itemsep}{0pt}

15:      \setlength{\parsep}{0pt}

16:      \normalfont\ttfamily}%

17:     \item[]}

18:    {\end{list}}

19: 

20: \usepackage{babel}

21: \makeatother

22: \begin{document}

23: 

24: \title{Log Analysis Case Study Using LoGS }

25: 

26: 

27: \author{Dmitry Mogilevsky\\

28: National Center for Supercomputer Applications\\

29: dmogilev@ncsa.uiuc.edu}

30: 

31: \maketitle

32: \begin{abstract}

33: A very useful technique a network administrator can use to identify

34: problematic network behavior is careful analysis of logs of incoming

35: and outgoing network flows.  The challenge one faces when attempting

36: to undertake this course of action, though, is that large networks

37: tend to generate an extremely large quantity of network traffic in

38: a very short period of time, resulting in very large traffic logs

39: which must be analyzed post-generation with an eye for contextual

40: information which may reveal symptoms of problematic traffic%

41: \footnote{Such as non-obvious port scans and traffic indicative of worm activity%

42: }.  A better technique is to perform real-time log analysis using a

43: real-time context-generating tool such as LoGS.

44: \end{abstract}

45: 

46: \section{Introduction}

47: 

48: One of the simplest and most comprehensive intrusion detection methods

49: available to a network administrator is analysis of firewall or network

50: manager (such as Cisco's NetFlow) logs\cite{Ranum04}. Even logs containing

51: very basic information, such as destination and source IP address-port

52: pairs can under proper scrutiny reveal important information about

53: attempted attacks on the system and internal problems. Firewall or

54: another central point for network traffic is an ideal spot for collecting

55: this information, since 

56: 

57: \begin{itemize}

58: \item All network traffic passes through it.

59: \item Most firewalls generate excellent activity logs\cite{Cid04}.

60: \end{itemize}

61: The usefulness of this technique is diminished by the fact that on

62: large networks, any interesting messages will be interspersed among

63: a large number of non-malicious traffic. Combined with the fact that

64: large networks send and receive on millions of connections per second,

65: doing intrusion detection becomes a problem of finding a needle in

66: a hay stack. For example, consider the following fictional log entries:

67: 

68: \begin{lyxcode}

69: Nov~5~14:03:33,{*}.{*}.{*}.10:3434,1.2.3.5:12346~

70: 

71: Nov~5~14:15:13,{*}.{*}.{*}.10:3434,1.2.3.6:12346~

72: 

73: Nov~5~14:28:32,{*}.{*}.{*}.10:3434,1.2.3.7:12346~

74: 

75: Nov~5~14:40:11,{*}.{*}.{*}.10:3434,1.2.3.8:12346

76: \end{lyxcode}

77: This example shows a host on address {*}.{*}.{*}.10 scanning our network

78: for open NetBus ports\cite{ISS98}. However, since this is a very

79: slow scan (individual connections are approximately 12 minutes apart),

80: there may be several million non-informative log entries separating

81: these interesting entries. Depending on the way the log is audited

82: by the administrator, it is possible for this trend to be missed.

83: Instead of analyzing large network logs in search of tell-tale signs

84: of attempted (or successful) intrusion, the network administrator

85: may opt for using a real-time log analysis tool to analyze log messages

86: as they are generated and detect problems based on context created

87: by previously seen messages.

88: 

89: 

90: \section{The Problem}

91: 

92: For this case study, anonymized NetFlow log generated by connections

93: to and from the network of a large university was examined. The log

94: is over 1 GB in size. Chronologically, it spans a little over one

95: hour. It contains 13.6 million individual entries. Currently, these

96: logs are collected, but not analyzed, despite containing a wealth

97: of information. It is possible to write a rudimentary script which

98: will process such logs post-creation and search for interesting information.

99: In adopting this strategy a number of questions must be considered.

100: 

101: \begin{enumerate}

102: \item How do I subdivide the log into separate files?

103: \item How do I collect and store contextual information that will help me

104: detect port scans?

105: \item Can I handle potential context overflow from one log to the next?

106: \item Do I process each log file after its created, or do I collect some

107: number of log files and process them as a batch?

108: \end{enumerate}

109: Appendix 1 shows a sample script to process such logs. While it is

110: fairly concise, it does a poor job of addressing contextual issues.

111: Specifically, it only stores state for the last connection, which

112: makes it impossible for this script to detect any port scans where

113: the connections are not immediately subsequent. While it is possible

114: to increase the depth of stored context, doing so would necessitate

115: creating a store-and-search infrastructure for context, which, when

116: done improperly can greatly reduce the performance of the script.

117: Additionally, this script does not address the problem of context

118: overflowing from one log file to another. These questions can be bypassed

119: altogether, on the other hand, by real-time scanning with LoGS.

120: 

121: 

122: \section{LoGS}

123: 

124: LoGS, currently under development by James Prewett at the Center for

125: High Performance Computing at University of New Mexico is a highly

126: customizable and extensible real-time log analysis engine written

127: in Common Lisp. It is quite efficient, able to process as many as

128: 72,000 messages per second \cite{Pre05}. Because it uses Common Lisp

129: in its rule definition, it can be programmed to create and store states

130: and run complex scripts whenever a message is matched \cite{Pre04}. 

131: 

132: The use of Common Lisp makes LoGS unique from other log analysis tools.

133: Common Lisp was chosen for its flexibility, availability and ease

134: of use. Lisp also has a fast regular expression engine\cite{Wei03},

135: which allows LoGS to achieve its high message processing speed. Also,

136: since Common Lisp is used to configure the rulesets as well, LoGS

137: is user-extendable.

138: 

139: LoGS consists of five components - Messages, Rules, Rulesets, Actions

140: and Contexts. Rules associate Messages (input from the analyzed log)

141: with Actions (Lisp or external scripts). Rulesets extend Rules by

142: grouping them together into related sets. Contexts collect related

143: messages together to be processed as a group. Because LoGS actions

144: can create new rules, as well as update existing rules, LoGS is run-time

145: configurable. \cite{Pre04}

146: 

147: 

148: \section{Analyzing Firewall logs with LoGS}

149: 

150: The context-oriented design of LoGS fits perfectly for the goal of

151: real-time firewall log analysis. Firewall logs differ from, for example,

152: system logs in that you cannot implement artificial ignorance\cite{Ranum04},

153: as every message may potentially contain interesting information when

154: taken in a context of other messages. Every incoming connection must

155: be examined against existing contents, and either update them if necessary

156: or create new ones.

157: 

158: 

159: \subsection{Rules}

160: 

161: To effectively detect suspicious behavior in connection logs, LoGS

162: must be configured to match every incoming message, isolating three

163: crucial pieces of information - local address, remote address, and

164: local port. The local port is then checked against a list of vulnerable

165: ports to identify a possible vulnerability scan. Next, the remote

166: address, local address and local port are checked against the existing

167: contexts for matches on remote address and local address (indicating

168: a potential vertical port scan) or remote address and local port (indicating

169: a potential horizontal port scan)\cite{Lis}. If an existing context

170: is found, the message is added to that context. Otherwise a new context

171: is created for the new message. 

172: 

173: 

174: \subsection{Contexts}

175: 

176: Each log entry is entered into a context, either a pre-existing one,

177: or a new one, depending on whether a similar message has been previously

178: seen. Each context that exists has a timeout, which is incremented

179: each time a new message is added to the context. When context timeout

180: occurs, a context action is triggered and the context is removed from

181: the system. By increasing the size of the timeout value, the administrator

182: can detect slower port scans (at the price of performance). 

183: 

184: 

185: \subsection{Actions}

186: 

187: When a context times out and certain conditions are met (for example,

188: number of accumulated messages in the context. It should be at least

189: two or more), an action will be triggered. Since LoGS allows to define

190: actions with arbitrary Lisp programs and even external scripts, its

191: possible for contexts to trigger very complex series of actions. At

192: the very least, all the messages in the context should be written

193: to a separate port scans file. A real-time alert should also be displayed

194: to the console whenever there is an open context which has accumulated

195: two or more messages. 

196: 

197: 

198: \subsection{Defining real-time log analyzer in LoGS}

199: 

200: Using the mentioned elements of LoGS it is fairly easy to construct

201: a small ruleset to do detailed real-time log analysis. The following

202: code is a sample of the LoGS code used to accomplish such a task,

203: written in Common Lisp. 

204: 

205: \begin{lyxcode}

206: 

207: 

208: ;Firewall~analysis~ruleset~to~spot~vertical

209: 

210: ;and~horizontal~port~scan

211: 

212: 

213: 

214: (make-instance

215: 

216: ~~'rule

217: 

218: ~~:match

219: 

220: ~~(lambda~(message)

221: 

222: ~~~~(multiple-value-bind~(matches~sub-matches)

223: 

224: ~~~~~~~~(cl-ppcre::scan-to-strings

225: 

226: ~~~~~~~~~(\char`\"{}({[}0-9{]}+),({[}0-9{]}+),({[}0-9{]}+:{[}0-9{]}+:{[}0-9{]}+),

227: 

228: ~~(TCP|UDP|ICMP),({[}0-9{]}+.{[}0-9{]}+.{[}0-9{]}+.{[}0-9{]}+):({[}0-9{]}+|-{}-),

229: 

230: ~~({[}0-9{]}+.{[}0-9{]}+.{[}0-9{]}+.{[}0-9{]}+):({[}0-9{]}+|-{}-),

231: 

232: ~~{[}0-9{]}+,({[}0-9{]}+)\char`\"{}

233: 

234: ~~~~~~~~~~(message~message)))

235: 

236: ~~~~~~(when~matches

237: 

238: ~~~~~~~~(values

239: 

240: ~~~~~~~~~t

241: 

242: ~~~~~~~~~`((sub-matches~,sub-matches))))))

243: 

244: ~~:actions

245: 

246: ~~~(

247: 

248: ~~~~~(make-instance~'rule

249: 

250: ~~~~~~~~:match

251: 

252: ~~~~~~~~(lambda~(message)

253: 

254: ~~~~~~~~~~(multiple-value-bind~(matches~sub-matches)

255: 

256: ~~~~~~~~~~~~~~~~(cl-ppcre::scan-to-strings

257: 

258: ~~~~~~~~~~~~~~~~~~~~~~~~\char`\"{}({[}0-9{]}+),({[}0-9{]}+),

259: 

260: ~~~~~~~~~~~~~~~~~~~~~~~~~({[}0-9{]}+:{[}0-9{]}+:{[}0-9{]}+),

261: 

262: ~~~~~~~~~~~~~~~~~~~~~~~~~(TCP|UDP|ICMP),

263: 

264: ~~~~~~~~~~~~~~~~~~~~~~~~~(aref~sub-matches~4):({[}0-9{]}+|-{}-),

265: 

266: ~~~~~~~~~~~~~~~~~~~~~~~~~(aref~sub-matches~6):({[}0-9{]}+|-{}-),

267: 

268: ~~~~~~~~~~~~~~~~~~~~~~~~~{[}0-9{]}+,({[}0-9{]}+)\char`\"{}

269: 

270: ~~~~~~~~~~~~~~~~~~~~~~~~(message~message))

271: 

272: ~~~~~~~~~~~~~~~~(when~matches

273: 

274: ~~~~~~~~~~~~~~~~~~(values

275: 

276: ~~~~~~~~~~~~~~~~~~~~T

277: 

278: ~~~~~~~~~~~~~~~~~~~~`((sourceip~,(aref~sub-matches~4))

279: 

280: ~~~~~~~~~~~~~~~~~~~~~~(sourceport,(aref~sub-matches~5))

281: 

282: ~~~~~~~~~~~~~~~~~~~~~~(destip,~(aref~sub-matches~6))

283: 

284: ~~~~~~~~~~~~~~~~~~~~~~(destport,~(aref~sub-matches~7)

285: 

286: ~~~~~~~~~~~~~~~~~~~~~~(time,~(aref~sub-matches~2))

287: 

288: ~~~~~~~~~~~~~~~~~~~)))))

289: 

290: ~~~~~~~~:actions

291: 

292: ~~~~~~~~(list

293: 

294: ~~~~~~~~~~(lambda~(message)

295: 

296: ~~~~~~~~~~~~~~~~(declare~(ignore~message))

297: 

298: ~~~~~~~~~~~~~~~~(ensure-context

299: 

300: ~~~~~~~~~~~~~~~~~~:name~(format~()~\char`\"{}vertical~scan~from~\textasciitilde{}A\char`\"{}~sourceip)

301: 

302: ~~~~~~~~~~~~~~~~~~:timeout~(+~get\_universal\_time~timeout\_value)

303: 

304: ~~~~~~~~~~~~~~~~~~:actions

305: 

306: ~~~~~~~~~~~~~~~~~~(list

307: 

308: ~~~~~~~~~~~~~~~~~~(lambda~(message)

309: 

310: ~~~~~~~~~~~~~~~~(add-to-context

311: 

312: ~~~~~~~~~~~~~~~~~~(format~()~\char`\"{}Vertical~scan:~\textasciitilde{}A:\textasciitilde{}A~to~\textasciitilde{}A:\textasciitilde{}A~at~\textasciitilde{}A\char`\"{}~

313: 

314: ~~~~~~~~~~~~~~~~~~~~sourceip~sourceport~destip~destport~time)

315: 

316: ~~~~~~~~~~~~~~~~~~message))))

317: 

318: ~~~)

319: 

320: (make-instance~'rule

321: 

322: ~~~~~~~~:match

323: 

324: ~~~~~~~~(lambda~(message)

325: 

326: ~~~~~~~~~~(multiple-value-bind~(matches~sub-matches)

327: 

328: ~~~~~~~~~~~~~~~~(cl-ppcre::scan-to-strings

329: 

330: ~~~~~~~~~~~~~~~~~~~~~~~~\char`\"{}({[}0-9{]}+),({[}0-9{]}+),

331: 

332: ~~~~~~~~~~~~~~~~~~~~~~~~~({[}0-9{]}+:{[}0-9{]}+:{[}0-9{]}+),

333: 

334: ~~~~~~~~~~~~~~~~~~~~~~~~~(TCP|UDP|ICMP),

335: 

336: ~~~~~~~~~~~~~~~~~~~~~~~~~(aref~sub-matches~4):({[}0-9{]}+|-{}-),

337: 

338: ~~~~~~~~~~~~~~~~~~~~~~~~~({[}0-9{]}+.{[}0-9{]}+.{[}0-9{]}+.{[}0-9{]}+):

339: 

340: ~~~~~~~~~~~~~~~~~~~~~~~~~(aref~sub-matches~7),

341: 

342: ~~~~~~~~~~~~~~~~~~~~~~~~~{[}0-9{]}+,({[}0-9{]}+)\char`\"{}

343: 

344: ~~~~~~~~~~~~~~~~~~~~~~~~(message~message))

345: 

346: ~~~~~~~~~~~~~~~~(when~matches

347: 

348: ~~~~~~~~~~~~~~~~~~(values

349: 

350: ~~~~~~~~~~~~~~~~~~~~T

351: 

352: ~~~~~~~~~~~~~~~~~~~~`((sourceip~,(aref~sub-matches~4))

353: 

354: ~~~~~~~~~~~~~~~~~~~~~~(sourceport,(aref~sub-matches~5))

355: 

356: ~~~~~~~~~~~~~~~~~~~~~~(destip,~(aref~sub-matches~6))

357: 

358: ~~~~~~~~~~~~~~~~~~~~~~(destport,~(aref~sub-matches~7)

359: 

360: ~~~~~~~~~~~~~~~~~~~~~~(time,~(aref~sub-matches~2))

361: 

362: ~~~~~~~~~~~~~~~~~~~)))))

363: 

364: ~~~~~~~~:actions

365: 

366: ~~~~~~~~(list

367: 

368: ~~~~~~~~~~(lambda~(message)

369: 

370: ~~~~~~~~~~~~~~~~(declare~(ignore~message))

371: 

372: ~~~~~~~~~~~~~~~~(ensure-context

373: 

374: ~~~~~~~~~~~~~~~~~~:name~(format~()~\char`\"{}horizontal~scan~from~\textasciitilde{}A\char`\"{}~sourceip)

375: 

376: ~~~~~~~~~~~~~~~~~~:timeout~(+~get\_universal\_time~timeout\_value)

377: 

378: ~~~~~~~~~~~~~~~~~~:actions

379: 

380: ~~~~~~~~~~~~~~~~~~(list

381: 

382: ~~~~~~~~~~~~~~~~~~(lambda~(context)

383: 

384: ~~~~~~~~~~~~~~~~~~~~(if~(>=~(get\_universal\_time)~(timeout~context))

385: 

386: ~~~~~~~~~~~~~~~~~~~~~~~(report\_context)

387: 

388: ~~~~~~~~~~~~~~~~~~)

389: 

390: ~~~~~~~~~~~~~~~~~~(lambda~(message)

391: 

392: ~~~~~~~~~~~~~~~~(add-to-context

393: 

394: ~~~~~~~~~~~~~~~~~~(format~()~\char`\"{}Horizontal~scan:~\textasciitilde{}A:\textasciitilde{}A~to~\textasciitilde{}A:\textasciitilde{}A~at~\textasciitilde{}A\char`\"{}~

395: 

396: ~~~~~~~~~~~~~~~~~~~~sourceip~sourceport~destip~destport~time)

397: 

398: ~~~~~~~~~~~~~~~~~~message))))

399: 

400: ~~~)

401: 

402: ~~)

403: 

404: 

405: \end{lyxcode}

406: 

407: \section{Conclusions}

408: 

409: Real time firewall log analysis in LoGS offers a flexible and extensible

410: alternative to batch offline analysis. Its capability for contextual

411: message parsing is ideally suited for the task of detecting port scans,

412: as these cannot be detected from any single connection and can only

413: be inferred by looking at the context of previous connections. LoGS

414: provides the infrastructure for contextual data collection, and the

415: capability to trigger arbitrarily sophisticated response. This makes

416: log analysis a very powerful tool for successful (and potentially

417: real-time) intrusion detection.

418: 

419: 

420: \section{Appendix 1 - Sample Perl code}

421: 

422: \begin{lyxcode}

423: \#!/usr/bin/perl

424: 

425: print~\char`\"{}Input?~\char`\"{};

426: 

427: \$infile~=~<STDIN>;

428: 

429: open(INPUT,\$infile)||die~\char`\"{}Could~not~open~\$infile\textbackslash{}n\char`\"{};

430: 

431: print~\char`\"{}Outgoing~connections?~\char`\"{};

432: 

433: \$outgoingfile~=~<STDIN>;

434: 

435: print~\char`\"{}Incoming~connections?~\char`\"{};

436: 

437: \$incomingfile~=~<STDIN>;

438: 

439: print~\char`\"{}File~date~(yyyy/mm/dd)?~\char`\"{};

440: 

441: \$date~=~<STDIN>;

442: 

443: print~\char`\"{}Vulnerabilities~file?~\char`\"{};

444: 

445: \$vulfile~=~<STDIN>;

446: 

447: chop(\$date);

448: 

449: \$portscans~=~0;

450: 

451: \$ongoingps~=~0;

452: 

453: open(VULNERABILITIES,~\char`\"{}\$vulfile\char`\"{})

454: 

455: ~||die~\char`\"{}Could~not~open~\$vulfile\textbackslash{}n\char`\"{};

456: 

457: open(OUTGOING,\char`\"{}>\$outgoingfile\char`\"{})

458: 

459: ~||die~\char`\"{}Could~not~open~\$outgoingfile\textbackslash{}n\char`\"{};

460: 

461: open(INCOMING,\char`\"{}>\$incomingfile\char`\"{})

462: 

463: ~||die~\char`\"{}Could~not~open~\$incomingfile\textbackslash{}n\char`\"{};

464: 

465: open(PORTSCANS,\char`\"{}>portscans\_\$infile\char`\"{})

466: 

467: ~||die~\char`\"{}Could~not~create~portscans~file\textbackslash{}n\char`\"{};

468: 

469: open(VULSCANS,\char`\"{}>vulscans\_\$infile\char`\"{})

470: 

471: ~||die~\char`\"{}Could~not~create~vulnerabilities~scan~file\textbackslash{}n\char`\"{};

472: 

473: while(<VULNERABILITIES>)~\{

474: 

475: ~m/\textasciicircum{}({[}a-zA-Z0-9~{]}+),({[}0-9{]}+),(in|out)\$/;

476: 

477: ~if~(\$3~==~'in')\{

478: 

479: ~~\$invul\{\$2\}~=~\$1~;

480: 

481: ~\}

482: 

483: ~else\{

484: 

485: ~~\$outvul\{\$2\}~=~\$1~;

486: 

487: ~\}

488: 

489: \}

490: 

491: 

492: 

493: \$counter~=~0;

494: 

495: \$sourceip~=~\char`\"{}\char`\"{};

496: 

497: \$sourceport~=~\char`\"{}\char`\"{};

498: 

499: \$destip~=~\char`\"{}\char`\"{};

500: 

501: \$destport~=~\char`\"{}\char`\"{};

502: 

503: \$time~=~\char`\"{}\char`\"{};

504: 

505: while(<INPUT>)~\{

506: 

507: /({[}0-9{]}+),({[}0-9{]}+),({[}0-9{]}+:{[}0-9{]}+:{[}0-9{]}+),

508: 

509: ~(TCP|UDP|ICMP),({[}0-9{]}+.{[}0-9{]}+.{[}0-9{]}+.{[}0-9{]}+)

510: 

511: ~:({[}0-9{]}+|-{}-),({[}0-9{]}+.{[}0-9{]}+.{[}0-9{]}+.{[}0-9{]}+)

512: 

513: ~:({[}0-9{]}+|-{}-),{[}0-9{]}+,({[}0-9{]}+)/;

514: 

515: \$lastsourceip~=~\$sourceip;

516: 

517: \$lastsourceport~=~\$sourceport;

518: 

519: \$lastdestip~=~\$destip;

520: 

521: \$lastdestport~=~\$destport~;

522: 

523: \$lasttime~=~\$time~;

524: 

525: \$time~=~\$3;

526: 

527: \$protocol~=~\$4;

528: 

529: \$sourceip~=~\$5;

530: 

531: \$sourceport~=~\$6;

532: 

533: \$destip~=~\$7;

534: 

535: \$destport~=~\$8;

536: 

537: \$packets~=~\$9~;

538: 

539: if~(\$destport~==~\char`\"{}-{}-\char`\"{})~

540: 

541: ~~\{\$destport~=~\char`\"{}0\char`\"{};\}

542: 

543: if~(\$sourceport~==~\char`\"{}-{}-\char`\"{})~

544: 

545: ~~\{\$sourceport~=~\char`\"{}0\char`\"{};\}

546: 

547: if~(\$sourceip~=\textasciitilde{}~/10.{[}0-9{]}+.{[}0-9{]}+.{[}0-9{]}+/)\{

548: 

549: ~print~OUTGOING~\char`\"{}FWOUT,\$date,\$time~-5:00

550: 

551: ~~GMT,\$sourceip:\$sourceport,\$destip:

552: 

553: ~~\$destport,\$protocol\textbackslash{}n\char`\"{};

554: 

555: ~if~(exists(\$outvul\{\$sourceport\}))\{

556: 

557: ~~print~VULSCANS~\char`\"{}Potential~Vulnerability:

558: 

559: ~~~\$outvul\{\$sourceport\}.\textbackslash{}n~\$time:~

560: 

561: ~~~\$sourceip:\$sourceport~->~\$destip:

562: 

563: ~~~\$destport\textbackslash{}n\char`\"{}~;

564: 

565: ~\}

566: 

567: \}

568: 

569: else\{

570: 

571: ~print~INCOMING~\char`\"{}FWIN,\$date,\$time~-5:00

572: 

573: ~~GMT,\$sourceip:\$sourceport,\$destip:

574: 

575: ~~\$destport,\$protocol\textbackslash{}n\char`\"{};

576: 

577: ~if~(\$sourceip~==~\$lastsourceip~\&\&~

578: 

579: ~~~~((\$destip~==~\$lastdestip~\&\&~

580: 

581: ~~~~~~\$destport~!=~\$lastdestport)||

582: 

583: ~~~~~(\$destport~==~\$lastdestport~\&\&~

584: 

585: ~~~~~~\$destip~!=~\$lastdestip)))~\{

586: 

587: ~~if~(exists(\$invul\{\$destport\}))\{

588: 

589: ~~~~print~VULSCANS~\char`\"{}Potential~Vulnerability:~

590: 

591: ~~~~~\$invul\{\$destport\}.\textbackslash{}n~\$time:~

592: 

593: ~~~~~\$sourceip:\$sourceport~->~\$destip:

594: 

595: ~~~~~\$destport\textbackslash{}n\char`\"{}~;

596: 

597: ~~\}

598: 

599: ~if~(\$ongoingps~==~0)\{

600: 

601: ~\$ongoingps~=~1;

602: 

603: ~\$portscans~=~\$portscans~+~1;

604: 

605: ~if~(\$destip~==~\$lastdestip)\{

606: 

607: ~~print~PORTSCANS~\char`\"{}Potential~vertical~portscan~from~

608: 

609: ~~~\$lastsourceip~at~\$lasttime\textbackslash{}n\char`\"{};

610: 

611: ~\}

612: 

613: ~else~\{

614: 

615: ~~print~PORTSCANS~\char`\"{}Potential~horizontal~portscan~from

616: 

617: ~~~\$lastsourceip~at~\$lasttime\textbackslash{}n\char`\"{};

618: 

619: ~\}

620: 

621: ~print~PORTSCANS~\char`\"{}\$lastsourceip:\$lastsourceport~->

622: 

623: ~~\$lastdestip:\$lastdestport\textbackslash{}n\char`\"{};

624: 

625: ~print~PORTSCANS~\char`\"{}\$sourceip:\$sourceport~->~

626: 

627: ~~\$destip:\$destport\textbackslash{}n\char`\"{};

628: 

629: ~\}

630: 

631: ~else~\{

632: 

633: ~print~PORTSCANS~\char`\"{}\$sourceip:\$sourceport~->~

634: 

635: ~~\$destip:\$destport\textbackslash{}n\char`\"{};

636: 

637: ~\}

638: 

639: \}else~\{

640: 

641: ~~\$ongoingps~=~0;

642: 

643: ~~\}~

644: 

645: ~\}

646: 

647: ~\$counter~=~\$counter~+~1~;

648: 

649: ~if((\$counter~\%~10000)~==~0)

650: 

651: ~\{

652: 

653: ~~print~\char`\"{}\$counter\textbackslash{}n\char`\"{};

654: 

655: ~\}

656: 

657: \}

658: 

659: print~\char`\"{}\$portscans~Portscans~detected~

660: 

661: ~and~written~to~portscans\_\$infile\textbackslash{}n\char`\"{};

662: 

663: close~(INPUT);

664: 

665: close~(OUTGOING);

666: 

667: close~(INCOMING);

668: 

669: close~(VULSCANS);

670: 

671: close~(PORTSCANS);

672: 

673: close~(VULNERABILITIES);

674: \end{lyxcode}

675: \begin{thebibliography}{Ranum04}

676: \bibitem[Pre04]{Pre04}James Prewett. {}``Listening to Your Cluster With LoGS''. LCI's

677: 5th International Conference, Linux Clusters: The HPC Revolution 2004.

678: Available on WWW: http://www.linuxclustersinstitute.org/Linux-HPC-Revolution/Archive/PDF04/05-Prewett\_J.pdf 

679: \bibitem[Pre04-2]{Pre04-2}James Prewett. {}``LoGS''. January 2004. Available on WWW: http://www.hpc.unm.edu/download/LoGS.pdf

680: \bibitem[Pre05]{Pre05}James Prewett. {}``Latest real-world benchmark''. Email communication.

681: January 22, 2005.

682: \bibitem[Wei03]{Wei03}Edi Weitz, {}``CL-PPCRE Benchmarking''. December 2003. Avaliable

683: on WWW: http://www.weitz.de/cl-ppcre/\#bench.

684: \bibitem[Ranum04]{Ranum04}Marcus J. Ranum. {}``Untapped Riches''. June 2004. Information Security

685: Magazine. Available on WWW: http://infosecuritymag.techtarget.com/ss/0,295796,sid6\_iss407\_art816,00.html

686: \bibitem[Cid04]{Cid04}Daniel B. Cid. {}``Detecting Intrusions with your Firewall Log and

687: OsHids''. Relevant Technologies, January 22nd 2004. Available on

688: WWW: http://www.relevanttechnologies.com/detint\_220104.asp 

689: \bibitem[ISS98]{ISS98}{}``ISS Vulnerability Alert''. Internet Security Systems. September

690: 10th 1998. Available on WWW: http://xforce.iss.net/xforce/alerts/id/advise8 

691: \bibitem[Lis]{Lis}Kevin Liston. {}``Intrusion Detection Faq''. SANS. Available on

692: WWW: http://www.sans.org/resources/idfaq/anomaly\_detection.php\end{thebibliography}

693: 

694: \end{document}

695: