2007 byggde jag ett system som är till för att hålla reda på vart i världen ett transportföretags containers och containertrailers håller till. Samt bokning av kontainers, traliers och utskrift av alla transportdokument och tulldeklarationer som behövs. Det är tillgängligt för transportföretagets alla agenter runt om i världen. De är ett ganska omfattande system skrivet i ASP mot SQL. Allt kördes via Loopia.
Problemet är att Loopia kommer att sluta stöda ASP vid årsskiftet. Vad göra? Det är samma med Binero och man kan säkert förvänta sig att det så småningom försvinner helt hos alla hotell. Någon egen server är inte aktuell.
Vilken plattform torde vara enklast att migrera till. PHP och mySQL ligger ju ganska nära att gå till? Eller finns det något riktigt enkelt och modernt verktyg man kan skriva om alltihop med. Det rör sig om circus 100 filer som måste skrivas om.
Enda trösten är att detta kommer att bli min sysselsättning i Västindien i vinter.
Senast redigerad av SeniorLemuren 22 augusti 2015, 12:49:44, redigerad totalt 1 gång.
Till att börja med kan jag ju tycka att du får skylla dig själv som nyutvecklade i ASP när den senaste versionen kom år 2000, och långt innan 2007 var all form av utveckling av ASP nedlagd ifrån Microsofts sida...
Hur som haver, det som ligger närmast till hands borde rimligtvis vara ASP.NET, förslagsvis med C#, men VB.NET om du känner dig mer bekväm med den syntaxen.
Byt leverantör till en som stödjer asp. Microsoft har lovat att det fungerar i IIS till minst 2024. Efter det kommer det fortfarande gå utmärkt att köra i linux apache+mono.
Misstänker att det är färre och färre som vill ha med ASP att göra, om jag inte har helt fel så är ASP.NET betydligt enklare att ha att göra med i webbhotellsmiljö, så jag kan tänka mig att det är en stor anledning till att de gärna släpper stödet för ASP då det innebär en del säkerhetsproblematik. (Så skulle jag nog också gjort, om det inte fanns en väldigt stor efterfrågan dvs.)
Nackdelen med virtuell maskin är att man själv behöver ha tillräcklig koll på säkerheten. Det är inte omöjligt att sätta upp en egen server med tillräcklig säkerhet, men det kräver en del inläsning och eftertanke.
Jag satte ju upp en egen exponerad server för att testa förut (den satte jag upp på en överbliven burk hemma och anslöt direkt till ett av uttagen på "fiberswitchen" så den fick egen publik IP-adress). Det syntes i loggarna att det blev en hel del försök att ta sig in, men just att det syntes i loggarna betydde ju att jag hade koll på det. Gäller att ha vettiga övervakningsverktyg så man ser om saker ändrar sig. Och framförallt verktyg som gör att man inte behöver sitta och plöja långa loggfiler varje dag utan mer att man får meddelande när nåt ändrar sig eller att man kan se trender i grafer.
Du är bakom brandväggar i IaaS-tjänsterna.
Din virtuella maskin får en publik IP-adress (VIP-address) utanför brandväggen och har en lokal IP-adress internt innanför brandväggen (DIP-address).
Det ingår i IaaS-tjänsten att du själv kan konfigurera dina brandväggsregler, inte bara adressöversättning utan även vilka publika nät som ska få access in: https://azure.microsoft.com/sv-se/docum ... endpoints/
Om du anslöt en dator rått mot Internet så finns det bara en person att skylla för det beslutet.
Det är bara att se till att inga tjänster körs som inte behöver vara igång och sen stänger men alla portar utom de som behöver vara öppna.
Jag har skrivit ihop en instruktion, första stegen är att installera Debian (enbart Base), ufw och ssh, stänga alla portar utom 22 och slå av möjlighet att logga in via ssh med root-kontot. Det är det som behöver göras lokalt, sen kan resten göras remote och man öppnar bara de portar som behöver vara öppna.
Att nån försöker hacka sig in genom en stängd port är minsta problemet ur säkerhetssynpunkt, det stora problemet är att de tjänster som behöver vara öppna utåt har brister som gör att det går att ta sig in. Finns inga som helst problem med att sätta en burk direkt på internet om alla portar är stängda. Varenda router och brandvägg sitter ju "direkt på internet" och de är ju en burk som alla andra.
Jag testade för att se hur svårt det var. Googlade först efter en massa sidor med olika tips och plockade sen ihop godbitarna så att säga.
Så länge man inte kommer att ha en massa lokala användare som är inloggade så går det att tajta ner rätt bra.
Att tro att man är skyddad bara för att man sitter bakom en brandvägg är rätt naivt, en brandvägg hindrar inte nån från att t.ex. trycka in ett rootkit via nåt säkerhetshål i webservern.
Nu när jag är hemma har jag tillgång till mina nerskrivna instruktioner från installationen av den där burken (jag skrev ner en summering av det jag googlade fram och sen vartefter jag installerade så fyllde jag på med mer detaljer).
ufw för enkel hantering av iptables. Numera finns utöver iptables även ipset som gör att man kan ha mer filter utan att tappa för mycket prestanda, men jag började aldrig testa med ipset på den burken. Med ipset så kan man t.ex. redan från scratch spärra uppkopplingar från diverse svartlistor (om man spärra t.ex. proxies eller kända spammare).
ssh för remote access, stäng av att root kan logga in (då måste en angripare först knäcka ett vanligt konto och sen root-lösen).
Ett smart knep är dessutom att stänga av inloggning med lösenord. Då måste en användare logga in med nyckel först, lösenordet används bara för sudo (för de som är sudoers). Det är dock lite vanskligt om man själv är enda användare på maskinen, ett lösenord kan man komma ihåg men en nyckel kan tappas bort.
fail2ban, som i det här läget främst syftar till att bromsa intrångsförsök via ssh (eftersom just nu är inget annat öppet).
Se till att bara användare i gruppen wheel kan köra su (görs i konfigurationen av pam).
Sen är det bra att sätta rätt options för shared memory, noexec och nosuid.
I sysctl.conf finns det en del grejer att tweaka också, men installation av ufw fixar de flesta av de grejerna. Handlar mycket om att bromsa dos-attacker (strunta i att svara på vissa typer av paket).
Apparmor för att minska risken med trojaner eller utbytta programfiler. Apparmor ligger i kerneln och är i princip en databas över vad olika program ska få göra. Om ett program plötsligt gör nåt som det inte ska får man direkt en varning.
Sen körde jag psad och rkhunter, använda dessutom logcheck (tillsammans med ett gäng egna filter) för att få varningar om konstigheter i loggfiler. Logcheck tog det ett par veckor att få "lagom pratsam".
Nagios med nagios-grapher tyckte jag var smidigt också, jag gjorde en hel massa egna script till dessa så jag t.ex. fick graf över antalet ip-adresser fail2ban bannade över tiden, grafer över ledigt utrymme på disken, CPU-last, diskutrymme, antal inkommande mail och massa sånt. Nagios har ju tröskelvärden man ställer in men graferna gör att man på ett bra sätt ser trender även om de inte kommit över tröskelvärdena.
Sen ska ju webserver, mysql och såna grejer in och säkras också (och portar eventuellt öppnas). Jag tillät i princip bara okrypterad trafik för inkommande SMTP. I stort sett alla grejer som kördes på Apache låg tvingade på ssl, IMAP och autentiserad SMTP (d.v.s. egna användare) var tvingat till tls, POP3 körde jag inte öht.
Backup bör man ju ha också, jag höll reda på vilka filer jag ändrade under installationen och var de låg, på så vis hade jag koll på vad som behöver backas upp och vad som kommer inte automatiskt vid ominstallation. Fast har man en virtuell maskin så brukar väl leverantören erbjuda snapshots av diskimagen så då är det inte lika viktigt. Jag körde med backup-ninja eftersom den är modulär.
Det är som sagt var inte "raketkirurgi", men det är en del att sätta sig in i. Har man lite intresse så är det inte svårt, men vill man bara att grejerna ska fungera är det kan ske bättre att "hyra" säkerheten.
