Hangt er ten eerste vanaf of je je datetime nu anders opslaat ( dus dat je dbase er iets mee kan ) en hoeveel keer per x tijd noem jij portscanning. Ff uitgaand van 25 keer per poort per dag en in mysql ( uit mijn hoofd, dus verfijning mag je zelf doen en uitgaande van bestaand timeformat, met alleen vandaag in je report, gesorteerd per dst_ip/src_ip/aantal keren aangeklopt )
code:
1
2
3
4
5
6
| select dst_ip,src_ip, dst_port, src_port, service,count(unique(dst_port)) as portknocking, count(src_ip) as numberintruders
from x
where right(timestamp,4)=right(now(),4)
group by src_ip, dst_port
having portknocking>25 and numberitrintuders=1
order by dst_ip asc, src_ip asc, portknocking desc |
Maar dit soort knullige sql komt voornamelijk doordat ik je tabel niet helemaal snap. Je timestamp gaat hooguit per minuut??? En je hebt er een aantal instaan???
Wat gebeurt er nu als ik op 2 ips jouw server ga portscannen tegelijk, krijg ik nu om en om een melding dat er 1 ip een port scant ( 100x per minuut ofzo maar aantal is 1 dus 100 logentries in 1 minuut allemaal aantal 1 en dan vanaf 2 ips ) of krijg ik per minuut 1 regel met gescande ports en aantal keren geprobeerd per ip ( dus 100x per minuut levert 2 logregels op met 100 poorten per regel en aantal 100x ).
Maar zowieso zou ik elke attempt los loggen in je dbase. dus geen aantal attempts, maar 3 attempts is 3 records. en dan wel met een timestamp in millisec, want per minuut is onnauwkeurig en onhandelbaar. Per keer loggen dan kan je dbase engine wel counten hoeveel keer het per minuut war ( maar je kan nu nog steeds een detaillistisch rapport maken wat er in die minuut gebeurde ).
Trekt je dbase engine het niet om realtime rapporten te maken vanuit je logtabel dan kan je nog steeds 1x per minuten een cronjob draaien die in een 2e tabel je gegevens per 5 minuten totaliseert,
Trekt je schijfruimte het niet om een hele logtabel van 2 dagen op te slaan, dan kan je alsnog 1x per 24 uur een cronjob draaien die uit je originele logtabel alle historische records verwijdert ( historisch is hier ouder dan 24 uur )
Maar je kan nog steeds ten alle tijden de makkelijke rapportage ophalen uit tabel 2 ( gevuld door cronjob per x minuten ) en vanuit daar inzoomen op de echte tabel per x minuten zodat je de echte gegevens ziet.
In de huidige methode zie ik alleen een mogelijkheid om het aantal te summen en dan te filteren, maar 3x een telnet poort scannen binnen 1 minuut doe ik nog wel met de hand.
En waarom moetn het opeenvolgende poorten zijn??? Ik heb ooit eens een primitieve portscanner geschreven die juist niet opeenvolgende poorten scande omdat firewalls hier toendertijd juist gek van werden. ( was toendertijd script om te kijken of een server up was, maar eerst poort 25, toen 80, toen 110, toen 443, toen 8080 leverde een beetje veel meldingen van klanten op, dus toen de volgorde maar random gemaakt ( en wat poorten toegevoegd later ))
En ik zou ook verwachten dat een huidige portscanner niet meer op volgorde scant, maar meer op prioriteit ( eerst icmp ( een computer is online, daarna tcp/80( een webserver is online) daarna tcp/p2p poorten ( waarschijnlijk een home computer), daarna tcp/21 ( ftp server is online ), daarna tcp/25 ( mailserver is online, gecombineerd met tcp/80, tcp/21 gok ik dat het een interessante computer is ), daarna tcp/23 ( telnet ook nog, waarschijnlijk een *nix server ), dan tcp/22 voor ssh dan tcp/443 voor https.
Uitgaande van opeenvolgende poorten zie jij deze portscan waarschijnlijk niet, maar uitgaande van priotiteiten dat ik servers zoek krijg je het volgende rijtje :
Geen icmp, geen tcp/80 wel p2p poorten : Home computer met een firewall, give up
Wel icmp, wel tcp/80, geen p2p poorten, geen tcp/21, geen tcp/25 wel tcp/23 : Waarschijnlijk een webserver met telnet toegang.
:strip_exif()/u/75345/1041192609.gif?f=community)
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)