Implementing Application and Data Security
Download
Report
Transcript Implementing Application and Data Security
Implementing Application and Data
Security
Level 250
Sandeep Modhvadia
Security Technical Specialist
http://blogs.msdn.com/sandeepm
[email protected]
This Presentation Is…
…about operational security
The easy way is not always the secure way
Networks are usually designed in particular ways
In many cases, these practices simplify attacks
In some cases these practices enable attacks
In order to avoid these practices it helps to
understand how an attacker can use them
How To Get Your Application & Data
Hacked in 10 Easy Steps
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Don’t patch anything
Run unhardened applications
Run everything as a domain admin
Open lots of holes in the firewall
Allow unrestricted internal traffic
Allow all outbound traffic
Don’t harden servers
Use lame passwords
Use high-level service accounts, in multiple places
Assume everything is OK
Fundamental Tradeoff
Secure
You get to pick any two!
Usable
Cheap
The Defense-in-Depth Model
Using a layered approach:
Increases an attacker’s risk of detection
Reduces an attacker’s chance of success
Data
ACLs, encryption, EFS
Application
Application hardening, antivirus
Host
OS hardening, authentication,
patch management, HIDS
Network segments, IPSec, NIDS
Internal Network
Perimeter
Physical Security
Policies, Procedures, & Awareness
Firewalls, Network Access
Quarantine Control
Guards, locks, tracking devices
Security documents, user
education
Knocking Down The Side Door
//Three mistakes in this statement alone:
SqlConnection conn = new SqlConnection();
conn.ConnectionString =
"data source=PYN-SQL;" +
"initial catalog=pubs;" +
"user id=sa;" +
"password=password;" +
"persist security info=True;“+
"packet size=4096";
conn.Open();
//Don't do this at home folks: SQL Query Composition
string strQuery;
strQuery = "select * from Users where UserName = '" +
username.Text +
"' and Password ='" +
password.Text + "';";
But Wait It Gets Better
int rowCount = ds.Tables["Users"].Rows.Count;
if(rowCount > 0) // If we get back something...
{
//...we must be succesfully logged in
Session["LoggedIn"] = true;
// Store the username in a session variable
Session["username"] = username.Text;
...
<body>
<asp:Label id="Username" runat="server">
Label
</asp:Label>
...
private void Page_Load(object sender, System.EventArgs e)
{
...
Username.Text = Session["username"].ToString();
}
SQL Injection Best Practices
Do not trust the user’s input!
Be strict about what represents valid input and reject
everything else
Regular expressions are your friend!
Any client-side access and validity checks are performed
on the server also
Do not use string concatenation for creating
SQL statements
Use parameterized queries to build queries or SPs
Do not divulge too much information/detail to the attacker (information
disclosure)
Connect to the database server using a low-privileged account
No connections to SQL Server as sa or sysadmin role member
Secure Installation
Physical security
Protect all related systems, media, backups, etc.
Never place RDBMS unprotected on the network
Firewall protected
S/W mediating database access
Install on NTFS file system
This allows securing the files appropriately
Isolate Services
Do not install on a Domain Controller
Use low privilege service account
Do not use LocalSystem, Local (machine) or Domain Administrator
Prevents compromised database to be used to bootstrap access to rest of
enterprise
Latest code is most secure code
Apply latest service packs and security patches!
Configuration Options
Authentication Mode
Use Integrated Security (Windows Authentication)
More Secure Protocols (Kerberos and NTLM)
Kerberos allows for delegation
Allows for password policy enforcements
Typically does not require app storing passwords
If using Mixed mode (Standard SQL Authentication)
Always use SSL to encrypt at least the login packets
Use strong passwords
Never use blank passwords!
Login Auditing
At a minimum audit failed login attempts!
Disallow ad-hoc queries
Choose static ports for named instances
Avoid opening UDP1434 at firewall
Securing Mobile Messaging
Communications
Reduced exposure – Exchange FE servers are in
CorpNet rather than in the DMZ
ISA 2004 used to protect Exchange FE servers – SSL
bridging mode
Certificate on the FE server must be trusted and
“verifiable” by ISA
Internet
Clients
DMZ
SSL
ISA Server
Corporate network
SSL
Mailbox
Server
Kerberos
Exchange 2003 FE
(OWA, OMA, EAS, RPC/HTTPs)
Active
Directory
Problem – RPC Protocol
Standard Firewall Challenge
Client accesses
Client connects
application
over to
portmapper
on server
Client knows
UUID port
learned
(port 135/tcp)
of service it wants
Portmapper responds
Client asks,
“What
with the
port and closes
port is associated
the connection
with my UUID?”
4402/tcp
135/tcp
Service
234-1111…}
RPC client
(Outlook)
UUID
Port
Exchange
4402/tcp
{12341234-1111…
4402
AD replication
{01020304-4444…
3544
MMC
{19283746-7777…
RPC
9233
server
(Exchange)
Due
tomatches
the random
Server
UUID tonature of RPC, this is not feasible over
the
current port…
the
Internet
RPC services grab random
high ports
they
start,
All when
64,512
high
ports & port 135 must be opened on traditional
serverfirewalls
maintains table
E-mail Hygiene at MS IT
Anti-virus
DNS Block Lists (RBL)
Allow/Deny Lists
Safe Sender Lists
Recipient Blocking
Sender Filtering (Domain/User)
Intelligent Mail Filter
E-mail Hygiene at MS IT
Connection/Sender/Recipient Filtering
Connection filtering
Blocking by IP/subnet
Exchange 2003 based RBL filtering
Subscribing to 3rd party RBL services
Sender and Recipient Filtering
Built into Exchange 2003 – Global Setting
Criteria based
Critical to fight mail bombing attacks
6 @microsoft.com recipients resulted in a
Filtering mail for ???
10,000,000+ msg/day savings
E-mail Hygiene at MS IT
Recipient Lookup
NDR processing takes a significant amount of
resources
Recipient lookup validates recipients before
accepting messages
C:\>telnet mailserver.domain.com 25
…
MAIL FROM:<>
250 2.1.0 <>....Sender OK
RCPT TO: <[email protected]>
550 5.1.1 User unknown
QUIT
Result: No message payload is transmitted –
savings in performance
Hardening Exchange
Exchange 2003 “Secure by default” examples
Legacy protocols (POP3/IMAP4) are disabled
OMA is disabled
OWA password changes are off
Kerberos authentication between OWA FE and BE
Anonymous SMTP relaying is off
Top Level Public Folders are locked down
10MB message limits
Tightened permissions
Watch for upgrade scenarios!
Existing settings are often not changed
BPA
Using IPSEC for Exchange
IPSEC was essential to secure Exchange 2000 FE-to-BE
OWA transactions in MS IT environment
IPSEC policies example
Exchange FE: meany; TCP any80; Encrypt (Kerberos)
Exchange BE: Respond only
You can be really creative with IPSEC if “block on fail” is needed
Use GPO to apply IPSEC policies by server role
Exchange 2003 FE-to-BE uses Kerberos authentication
User credentials are encrypted by default
IPSEC is still possible to protect data traveling between FE and BE,
but beware of data exposure at the next hop (SMTP)
Signing & Encrypting Email
Internal / External Considerations
Rights Management Server
Outlook Web Access
Smartcards
Small Business Server
Service Pack 1
ISA Server 2004
SUS / WUS
SBS Group Policy
© 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only.
MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.